กำลังเตรียมประสบการณ์ดิจิทัล
เมื่อเอเจนต์ AI เริ่มเขียนและส่งโค้ดแทนคน ทราฟฟิก Git ของ GitHub โตแบบทวีคูณจนใกล้ชนเพดานกำลังไฟของศูนย์ข้อมูลเดิม GitHub เล่าว่าย้ายสำเนาของ repository เกือบทั้งหมดไปไว้บน Azure แล้ว และกำลังเปลี่ยนสถาปัตยกรรมให้รับงานเขียนได้มากขึ้น 3-4 เท่า บทความนี้สรุปแนวคิดหลักที่ทีมพัฒนาระบบทั่วไปนำไปใช้ได้ ตั้งแต่ลำดับการย้ายระบบที่ลดความเสี่ยง ไปจนถึงการลดงานที่ต้องเข้าคิวรอกันโดยไม่จำเป็น
เมื่อเอเจนต์ AI เริ่มเขียนและส่งโค้ดแทนคน ทราฟฟิก Git ของ GitHub โตแบบทวีคูณจนใกล้ชนเพดานกำลังไฟของศูนย์ข้อมูลเดิม GitHub เล่าว่าย้ายสำเนาของ repository เกือบทั้งหมดไปไว้บน Azure แล้ว และกำลังเปลี่ยนสถาปัตยกรรมให้รับงานเขียนได้มากขึ้น 3-4 เท่า บทความนี้สรุปแนวคิดหลักที่ทีมพัฒนาระบบทั่วไปนำไปใช้ได้ ตั้งแต่ลำดับการย้ายระบบที่ลดความเสี่ยง ไปจนถึงการลดงานที่ต้องเข้าคิวรอกันโดยไม่จำเป็น
Git เป็นบริการชั้นล่างสุดที่เกือบทุกอย่างบน GitHub พึ่งพา GitHub โฮสต์ราวหนึ่งพันล้าน repository และระบบกลางชื่อ Spokes รับงานเกินแสนล้านคำสั่งต่อวัน เมื่อทราฟฟิกโตเร็วจนใกล้ขีดจำกัดของไฟฟ้าและห่วงโซ่อุปทานฮาร์ดแวร์ ทีมจึงต้องย้ายข้อมูลไปคลาวด์ ปัจจุบัน 99.99999% ของ repository มีสำเนาอยู่บน Azure แล้ว repository ส่วนใหญ่มีสำเนาห้าชุด สองชุดอยู่บน Azure และ Azure รับทราฟฟิก Git ราวครึ่งหนึ่ง
ทีมตัดสินใจไม่เปลี่ยนสองอย่างพร้อมกัน คือที่ตั้งของระบบกับวิธีเก็บข้อมูล เพราะที่ขนาดนี้ความเสี่ยงสูงเกินไป จึงเริ่มจากย้ายสำเนาข้อมูลทีละ repository แล้วให้ทราฟฟิกตามข้อมูลไปเอง ระบบเลือกส่งคำขอไปยังสำเนาที่อยู่ภูมิภาคเดียวกันก่อน เมื่อสำเนาย้ายไปมากขึ้น ทราฟฟิกก็ค่อย ๆ ไหลไป Azure จนภูมิภาคเดิมว่าง แนวคิดนี้ใช้ได้กับการย้ายระบบทุกขนาด คือแยกการเปลี่ยนแปลงใหญ่ออกเป็นขั้นที่ย้อนกลับได้
เดิมการเขียนข้อมูลลง repository หนึ่งต้องเข้าคิวผ่านล็อกเดียวทั้ง repository (quorum คือการให้สำเนาส่วนใหญ่ยืนยันตรงกันก่อนถือว่าเขียนสำเร็จ) สำเนาที่ช้าที่สุดจึงกำหนดความเร็วของทุกคน ระบบใหม่ย้ายการยืนยันลงไปที่ระดับ reference แต่ละตัว เช่น แต่ละ branch หรือ tag การ push เข้า branch ต่างกันจึงไม่ต้องรอกันอีก มีเพียงการเขียน branch เดียวกันเท่านั้นที่ต้องเข้าคิว ซึ่งตรงกับกติกาความถูกต้องของ Git ที่คิดเป็นราย reference อยู่แล้ว ในการทดสอบภายในด้วยทราฟฟิกที่ใกล้จริง การเขียนคนละ reference ทำได้มากขึ้น 3-4 เท่าและเร็วขึ้น
| เรื่อง | ตัวเลข |
|---|---|
| repository ที่มีสำเนาบน Azure | 99.99999% |
| สัดส่วนทราฟฟิก Git ที่ Azure รับ | ราวครึ่งหนึ่ง |
| ระยะเวลาเดินทางของข้อมูลต่อรอบระหว่างศูนย์ข้อมูล | ราว 25 มิลลิวินาที (ห่างราว 1,600 กิโลเมตร) |
| อัตราการอ่านต่อการเขียนของ repository ส่วนใหญ่ | 100 ถึง 1,000 ครั้งต่อหนึ่งการเขียน |
| ปริมาณการเขียนเมื่อใช้ quorum รายสาขา | มากขึ้น 3-4 เท่า |
ข้อมูลของ repository ถูกเก็บถาวรใน Azure Blob Storage แล้วใช้สำเนาเสมือนสองแบบ แบบแรกเป็นสำเนาสำหรับเขียน ทำหน้าที่เป็นสะพานส่งข้อมูลลงที่เก็บถาวร และจะตอบว่าเขียนสำเร็จก็ต่อเมื่อข้อมูลบันทึกถาวรแล้วเท่านั้น แบบที่สองเป็นสำเนาสำหรับอ่านที่เพิ่มจำนวนได้ตามความต้องการ ดึงข้อมูลจากที่เก็บถาวรมาไว้ในแคชแล้วตอบคำขออ่าน เพราะ repository ส่วนใหญ่ถูกอ่านมากกว่าเขียนหลายร้อยเท่า การแยกแบบนี้ทำให้ขยายฝั่งอ่านได้โดยไม่กระทบฝั่งเขียน ในการทดสอบ เครื่องมือยิงโหลดถึงขีดจำกัดของตัวเองก่อนสำเนาสำหรับอ่านด้วยซ้ำ
GitHub บอกว่าปัญหาถัดไปคือขีดจำกัดของการเขียน เพราะแต่ละการเขียนยังต้องรอสำเนาที่เก็บข้อมูลเต็มชุด ทั้งที่ข้อมูลส่วนใหญ่ของ Git ไม่เปลี่ยนแปลงและไม่ต้องเรียงลำดับ บทความตอนสุดท้ายของชุดนี้จะเล่าผลในงาน GitHub Universe ปลายเดือนตุลาคม 2026
ระบบของธุรกิจไทยอาจไม่ได้ใหญ่ระดับนี้ แต่ปัญหาเดียวกันเกิดได้เมื่อผู้ใช้เพิ่มขึ้นหลายเท่าในช่วงสั้น ๆ เช่น ช่วงโปรโมชันหรือเมื่อเริ่มให้ระบบอัตโนมัติเรียกใช้งาน อ่านกรณีที่เกี่ยวข้องได้ที่บทเรียนจากเหตุ GitHub ขัดข้องเดือนสิงหาคม 2026 ทีมงาน Smart Cyber Tech ออกแบบระบบคลาวด์ที่ขยายตัวได้เมื่อผู้ใช้เพิ่มหลายเท่า ปรึกษาได้ที่ แบบฟอร์มติดต่อ
บทความอื่นที่เกี่ยวข้อง
GitHub เผยแพร่รายงานหลังเหตุการณ์ล่มยาว 7 ชั่วโมง 47 นาที เมื่อ 17 สิงหาคม 2026 ซึ่งกระทบทั้งการล็อกอิน Actions API และ Copilot ทั่วโลก สาเหตุไม่ได้มาจากการเปลี่ยนโค้ดหรือคอนฟิก แต่มาจากความจุที่ตามการเติบโตไม่ทัน บทความนี้สรุปสิ่งที่เกิดขึ้นและเช็กลิสต์ที่ทีมไทยเอาไปใช้ได้ทันที
อ่านบทความ
เว็บที่อัปเดตบ่อยมักมีผู้ใช้กลุ่มหนึ่งเจอหน้าโหลดช้าทุกครั้งหลัง deploy ทั้งที่ค่าเฉลี่ยดูปกติ Vercel แก้ปัญหานี้ที่ชั้น CDN จนเวลาค้นหาข้อมูลเส้นทางของคำขอกลุ่มที่ช้าที่สุด 1 เปอร์เซ็นต์ (P99) ลดจาก 215.8 เหลือ 19.1 มิลลิวินาที โดยไม่ได้เพิ่มเครื่อง แต่เปลี่ยนจากการดึงข้อมูลทีละเส้นทางมาเป็นการดึงเป็นก้อนขนาดราว 200 KB ที่มีดัชนีในตัว เราสรุปแนวคิด ตัวเลข และสิ่งที่ทีมพัฒนาเว็บในไทยหยิบไปใช้กับระบบ cache ของตัวเองได้
อ่านบทความ
ทีมที่ให้ AI agent ทำงานหลายขั้นตอนเริ่มเสียเวลากับคำถามเดิม ๆ ว่างานถึงไหนแล้ว ใครอนุมัติอะไรไป และตรงไหนยังรอคน เพราะทุกอย่างจมอยู่ในแชตยาว GitHub Copilot app เสนอทางออกชื่อ canvas คือพื้นที่ทำงานร่วมที่คงอยู่และตรวจสอบได้ บทความนี้สรุปแนวคิด ต้นทุนที่ต้องลงก่อน และวิธีเริ่มกับงานที่ทีมทำซ้ำอยู่แล้ว
อ่านบทความตั้งแต่ประเมินระบบปัจจุบัน วางแผน จนถึงลงมือพัฒนา — คุยกับเราได้โดยไม่มีค่าใช้จ่าย
