Blacksmith đã đạt được những cải thiện hiệu suất đáng kể cho bộ nhớ đệm GitHub Actions bằng cách reverse engineering các giao thức nội bộ của nền tảng này và triển khai network proxying trong suốt. Phương pháp này mang lại hiệu suất cache nhanh hơn tới 10 lần mà không yêu cầu người dùng phải thay đổi bất kỳ dòng code nào.
Thách thức bắt đầu khi GitHub ngừng hỗ trợ hệ thống cache cũ để chuyển sang dịch vụ mới dựa trên Twirp sử dụng Azure Blob Storage SDK . Thay vì duy trì các fork của các action phổ biến, các kỹ sư của Blacksmith quyết định chặn và chuyển hướng các yêu cầu cache ở tầng mạng trong khi vẫn làm cho chúng có vẻ như đang tiếp cận máy chủ của GitHub .
Cải thiện hiệu suất:
- Tốc độ cache: Nhanh hơn tới 10 lần so với GitHub Actions tiêu chuẩn
- Tương thích: Hỗ trợ 100% các workflow hiện có
- Thay đổi code cần thiết: Bằng không
- Kiến trúc: Hệ thống proxy đa lớp với NGINX cấp VM và định tuyến cấp host
 |
|---|
| Biểu diễn trực quan về tối ưu hóa công nghệ và hiệu quả trong hiệu suất cache của GitHub Actions |
Reverse Engineering giao thức Cache mới của GitHub
Đội ngũ đã sử dụng hỗ trợ AI để phân tích lưu lượng mạng và tái tạo các định nghĩa giao thức cho dịch vụ cache mới của GitHub . Họ phát hiện ra rằng GitHub đã chuyển từ hệ thống dựa trên REST sang hệ thống sử dụng Protocol Buffers và TWIRP để giao tiếp, với việc lưu trữ trực tiếp lên Azure Blob Storage thông qua các URL đã ký.
Một thành viên cộng đồng đã từng làm việc với reverse engineering tương tự đã lưu ý về độ phức tạp liên quan, đề cập rằng họ phải tái tạo các file protobuf từ code đã được tạo ra cho đến khi đạt được sự khớp từng byte với các đặc tả gốc. Điều này làm nổi bật độ sâu kỹ thuật cần thiết cho những dự án như vậy.
Kiến trúc Network Proxying đa tầng
Blacksmith đã triển khai một hệ thống proxying tinh vi với nhiều tầng. Bên trong mỗi máy ảo, họ cấu hình các máy chủ NGINX để định tuyến các yêu cầu đến các proxy cấp host. Thiết kế này cho phép họ duy trì trạng thái cho việc upload và download trong khi đảm bảo kiểm soát truy cập phù hợp.
Azure SDK đã tạo ra những thách thức bất ngờ. Khi hostname không khớp với pattern blob.core.windows.net của Azure , SDK sẽ vô hiệu hóa nhiều tối ưu hóa đồng thời, gây ra sự suy giảm hiệu suất đáng kể. Đội ngũ phải xây dựng lại các URL tương thích với Azure và triển khai định tuyến lưu lượng tùy chỉnh để duy trì hiệu suất.
Các Thành Phần Kiến Trúc Kỹ Thuật:
- Giao thức: Dịch vụ mới dựa trên Twirp của GitHub với Protocol Buffers
- Lưu trữ: Azure Blob Storage SDK với signed URLs
- Proxy: NGINX (cấp VM) → Proxy cấp Host → Backend tương thích S3 tùy chỉnh
- Lọc gói tin: nftables (thay thế iptables để có độ ổn định tốt hơn)
- Backend: Cụm MinIO tự lưu trữ (tương thích S3)
Từ sự hỗn loạn của iptables đến độ chính xác của nftables
Các nỗ lực ban đầu sử dụng iptables để lọc gói tin đã tạo ra những cơn ác mộng về vận hành. Với nhiều VM tạm thời liên tục thêm và xóa các quy tắc, hệ thống trở nên không ổn định và khó quản lý. Cuộc thảo luận cộng đồng tiết lộ đây là một vấn đề phổ biến - một developer đã mô tả iptables như không có giao diện lập trình ổn định và là một cơn ác mộng về race condition.
Giải pháp đến thông qua nftables , cung cấp các thay đổi cấu hình nguyên tử và khả năng namespace tốt hơn. Điều này cho phép Blacksmith quản lý các quy tắc cho mỗi VM mà không xung đột, làm cho hệ thống đáng tin cậy hơn nhiều ở quy mô lớn.
Các Thách Thức Kỹ Thuật Chính Đã Được Giải Quyết:
- Tối ưu hóa nhận diện hostname của Azure SDK cho xử lý đồng thời
- Tính không ổn định của iptables với các VM tạm thời ở quy mô lớn
- Tái cấu trúc protocol buffer từ mã được tạo ra của GitHub
- Quản lý quy tắc nguyên tử với namespacing của nftables
- Proxy hai chiều giữa các giao thức Azure Blob Storage và AWS S3
Kết quả hiệu suất và phản ứng của ngành
Những cải thiện là đáng kể - khách hàng thấy tốc độ cache nhanh hơn tới 10 lần với throughput cao hơn đáng kể so với GitHub Actions tiêu chuẩn. Đáng chú ý, điều này hoạt động với 100% các workflow hiện có mà không cần bất kỳ sửa đổi code nào.
Phương pháp này đã thu hút sự chú ý từ các đối thủ cạnh tranh trong không gian tăng tốc CI/CD. Một số công ty đã triển khai các chiến lược tối ưu hóa cache tương tự, trong khi những công ty khác đã chọn xây dựng hoàn toàn các nền tảng CI mới thay vì làm việc trong các ràng buộc của GitHub Actions .
Tại RWX chúng tôi đã hơi mệt mỏi với việc liên tục cố gắng khắc phục các hạn chế của nền tảng với self-hosted runner, vì vậy chúng tôi chỉ xây dựng một nền tảng CI hoàn toàn mới trên một mô hình thực thi hoàn toàn mới.
Thành tựu kỹ thuật này chứng minh cách kiến thức hệ thống sâu sắc và kỹ thuật mạng sáng tạo có thể cải thiện hiệu suất một cách đáng kể trong môi trường cloud CI/CD, ngay cả khi làm việc trong các ràng buộc của các nền tảng hiện có.
Tham khảo: Reverse engineering GitHub Actions cache to make it fast