GitHub rombak penyimpanan Git agar sanggup menampung tulisan sebanyak era agent
GitHub sedang memindahkan repositori Git sedunia dari pusat data miliknya ke Azure, dan sebuah tulisan engineering baru menjelaskan bagian tersulit yang masih tersisa. Proses penyalinannya hampir rampung: sekitar 99,99999% repositori kini berada di Azure, kebanyakan dengan dua dari lima replika di sana, dan Azure sudah melayani sekitar separuh dari seluruh lalu lintas Git. Masalahnya ada pada repositori yang paling sibuk. Setiap penulisan harus menunggu replika yang berjarak sekitar 25 milidetik, dan perjalanan bolak-balik itulah yang membuat repo terberat sulit berpindah dengan mulus.
Solusinya adalah berhenti memperlakukan satu repositori sebagai satu unit untuk koordinasi penulisan. GitHub kini menjalankan quorum terpisah untuk tiap Git reference, sehingga push ke satu branch tidak lagi menunggu push ke branch lain. Dalam pengujian, cara ini menaikkan throughput penulisan tiga sampai empat kali lipat dengan latensi lebih rendah. Di lapisan bawah, data repositori tersimpan secara durable di Azure Blob Storage, dan sebuah "virtual write replica" yang bersifat sementara mengalirkan tulisan ke penyimpanan itu, menggabungkan penulisan bersamaan ke dalam round trip yang dipakai bersama, dan baru memberi acknowledge setelah data benar-benar durable. Replika baca memanaskan cache dari object storage yang sama dan melayani baca tanpa ikut quorum, sehingga penskalaan baca terpisah dari koordinasi tulis. Repo yang berat di sisi baca menghadapi 100 hingga 1.000 baca per satu tulis, jadi pemisahan ini berarti.
Angka skalanya memberi gambaran beban kerjanya. Spokes, lapisan routing dan quorum, menangani jauh di atas 100 miliar operasi per hari. GitHub menyebut akan ada tulisan lanjutan yang menjelaskan kondisi akhirnya, dan bahwa sebuah grup konsensus kecil tetap ada dalam tumpukan sistemnya.
Kenapa ini penting
Kalau Anda mengelola repositori besar atau mengarahkan banyak coding agent ke sana, latensi penulisan adalah tembok pertama yang Anda hantam, dan GitHub sedang membangun ulang lapisan penyimpanannya khusus untuk itu. Desain per reference juga memberi petunjuk soal rencana para penyedia kode menangani banyak agent yang menulis ke satu repo sekaligus, hal yang layak dipantau jika Anda sedang merancang alur kerja berbasis agent.