GitHub、Git基盤を刷新　「エージェント5000体」が1つのrepoに同時push

米GitHubは11月5日（米国時間）、新しいGit保存基盤の仕組みを説明する技術記事を公開した。社内の試験では、5000体のエージェントが1つのリポジトリで同時に作業し、毎秒7200回のpushを送っても、読み出しの遅延は低いまま保てたという。設計の核は、pushのうち順番をそろえる必要があるのはブランチなどの参照の更新だけだ、という見立てにある。並列で動くコーディングエージェントが同じrepoに次々と書き込んでも、Gitの使い方を変えずに受け止める土台になる。

1つのrepoへの書き込みが急増する

GitHubの記事によると、今いちばん忙しいrepoでも、書き込みは1秒あたり多くて数十回で、それも短い山として来る。エージェントが並列に、昼夜を問わず動くようになると、この山が1年以内に途切れない流れになると同社はみる。しかもpushのたびにCIが走り、デプロイの仕組みが新しいコミットを取りに来て、ほかのエージェントも文脈を得るためにfetchする。書き込み1回が、何倍もの読み出しを呼ぶわけだ。

実際、あるrepoへの1日の要求数は3月から5月で約4倍に増え、その後も指数関数的に伸びているという。そこで同社は、次の一段ではなく、少なくとも今の100倍の規模を目標に置いた。1つのrepoで毎秒数千の書き込みを受け、書き込みを複数のノードで処理し、pushの待ち時間を短くする。エージェントは1回のpushが終わるまで次の手順に進めないからだ。

合意が要るのは参照の更新だけ

Gitのオブジェクトは中身から名前が決まり、後から変わらない。だから2つの書き手が同時に保存しても、互いに何も取り決めなくてよい。順番をそろえる必要があるのは参照の更新で、これはpush全体に比べてごく小さい。新しい基盤「Rubicon」はこの点を軸に組まれた。

pushが来ると、使い捨てのサーバー群「仮想レプリカ」が受け取ったパックを索引付けして「Azure Blob Storage」に上げる。次に、参照専用の複製ログ「Ref-CAS」に1回のトランザクションを確定させ、参照を更新する。Ref-CASは、各参照が書き手の期待する値のままかを確かめてから書き換える仕組みだ。エージェントは主に自分のブランチにpushするので、更新はほとんどぶつからず、並列に進む。

同社は先に、参照の状態を丸ごとBlob Storageに置く案も試したが、書き込みは毎秒数百回の半ばで頭打ちになった。参照を分けて置く案では、読み出しのたびに全部の分割を確かめる必要があり、読み出しが遅くなった。Ref-CASなら参照の更新だけで毎秒数万回の操作をこなせるという。読み出し側も、手元の版が最新ならやりとりは比較1回で済む。書き込みより読み出しの方が桁違いに多いので、この軽さが効く。

掃除は配信と別のノードで

pushのたびにパックが1つ増え、放っておくと読み出しが遅くなる。従来は、要求をさばくレプリカ自身がパックをまとめる圧縮を担っていた。新しい基盤では、専用の圧縮ノードがBlob Storageに直接つないで裏で処理する。結果として、pushが増えてもパックの数はほぼ横ばいで、書き込みが増えても遅延の曲線は平らなままだったと同社は書く。使われなくなったオブジェクトを消すガベージコレクションも、同じく専用の作業ノードに任せる。

クローン不要の作業も視野に

新しい基盤は限定のプライベートプレビューで提供中で、広い展開は来年初めを予定する。同社は次の手として、全体をクローンせずにサーバーから必要なファイルだけを読む作業、複数ファイルの変更を1回で確定し衝突時はきれいに拒む「アトミックなコミットAPI」、変更を購読できるイベントストリームを挙げた。Git本体でも、部分クローンや「sparse checkout」がうまく組み合うよう改善を続けるという。

要は、順番をそろえる範囲を参照の更新だけに絞ったことで、1つのrepoに数千のエージェントが押し寄せても、開発者は今までどおりGitを使える。

編集部の見方

並列のエージェントを1つのrepoで回すチームにとって、pushの待ちやCIの読み出しの集中は、すでに目に見える詰まりになりつつある。GitHubの記事は、その詰まりを基盤の側で引き受ける意思表示と読める。手元で効くのは、むしろ次の手として挙げたクローン不要の作業とアトミックなコミットAPIだ。エージェントごとにブランチを分けて書く今の運用は、Ref-CASの「更新がぶつからない」前提ともかみ合う。ただし数字は社内試験の値で、プレビューの対象や料金はまだ示されていない。