GitHub เปิดตัว Rubicon สถาปัตยกรรมจัดเก็บ Git ยุคใหม่

เมื่อสัปดาห์ที่แล้วในงาน GitHub Universe เราได้ประกาศเปิดตัวสถาปัตยกรรมจัดเก็บข้อมูล Git ใหม่ที่รองรับการเขียนข้อมูลได้หลายพันรายการต่อวินาที พร้อมขยายการอ่านได้ตามต้องการ ผลการทดสอบภายในพบว่าระบบสามารถรองรับเอเจนท์ 5,000 รายที่ทำงานพร้อมกันในหนึ่ง repository โดยส่งข้อมูลได้ถึง 7,200 pushes ต่อวินาที ในขณะที่ยังรักษาความเร็วในการอ่าน (latency) ได้อย่างสม่ำเสมอ

สถาปัตยกรรมใหม่นี้ถือเป็นรากฐานสำคัญของ GitHub ในการสนับสนุนการพัฒนาโดยใช้เอเจนท์ (agentic development) สำหรับนักพัฒนาหลายร้อยล้านคน โดยเราสร้างมันขึ้นมาภายใต้ระบบเดิมของ GitHub ในขณะที่ยังคงเปิดให้บริการตามปกติ

ในช่วงปีที่ผ่านมา เอเจนท์ได้เปลี่ยนภาพลักษณ์ของ repository ที่มีทราฟฟิกหนาแน่น ใน โพสต์แรก ของซีรีส์นี้ เราได้วางหลักการสองประการสำหรับสถาปัตยกรรมยุคถัดไป คือ การลดการประสานงานให้น้อยที่สุด (minimize coordination) และการแยกส่วนการจัดเก็บข้อมูลออกจากส่วนการประมวลผล (decouple storage from compute)

ใน โพสต์ล่าสุด เราได้อธิบายถึงขั้นตอนการเปลี่ยนผ่าน ทั้งการย้าย 99.99999% ของ repository เข้าสู่ Azure และการสร้าง virtual replicas ที่สำรองข้อมูลโดย Azure Blob Storage โดยมีข้อสังเกตสำคัญคือ Git objects นั้นไม่สามารถเปลี่ยนแปลงได้ (immutable) ทำให้ผู้เขียนสองรายสามารถจัดเก็บข้อมูลพร้อมกันได้โดยไม่ต้องตกลงกัน ส่วนที่ต้องมีการประสานงานมีเพียงการอัปเดต reference ซึ่งมีขนาดเล็กมากเท่านั้น

การสร้างเพื่อรองรับขนาดของเอเจนท์ (Building for agent scale)

เราวิเคราะห์ขนาดของแพลตฟอร์ม GitHub ผ่านสองแกนหลัก ได้แก่ การขยายตัวในแนวราบ (Horizontal scale) ซึ่งเป็นจำนวนนักพัฒนาและเอเจนท์ข้ามหลาย repository และการขยายตัวในแนวตั้ง (Vertical scale) คือจำนวนผู้ใช้งานที่ทำงานบน หนึ่ง repository ซึ่งความต้องการส่วนใหญ่ของเรามาจากแกนแนวตั้งนี้เอง

ปัจจุบัน repository ที่ยุ่งที่สุดได้รับข้อมูลสูงสุดเพียงไม่กี่โหลต่อวินาที แต่เราคาดการณ์ว่าเมื่อเปลี่ยนเป็นภาระงานของเอเจนท์ที่ทำงานแบบขนานตลอด 24 ชั่วโมง อัตราการเขียนจะเพิ่มขึ้นอย่างต่อเนื่อง แผนภูมิด้านล่างแสดงให้เห็นว่าคำขอรายวันต่อหนึ่ง repository เติบโตขึ้นประมาณ 4 เท่าในช่วงเวลาสั้นๆ และยังมีแนวโน้มเพิ่มขึ้นแบบเอกซ์โพเนนเชียล

สถาปัตยกรรมใหม่นี้จึงถูกออกแบบมาให้ยอมรับการเขียนได้หลายพันรายการต่อวินาที รองรับ writer nodes หลายตัวเพื่อกระจายภาระงาน CPU ในการทำดัชนี (indexing) ลด commit latency และแยกส่วนประกอบแต่ละส่วนให้ขยายขนาดได้อย่างเป็นอิสระ

ขอแนะนำ "Project Rubicon"

โครงการ "Rubicon" เริ่มต้นในเดือนพฤษภาคม 2026 เพื่อตอบโจทย์ความต้องการดังกล่าว โดยชื่อนี้สื่อถึงจุดที่ย้อนกลับไม่ได้ของยุค agentic development ในด้านโครงสร้างพื้นฐาน คำขอจาก Git clients, API และเว็บ UI จะยังคงผ่าน Spokes เพื่อทำหน้าที่ routing แต่ระบบ data plane ด้านล่างถูกยกเครื่องใหม่ทั้งหมด

ระบบใหม่จะใช้ virtual replicas ซึ่งเป็นหน่วยประมวลผลแบบใช้แล้วทิ้ง (disposable compute) โดยมีดิสก์ในตัวทำหน้าที่เป็นแคช เมื่อ repository มีการใช้งานหนาแน่น เราจะเพิ่ม virtual replicas เข้าไปช่วยได้ทันที ส่วนสถานะที่คงทน (Durable state) จะถูกเก็บไว้ในสองส่วนคือ Git objects ใน Azure Blob Storage และ References ในบริการที่เรียกว่า Ref-CAS (Reference Compare-and-Swap)

การลดการประสานงานให้น้อยที่สุด: การเปลี่ยนแปลงสถานะ reference ที่ throughput สูง

Azure Blob Storage เหมาะอย่างยิ่งสำหรับการเก็บข้อมูลถาวร เช่น Packs และ indexes ที่เขียนเพียงครั้งเดียวและไม่มีการเปลี่ยนแปลงอีก

อย่างไรก็ตาม การอัปเดต reference ที่มีการเขียนพร้อมกันจำนวนมากเป็นเรื่องยากสำหรับระบบจัดเก็บแบบเดิม หลังจากทดลองหลายแนวทาง เราจึงสร้าง Ref-CAS ขึ้นมาเพื่อทำหน้าที่จัดการธุรกรรมแบบ compare-and-swap โดยเฉพาะ ซึ่งช่วยให้การอัปเดต reference ที่ไม่ขัดแย้งกันสามารถทำสำเนาได้แบบขนานและมีความเร็วสูงถึงหลายหมื่นรายการต่อวินาที

การแยกส่วนการจัดเก็บออกจากส่วนการประมวลผล: การทำ compaction ที่การเขียนหลายพันรายการต่อวินาที

ในสถาปัตยกรรมใหม่ การทำ compaction หรือการรวม pack ข้อมูลจะรันในเบื้องหลังบนโหนดแยกต่างหาก ไม่รบกวนทราฟฟิกการใช้งานปกติ Compaction nodes จะอ้างสิทธิ์การดูแลข้อมูลผ่านระบบสัญญาเช่า (lease) และทำงานร่วมกับ Blob Storage โดยตรง

กระบวนการนี้สามารถขยายขนาดได้โดยการเพิ่มโหนดตามจำนวน shard ของข้อมูล ผลลัพธ์ที่ได้คือจำนวน pack จะคงที่แม้จำนวนการ push จะเพิ่มสูงขึ้นอย่างมาก ช่วยให้กราฟ latency ของการอ่านและเขียนยังคงราบเรียบสม่ำเสมอ

สิ่งที่จะเกิดขึ้นต่อไป

เป้าหมายของเราคือการทำให้ทุก repository รันบนสถาปัตยกรรมเดียวกัน ไม่ว่าจะเป็นโปรเจกต์ส่วนตัวหรือ monorepo ขนาดใหญ่ เรากำลังมุ่งเน้นไปที่การปรับปรุงให้การอ่านดึงเฉพาะข้อมูลที่จำเป็น (Partial replicas), การสร้าง Global replicas เพื่อลดระยะทางในการเข้าถึง และการพัฒนาฟีเจอร์สำหรับเอเจนท์ เช่น Atomic commit API และระบบ Event streams

นอกจากนี้ เราจะยังคงร่วมพัฒนาโครงการ Git ต่อไป เพื่อลดต้นทุนในการโคลนข้อมูลและเพิ่มความเร็วในการไล่เรียงประวัติ (history walks) ปัจจุบัน Rubicon เปิดให้ทดสอบแบบจำกัด และจะขยายการใช้งานในวงกว้างช่วงต้นปีหน้า เพื่อรองรับจินตนาการใหม่ๆ ของเหล่านักพัฒนาในยุค AI ต่อไป