この記事は後半です。前半は Qiita にあります: 5,000体のエージェントが押し寄せるGitHub、ロックを捨てた新ストレージの入口
前半では、GitHub がリポジトリ全体をひとまとめに扱うやり方では限界が来たこと、そして更新の同意範囲を参照ごとに縮めたことまで見た。ここから先で大事なのは、その変更が単なる高速化ではなく、待ち行列の作り方そのものを変えている点だ。
画像: github.blog より
旧構成の弱点は、1 件の書き込みがリポジトリ全体の進行を握ってしまうことだった。速い書き込みも遅い書き込みも同じ列に並び、遅いものが全体の足を引っ張る。参照単位に切り分けると、この詰まり方が消える。別のブランチに対する push は、同じリポジトリでも互いの進行を止めにくい。GitHub が内部テストで 3〜4 倍のスループット向上と低レイテンシを示したのは、この分離が効いているからだ。
ただし、これは「ロックを消した」わけではない。整合性が必要な場所だけを狭く縛っただけだ。Git の性質上、オブジェクト本体は内容で名前が決まり、変わらない。だから並列に置ける。一方で、どの参照をどのコミットに向けるかは順序が要る。GitHub はそこだけを厳密に扱う。見た目は軽くなっても、正しさの芯は残している。
画像: github.blog より
新アーキテクチャのもう一つの柱は、仮想レプリカだ。ここは永続データを抱え込む本体ではなく、需要に応じて増減する計算資源として置かれている。ローカルディスクも最終的な正本ではなく、いつでも作り直せるキャッシュだ。従来の「このノードがこのリポジトリの状態を持ち続ける」という考え方から、かなり離れている。
書き込みの流れはこうだ。仮想レプリカが incoming pack を受け取り、Blob Storage に上げる。そのあと Ref-CAS に 1 回のトランザクションを投げ、パックの一覧と参照をまとめて更新する。読み取りは逆に、Ref-CAS で参照の版を確認し、Blob Storage から必要なパックを引いてキャッシュに載せて返す。読み取りと書き込みが同じ器に閉じ込められていないので、片方の負荷がもう片方を丸ごと止めることが減る。
ここで面白いのは、キャッシュを「守るもの」ではなく「温め直せるもの」と見ていることだ。仮想レプリカが消えても、別の仮想レプリカが続きを引き継ぐ。キャッシュが飛んでも、正本は Blob Storage 側にある。これは運用上かなり強い。障害時に「そのノードの状態をどう救うか」より、「次のノードをどれだけ早く温めるか」に寄せられるからだ。
GitHub の主張はかなり明快だが、限界もはっきりしている。まず、書き込みの上限は参照の競合具合に依存する。別参照への push が多いと伸びやすいが、同じ参照に集中すると当然詰まる。つまり、同一ブランチへ連続で書き込む運用では、恩恵は小さくなる。
次に、読み取りの伸び方も万能ではない。Blob Storage からの取得や、キャッシュの温まり方には現実的なコストがある。GitHub も、読み取りは需要に応じて広げられる一方で、最初は背景で整合を取りながら動くため、あらゆる読み取りに同じように効くわけではないと示している。すぐに全データが手元にある前提ではないので、必要な状態だけを素早く引けるようにしていく段階が残る。
さらに、コンパクションの存在も無視できない。パックをまとめ直し、不要なオブジェクトを掃除する作業は、読み取り性能を守るために必要だが、ただの副作用ではなく別の仕事として走る。GitHub はこれを仮想レプリカから切り離し、バックグラウンドの compaction node に寄せている。つまり、速さは「何もしない」ことで出しているのではなく、裏方を別にしたから出ている。
この設計が刺さるのは、巨大なモノレポだけではない。実際には、CI が多い、ボットが多い、細かい修正が大量に流れる、といった運用で効く。特に、同じリポジトリに対して複数の自動化が並走する環境では、参照単位に分けた更新が効きやすい。人間が少人数で触るだけの場面なら、ここまでの仕組みは過剰かもしれない。
自分なら、まず「同じ参照にどれだけ書き込みが集中しているか」を見る。そこが偏っているなら、アーキテクチャをどれだけ新しくしても、体感はそこまで変わらないはずだ。逆に、複数のブランチや一時的な検証用参照に書き込みが散っているなら、この設計の恩恵は大きい。待ち時間が減るだけでなく、障害時の復旧も見通しやすくなる。
GitHub が今回明かしたのは、派手な数値よりも、その数字を支える切り方だ。リポジトリ全体をひとつの箱として守る発想をやめ、参照、オブジェクト、キャッシュ、コンパクションを別々に扱う。だから 5,000 体のエージェントでも、7,200 push/秒でも、ただの誇張で終わらない。もちろん、全ての場面を救う設計ではない。それでも、Git を「1 回の書き込みで全体が止まる仕組み」から少しずつ外していく方向としては、かなり筋がいい。
