GitHubプラットフォームは、修正や更新の集中的かつ継続的なストリームを生成するAIエージェント（AI Agents）やソフトウェアの普及に伴い、Gitシステムにおける作業密度の前例のない増加に直面している。従来のデータセンターにおける電力容量の物理的制限やサプライチェーンの問題に対処するため、同社はアーキテクチャ計画を発表し、これまでに同社のリポジトリの99.99999%のレプリカを自身のデータセンターとMicrosoft Azureクラウドの間で共同配置させる移行を完了させた。
レイテンシの障壁とリポジトリ全体のロック
GitHubは、プラットフォーム上で最も使用され変更頻度が高いリポジトリ（残りのわずか0.00001%に相当）が、ネットワーク応答時間という技術的障壁に直面していたと説明した。同社のデータセンターから約1,000マイル離れた米国中部（Central US）のAzureリージョンにデータを転送する場合、ネットワーク接続ごとに往復で約25ミリ秒のレイテンシ（遅延）が加算される。
同期・合意形成システム「Spokes」の旧アーキテクチャでは、新しい書き込み処理が行われるたびに、レプリカ（複製）からの応答があるまでリポジトリ全体レベルでのロック（Repository-wide lock）をかける必要があった。この全体ロックが保持されるため、最もネットワーク速度の遅いレプリカが応答時間とリポジトリ全体の最大スループットを決定することになり、開発者やAIエージェントから頻繁にコードプッシュを受けるアクティブなリポジトリでボトルネックが発生していた。
個別の参照に基づく合意形成
このボトルネックを解消するため、GitHubは最初のアーキテクチャ原則である「調整の最小化と不要なロックの排除」を適用し、合意形成メカニズムを再構築した。更新時にリポジトリ全体をロックする代わりに、合意形成とロックの範囲をブランチ（Branches）やタグ（Tags）などの個別の参照（Per-reference serialization）のみに適用するように変更した。
開発者やAIエージェントが実行する並行書き込み処理のほとんどは異なるブランチを対象としているため、変更処理が単一のキューで互いに待機する必要はなくなった。同社が実際の負荷の下で実施した内部テストでは、レイテンシの大幅な減少とともに、書き込み処理の処理能力が3〜4倍に増加したことが示された。
ストレージと計算処理の分離とオブジェクトストレージの活用
第2段階には、2番目のアーキテクチャ原則である「ストレージと計算処理能力の分離（Decoupling storage from compute）」の適用が含まれている。ほとんどのGitリポジトリは、書き込み1回に対して読み込みが100〜1,000回というように、書き込みに比べて読み込み処理の密度が高い特徴がある。旧アーキテクチャでは、読み込みと書き込みが同じリソースやメモリを奪い合っていた。
これを解決するため、GitHubはオブジェクトストレージ（Azure Blob Storage）を「仮想書き込みレプリカ（Virtual Write Replica）」と呼ばれる合意形成クォーラムの仮想メンバーとして追加した。このレプリカは過渡的なパイプラインとして機能し、トランザクションを集約して変更をクラウドストレージへ持続的にストリーミングする。ストレージ側で確認が完了すると、プラットフォームは要求に応じて拡張可能な無制限の「仮想読み込みレプリカ（Virtual Read Replicas）」を起動できるようになり、これらのレプリカはデータの書き込み速度や同期に影響を与えることなく、バックグラウンドでキャッシュを更新する。
ソフトウェア開発インフラにおける実質的な変化とは？
GitHubにおけるこの技術的転換は、AI依存の自動化作業の性質に耐えられるよう大規模分散システムがどのように再設計されているかを反映している。主な実質的影響は以下のように要約できる。
- スループット上限の引き上げ： 大型リポジトリでブロック（ロック）を発生させることなく、AIエージェントや開発者が集中的な並行プッシュを実行可能にする。
- 読み込み拡張の柔軟性： 重い合意形成手続きを経ることなく、読み込みサーバーを増設しキャッシュを独立して割り当てることが可能になる。
- 基幹システムの継続性： 1日あたり1000億回以上の処理を実行する「Spokes」システムの内部コンポーネントを、サービスの停止やデータ整合性の損害を伴うことなく更新できる。