Japanese Translation:

GitHub はグローバルデータシステムの見直しを行い、書き込みスループットの最大 4 倍への増大を目指して速度とスケーラビリティを劇的に向上させる取り組みを進めています。現在のプラットフォームではリポジトリ全体を単一の単位として扱うため、動作が最も遅いレプリカまで待たなければならず、これが大きなボトルネックとなっています。これを解消するために、GitHub は従来のモデルから、個々の参照を個別に扱い、耐久性のある Azure Blob Storage によってバックアップされる新しいモデルへ移行します。この変更により、読み取りと書き込みが分離され、Git のトラフィックが増加しても特定の地域に依存する遅延がなくなります。単純なデータコピーから複雑な新インフラストラクチャーへと進化させるのは、電力制限およびサプライチェーンの制約があるため不可欠です。今後のアップデートでは、最終的なアーキテクチャの詳細（書き込みスループットの向上や、ガレージコレクションのスケーリングなどの二次的課題に対する解決策）が示されます。ユーザーは、システムが変更を行う際にリポジトリ全体をロックする不再是するため、異なるブランチを更新する際のレイテンシが大幅に低下するのを最終的に目撃することになります。

GitHub の Git アーキテクチャ：1 年間での変化と次へのステップ

1 年間の推移と現状

過去 1 年で、Git のトラフィックは指数関数的に増加し、リポジトリの存在場所に変化が生じました。

リポジトリの分布
- GitHub 上の Git リポジトリの 約 99.99999％ は、同時に二つの場所に住んでいます。
  - データセンター内
  - Azure クラウド上
- 残りの 0.00001％ はプラットフォーム上で活発に利用されていますが、移行の障壁となる唯一の要因は 「25ms の往復時間（RTT）」 です。

設計変更の基本原理とアプローチ

次世代ストレージアーキテクチャを支える二つの原理に従い、旧設計から新設計への橋渡しを実現しています。

基本原理
- 協調処理を最小限に抑える
- ストレージ機能と計算機能を分離する
主な変更点
- クォーラムによる書込みのシリアライズ（系列化）方法を変更
- 高頻度利用のリポジトリを Azure へ移転
- 永続性を持たない「レプリカ」の実装への扉を開く

移行の背景と進行状況

アジェンツ・シフトと制約条件

今回の移行は、以下の要因によって牽引されました。

エージェント（AI）によるトラフィックの急増
データセンターおよび周辺地域の電力容量限界
物理的なサプライチェーンの制約

慎重な順序立てた移行

リスクを減らすため、データの移行とアーキテクチャの進化は順次行われました。

まずデータを引き移す
次にアーキテクチャを進化させる

**Git は「Tier 0 サービス」**であり、GitHub の核となる機能です。そのため以下の順序で移行が実施されました：

データ、サービス、依存関係の全移転
2025 年 8 月に Azure Central US リージョンへの初回コピー設置
現在: 多くのリポジトリで 5 つのレプリカのうち 2 つが Azure にある
- Azure が Git のトラフィックの約半分を処理し、自前のデータセンターは安定しています。

「残すものなし」ポリシーの実装

移行期間中はトラフィックがデータを追跡して移動します。全てのリポジトリは以下のプロセスを経ます：

耐久性・可用性・スケーラビリティのバランス: 5 つのレプリカを保持
優先ルーティング (Spokes): 読み取りレイテンシ最小化のため、ユーザーと同じリージョン・AZ のレプリカへ誘導
段階的移行: Azure のレプリカが増えるにつれ、旧リージョンでの受入れ割合は減少し、最終的に旧リージョンへのリクエストが完全になくなるまで推移

残りの 0.00001％をAzureに移行するための技術的解決策

書込みスループットのボトルネックと原因

従来のマルチリージョン構成では、以下の理由により書込みスループットに上限がありました：

マジョリティルール: クォーラムが全ての健全なレプリカからの応答を待機するため、最も遅いレプリカ全体のレイテンシ（約 25ms×複数 RTT）で制約されます。
ロックとキュー: 単一の未整理されたリクエストキューとなり、書込みレート増大に伴い待機時間が長引きます。

解決策：参照ごとのシリアライゼーション (Per-Reference Serialization)

協調処理の最小化という原則に基づき、クォーラムの範囲を「全体のリポジトリ」から「個々の参照（ブランチなど）」に変更しました。

従来モデルの問題: 参照全体の更新のため、リポジトリ全体にロックがかかる単一キュー。
新モデルのメリット:
- 異なる参照への書込み（例：自分のブランチへのプッシュ）は互いを待たずに並列処理可能。
- リポジトリ全体に存在する単一のボトルネックが消失。
- 内部テスト結果：異なる参照への書込みにおいて、レイテンシを維持しつつスループットが 3〜4 倍向上。

これにより、残りのリポジトリも Azure への移行が可能となり、25ms の遅延による影響も吸収できるようになりました。

読み取りのスケーリングを個別に行う（ストレージと計算の分離）

多くのリポジトリは「読み取り偏り」が強く、書込み 1 つに対し 100〜1,000 回の読み取りが行われます。これによりリソース競争が発生していました。

新しいアーキテクチャ構成

Azure Blob Storageと計算機能を分離することで独立したスケーリングを実現しました。

データの永続化: リポジトリデータを Azure Blob Storage に保存。
役割の分離:
- 書込みクォーラムとは独立に読み取りトラフィックをスケール可能に。
- 読み取り専用のインメモリキャッシュ容量を大幅に拡大可能（コンパクト化も考慮）。

「仮想レプリカ」の導入

オブジェクトストレージをクォーラムメンバーとするための特別な構成「仮想レプリカ」を採用しました。

書き込み側:
- 一時的な計算ノードが書込みをストリーミングし、Azure Blob Storage に永続化するまで承認待ち（クォーラム参加）。
- 複数の同時書込みを一つのネットワーク入出力に結合（Coalesce）することでコスト削減。
- コンパクト化処理も担当。
読み取り側:
- オンデマンドで多数の仮想読み取りレプリカをスケールアウト可能。
- 各リプレリカが Blob Storage からキャッシュをウォームアップし、バックグラウンドで整合性を確保。

結果:

分散負荷テストでは、既存アーキテクチャの上限を超えてスケーリング成功。
仮想読み取りレプリカにより、ハネス自体の制限に到達した。

残りの課題と今後の展望

整合性の最適化: バックグラウンドでの整合性確認をインライン化し、最終更新時のみ差分取得。
クォーラムの限界: 書込みスループットは向上したが、クォーラム自体がさらに増加する際のボトルネックとなっている点への対応が必要。

次へ：さらなるスループット向上に向けて

今日の GitHub は、Spokes クォーラムを基盤とし、以下の機能も担っています。

内部クライアント向け統一的な API（日平均 1000 億回以上の操作）
「スイーパー」としての背景システム（再均衡処理、修復など）

しかし、現在のコミットプロトコルでは 10 億個のリポジトリを超えた先は到達できません。

次のステップと焦点

ボトルネックの移動: 各書込みが完全なレプリカを待つ現状を打破し、順序立てる必要のない部分を特定。
- Git オブジェクトの不変性と命名規則を利用。
- 残りの難問は「可能な限り高速に順序立てながら、ボトルネックを別の場所に移さないこと」。
二次的効果への対応:
- 永続的な参照状態の保存先の見直し。
- コンパクト化とガーベージコレクションのスケーリング設計。

結論: エージェントのトラフィックは加速しており、これらのステップがリポジトリに余裕を与えています。最終状態に向けて着実に進化を続けています。

今後の予定: 来週の「GitHub Universe」およびシリーズ最終記事で、さらに詳細な技術解説をお送りします。

エージェントスケールのGitインフラへの架け橋