Blacksmith telah mencapai peningkatan prestasi yang dramatik untuk cache GitHub Actions dengan melakukan kejuruteraan terbalik terhadap protokol dalaman platform dan melaksanakan proksi rangkaian yang telus. Pendekatan ini memberikan prestasi cache yang lebih pantas sehingga 10x tanpa memerlukan sebarang perubahan kod daripada pengguna.
Cabaran bermula apabila GitHub menghentikan sistem cache lama mereka memihak kepada perkhidmatan baharu berasaskan Twirp yang menggunakan Azure Blob Storage SDK. Daripada mengekalkan fork tindakan popular, jurutera Blacksmith memutuskan untuk memintas dan mengubah hala permintaan cache di peringkat rangkaian sambil membuatkan ia kelihatan masih sampai ke pelayan GitHub.
Peningkatan Prestasi:
- Kelajuan cache: Sehingga 10x lebih pantas daripada GitHub Actions standard
- Keserasian: 100% aliran kerja sedia ada disokong
- Perubahan kod diperlukan: Sifar
- Seni bina: Sistem proksi berbilang lapisan dengan NGINX peringkat VM dan penghalaan peringkat hos
 |
|---|
| Perwakilan visual pengoptimuman teknologi dan kecekapan dalam prestasi cache GitHub Actions |
Kejuruteraan Terbalik Protokol Cache Baharu GitHub
Pasukan menggunakan bantuan AI untuk menganalisis trafik rangkaian dan membina semula definisi protokol untuk perkhidmatan cache baharu GitHub. Mereka mendapati bahawa GitHub telah beralih daripada sistem berasaskan REST kepada sistem yang menggunakan Protocol Buffers dan TWIRP untuk komunikasi, dengan penyimpanan terus ke Azure Blob Storage melalui URL yang ditandatangani.
Seorang ahli komuniti yang bekerja pada kejuruteraan terbalik yang serupa menyebut kerumitan yang terlibat, menyatakan mereka terpaksa membina semula fail protobuf daripada kod yang dijana sehingga mencapai padanan bait-demi-bait dengan spesifikasi asal. Ini menunjukkan kedalaman teknikal yang diperlukan untuk projek sedemikian.
Seni Bina Proksi Rangkaian Berbilang Lapisan
Blacksmith melaksanakan sistem proksi yang canggih dengan berbilang lapisan. Di dalam setiap mesin maya, mereka mengkonfigurasi pelayan NGINX untuk mengarahkan permintaan ke proksi peringkat hos. Reka bentuk ini membolehkan mereka mengekalkan keadaan untuk muat naik dan muat turun sambil memastikan kawalan akses yang betul.
Azure SDK menimbulkan cabaran yang tidak dijangka. Apabila nama hos tidak sepadan dengan corak blob.core.windows.net Azure, SDK melumpuhkan banyak pengoptimuman konkurensi, menyebabkan kemerosotan prestasi yang ketara. Pasukan terpaksa membina semula URL yang serasi dengan Azure dan melaksanakan penghalaan trafik tersuai untuk mengekalkan prestasi.
Komponen Seni Bina Teknikal:
- Protokol: Perkhidmatan berasaskan Twirp baharu GitHub dengan Protocol Buffers
- Penyimpanan: Azure Blob Storage SDK dengan URL yang ditandatangani
- Proksi: NGINX (peringkat-VM) → Proksi peringkat-hos → Backend serasi S3 tersuai
- Penapisan Paket: nftables (menggantikan iptables untuk kestabilan yang lebih baik)
- Backend: Kluster MinIO yang dihoskan sendiri (serasi- S3 )
Daripada Kekacauan iptables kepada Ketepatan nftables
Percubaan awal menggunakan iptables untuk penapisan paket mencipta mimpi ngeri operasi. Dengan berbilang VM sementara yang sentiasa menambah dan mengeluarkan peraturan, sistem menjadi tidak stabil dan sukar diurus. Perbincangan komuniti mendedahkan ini adalah masalah biasa - seorang pembangun menggambarkan iptables sebagai tidak mempunyai antara muka programatik yang stabil dan menjadi mimpi ngeri keadaan perlumbaan.
Penyelesaian datang melalui nftables, yang menawarkan perubahan konfigurasi atom dan keupayaan ruang nama yang lebih baik. Ini membolehkan Blacksmith menguruskan peraturan setiap VM tanpa konflik, menjadikan sistem lebih dipercayai pada skala besar.
Cabaran Teknikal Utama yang Diselesaikan:
- Pengecaman nama hos Azure SDK untuk pengoptimuman konkurensi
- Ketidakstabilan iptables dengan VM sementara pada skala besar
- Pembinaan semula buffer protokol daripada kod yang dijana oleh GitHub
- Pengurusan peraturan atomik dengan ruang nama nftables
- Proksi dua hala antara protokol Azure Blob Storage dan AWS S3
Keputusan Prestasi dan Respons Industri
Peningkatan adalah besar - pelanggan melihat kelajuan cache sehingga 10x lebih pantas dengan daya pemprosesan yang jauh lebih tinggi berbanding GitHub Actions standard. Terutamanya, ini berfungsi dengan 100% aliran kerja sedia ada tanpa sebarang pengubahsuaian kod diperlukan.
Pendekatan ini telah menarik perhatian daripada pesaing dalam ruang pecutan CI/CD. Sesetengah syarikat telah melaksanakan strategi pengoptimuman cache yang serupa, manakala yang lain telah memilih untuk membina platform CI yang baharu sepenuhnya daripada bekerja dalam kekangan GitHub Actions.
Di RWX kami agak jemu dengan sentiasa cuba mengatasi batasan platform dengan pelari yang dihoskan sendiri, jadi kami hanya membina platform CI yang baharu sepenuhnya pada model pelaksanaan yang baharu.
Pencapaian teknikal ini menunjukkan bagaimana pengetahuan sistem yang mendalam dan kejuruteraan rangkaian yang kreatif boleh meningkatkan prestasi secara dramatik dalam persekitaran CI/CD awan, walaupun ketika bekerja dalam kekangan platform sedia ada.
Rujukan: Reverse engineering GitHub Actions cache to make it fast