Blacksmith telah mencapai peningkatan performa yang dramatis untuk cache GitHub Actions dengan melakukan reverse engineering terhadap protokol internal platform dan mengimplementasikan network proxying yang transparan. Pendekatan ini memberikan performa cache hingga 10x lebih cepat tanpa memerlukan perubahan kode apapun dari pengguna.
Tantangan dimulai ketika GitHub menghentikan sistem cache lama mereka dan beralih ke layanan baru berbasis Twirp yang menggunakan Azure Blob Storage SDK. Daripada memelihara fork dari actions populer, para engineer Blacksmith memutuskan untuk mencegat dan mengalihkan permintaan cache di tingkat jaringan sambil membuatnya tampak masih mencapai server GitHub.
Peningkatan Performa:
- Kecepatan cache: Hingga 10x lebih cepat dibandingkan GitHub Actions standar
- Kompatibilitas: 100% workflow yang ada didukung
- Perubahan kode yang diperlukan: Nol
- Arsitektur: Sistem proxy multi-layer dengan NGINX tingkat VM dan routing tingkat host
 |
|---|
| Representasi visual dari optimisasi teknologi dan efisiensi dalam performa cache GitHub Actions |
Reverse Engineering Protokol Cache Baru GitHub
Tim menggunakan bantuan AI untuk menganalisis lalu lintas jaringan dan merekonstruksi definisi protokol untuk layanan cache baru GitHub. Mereka menemukan bahwa GitHub telah beralih dari sistem berbasis REST ke sistem yang menggunakan Protocol Buffers dan TWIRP untuk komunikasi, dengan penyimpanan langsung ke Azure Blob Storage melalui signed URL.
Salah satu anggota komunitas yang bekerja pada reverse engineering serupa mencatat kompleksitas yang terlibat, menyebutkan bahwa mereka harus merekonstruksi file protobuf dari kode yang dihasilkan hingga mencapai kecocokan byte-for-byte dengan spesifikasi asli. Ini menunjukkan kedalaman teknis yang diperlukan untuk proyek semacam ini.
Arsitektur Network Proxying Multi-Layer
Blacksmith mengimplementasikan sistem proxying yang canggih dengan beberapa lapisan. Di dalam setiap virtual machine, mereka mengkonfigurasi server NGINX untuk merutekan permintaan ke proxy tingkat host. Desain ini memungkinkan mereka mempertahankan state untuk upload dan download sambil memastikan kontrol akses yang tepat.
Azure SDK menghadirkan tantangan yang tidak terduga. Ketika hostname tidak cocok dengan pola blob.core.windows.net milik Azure, SDK menonaktifkan banyak optimisasi konkurensi, menyebabkan degradasi performa yang signifikan. Tim harus membangun kembali URL yang kompatibel dengan Azure dan mengimplementasikan routing lalu lintas khusus untuk mempertahankan performa.
Komponen Arsitektur Teknis:
- Protokol: Layanan berbasis Twirp baru dari GitHub dengan Protocol Buffers
- Penyimpanan: Azure Blob Storage SDK dengan signed URL
- Proxying: NGINX (tingkat VM) → Proxy tingkat Host → Backend kustom yang kompatibel dengan S3
- Packet Filtering: nftables (menggantikan iptables untuk stabilitas yang lebih baik)
- Backend: Kluster MinIO yang di-hosting sendiri (kompatibel dengan S3)
Dari Kekacauan iptables ke Presisi nftables
Upaya awal menggunakan iptables untuk filtering paket menciptakan mimpi buruk operasional. Dengan beberapa VM ephemeral yang terus-menerus menambah dan menghapus aturan, sistem menjadi tidak stabil dan sulit dikelola. Diskusi komunitas mengungkapkan bahwa ini adalah masalah umum - salah satu developer menggambarkan iptables sebagai tidak memiliki antarmuka programatik yang stabil dan menjadi mimpi buruk race condition.
Solusi datang melalui nftables, yang menawarkan perubahan konfigurasi atomik dan kemampuan namespacing yang lebih baik. Ini memungkinkan Blacksmith mengelola aturan per VM tanpa konflik, membuat sistem jauh lebih andal dalam skala besar.
Tantangan Teknis Utama yang Berhasil Diselesaikan:
- Pengenalan hostname Azure SDK untuk optimasi konkurensi
- Ketidakstabilan iptables dengan VM sementara dalam skala besar
- Rekonstruksi protocol buffer dari kode yang dihasilkan GitHub
- Manajemen aturan atomik dengan namespacing nftables
- Proxying dua arah antara protokol Azure Blob Storage dan AWS S3
Hasil Performa dan Respons Industri
Peningkatannya sangat substansial - pelanggan melihat kecepatan cache hingga 10x lebih cepat dengan throughput yang jauh lebih tinggi dibandingkan GitHub Actions standar. Yang patut dicatat, ini bekerja dengan 100% workflow yang ada tanpa memerlukan modifikasi kode apapun.
Pendekatan ini telah menarik perhatian dari kompetitor di ruang akselerasi CI/CD. Beberapa perusahaan telah mengimplementasikan strategi optimisasi cache serupa, sementara yang lain memilih untuk membangun platform CI yang sepenuhnya baru daripada bekerja dalam batasan GitHub Actions.
Di RWX kami agak lelah terus-menerus mencoba mengatasi keterbatasan platform dengan self-hosted runner, jadi kami hanya membangun platform CI yang sepenuhnya baru dengan model eksekusi yang benar-benar baru.
Pencapaian teknis ini menunjukkan bagaimana pengetahuan sistem yang mendalam dan network engineering yang kreatif dapat secara dramatis meningkatkan performa dalam lingkungan cloud CI/CD, bahkan ketika bekerja dalam batasan platform yang ada.
Referensi: Reverse engineering GitHub Actions cache to make it fast