GitHub ยกเครื่องโครงสร้างพื้นฐาน Git รองรับการพัฒนาระดับ Agent

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

การพัฒนาซอฟต์แวร์โดยใช้เอเจนต์ (Agentic software development) กำลังขับเคลื่อนการเปลี่ยนแปลงทางสถาปัตยกรรมครั้งถัดไป เมื่อนักพัฒนาและเอเจนต์ทำงานร่วมกันในคลังเก็บรหัส (repository) ที่ได้รับคอมมิต (commit) นับล้านครั้งต่อวัน ปริมาณงานเหล่านี้ต้องการสถาปัตยกรรม Git ที่แตกต่างออกไป เราจึงกำลังสร้างโครงสร้างพื้นฐานใหม่เพื่อรองรับสิ่งนี้ โดยโพสต์นี้จะสำรวจความต้องการและหลักการออกแบบที่อยู่เบื้องหลังทั้งหมด

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

นอกเหนือจากปริมาณงานสูงสุดเหล่านี้ กิจกรรม Git โดยรวมบน GitHub ก็เติบโตอย่างรวดเร็วเช่นกัน โดยระหว่างเดือนกันยายน 2025 ถึงสิงหาคม 2026 กิจกรรมเพิ่มขึ้นมากกว่า 2 เท่าจากระดับเดิม จาก 218.2 พันล้านเหตุการณ์ เป็น 473.3 พันล้านเหตุการณ์ต่อเดือน เฉพาะในเดือนกันยายนเพียงเดือนเดียว นักพัฒนาและเอเจนต์ได้ทำการคอมมิตรวม 7.38 พันล้านครั้ง ซึ่งมากกว่าปีก่อนหน้าถึงห้าเท่า

repository ที่อยู่บนจุดสูงสุดของกราฟแสดงให้เห็นว่าการพัฒนาโดยเอเจนต์ในระดับแนวหน้าเป็นอย่างไร ทีมวิศวกรขนาดใหญ่ที่รัน CI pipeline หนาแน่นควบคู่ไปกับฝูงเอเจนต์ที่เพิ่มจำนวนขึ้นต้องการการอ่านและเขียนพร้อมกันอย่างต่อเนื่องในระดับที่น้อยแห่งจะไปถึง เราจึงลงทุนอย่างหนักในโครงสร้างพื้นฐานเพื่อมอบรากฐานสำหรับปริมาณงานที่ทะเยอทะยานที่สุดเหล่านี้

การสร้างเพื่อรองรับขนาดนี้หมายถึงการแก้ปัญหาความท้าทายหลายประการ:

• การคอมมิตกลายเป็นคอขวด: เอเจนต์มักคอมมิตหรือทำ checkpoint แทบทุกการกระทำ ความเร็วของมันจึงถูกจำกัดด้วยความหน่วง (latency) ของการ push ซึ่งเป็นสิ่งที่มนุษย์อาจไม่เคยสังเกตเห็น
• ปริมาณงานเขียนเพิ่มขึ้นมหาศาล: การ push เติบโตขึ้น 4.9 เท่าเมื่อเทียบปีต่อปี จาก 0.69 พันล้านครั้งเป็น 3.35 พันล้านครั้งต่อเดือน
• การ merge แย่งชิงทรัพยากร: การพัฒนาแบบ Trunk-based และ merge queues รวมงานไปยังการอ้างอิง (ref) เดียว ส่งผลให้การ merge pull request บน GitHub เติบโตขึ้นเกือบ 4 เท่าจากปีที่แล้ว
• การ push หนึ่งครั้งส่งผลต่อการอ่านนับพัน: ตัวอย่างเช่น GitHub Actions เพียงอย่างเดียวถูกรันไป 3.26 พันล้านครั้งในเดือนกันยายน มากกว่าปีที่แล้วกว่า 4 เท่า
• การจัดการ repository ต้องรวดเร็ว: การบีบอัดข้อมูลและทำความสะอาดไฟล์ที่ไม่จำเป็นต้องทำได้ต่อเนื่องแม้ในขณะที่มีการเขียนข้อมูลจำนวนมาก

การขยายการอ่าน (Read) นั้นทำได้ง่ายด้วยการเพิ่ม cache หรือ replica แต่การเขียน (Write) นั้นยากกว่ามาก เพราะทุกการ push ต้องจัดเก็บอย่างทนทานและสอดคล้องกันก่อนที่งานขั้นต่อไปจะเริ่มได้

จุดที่สถาปัตยกรรมปัจจุบันเผชิญกับความต้องการใหม่

สถาปัตยกรรมปัจจุบันใช้ระบบ Spokes ซึ่งเก็บสำเนาฉบับเต็มไว้ใน disk ของ fileserver 5 เครื่อง เพื่อความหน่วงต่ำและความซ้ำซ้อนของข้อมูล อย่างไรก็ตาม กลไกความทนทาน (durability) ที่เราใช้นั้นกลายเป็นอุปสรรคต่อการขยายขนาด (scale) เนื่องจากทุก replica ต้องร่วมในการเขียนทุกครั้ง การเพิ่ม replica เพื่อรองรับการอ่านจึงทำให้การเขียนช้าลงโดยปริยาย เพื่อตอบสนองความต้องการที่เน้นเอเจนต์เป็นหลัก เราจำเป็นต้องแยกความทนทานออกจากขนาดการใช้งานโดยไม่สูญเสียความเชื่อมั่นที่ทีมต่างๆ มีให้เรา

สร้างเพื่อระบบที่ยุ่งที่สุด เพื่อผลลัพธ์ที่ดีกว่าสำหรับทุกคน

เรากำลังสร้างโครงสร้างพื้นฐานใหม่ในขณะที่ GitHub ยังคงทำงานตามปกติโดยไม่มีช่วงเวลาซ่อมบำรุง เรามุ่งเป้าไปที่ปริมาณงานที่ต้องการความซับซ้อนสูงสุด ทั้งองค์กรที่ควบคุมเข้มงวด ทีมที่สร้างระบบปฏิบัติการ และกลุ่มที่ใช้เอเจนต์นับพันตัวต่อหนึ่ง codebase การวางระบบสำหรับขนาดดังกล่าวจะช่วยยกระดับพื้นฐานให้กับผู้ใช้ทุกคน ตั้งแต่นักเรียนที่เปิด PR แรกไปจนถึงผู้ดูแลโปรเจกต์โอเพนซอร์ส

สถาปัตยกรรมใหม่ยังคงรักษาหลักการสำคัญเพื่อให้แพลตฟอร์มรับใช้ทุกคนได้ ดังนี้:

• สร้างบน workflow เดิม: รองรับการสร้าง branch, รีวิว และ merge ในระดับกิจกรรมที่สูงขึ้น
• ให้ความสำคัญกับความน่าเชื่อถือ: ความเชื่อมั่นคือหัวใจสำคัญที่ช่วยให้องค์กรสร้างระบบอัตโนมัติและส่งมอบงานได้ตามกำหนด
• ให้ผู้คนควบคุมรหัสของตนเอง: แม้เอเจนต์จะรับภาระงานมากขึ้น แต่เจ้าของรหัสต้องยังคงสามารถรีวิวและอนุมัติงานได้เสมอ

แนวทางใหม่สู่ยุคเอเจนต์

เราใช้หลักการออกแบบระบบกระจายตัว (distributed systems) เพื่อเพิ่มประสิทธิภาพและความพร้อมกันในการทำงาน:

ลดการประสานงาน (Minimize coordination)

เรากำลังออกแบบระบบใหม่ให้ประสานงานเฉพาะสิ่งที่จำเป็นจริงๆ เช่น การอัปเดตการอ้างอิง (reference update) ส่วนงานที่หนักกว่าอย่างการสแกนความลับหรือการตรวจสอบความเชื่อมต่อของ object จะถูกแยกออกไปทำขนานกัน เพื่อให้เส้นทางวิกฤต (critical path) ของการ push สั้นลงและตอบสนองได้เร็วขึ้น นอกจากนี้ยังย้ายงานบำรุงรักษาอย่างการเก็บขยะ (garbage collection) ออกไปรันบน worker แยกต่างหาก ไม่ให้รบกวนการทำงานสด

แยกส่วนจัดเก็บข้อมูลออกจากการคำนวณ (Decouple storage from compute)

การแยกเลเยอร์การจัดเก็บออกจากเลเยอร์ตอบคำขอช่วยให้เราขยายขนาดแต่ละส่วนได้อย่างอิสระ:

• ขยายการอ่านอิสระ: ใช้ compute worker น้ำหนักเบาในการทำ cache เพื่อตอบคำขอ โดยไม่ต้องเพิ่ม replica ที่ทนทานซึ่งจะไปหน่วงงานเขียน
• ใช้เทคโนโลยีคลาวด์ให้เกิดประโยชน์: เก็บข้อมูลหลักไว้ใน Azure Blob Storage เพื่อความทนทานระดับสูง แล้วปรับแต่งเลเยอร์คำนวณให้มีความหน่วงต่ำที่สุด
• กู้คืนและปรับความจุได้ทันที: เมื่อแยกส่วนกัน การล้มเหลวของ worker จะไม่ทำให้ข้อมูลสูญหาย และสามารถเพิ่มหรือลดจำนวน worker ได้ตามความหนาแน่นของการใช้งานจริง เช่น ในช่วงที่มีการออกเวอร์ชันใหม่

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

สถาปัตยกรรมใหม่นี้ถูกออกแบบมาเพื่อปริมาณงานสูงสุด โดยผลทดสอบภายในพบว่าสามารถรองรับงานเขียนได้สูงขึ้นถึง 35 เท่า พร้อมความจุการอ่านที่ปรับสเกลได้เองตามต้องการ GitHub จะวิวัฒนาการรากฐานต่อไปเพื่อรองรับโลกการพัฒนาแบบอัตโนมัติ และในโพสต์ถัดไปเราจะเจาะลึกรายละเอียดทางเทคนิคของการเดินทางครั้งนี้