ห้องเก็บข้อมูลสีเขียวเข้มมีท่อจำนวนมากไหลผ่านวาล์วแคบที่คุมปริมาณ โดยมีท่อหนึ่งรับภาระหนาแน่นผิดปกติเป็นสีอำพัน
aiopenaidistributed-systemsstorage

Habitat ของ OpenAI: ระบบ 70 ล้าน Request/วินาทีโตได้เพราะทำให้น้อยลง

พี่โชว์Engineering

ระบบฐานข้อมูลมักเริ่มพังไม่ใช่เพราะ request เฉลี่ยเยอะ แต่เพราะงานหนึ่งชิ้นแพงกว่างานอื่นแบบไร้ขอบเขตครับ OpenAI เผยเมื่อ 11 กันยายนว่า Habitat แพลตฟอร์ม online storage ภายในรับมากกว่า 70 ล้าน request ต่อวินาที เก็บข้อมูลมากกว่า 500 PB และรองรับผลิตภัณฑ์ที่มีผู้ใช้รายสัปดาห์กว่าพันล้านคนในเกือบ 40 ภูมิภาค

ตัวเลขใหญ่สะดุดตา แต่บทเรียนที่เอากลับมาใช้ได้คือ Habitat เลือกทำให้น้อยลง มันเปิด NoSQL API ที่จำกัดและคาดการณ์ต้นทุนได้ แทนให้ client เขียน query ซับซ้อนซึ่งสร้าง scan หรือ fan-out ไม่จำกัด

WHY: ความยืดหยุ่นที่ไม่มีเพดานกลายเป็นภาระส่วนรวม

ถ้าเขียน query แพงได้ด้วยโค้ดหนึ่งบรรทัด แต่ platform ต้องใช้เครื่องจำนวนมากรับผล ทีมที่เรียกไม่ได้เห็นต้นทุนจริง ปัญหาเหมือนบุฟเฟต์ที่ลูกค้าตักได้ทุกอย่างโดยครัวไม่รู้ว่าโต๊ะหนึ่งจะสั่งสิบหรือหมื่นจาน Habitat บังคับ object/edge access แบบงานคงที่ ส่วน analytics และ traversal ซับซ้อนไปเส้นทาง offline ที่แยกทรัพยากร

นี่ไม่ใช่สูตรว่า NoSQL ดีกว่า SQL แต่เป็นหลัก isolation: งานออนไลน์ที่กำหนด SLO ต้องไม่แชร์ failure surface กับงานสำรวจที่ต้นทุนแกว่ง ถ้าระบบเราใช้ Postgres ต่อได้ ก็ทำด้วย query allowlist, statement timeout, read replica และ workload queue ที่แยกกัน

Incident ที่ชี้ Metastable Failure

ทีมพบ pod บางตัวรับ concurrent request มากกว่าค่าเฉลี่ย 5–10 เท่า แม้หยุด client ต้นเหตุแล้ว pod เหล่านั้นยังทรุดต่อ สภาวะแบบ metastable หมายถึงระบบเข้าโหมดเสียแล้ว feedback ภายในทำให้มันเสียต่อเอง

สมมติฐานชี้ไปที่ connection pool และการจำกัดอายุ reuse ช่วยหยุดอาการ ก่อนพบว่า aiohttp เลือก connection ล่าสุดแบบ LIFO ทำให้ปลายทางบางตัวถูกวนใช้หนักกว่าเดิม บทเรียนคือ average utilization ไม่พอ ต้องดู distribution ต่อ process, connection age และ load-balancer decision พร้อมกัน

จาก Python ไป Rustเมื่อถึงเวลา

OpenAI ระบุว่า Python เคยรองรับมากกว่า 20 ล้าน request ต่อวินาที ทีมชะลอ rewrite หนึ่งปีเพื่อแก้ปัญหาเร่งด่วนก่อน แล้วในไตรมาสสองปี 2026 วิศวกรสองคนร่วมกับ Codex และ GPT-5.5 ย้าย service ไป Rust ปัจจุบันรับ 95% ของ production traffic และรายงานว่าใช้ CPU มีประสิทธิภาพขึ้น 6 เท่า หน่วยความจำ 15 เท่า

ตัวเลขนี้เป็นผลของ workload และ implementation ของ OpenAI ไม่ใช่ benchmark ทั่วไป ประเด็นสำคัญคือทีม rewrite หลัง contract และ bottleneck ชัด ไม่ใช่เลือกภาษาใหม่เพื่อหวังว่าปัญหา distributed system จะหายเอง

Recap

  • จำกัด API ให้ต้นทุน request คาดการณ์ได้
  • แยก online serving จาก analytics และ graph traversal
  • เฝ้าดู tail process ไม่ดูค่าเฉลี่ยอย่างเดียว
  • ทดสอบสมมติฐานด้วย control เล็กก่อน rewrite
  • เปลี่ยนภาษาเมื่อ contract กับ profile ชัดแล้ว

พรุ่งนี้ลองหา endpoint หนึ่งตัวที่ผู้เรียกสร้าง fan-out ได้ไม่จำกัด แล้วเพิ่ม budget ที่ enforce ฝั่ง platform ครับ