Meta เปิดตัว ZGateway: ระบบ Proxy ไร้สถานะ รองรับ Traffic กว่า 1 พันล้านครั้งต่อวินาที

ทีมวิศวกรของ Meta ได้เปิดตัว ZGateway ซึ่งเป็น Proxy Tier ที่เข้ามาคั่นกลางระหว่างแอปพลิเคชันฝั่ง Client และ ZippyDB ซึ่งเป็น Key Value Store ที่ถูกใช้งานมากที่สุดในองค์กร

ปัจจุบัน ZippyDB ทำหน้าที่รองรับข้อมูล Metadata ของผลิตภัณฑ์, ตัวนับ (Counters) และการตั้งค่าต่างๆ ด้วยความเร็วระดับหลายพันล้านครั้งต่อวินาที โดย ZGateway เริ่มต้นจากการเป็นวิธีแก้ปัญหาการแพร่กระจายของการเชื่อมต่อ (Connection Sprawl) ในโฮสต์ของ Client กว่าล้านเครื่อง ก่อนจะพัฒนาไปสู่การเป็นศูนย์กลางสำหรับทำ Batching, Admission Control, Caching และ Failover

ทำไม ZippyDB ถึงต้องการ Proxy

ภายใต้การเข้าถึงโดยตรง (Direct Access) แบบเดิม Client ของ ZippyDB ทุกตัวต้องเชื่อมต่อกับทุก Database Host ที่ต้องการ ซึ่ง Client เพียงตัวเดียวอาจต้องเข้าถึง Shard นับหมื่นรายการในโฮสต์หลายแสนเครื่อง ส่งผลให้ทั้งฝั่ง Client และ Database Host ต้องแบกรับการเชื่อมต่อ TLS จำนวนมหาศาล

การเชื่อมต่อที่ค้างไว้โดยไม่ได้ใช้งานจะสิ้นเปลืองหน่วยความจำ, CPU และ File Descriptor ของทั้งสองฝั่ง และหากมีกลุ่ม Client เพิ่มขึ้น จำนวนการเชื่อมต่อขาเข้าก็จะยิ่งพุ่งสูงขึ้น จนอาจเกิดเหตุการณ์พายุการเชื่อมต่อใหม่ (Reconnection Storms) ที่ทำให้ระบบแครชจากการใช้ File Descriptor จนหมดหรือเกิดปัญหาหน่วยความจำเต็ม (OOM) การแก้ไขที่ฝั่ง Client ทำได้ยากมากเพราะมีทีมงานหลายร้อยทีมดูแล Client ที่แตกต่างกันออกไป

ZGateway คืออะไร

ZGateway คือ Stateless Proxy Tier ที่วางอยู่ระหว่าง Client ของ ZippyDB และกลุ่มฐานข้อมูล ZServer ปัจจุบันรองรับการทำงานได้มากกว่า 1 พันล้านครั้งต่อวินาที และรับ Traffic ของ ZippyDB ไปแล้วประมาณ 40% โดยคาดว่าจะเพิ่มขึ้นเกิน 60% ในอนาคต ซึ่งพบว่ามีค่า Overhead ในการประมวลผลเพียง 6% สำหรับการใช้งานทั่วไป

ระบบทำงานในรูปแบบ Regional Tier ผ่าน ServiceRouter ซึ่งเป็น Service Mesh ของ Meta โดยรองรับทั้งรูปแบบ Pure Proxy และ Read-through Cache ตัว Engine หลักพัฒนาด้วยภาษา C++ ที่มีประสิทธิภาพสูง ทำให้ ZGateway ทำหน้าที่เป็น ZippyDB Client ในรูปแบบ Managed Service ได้อย่างสมบูรณ์

กระบวนการทำงานเริ่มจาก Client ส่งคำขอผ่าน Sticky Connection ไปยังโฮสต์ ZGateway ประจำภูมิภาค เพื่อทำการ Terminate TLS, ตรวจสอบสิทธิ์ (ACL), ควบคุม Traffic (Shaping) แยกตามรายผู้เช่า (Tenant) และระบุ Shard ที่ถูกต้อง นอกจากนี้ยังตรวจสอบ Local Cache และทำ Batching คำขอเพื่อส่งต่อไปยัง Replica ที่เหมาะสม โดยระบบจะส่งการตอบกลับคืนแบบ Demultiplex พร้อมบันทึก Metrics และ Trace การใช้งานอย่างละเอียด

คณิตศาสตร์ของ Fan-In และ Fan-Out

Meta จำลองการทำงานของระบบนี้เหมือนการโยนลูกบอลลงถัง เพื่อคำนวณโอกาสที่โฮสต์จะถูกเข้าถึง จากตัวเลขสมมติใน 20 ภูมิภาคที่มี Database Host 5 แสนเครื่อง และ Client 1 ล้านเครื่อง พบว่าการใช้ ZGateway ช่วยลดจำนวนการเชื่อมต่อต่อโฮสต์ลงได้ถึง 97-98% และลดการเชื่อมต่อแบบถาวร (Persistent Connections) โดยรวมได้ประมาณ 19 เท่า

ข้อดีสำคัญคือเรื่องการขยายตัว (Scaling) เพราะเดิมทีจำนวน Fan-in จะเติบโตแบบเส้นตรงตามจำนวน Client แต่เมื่อมี ZGateway จำนวน Fan-in จะถูกจำกัดอยู่เพียงแค่จำนวนภูมิภาคคูณด้วยความหนาแน่นของ Shard ต่อโฮสต์เท่านั้น ทำให้ Meta สามารถควบคุมการขยายตัวของระบบได้ง่ายขึ้น

ความสามารถที่ตามมา

• Safe migration: ใช้ Configuration Flags ควบคุมการย้ายระบบตามประเภทบริการและ Shard ทำให้สามารถปรับสัดส่วนการใช้งาน (Ramp) หรือสั่งหยุดฉุกเฉิน (Global Kill Switch) ได้ทันที
• Discriminant Load Shedding (DLS): แยก Traffic ตามความสำคัญ (Priority) ของแต่ละ Tenant โดยในสภาวะ CPU โหลดเกิน 90% ระบบสามารถคัดกรองเฉพาะ Tenant ที่สร้างปัญหาเพื่อลดภาระ (Shed Load) ขณะที่ Tenant อื่นๆ อีกกว่า 99% ยังทำงานได้ปกติ
• Read caching: มี Cache Tier ภายในโปรเซสที่ช่วยจัดการ Hot Reads และรักษาความสดใหม่ของข้อมูลผ่านระบบ Change-data-capture
• Load balancing: ปรับสมดุลภาระงานตามกำลัง CPU ของโฮสต์ที่มีตั้งแต่ 26 ถึง 126 คอร์ เพื่อให้การกระจายงานมีประสิทธิภาพสูงสุด
• Cross-region resilience: รองรับการ Fail Over ไปยังภูมิภาคใกล้เคียงหาก Regional Tier เดิมรับภาระจนเต็ม
• Transactions: ย้ายการบันทึกข้อมูลฝั่ง Client มาไว้ที่ Gateway ช่วยรวบรวมขั้นตอนการทำงานให้กระชับขึ้นโดยไม่สูญเสียความเสถียร

ประเด็นสำคัญ

• ZGateway รองรับการทำงานมหาศาลกว่า 1 พันล้านครั้งต่อวินาที โดยมี Overhead ต่ำเพียง 6%
• เปลี่ยนรูปแบบการขยายตัวของ Database Fan-in จากเส้นตรงตามจำนวน Client มาเป็นจำนวนคงที่ที่ควบคุมได้
• การทำ Batching ช่วยลดปัญหา Hot-key Stampedes และลดความซับซ้อนของ Client Libraries
• ระบบ DLS มีความแม่นยำสูง สามารถแยกแยะและจัดการเฉพาะ Tenant ที่มีปัญหาได้โดยไม่กระทบผู้ใช้ส่วนใหญ่
• เทคโนโลยีนี้ถูกออกแบบมาเพื่อโครงสร้างพื้นฐานของ Meta โดยเฉพาะ หัวใจสำคัญจึงอยู่ที่ "แนวคิดการออกแบบ" มากกว่าการเป็นซอฟต์แวร์สำเร็จรูปที่นำไปใช้ภายนอกได้ทันที