Cursor đã giải quyết bài toán mở rộng Git như thế nào

Các nhà phát triển từng gặp sự cố với các đợt outage của GitHub gần đây nên biết rằng vẫn có những cách khác để quản lý Git ở quy mô lớn. Một trong số đó, được Cursor triển khai gần đây, là xây dựng hệ thống quản lý phiên bản phân tán dựa trên lưu trữ đối tượng.

Trong một bài đăng mới, kỹ sư hệ thống chính Vicent Martí của Cursor đã giải thích cách công ty con của SpaceX xử lý các vấn đề mở rộng với hệ thống Git vốn nổi tiếng khó tính. Bài viết mô tả kiến trúc của Origin — dịch vụ kho lưu trữ Git do Cursor tự phát triển, chạy trên nền tảng engine nội bộ có tên Continuity. Bản beta của dịch vụ này hiện đã có trong các gói trả phí của Cursor.

"Các tác nhân AI đã thay đổi hoàn toàn cách chúng ta làm việc với phần mềm, và theo nhiều cách, chúng khiến tình hình tồi tệ hơn. Nhiều mã hơn, nhiều PR hơn, nhiều lần chạy CI hơn. Quản lý phiên bản là cốt lõi của tất cả những điều này, và có lẽ là thứ khó thay đổi nhất qua một đêm," Martí viết.

Martí có nhiều năm kinh nghiệm làm việc tại GitHub trong phần lớn thập kỷ qua, khi công ty đạt đến kiến trúc hiện tại để quản lý Git.

Đồng bộ hóa là điểm nghẽn

Linus Torvalds, cha đẻ của Git, thiết kế phần mềm này hoạt động như một kho dữ liệu định địa chỉ theo nội dung (content-addressable data store), nơi mọi đối tượng được lưu trữ và đánh chỉ mục bằng hàm băm SHA-1 của nội dung. Git xem một kho lưu trữ như một đồ thị có hướng không chu trình (DAG), với mỗi commit là một nút trong đồ thị, kết nối với nhau bằng các con trỏ.

Một máy chủ Git có thể tra cứu trực tiếp một đối tượng bằng SHA của nó, nhưng nếu không có sẵn SHA, nó "phải duyệt từng bước qua toàn bộ DAG", Martí giải thích.

Khách hàng có thể chỉ muốn tải về một gói tin (packfile) gộp của kho lưu trữ, hoặc lấy danh sách các thay đổi gần đây, nhưng để đáp ứng các yêu cầu này, máy chủ buộc phải duyệt toàn bộ đồ thị chỉ để thu thập các đối tượng cần thiết.

Hãy thử tưởng tượng cung cấp dịch vụ như vậy cho hơn 400 triệu kho lưu trữ — bạn sẽ hình dung được quy mô mà GitHub đang vận hành (hoặc đang chật vật). Sau nhiều lần thử nghiệm, các kỹ sư GitHub đã chốt giải pháp gọi là Spokes, về cơ bản là giữ ít nhất ba bản sao đồng bộ chặt chẽ của mỗi kho lưu trữ trên các ổ NVMe tốc độ cao.

Cách tiếp cận này trở thành tiêu chuẩn ngành, nhưng theo thời gian, giới hạn của nó dần lộ rõ; vấn đề chính là càng tạo nhiều bản sao, thời gian đồng bộ càng kéo dài. Và Git không hoạt động tốt với mô hình "nhất quán cuối cùng" (eventual consistency), Martí giải thích.

Thêm vào đó, các tác nhân AI ngày nay cũng gây ra sự hỗn loạn riêng của chúng.

"Khi các tác nhân AI làm việc với kho lưu trữ Git ở quy mô lớn, chúng thường hoạt động ngoài phạm vi monorepo bằng cách tạo ra một số lượng khổng lồ các kho lưu trữ nhỏ, nhiều cái chỉ dùng một lần rồi bỏ, và hầu hết hầu như không được chạm tới," Martí viết.

Lưu trữ đối tượng đến giải cứu

Khi Cursor bắt tay xây dựng hệ thống Git riêng, họ chuyển sang lưu trữ đối tượng. Khác với lưu trữ tệp (file storage) hay khối (block storage), lưu trữ đối tượng gán cho mỗi phần dữ liệu một định danh duy nhất và xếp chúng vào một không gian tên duy nhất (không có thư mục).

Lưu trữ đối tượng phổ biến nhất hiện nay là Amazon Simple Storage Service (S3) của AWS, ngày càng được dùng làm lớp nền tảng cho các phần mềm doanh nghiệp như cơ sở dữ liệu, kho chứa container và message broker nhờ chi phí thấp, độ dự phòng tích hợp sẵn và khả năng mở rộng gần như vô hạn.

Với Origin, các thao tác push được tải lên S3 dưới dạng nhật ký ghi trước (write-ahead log — WAL), ghi lại mọi thay đổi dưới dạng đối tượng bất biến. Khi có thể, các thay đổi được gộp lại để tăng tốc độ truyền tải.

Đồng thời, các push được ghi vào bản sao "tham chiếu" cục bộ của kho lưu trữ (thường là ổ NVMe). Sau khi cả hai thao tác hoàn tất, các bản sao khác của kho lưu trữ có thể tải về các thay đổi khi cần.

"Chỉ cần đồng bộ giao dịch tham chiếu với một kho lưu trữ cục bộ duy nhất thay vì một nhóm bản sao, chúng tôi có một hệ thống có thể tiếp nhận các push nhanh như tốc độ đĩa cho phép," Martí viết.

Git vẫn phải thực hiện duyệt DAG cho nhiều thao tác, nhưng tốt hơn là làm việc đó cục bộ trên ổ SSD tốc độ cao thay vì qua mạng.

"Mỗi kho lưu trữ nằm ở đâu? Câu trả lời là 'bất cứ đâu'. Không quan trọng! Chúng tôi coi kho lưu trữ như một bộ nhớ đệm ấm trên đĩa, nhưng nguồn dữ liệu gốc luôn luôn là write-ahead log," Martí nhấn mạnh.

Chúng ta sẽ thấy cách tiếp cận này hoạt động hiệu quả ra sao khi Origin chính thức trở thành dịch vụ production. Nhưng nếu không thấy các câu chuyện về sự cố Origin trong thời gian tới, các nhà quản lý Git sẽ biết rằng lưu trữ đối tượng đáng để xem xét nghiêm túc.

Các chủ đề liên quan: CI/CD, AWS, DevOps, GitHub, Git, tác nhân AI