GitHub dịch chuyển hạ tầng Git lên Azure: Bước đệm cho kỷ nguyên phát triển nhờ AI agent

Trong suốt một năm qua, khi lưu lượng Git tăng theo cấp số nhân, 99,99999% kho mã nguồn trên GitHub đã tồn tại song song ở hai nơi: trung tâm dữ liệu riêng của GitHub và Azure. Số còn lại là những repo bận rộn nhất nền tảng, và chúng bị chặn lại chỉ vì một lý do: một vòng khứ hồi mạng mất 25ms.

Đây là câu chuyện kỹ thuật về cách GitHub chuyển đổi hạ tầng Git quy mô hàng tỷ repository mà không phải dừng dịch vụ — một bài toán đầy thách thức khi làn sóng lập trình viên và AI agent đang ghi dữ liệu liên tục 24/7.

Hạ tầng Git quy mô lớn của GitHub trên Azure

Vì sao GitHub phải di chuyển lên mây?

Thời điểm và hình thức của cuộc di chuyển đều bị chi phối bởi sự chuyển dịch sang kỷ nguyên agent. Lưu lượng tăng nhanh, công suất điện của trung tâm dữ liệu và cả khu vực địa lý xung quanh đã chạm trần, trong khi chuỗi cung ứng vật lý cũng gặp hạn chế.

Ban đầu, năng lực mở rộng còn lại vừa đủ để GitHub di chuyển an toàn, nhưng không đủ để làm chậm rãi. Trong khi đó, các thao tác Git là dịch vụ Tier 0 — gần như mọi thứ trên GitHub đều phụ thuộc vào dữ liệu kho mã nguồn. Vì vậy, đội ngũ buộc phải sắp xếp thứ tự công việc cẩn thận: di chuyển dữ liệu trước, tiến hóa kiến trúc sau.

Bản sao đầu tiên của một repository đã đặt chân lên vùng Central US của Azure vào tháng 8/2025. Hiện nay, phần lớn repository có hai trong năm bản sao nằm trên Azure, và Azure đảm nhận khoảng một nửa lưu lượng Git.

Nguyên tắc cốt lõi của kiến trúc mới

Kiến trúc lưu trữ thế hệ mới của GitHub dựa trên hai nguyên tắc:

• Giảm thiểu phối hợp (minimize coordination): không tuần tự hóa những gì không cần tuần tự.
• Tách rời lưu trữ khỏi compute (decouple storage from compute): mỗi thành phần có thể mở rộng độc lập.

Nút thắt cuối cùng: 0,00001% repository còn lại

Với kiến trúc hiện tại, một repository được lưu trữ ở nhiều vùng có giới hạn thông lượng ghi thấp hơn. Cơ chế quorum của Spokes chỉ cần đa số để cam kết một thao tác ghi, nhưng nó vẫn chờ mọi bản sao khỏe mạnh phản hồi trước khi tiếp tục. Hệ quả là bản sao chậm nhất quyết định độ trễ của mọi thao tác ghi.

Khi một bản sao nằm ở vùng Azure đích, cách trung tâm dữ liệu khoảng 1.000 dặm (khoảng 1.600km), mỗi vòng khứ hồi mạng tốn khoảng 25ms, và một thao tác ghi cần nhiều vòng khứ hồi. Với repository đã gần chạm trần thông lượng, điều này đồng nghĩa với việc tụt lại ngày càng xa sau mỗi lần push.

Giải pháp: Quorum theo từng tham chiếu

Điểm mấu chốt nằm ở chỗ: yêu cầu nhất quán của Git áp dụng cho từng tham chiếu (reference) riêng lẻ, chứ không phải toàn bộ repository. Một khi máy chủ chấp nhận cập nhật cho một tham chiếu, client không được thấy giá trị cũ hơn nữa.

Trong hầu hết trường hợp, các cập nhật cho những tham chiếu khác nhau không phụ thuộc lẫn nhau. Vì thế, GitHub quyết định thay đổi phạm vi quorum từ toàn bộ repository sang từng tham chiếu riêng lẻ.

Khóa toàn bộ repository trong suốt quá trình cập nhật tham chiếu biến quorum thành một hàng đợi đơn lẻ, mỗi lúc chỉ có một thao tác ghi — và mỗi thao tác tốn thời gian bằng bản sao chậm nhất.

Với cơ chế tuần tự hóa theo từng tham chiếu, chỉ những thao tác ghi tranh chấp trên cùng một tham chiếu mới phải chờ nhau. Trên thực tế, phần lớn thao tác ghi chạm vào các nhánh khác nhau — chẳng hạn AI agent và lập trình viên push lên nhánh riêng của họ — nên không còn phải xếp hàng.

Kết quả thử nghiệm nội bộ với lưu lượng thực tế: các thao tác ghi vào những tham chiếu khác nhau đạt thông lượng cao gấp 3–4 lần với độ trễ thấp hơn.

Mở rộng khả năng đọc độc lập nhờ lưu trữ đối tượng

Hầu hết repository lệch mạnh về phía đọc, với tỉ lệ từ 100 đến 1.000 lượt đọc cho mỗi lượt ghi. Hiện tại, đọc và ghi dùng chung bản sao nên cạnh tranh tài nguyên với nhau.

Bước tiếp theo là đưa Azure Blob Storage trở thành một thành viên đặc biệt của quorum — gọi là bản sao ảo (virtual replica). Node này hoạt động như cầu nối tới lưu trữ đối tượng, chỉ truyền dữ liệu ghi vào chứ không phục vụ đọc. Nhờ vậy, thao tác ghi chỉ được xác nhận khi dữ liệu đã bền vững trên lưu trữ đối tượng.

Từ đó, GitHub có thể mở rộng tùy ý số lượng bản sao đọc ảo theo nhu cầu. Mỗi bản sao đọc làm ấm bộ nhớ đệm từ Azure Blob Storage và bắt đầu nhận lưu lượng mà không cần tham gia quorum, dùng lưu trữ đối tượng làm nguồn sự thật.

Trong thử nghiệm nội bộ, bộ công cụ kiểm thử tải phân tán của GitHub thường xuyên chạm trần với kiến trúc cũ. Nhưng khi đối đầu với các bản sao đọc ảo, chính bộ công cụ này chạm giới hạn của nó trước.

Ý nghĩa với cộng đồng lập trình viên Việt Nam

Đối với các đội ngũ phát triển tại Việt Nam — những người ngày càng dựa vào GitHub làm nền tảng cộng tác, CI/CD và lưu trữ mã nguồn — những thay đổi hạ tầng này mang lại trải nghiệm push/pull mượt mà hơn, đặc biệt khi làm việc nhóm đông người hoặc khi tích hợp các công cụ AI hỗ trợ lập trình ghi dữ liệu liên tục.

Đây cũng là bài học kiến trúc đáng tham khảo cho các kỹ sư hệ thống Việt Nam: chỉ phối hợp khi thực sự cần thiết, và tách rời các thành phần để chúng mở rộng độc lập.

Điều gì tiếp theo?

GitHub khẳng định vẫn chưa dừng lại. Sau khi hoàn tất các bước này, giới hạn tiếp theo là thông lượng ghi. Mỗi thao tác ghi vẫn phải chờ các bản sao giữ bản sao đầy đủ của repository, dù rất ít phần thực sự cần được sắp thứ tự.

Giao thức commit đã đưa GitHub tới một tỷ repository sẽ không thể đưa nó tới tỷ tiếp theo và xa hơn nữa.

Đội ngũ cho biết sẽ tiết lộ trạng thái cuối cùng của kiến trúc, những vấn đề bậc hai phải giải quyết, và lý do vì sao vẫn còn một nhóm đồng thuận nhỏ trong hệ thống — dự kiến tại sự kiện GitHub Universe và bài viết cuối cùng của loạt bài.