Meta เปิดตัว ZGateway: พร็อกซีไร้สถานะจัดการทราฟฟิก ZippyDB
Meta เปิดตัว ZGateway ชั้นพร็อกซีไร้สถานะเพื่อรวมทราฟฟิก ZippyDB รองรับการทำงานมากกว่า 1 พันล้านครั้งต่อวินาที พร้อมลดภาระการเชื่อมต่อของเซิร์ฟเวอร์
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- Meta เปิดตัว ZGateway ชั้นพร็อกซีไร้สถานะสำหรับ ZippyDB
- รองรับการดำเนินงานมากกว่า 1 พันล้านครั้งต่อวินาที
- แบกรับทราฟฟิกราว 40% และคาดว่าจะเพิ่มขึ้นเกิน 60%
- ช่วยแก้ปัญหาการเชื่อมต่อ TLS ล้นและลดความเสี่ยงระบบล่ม
ในอดีตสถาปัตยกรรมแบบเข้าถึงโดยตรงทำให้ไคลเอนต์ ZippyDB ทุกตัวต้องเชื่อมต่อไปยังโฮสต์ฐานข้อมูลที่จำเป็นทั้งหมด ส่งผลให้ไคลเอนต์หนึ่งตัวสามารถแตะต้องชาร์ดนับหมื่นรายการบนโฮสต์นับแสนแห่งได้ ทำให้ทั้งไคลเอนต์ทั่วไปและโฮสต์ฐานข้อมูลต้องแบกรับการเชื่อมต่อแบบ TLS นับหมื่นรายการ การเชื่อมต่อที่ไม่ได้ใช้งานเหล่านี้สิ้นเปลืองทั้งหน่วยความจำ ซีพียู และฟายล์ดิสคริปเตอร์ (file descriptor) ทั้งสองฝั่ง นอกจากนี้พายุการเชื่อมต่อใหม่ (reconnection storms) ยังเคยทำให้ระบบล่มจากปัญหาฟายล์ดิสคริปเตอร์หมดและการใช้หน่วยความจำเกิน (OOMs) เช่น ในเหตุการณ์ที่ข้อผิดพลาดในการกำหนดเส้นทางทำให้ไคลเอนต์เปิดการเชื่อมต่อหนึ่งรายการต่อหนึ่งชาร์ดจนทำให้กลุ่มเซิร์ฟเวอร์วนลูปรีบูต การแก้ไขปัญหาที่ฝั่งไคลเอนต์นั้นทำได้ยากเนื่องจากมีทีมงานหลายร้อยทีมเป็นเจ้าของกลุ่มไคลเอนต์เหล่านี้
เพื่อแก้ปัญหาดังกล่าว Meta จึงได้พัฒนา ZGateway ซึ่งทำหน้าที่เป็นชั้นพร็อกซีไร้สถานะ (stateless proxy tier) วางอยู่ระหว่างไคลเอนต์ ZippyDB และกลุ่มฐานข้อมูล ZServer โดยจากข้อมูลของ Meta ระบุว่าระบบนี้สามารถจัดการการดำเนินงานได้มากกว่า 1 พันล้านครั้งต่อวินาที และรองรับทราฟฟิกของ ZippyDB อยู่ที่ประมาณ 40% โดยมีการคาดการณ์ว่าจะเพิ่มขึ้นทะลุ 60% ด้วยค่าใช้จ่ายด้านการประมวลผลประมาณ 6% สำหรับการใช้งานทั่วไป
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ระบบนี้ทำงานเป็นระดับภูมิภาคผ่านการค้นหาผ่าน ServiceRouter ซึ่งเป็น service mesh ของ Meta โดยมีให้เลือกใช้งานใน 2 รูปแบบ ได้แก่ พร็อกซีแบบบริสุทธิ์ (pure proxy) และแคชแบบอ่านผ่าน (read-through cache) ตัวเอนจิ้นเบื้องหลังคือไคลเอนต์ C++ แบบหนาของ ZippyDB ทำให้ ZGateway เปรียบเสมือนไคลเอนต์ ZippyDB ที่ทำงานเป็นบริการแบบจัดการ (managed service)
การใช้พร็อกซีไร้สถานะ (stateless proxy) ในสถาปัตยกรรมฐานข้อมูลขนาดใหญ่เช่นนี้ ช่วยลดความซับซ้อนในการจัดการการเชื่อมต่อระดับมหภาคได้อย่างมีประสิทธิภาพ แทนที่จะปล่อยให้ไคลเอนต์นับล้านตัวเชื่อมต่อตรงกับโฮสต์ฐานข้อมูลนับแสนแห่ง ซึ่งเสี่ยงต่อปัญหาการจัดการทรัพยากรฮาร์ดแวร์ การมีชั้นกลางคอยพักและจัดระเบียบคำขอ (Pooling และ Batching) ช่วยให้ระบบมีความยืดหยุ่นและรองรับปริมาณงานมหาศาลของบริการระดับโลกอย่าง Meta ได้อย่างเสถียร
กระบวนการทำงานเริ่มต้นเมื่อไคลเอนต์ส่งคำขอผ่านการเชื่อมต่อแบบ sticky ไปยังโฮสต์ ZGateway ในภูมิภาค ซึ่งจะทำหน้าที่ยุติการเชื่อมต่อ TLS ตรวจสอบสิทธิ์กับ ACL ของการใช้งาน ควบคุมการเข้าถึงและการจัดระเบียบตามผู้เช่า (tenant) แก้ไขตำแหน่งชาร์ด ตรวจสอบแคชในระดับแคชเชียง (caching tiers) ทำการรวมคำขอ (batching) กับคำขออื่นๆ ที่กำลังดำเนินการสำหรับชาร์ดนั้น และส่งต่อสำเนาที่ถูกต้องไปยังรีพลีกาที่เกี่ยวข้อง จากนั้นจึงทำการแยกสัญญาณตอบกลับ (demultiplex) พร้อมบันทึกเมตริก ร่องรอย (traces) และการใช้งานโควต้าตามการใช้งานแต่ละประเภท โดยที่ TLS ยังคงอยู่ภายในสแต็ก Thrift / ServiceRouter และการเลือกจำลองยังคงอยู่ภายในไคลเอนต์ที่ฝังอยู่
ที่มา: MarkTechPost
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น