Ing. Calogero Bono
GitHub telah menjelaskan Rubicon, arsitektur penyimpanan Git baru yang diumumkan di GitHub Universe. Menurut perusahaan, dalam pengujian internal sistem ini mampu menahan 5.000 agen bersamaan pada satu repository, dengan 7.200 push per detik dan pembacaan berlatensi rendah. Hal ini penting karena agen pemrograman mengubah beban repository, dan apa yang kuat ditopang GitHub hari ini mungkin tidak cukup setahun lagi.
Beberapa istilah sebelum masuk ke faktanya. Agen adalah program AI yang menulis kode dan melakukan push sendiri. Reference adalah penunjuk ke sebuah commit, seperti sebuah branch. Pack adalah berkas yang mengumpulkan objek Git. Compare-and-swap adalah operasi yang memperbarui sebuah nilai hanya jika tidak ada yang mengubahnya dalam waktu bersamaan. Blob Storage adalah layanan penyimpanan objek milik Azure.
Apa itu Rubicon dan mengapa GitHub membangunnya?
Rubicon adalah nama proyek yang dengannya GitHub merancang ulang cara menyimpan dan menyajikan data Git. Menurut artikel GitHub, pekerjaan ini dimulai pada Mei 2026, tepat setelah migrasi awal ke Azure.
Alasannya adalah beban kerja. GitHub menyatakan bahwa repository paling sibuk saat ini menerima paling banyak puluhan penulisan per detik, dalam ledakan singkat. Dengan agen yang bekerja paralel dan terus-menerus, GitHub memperkirakan ritme itu akan menjadi konstan dalam setahun. Karena itu, ia menetapkan target setidaknya dua orde magnitudo lebih tinggi.
Persyaratan skala apa yang ditetapkan GitHub?
GitHub membedakan dua sumbu. Skala horizontal menyangkut banyak repository, dan di sini solusi yang sudah teruji seperti partisi dan routing berdasarkan beban tetap dipakai. Skala vertikal menyangkut satu repository yang sangat besar dan sibuk, dan dari sinilah hampir semua persyaratan berasal.
Untuk satu repository, arsitektur harus mampu menerima ribuan penulisan per detik dan mendukung banyak node penulisan. Arsitektur juga harus menurunkan latensi commit, karena agen menunggu setiap push sebelum melangkah berikutnya. Setiap push juga menghasilkan lebih banyak pembacaan, dari CI, deploy, dan agen lain, dan GitHub berbicara tentang efek amplifikasi yang kuat.
Salah satu contoh yang disebut adalah repository yang lalu lintas hariannya tumbuh sekitar 4 kali lipat antara Maret dan Mei.
Bagaimana arsitektur baru ini bekerja?
Gagasan dasarnya adalah bahwa kesepakatan hanya diperlukan untuk pembaruan reference. Objek Git bersifat immutable dan diidentifikasi dari isinya, sehingga beberapa penulis dapat menyimpannya bersamaan. Dengan begitu, penyimpanan, pelayanan permintaan, dan pemeliharaan dapat diskalakan secara independen.
Permintaan masuk ke Spokes, yang tetap mengurus routing dan penyeimbangan beban. Di bawahnya ada bidang data baru, dengan replika virtual, komputasi sekali pakai yang disk lokalnya hanya cache yang bisa dibangun ulang. Status yang tahan lama berada di dua tempat.
- Pack dan data akselerasi di Azure Blob Storage.
- Reference dan daftar pack (manifest) di Ref-CAS, sebuah layanan log yang direplikasi.
Sebuah penulisan mengindeks pack, mengunggahnya ke Blob Storage, lalu melakukan satu transaksi di Ref-CAS. Sebuah pembacaan memeriksa versi reference, mengunduh pack yang belum ada, dan merespons dari cache. Kompaksi pack berjalan di node terpisah, tidak pernah di replika.
Apakah ada dampaknya bagi yang menggunakan Git setiap hari?
Menurut GitHub, tidak. Git tetap Git, dengan push, fetch, dan branch yang bekerja dengan cara yang sama dan proteksi yang sama. Perubahannya terjadi di balik layar dan dijalankan sementara platform tetap beroperasi.
Topik ini berkaitan dengan apa yang sedang terjadi pada alat Git untuk agen, seperti kasus OpenAI mengakuisisi Pierre. Bagi yang sudah mahir dengan perintah dasar, misalnya dengan Git bisect dan blame, tidak perlu mengubah kebiasaan.
Batasan yang perlu kamu ketahui
Angka 5.000 agen dan 7.200 push per detik berasal dari pengujian internal yang dinyatakan GitHub, tanpa verifikasi pihak luar. Teks yang tersedia terpotong sebelum rincian dua komponen yang dibahas mendalam, sehingga kita belum mengetahui trade-off teknisnya. Tanggal adopsi lengkap untuk seluruh repository belum tersedia.
Apa dampaknya bagi yang bekerja dengan digital
Untuk agensi atau tim kecil, dalam waktu dekat hampir tidak ada dampaknya. Namun ada poin lain yang perlu diperhatikan. Jika alur kerjamu menggunakan agen yang sering melakukan push, GitHub sedang bersiap agar sistemnya tetap kuat. Tetap berguna untuk mengevaluasi pipeline-mu sendiri, karena setiap push memicu rangkaian pembacaan, seperti yang dijelaskan juga dalam perbandingan GitLab CI/CD dan GitHub Actions. Bagi yang membangun platform dengan banyak klien, prinsip memisahkan komputasi dan data layak diperhatikan, topik yang dekat dengan multi-tenant.
Pendapat kami
Rubicon adalah proyek rekayasa yang serius, dan gagasan mengoordinasikan hanya reference itu elegan. Namun namanya juga menyiratkan hal lain. GitHub menganggap beban agen sebagai titik tanpa jalan kembali, dan menganggapnya sebagai kepastian. Masih perlu dilihat apakah pertumbuhannya benar-benar seperti yang diperkirakan, atau apakah pengujian sintetis melebih-lebihkan penggunaan nyata. Yang dibutuhkan adalah data independen, bukan hanya data dari penyedia.
Pertanyaan yang sering diajukan
Apa itu Project Rubicon dari GitHub?
Itu adalah arsitektur penyimpanan Git baru dari GitHub, yang diumumkan di GitHub Universe. Arsitektur ini memisahkan penyimpanan dan komputasi serta hanya mengoordinasikan pembaruan reference.
Berapa push per detik yang bisa ditangani?
Dalam pengujian internal, GitHub menyatakan 7.200 push per detik pada satu repository, dengan 5.000 agen bersamaan. Itu data dari perusahaan dan belum diverifikasi pihak ketiga.
Apakah saya harus mengubah cara menggunakan Git?
Tidak. Menurut GitHub, push, fetch, dan branch tetap bekerja seperti biasa, dengan proteksi yang sama.
Di mana data disimpan?
Pack disimpan di Azure Blob Storage. Reference dan daftar pack disimpan di Ref-CAS, sebuah layanan log yang direplikasi.
Mengapa sebuah repository membutuhkan lebih banyak replika?
Karena mengindeks pack dan memeriksa keterhubungan objek memakan banyak CPU. Lebih banyak node mendistribusikan pekerjaan dan meningkatkan toleransi kesalahan.
Hal yang perlu diperhatikan saat Rubicon hadir di repository semua orang
Ujian sesungguhnya adalah ketika angka internal berpindah ke repository nyata. Berikut yang perlu kamu pantau.
- Ikuti artikel lanjutan dari seri GitHub tentang dua komponen yang dibahas mendalam, untuk memahami trade-off-nya.
- Periksa apakah waktu push dan fetch pada repository-mu berubah dalam beberapa bulan ke depan.
- Pastikan apakah GitHub mempublikasikan batasan atau aturan penggunaan untuk agen dengan push paralel yang banyak.
