GitHub ra mắt kiến trúc lưu trữ Git chịu tải 7.200 push/giây

GitHub vừa công bố kiến trúc lưu trữ Git thế hệ mới với tên nội bộ "Project Rubicon", được thiết kế để chịu được hàng nghìn thao tác ghi mỗi giây trên cùng một repository, trong khi khả năng đọc vẫn mở rộng theo nhu cầu. Trong các thử nghiệm nội bộ, GitHub đã chứng minh khả năng hỗ trợ 5.000 agent (tác nhân AI) cùng làm việc trên một repository, gửi tới 7.200 push mỗi giây, đồng thời phục vụ lưu lượng đọc với độ trễ thấp ổn định.

Đây không phải một bản nâng cấp nhỏ: theo GitHub, kiến trúc mới là nền tảng để nền tảng này phục vụ phát triển phần mềm bằng agent cho hàng trăm triệu lập trình viên. Đáng chú ý là toàn bộ quá trình được triển khai ngay dưới hệ thống đang vận hành, không cần dừng dịch vụ.

Vì sao kiến trúc cũ không còn đủ

Trong một năm qua, các agent đã thay đổi diện mạo của những repository bận rộn nhất. Hiện nay, các repository đông hoạt động nhất trên GitHub.com chỉ nhận tối đa vài chục thao tác ghi mỗi giây, thường thành từng đợt ngắn. Khi công việc chuyển dần sang các agent chạy song song và liên tục, GitHub dự đoán những đợt bùng nổ này sẽ trở thành tốc độ duy trì trong vòng một năm tới.

Mỗi push lại kéo theo nhiều thao tác đọc: CI chạy, hệ thống triển khai kéo commit mới, các agent khác tải về để lấy ngữ cảnh. Hiệu ứng khuếch đại này khiến lưu lượng đọc tăng theo cấp số nhân so với ghi. Một biểu đồ được GitHub công bố cho thấy lưu lượng truy cập hằng ngày tới một repository đã tăng khoảng 4 lần từ tháng 3 đến tháng 5 và tiếp tục tăng theo quỹ đạo hàm mũ.

Biểu đồ tăng trưởng lưu lượng của một repository GitHub

Thay vì chỉ tính cho mức tăng kế tiếp, GitHub đặt mục tiêu mở rộng ít nhất hai bậc độ lớn. Với một repository đơn lẻ, kiến trúc mới phải tiếp nhận hàng nghìn thao tác ghi mỗi giây, hỗ trợ nhiều node ghi, giảm thiểu độ trễ commit, ghi nhận thay đổi theo đúng thứ tự cho từng tham chiếu (reference) và giữ chi phí đọc thấp khi không có gì thay đổi.

Hai nguyên tắc cốt lõi

Kiến trúc mới dựa trên quan sát mà GitHub đã nêu ở bài viết trước: rất ít phần của một thao tác ghi cần được sắp xếp thứ tự. Các đối tượng Git (Git object) là bất biến và được đặt tên theo nội dung, nên hai bên ghi có thể lưu chúng cùng lúc mà không cần thống nhất với nhau. Phần duy nhất của một push cần sự đồng thuận là cập nhật tham chiếu — và phần này rất nhỏ.

Từ đó, hai nguyên tắc được áp dụng: giảm thiểu phối hợp (minimize coordination) và tách rời lưu trữ khỏi tính toán (decouple storage from compute). Nhờ vậy, các thành phần từng gắn chặt với nhau như lưu dữ liệu, phục vụ yêu cầu và bảo trì repository có thể mở rộng độc lập. Với lập trình viên, Git vẫn là Git: vẫn push, fetch, tạo nhánh và giữ nguyên các lớp bảo vệ như cũ.

Một request đi qua hệ thống thế nào

Ở tầng trên, yêu cầu từ Git client, API và giao diện web vẫn đến Spokes — thành phần phụ trách định tuyến, cân bằng tải và cung cấp API nội bộ mà phần còn lại của GitHub dùng để đọc, ghi dữ liệu repository. Spokes cũng tiếp tục đảm nhận vai trò phân vùng, cô lập và đảm bảo công bằng giữa các tenant.

Điểm mới nằm ở tầng dữ liệu bên dưới. Spokes định tuyến mỗi yêu cầu tới một nhóm nhỏ bản sao ảo (virtual replica) được gán cho repository đó. Đây là một cụm máy tính dùng một lần, có thể phục vụ đọc, ghi hoặc cả hai, và đĩa cục bộ của chúng chỉ là bộ đệm có thể xây dựng lại bất cứ lúc nào.

• Ghi: một bản sao ảo lập chỉ mục cho pack gửi đến, tải lên Azure Blob Storage, rồi commit một giao dịch duy nhất vào Ref-CAS để đưa pack vào danh mục và cập nhật tham chiếu. Sau đó, một node compaction (nén gộp) sẽ gộp pack này với các pack khác để giữ tốc độ đọc.
• Đọc: bản sao ảo kiểm tra phiên bản tham chiếu với Ref-CAS, kéo các pack cần thiết từ Blob Storage vào bộ đệm rồi phục vụ yêu cầu từ đó.

Luồng xử lý request trong kiến trúc mới

Trạng thái bền vững nằm ở hai nơi: các đối tượng Git (dưới dạng pack và dữ liệu tăng tốc đọc) trong Azure Blob Storage, còn tham chiếu và danh mục pack trong một dịch vụ log sao chép riêng gọi là Ref-CAS (Reference Compare-and-Swap).

Ref-CAS: giải bài toán cập nhật tham chiếu

Azure Blob Storage rất phù hợp để lưu dữ liệu nặng, nhưng tham chiếu của một repository bận rộn lại có mẫu truy cập ngược lại: một lượng trạng thái nhỏ bị nhiều thao tác ghi tranh nhau cập nhật cùng lúc. GitHub đã thử hai cách tiếp cận.

Cách thứ nhất là một write-ahead log cho toàn bộ tham chiếu của repository, đánh chỉ mục bằng một blob duy nhất. Cách này đúng về mặt logic và đọc rẻ, nhưng chỉ một thao tác ghi có điều kiện lên blob được phép diễn ra tại một thời điểm. Kể cả khi gộp mọi push đến trong lúc ghi vào lần kế tiếp, trần thông lượng vẫn chỉ đạt mức trung bình vài trăm thao tác mỗi giây.

Cách thứ hai chia tham chiếu ra nhiều blob phân đoạn. Thông lượng ghi tăng, nhưng mỗi lần đọc phải kiểm tra mọi phân đoạn, tức là tốc độ đọc bị kéo xuống theo phân đoạn chậm nhất — trong khi đọc nhiều hơn ghi hàng bậc độ lớn. GitHub đã đánh đổi độ trễ ghi lấy độ trễ đọc và không chấp nhận điều đó.

Giải pháp cuối cùng là Ref-CAS: một dịch vụ log sao chép chuyên cho tham chiếu. Mỗi cập nhật tham chiếu là một phép compare-and-swap được commit bởi một nhóm đồng thuận (quorum). Giao dịch chỉ khóa những tham chiếu mà nó chạm tới, kiểm tra giá trị hiện tại đúng như người ghi kỳ vọng, và chỉ hiển thị sau khi đa số bản sao của log đã ghi nhận. Vì agent chủ yếu push lên nhánh riêng nên phần lớn cập nhật không tranh chấp và được sao chép song song.

Mỗi commit nhận một số thứ tự log (LSN), và phiên bản của repository chính là LSN của commit mới nhất. Khi đọc, bản sao ảo gửi phiên bản mà nó đang giữ: nếu vẫn là phiên bản hiện tại, phản hồi không mang theo tham chiếu nào, tức là một repository không thay đổi chỉ tốn một phép so sánh.

Khác với nhóm đồng thuận trong kiến trúc cũ, Ref-CAS không bao giờ lưu hay kiểm tra dữ liệu đối tượng — nó chỉ giữ con trỏ. Bản sao ảo phải tải pack lên Blob Storage trước khi commit giao dịch tham chiếu, nên một tham chiếu luôn chỉ trỏ tới các đối tượng đã bền vững. Nhờ vậy, hệ thống có thể xử lý riêng phần trạng thái tham chiếu với tốc độ hàng chục nghìn thao tác mỗi giây.

Compaction chạy nền, tách khỏi node phục vụ

Hỗ trợ hàng nghìn thao tác ghi mỗi giây trên một repository tạo ra vấn đề bậc hai: duy trì hiệu năng đọc và ghi. Mỗi push thêm một pack vào Blob Storage, và càng nhiều pack thì tra cứu càng tốn kém, nên số pack không thể tăng vô hạn.

Trong kiến trúc cũ, compaction chạy trên chính các replica phục vụ lưu lượng, và phải chạy trên mọi replica. Trong kiến trúc mới, nó chạy hoàn toàn ở nền trên các node riêng, thao tác trực tiếp trên lưu trữ bền vững và dùng Ref-CAS để thông báo trạng thái cho các bản sao ảo. Nhờ đó, CPU và bộ nhớ của bản sao ảo gần như được dành trọn cho việc phục vụ yêu cầu.

Nội dung các pack được quản lý qua danh mục

Mỗi node compaction nhận quyền sở hữu một tập dữ liệu con của repository thông qua một lease (hợp đồng thuê khóa), nhờ vậy có thể mở rộng theo chiều ngang. Node đọc danh mục để tìm pack mới, gom chúng vào một phân đoạn mở, và khi phân đoạn đạt ngưỡng về số pack, kích thước hoặc tuổi thì "niêm phong" nó lại rồi gộp thành ít pack lớn hơn. Trước khi công bố, node kiểm tra các pack mới chứa đúng các đối tượng như đầu vào, tải lên, thêm vào danh mục, rồi một giao dịch thứ hai gỡ các pack cũ ra.

Kết quả là số lượng pack gần như phẳng trong khi số push vẫn tăng. Compaction chỉ gộp pack chứ giữ lại mọi đối tượng; việc xóa các đối tượng không còn được tham chiếu (do nhánh bị xóa hay force-push) là nhiệm vụ của garbage collection, vận hành tương tự với các worker chuyên dụng.

Những gì GitHub dự định làm tiếp

GitHub cho biết kiến trúc này hiện đang ở giai đoạn private preview giới hạn, với kế hoạch mở rộng rộng rãi vào đầu năm sau. Trước mắt, họ tập trung vào ba hướng.

Thứ nhất là cải thiện hạ tầng: chỉ tải đúng đối tượng cần từ Blob Storage thay vì cả pack, nhóm pack theo loại (commit, tree, blob), replica một phần không cần toàn bộ pack trên đĩa, materialized view (chẳng hạn bản sao nông gần thời gian thực của nhánh mặc định), replica toàn cầu và khả năng mở rộng về 0.

Thứ hai là làm mỗi thao tác của agent rẻ hơn: làm việc không cần clone, API commit nguyên tử cho thay đổi nhiều file, và luồng sự kiện để agent phản ứng theo thời gian thực.

Thứ ba là cải tiến chính Git: hoàn thiện partial clone, shallow clone và sparse checkout để chúng phối hợp tốt với nhau, loại bỏ các đoạn mã chậm đi nhanh hơn tốc độ tăng của repository, tăng tốc duyệt lịch sử nhờ commit-graph, và cảnh báo sớm các lỗi phổ biến mà agent cũng như lập trình viên hay mắc.

Góc nhìn

Điểm đáng chú ý với các đội phát triển tại Việt Nam là kiến trúc này được thiết kế cho trường hợp một repository bận rộn chứ không chỉ cho nhiều repository. Nếu các agent lập trình trở thành công cụ quen thuộc trong quy trình làm việc, áp lực sẽ dồn vào những monorepo nội bộ hoặc các repository dùng chung cho nhiều nhóm. Việc GitHub hướng tới để mọi repository chạy chung một kiến trúc, không cần xử lý đặc biệt cho repo bận, nghĩa là một dự án nhỏ bỗng có cả một đội agent có thể vẫn giữ nguyên hạ tầng.

Về mặt kỹ thuật, cách tách riêng Ref-CAS và đưa compaction ra khỏi node phục vụ là gợi ý đáng tham khảo cho những ai tự vận hành hệ thống lưu trữ mã nguồn hoặc CI quy mô lớn: phần dữ liệu bất biến giao cho object storage, phần trạng thái nhỏ nhưng tranh chấp cao giao cho dịch vụ chuyên dụng. Tuy nhiên, cần lưu ý rằng đây là mô tả từ chính GitHub, tính năng mới chỉ ở dạng private preview giới hạn với lịch mở rộng vào đầu năm sau, nên các đội chưa cần điều chỉnh quy trình ngay.