การย้ายข้อมูลบัญชีแยกประเภทของ Uber จาก DynamoDB ไปยัง LedgerStore

 (uber.com)
2 คะแนน โดย GN⁺ 2024-05-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • สัปดาห์ที่แล้วเราได้สำรวจ LedgerStore (LSG) ซึ่งเป็นฐานข้อมูลสไตล์บัญชีแยกประเภทแบบเขียนต่อท้ายโดยเฉพาะของ Uber
  • สัปดาห์นี้จะพูดถึงวิธีที่ Uber ย้ายข้อมูลบัญชีแยกประเภทซึ่งมีความสำคัญต่อธุรกิจไปยัง LSG
  • กล่าวถึงวิธีการย้ายรายการมากกว่า 1 ล้านล้านรายการ (ข้อมูลหลายเพตะไบต์) อย่างโปร่งใสโดยไม่มีการหยุดชะงัก พร้อมบทเรียนที่ได้จากกระบวนการนี้

ประวัติ

  • Gulfstream คือแพลตฟอร์มการชำระเงินของ Uber และเปิดตัวในปี 2017 โดยใช้ DynamoDB
  • ที่สเกลของ Uber การใช้ DynamoDB มีค่าใช้จ่ายสูงขึ้น จึงเริ่มเก็บข้อมูลเพียง 12 สัปดาห์ (hot data) ไว้ใน DynamoDB และย้ายข้อมูลเก่า (cold data) ไปเก็บใน TerraBlob ซึ่งเป็น blobstore ของ Uber
  • ในระยะยาว Uber ต้องการใช้ LSG เป็นโซลูชัน โดย LSG ถูกออกแบบมาเฉพาะสำหรับการจัดเก็บข้อมูลสไตล์การชำระเงิน
  • ความสามารถหลักของ LSG:
    • ความไม่เปลี่ยนแปลงที่ตรวจสอบได้ (สามารถยืนยันได้ด้วยลายเซ็นเข้ารหัสว่าเรคคอร์ดไม่ได้ถูกแก้ไข)
    • การจัดเก็บแบบแบ่งชั้นเพื่อควบคุมต้นทุน (hot data อยู่ในที่ที่เหมาะกับการให้บริการคำขอ ส่วน cold data อยู่ในที่ที่เหมาะกับการจัดเก็บ)
    • ปรับปรุง latency ของ secondary index ที่มีความสอดคล้องในท้ายที่สุด
  • ภายในปี 2021 Gulfstream ใช้การผสมกันของ DynamoDB, TerraBlob และ LSG ในการจัดเก็บข้อมูล
    • DynamoDB: ข้อมูลล่าสุด 12 สัปดาห์
    • TerraBlob: cold data
    • LSG: ปลายทางที่ใช้บันทึกข้อมูลและเป็นเป้าหมายของการย้ายข้อมูล

ทำไมต้องย้ายข้อมูล?

  • LSG เหมาะกับการเก็บข้อมูลสไตล์บัญชีแยกประเภทมากกว่า เนื่องจากมีคุณสมบัติความไม่เปลี่ยนแปลง
  • การย้ายไปยัง LSG ช่วยลดค่าใช้จ่ายแบบต่อเนื่องได้อย่างมาก
  • การเปลี่ยนจากสตอเรจ 3 แห่งมาเป็น 1 แห่งช่วยทำให้โค้ดและสถาปัตยกรรมของบริการ Gulfstream เรียบง่ายขึ้น
  • LSG ให้คำมั่นเรื่อง latency ของการทำดัชนีที่สั้นลง และเนื่องจากรันแบบ on-premise ภายในดาต้าเซ็นเตอร์ของ Uber จึงให้ network latency ที่เร็วกว่า

ความเสี่ยงที่เกี่ยวข้องกับลักษณะของข้อมูล

  • ข้อมูลที่ย้ายคือข้อมูลบัญชีแยกประเภททางธุรกิจทั้งหมดของ Uber ตั้งแต่ปี 2017:
    • บันทึกแบบ immutable: ขนาดหลังบีบอัด 1.2 PB
    • secondary index: ขนาดไม่บีบอัด 0.5 PB
  • บันทึกแบบ immutable ไม่สามารถแก้ไขได้ ขณะที่ข้อมูล secondary index มีความยืดหยุ่นให้แก้ไขได้เมื่อจำเป็นต้องแก้ปัญหา

การตรวจสอบความถูกต้อง

  • เพื่อให้มั่นใจว่า backfill ถูกต้องและยอมรับได้ในทุกด้าน จำเป็นต้องตรวจสอบทั้งความสามารถในการรองรับทราฟฟิกปัจจุบัน และความถูกต้องของข้อมูลที่ไม่ได้ถูกเข้าถึงอยู่ในตอนนี้
  • เกณฑ์การตรวจสอบ:
    • ความครบถ้วน: ทุกเรคคอร์ดถูก backfill แล้วหรือไม่
    • ความถูกต้อง: ทุกเรคคอร์ดถูกต้องหรือไม่
    • โหลด: LSG รองรับโหลดปัจจุบันได้หรือไม่
    • latency: ค่า P99 latency ของ LSG อยู่ในช่วงที่ยอมรับได้หรือไม่
    • ความหน่วง: latency ของการสร้าง secondary index อยู่ในช่วงที่ยอมรับได้หรือไม่

Shadow validation

  • เปรียบเทียบการตอบกลับก่อนและหลังการย้ายข้อมูล เพื่อให้แน่ใจว่าทราฟฟิกปัจจุบันจะไม่ถูกรบกวนจากปัญหาการย้ายข้อมูลหรือบั๊กในโค้ด
  • ผ่าน shadow validation Uber ยืนยันได้ว่า backfill มีความครบถ้วนและถูกต้องอย่างน้อย 99.99% โดยตั้งเพดานบนไว้ที่ 99.9999%
  • Shadow validation ช่วยยืนยันว่า LSG สามารถรองรับ production traffic ได้ และเพิ่มความเชื่อมั่นต่อโค้ดสำหรับเข้าถึงข้อมูล
  • Shadow validation ยังเพิ่มความเชื่อมั่นต่อความครบถ้วนและความถูกต้องของข้อมูลที่กำลังถูกเข้าถึงอยู่ในปัจจุบัน

การตรวจสอบแบบออฟไลน์และ incremental backfill

  • เปรียบเทียบข้อมูลทั้งหมดใน LSG กับ data dump จาก DynamoDB
  • การตรวจสอบแบบออฟไลน์ช่วยยืนยันว่า data backfill ถูกดำเนินการอย่างถูกต้อง และครอบคลุมข้อมูลทั้งหมด
  • การตรวจสอบแบบออฟไลน์ควรทำควบคู่ไปกับ shadow validation

ปัญหาในการทำ backfill

  • การทำ backfill ทุกครั้งมีความเสี่ยง Uber ใช้ Apache Spark ในการทำ backfill
  • วิธีรับมือกับปัญหา:
    • การขยายสเกล: เริ่มจากขนาดเล็กแล้วค่อย ๆ ขยาย
    • incremental backfill: แบ่งข้อมูลเป็นแบตช์เล็ก ๆ แล้วทำ backfill
    • การควบคุมความเร็ว: ปรับอัตราความเร็วของงาน backfill
    • การควบคุมความเร็วแบบไดนามิก: ปรับความเร็วตามการติดตามสถานะปัจจุบันของระบบ
    • การหยุดฉุกเฉิน: มีความสามารถในการหยุด backfill ได้อย่างรวดเร็วหากสงสัยว่าระบบโอเวอร์โหลด
    • ขนาดไฟล์ข้อมูล: รักษาขนาดไฟล์ data dump ให้อยู่ในระดับที่เหมาะสม
    • ความทนทานต่อความผิดพลาด: รับมือกับปัญหาคุณภาพ/ความเสียหายของข้อมูล
    • การทำล็อก: จำกัดปริมาณล็อกเพื่อไม่ให้สร้างภาระกับโครงสร้างพื้นฐานด้าน logging

การลดความเสี่ยง

  • วิเคราะห์ข้อมูลจากสถิติการตรวจสอบและ backfill หลากหลายรูปแบบ และค่อย ๆ rollout LSG อย่างระมัดระวัง
  • ในช่วงแรก ใช้ fallback เพื่อดึงข้อมูลจาก DynamoDB หาก backfill ล้มเหลว
  • ตรวจสอบ fallback log เพื่อยืนยันว่าไม่ได้มีข้อมูลหายไปจาก LSG จริง ๆ

บทสรุป

  • บทความนี้กล่าวถึงกระบวนการย้ายข้อมูลบัญชีแยกประเภทที่สำคัญต่อธุรกิจในระดับขนาดใหญ่จาก data store หนึ่งไปยังอีก data store หนึ่ง
  • ครอบคลุมหลายแง่มุม เช่น เกณฑ์การย้ายข้อมูล การตรวจสอบความถูกต้อง ปัญหาในการทำ backfill และความปลอดภัย
  • การย้ายข้อมูลเสร็จสมบูรณ์ภายใน 2 ปี โดยไม่มีการหยุดชะงักหรือเหตุขัดข้อง

ความเห็นของ GN⁺

  • ความสำคัญของการย้ายข้อมูล: การย้ายข้อมูลขนาดใหญ่มีความซับซ้อนและมีความเสี่ยง แต่ให้ประโยชน์ระยะยาวอย่างมากผ่านการลดต้นทุนและการทำให้ระบบเรียบง่ายขึ้น
  • ประโยชน์ของ shadow validation: Shadow validation เป็นเครื่องมือทรงพลังที่ช่วยตรวจสอบความครบถ้วนและความถูกต้องของข้อมูลได้โดยไม่กระทบต่อทราฟฟิกจริง
  • ความจำเป็นของการตรวจสอบแบบออฟไลน์: การตรวจสอบแบบออฟไลน์เป็นสิ่งจำเป็น เพราะสามารถค้นหาปัญหาที่ shadow validation เพียงอย่างเดียวอาจไม่พบ
  • แนวทางแบบค่อยเป็นค่อยไปของ backfill: การแบ่งงาน backfill เป็นแบตช์เล็ก ๆ และทำอย่างเป็นขั้นตอนมีประสิทธิภาพในการป้องกันระบบโอเวอร์โหลด
  • ความสามารถในการหยุดฉุกเฉิน: ความสามารถในการหยุดงาน backfill ได้อย่างรวดเร็วเมื่อเกิดปัญหาเป็นสิ่งสำคัญต่อการรักษาเสถียรภาพของระบบ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-21
ความเห็นบน Hacker News

สรุปรวมคอมเมนต์จาก Hacker News

  • 2 billion rides per quarter

    • Uber รองรับการเดินทาง 2 พันล้านครั้งต่อไตรมาส ซึ่งเทียบได้กับธุรกรรมราว 1,000 รายการต่อวินาที จึงทำให้เข้าใจได้ยากว่าทำไมต้องกังวลเรื่องการขยายอินฟราสตรักเจอร์ขนาดนั้น

  • Using DynamoDB poorly

    • Uber ใช้ DynamoDB ได้ไม่ดีนัก โดยเส้นทางการใช้งานสำคัญของผู้ใช้บางส่วน (CUJ) ต้องการความสอดคล้องแบบเข้มงวด และยังต้องมี data warehousing สำหรับธุรกรรมย้อนหลังด้วย จึงแปลกที่ไม่ได้เปลี่ยนไปใช้สถาปัตยกรรม DynamoDB และ Redshift

  • Google rejects

    • ดูเหมือน Uber จะหยิบโครงการที่ล้มเหลวจาก Google มาใช้ โครงการแบบนี้มักมีเป้าหมายเพื่อการเลื่อนตำแหน่งใหญ่ ๆ ประมาณว่า "ออกแบบและสร้างระบบของตัวเอง ประหยัดไป $Xm! โปรดเลื่อนตำแหน่งให้ฉัน!" แต่ต้นทุนการสร้างกลับสูงกว่า และอีกไม่กี่ปีก็มีโอกาสถูกทิ้ง

  • SQLite on a single server

    • สงสัยว่าจะเก็บข้อมูลขนาด 1.7 เพตะไบต์ (ระเบียนที่ทำดัชนีไว้ 1 ล้านล้านรายการ) ลงใน SQLite บนเซิร์ฟเวอร์ bare metal ประสิทธิภาพสูงเพียงเครื่องเดียวได้หรือไม่ พร้อมแนบลิงก์ตัวอย่าง

  • LedgerStore not open source

    • LedgerStore ไม่ได้เป็นโอเพนซอร์ส ถ้าจะหาข้อมูลที่เกี่ยวข้องต้องตามไปดูโพสต์ในบล็อกของ Uber และมีลิงก์ไปยังโพสต์จากปี 2021 ให้ด้วย

  • Era of custom infrastructure

    • ราวปี 2015 บริษัทเทคจำนวนมากอย่าง Netflix, Spotify, SoundCloud และ Uber สร้างเครื่องมือด้านอินฟราสตรักเจอร์และฐานข้อมูลกันเยอะมาก ทุกวันนี้วิศวกรจำนวนมากพูดกันด้วยศัพท์แบบ AWS/คลาวด์ การได้เห็นองค์กรที่ยังสร้างเครื่องมือเองจึงยังรู้สึกสดใหม่

  • Expensive proprietary cloud

    • นี่เป็นตัวอย่างที่ชัดเจนว่าดาต้าสโตร์บนคลาวด์แบบ proprietary มีราคาแพงแค่ไหน และการย้ายไปอย่างอื่นก็เป็นไปได้

  • Considered TigerBeetle?

    • สงสัยว่าได้พิจารณา TigerBeetle หรือไม่

  • DynamoDB is expensive

    • ไม่แน่ใจเรื่องความคุ้มค่าทางเศรษฐศาสตร์ของโครงการนี้ แต่ DynamoDB แพงมาก เคยคิดว่าคนอื่นแค่ใช้งานผิดวิธี แต่แม้จะใช้เป็น distributed hash table ก็ยังมีต้นทุนสูงอยู่ดี

  • Cost of running the team

    • ดูเหมือนต้นทุนในการดูแลทีมโครงการอาจไม่ได้ต่างจากเงินที่ประหยัดได้มากนัก ($6 ล้าน) และยังมีค่าบำรุงรักษาเพิ่มเข้ามาอีก ระบบชำระเงินอาจไม่ใช่การเดิมพันระยะยาว จึงน่าสนใจว่าทำไมถึงทำโครงการนี้ บางทีอาจเป็น sunk cost ที่ผูกกับทีมวิศวกรรมที่มีอยู่แล้ว