GitHub เผยแผนย้าย Git สู่ Azure และแก้คอขวด Push ด้วย Quorum ราย Reference

GitHub เผยรายละเอียดวิศวกรรมเมื่อ 21 ตุลาคม 2026 ว่าขณะนี้ repository จำนวน 99.99999% มีสำเนาอยู่ทั้งศูนย์ข้อมูลเดิมและ Azure แล้ว และ Azure รับทราฟฟิก Git ราวครึ่งหนึ่ง บทความอธิบายปัญหาที่ทำให้ repo ที่ยุ่งที่สุดยังย้ายไม่ครบ: การเขียนต้องรอ replica ที่อยู่ไกลและระบบเดิมล็อกงานในระดับทั้ง repository ทำให้รอบเครือข่ายประมาณ 25 มิลลิวินาทีจำกัด throughput เรื่องนี้เป็นตัวอย่างการออกแบบ storage สำหรับยุคที่คนและ agent สร้าง branch และ push พร้อมกันมากขึ้น

ทำไมสำเนาที่อยู่ไกลจึงกระทบการเขียน

GitHub ใช้ระบบ Spokes จัดการ replica โดย repo ส่วนใหญ่มีห้าสำเนาเพื่อความทนทานและความพร้อมใช้งาน กลไกเดิมต้องได้เสียงส่วนใหญ่เพื่อ commit แต่ยังรอ replica ที่สุขภาพดีทุกตัวตอบกลับก่อนเดินหน้าต่อ หากหนึ่งสำเนาอยู่คนละภูมิภาค ความล่าช้าของเส้นทางไกลจึงเข้าไปอยู่ในทุก write และ lock ระดับ repository ทำให้ write อื่นรอคิวด้วย แม้ผู้ใช้จะ push ไปคนละ branch ก็ตาม

GitHub อธิบายว่าจะเปลี่ยนขอบเขตการจัดลำดับจากทั้ง repository เป็นราย reference เช่น branch หรือ tag หลักความสอดคล้องที่ต้องรักษาคือ เมื่อระบบรับการอัปเดต reference หนึ่งแล้ว ลูกค้าไม่ควรเห็นค่าเก่ากว่านั้นอีก แต่การอัปเดตคนละ reference ส่วนใหญ่ไม่จำเป็นต้องต่อคิวเดียวกัน การแยกคิวจึงช่วยให้ push หลาย branch ทำพร้อมกันได้ ขณะเดียวกัน write ที่ชน reference เดียวกันยังถูกจัดลำดับอย่างถูกต้อง

ผลทดสอบภายในด้วยทราฟฟิกจำลองของ GitHub พบว่า write ไปคนละ reference ได้ throughput สูงขึ้นประมาณ 3–4 เท่าและ latency ต่ำลง ตัวเลขนี้เป็นผลทดสอบภายในของระบบ GitHub ไม่ใช่คำรับประกันว่า git push ของทุกทีมจะเร็วขึ้นเท่านี้ ปัจจัยอย่าง CI, ขนาด object, เครือข่ายของผู้ใช้ และ branch protection ยังมีผลต่อเวลาที่เห็นปลายทาง

แยกการอ่านออกจาก quorum

GitHub ระบุว่า repo จำนวนมากมีการอ่าน 100–1,000 ครั้งต่อการเขียนหนึ่งครั้ง แต่ปัจจุบัน read และ write ใช้ replica ชุดเดียวกัน จึงแข่งขันกันใช้ทรัพยากร แผนต่อไปคือเก็บข้อมูลอย่างทนทานใน Azure Blob Storage และเพิ่ม virtual write replica ที่ร่วม quorum แต่ไม่รับ read มันสตรีม write ไป object storage และจะไม่ยืนยัน write ก่อนข้อมูลทนทาน จากนั้นสามารถเพิ่ม virtual read replica ตามโหลด โดยอุ่น cache จาก object storage และไม่ต้องเข้าร่วม quorum

ส่วนนี้ยังมีงานตามมา GitHub ระบุว่า read replica แบบใหม่ยังต้องปรับการตามข้อมูลให้ทันสำหรับ workload บางชนิด และ quorum ยังเป็นเพดานของการเขียนในระยะยาว จึงควรแยกให้ชัดว่าอะไรย้ายสำเร็จแล้ว อะไรอยู่ในการทดสอบ และอะไรเป็นสถาปัตยกรรมเป้าหมาย ไม่เขียนว่าการแยก read/write เปิดครบทั่วระบบแล้ว

บทเรียนสำหรับทีมที่ดูแลระบบของตน

ประเด็นสำคัญคือหาหน่วยของข้อมูลที่จำเป็นต้อง serialize จริง หากระบบจับ lock กว้างเกินไป งานที่ไม่เกี่ยวกันจะรอกันเอง แต่การลดขอบเขต lock ต้องรักษา invariant ของข้อมูลให้ชัดและทดสอบกรณีชนกัน การนำ object storage มาเป็นแหล่งข้อมูลทนทานช่วยขยาย read ได้ แต่ต้องออกแบบ cache, การตามสถานะ และจุดยืนยัน write ให้ตรงกับระดับความคงทนที่สัญญากับผู้ใช้

ข่าวนี้ไม่ได้บอกให้ทุกทีมย้าย Git server ไปคลาวด์ แต่ชี้ให้เห็นวิธีที่ GitHub แยกปัญหาการย้ายข้อมูล ความสอดคล้อง และการรองรับโหลดเป็นขั้นตอน พร้อมวัดผลจาก workload จริงก่อนขยาย

แหล่งข่าว: บทความวิศวกรรม GitHub วันที่ 21 ตุลาคม 2026