GitHubコミット急増、Git基盤を再構築

GitHubのプリンシパルソフトウェアエンジニア、Brian Celenza氏は10月6日、公式エンジニアリングブログでGitストレージ層を再構築していることを明らかにした。理由は明快で、AIエージェントが書き込みトラフィックを既存アーキテクチャの限界まで押し上げたためだという。社内ベンチマークでは、新アーキテクチャにより書き込みスループットが最大35倍向上した。

記事では過去1年の成長データが示されている。

最も負荷の高い単一リポジトリは、8月だけで約10億件のリクエストを受けた。エージェントの書き込み挙動について記事はこう表現している。

"An agent in a tight loop commits or checkpoints after nearly every action"

（ループ処理するエージェントは、ほぼ1アクションごとにコミットやチェックポイントを行う）

旧アーキテクチャは書き込みで限界に

GitHubの既存リポジトリストレージシステムは「Spokes」と呼ばれる。各リポジトリは標準で複数のファイルサーバーのローカルディスクに完全なコピーを保持し、合計5レプリカを持つ。プッシュで参照を更新する際は、多数決方式の3フェーズコミットプロトコルにより、CI、Webサイト、APIクライアントが一貫したリポジトリの状態を参照できるようにしている。

この設計では、レプリカがデータ損失防止と読み取りトラフィックの分散という2つの役割を同時に担う。代償として、すべてのレプリカが書き込みごとに関与する必要があり、レプリカを増やして読み取り性能を上げるほど書き込みは遅くなる。人間の開発者が主体で読み取りが書き込みを大きく上回っていた時代には問題にならなかったが、エージェントが書き込み頻度を引き上げたことで、レプリカ数そのものが書き込みのボトルネックになった。

新アーキテクチャは3層に分割

1つ目は協調処理の最小化だ。各者間の合意が必要な作業は参照更新のみとし、オブジェクトストレージ、検証、セキュリティスキャンは並列処理に変更した。

2つ目はストレージとコンピュートの分離だ。永続化はAzure Blob Storageに委ね、読み取りは軽量なワーカープロセス群が処理する。記事はこう説明する。

"Separating the two lets us scale each one independently"

（両者を分離することで、それぞれを独立してスケールできる）

3つ目はバックグラウンドのメンテナンスの分離だ。圧縮とガベージコレクションは専用のワーカープロセスで実行し、リアルタイムのリクエストとリソースを競合しなくなった。ブランチ保護、必須レビュー、監査ログ、可観測性といった制御機能はそのまま維持されている。

書き込み量をざっくり計算すると

1カ月を30日として計算すると、月間73.8億件のコミットは1秒あたり約2850件、33.5億件のプッシュは1秒あたり約1290件になる。1年前は1秒あたり約270件だった。プッシュごとに5レプリカが関与する前提なら、旧アーキテクチャは1秒あたり約6500件のレプリカ書き込みを処理していたことになる（リトライやメンテナンス作業は含まない粗い推計）。

35倍のスループット向上は、年4.9倍というプッシュの増加ペースに対して、計算上は数年分の余裕を残す。ただしこれは、エージェントのトラフィックの増加曲線がこれ以上急にならないという前提に立っており、GitHub自身もその予測は示していない。

記事が触れていないこと

新アーキテクチャへの移行がどこまで進んでいるか、全面切り替えがいつになるかについてはスケジュールが示されていない。35倍というベンチマークがどの規模のリポジトリ、どの並行数で測定されたかも説明がない。レート制限が変更されるかどうかなど、ユーザーへの影響についても記事は言及していない。

GitHubは今年、長時間に及ぶ障害を何度か起こしているが、記事はこれらの事故には触れておらず、新アーキテクチャが同様の事態を防げるかどうかも述べていない。Celenza氏は、このシリーズの次回では将来のアーキテクチャと今回の改修の経緯をより詳しく説明すると予告して締めている。

参考資料：GitHub公式エンジニアリングブログ、CocoLoop；月間コミット・プッシュ・Actions実行数はGitHub公式データで確認。