OpenAIにおけるGitのスケーリング：Pandoがいかにしてペタバイト規模のスループットを実現したか

TL;DR

OpenAIは、標準のGitクライアントを維持しつつ、プッシュのレイテンシを5分の1に短縮し、1日あたりペタバイト規模のデータ転送を実現するカスタムGitバックエンド「Pando」を構築しました。これは、リポジトリ全体の整合性を緩和し、クライアント間でパックファイルを再利用することで達成されています。

OpenAIが新しいGitバックエンドを必要とした理由

Codexの登場により、多くのエンジニアが並行して作業できるようになり、ブランチ、プッシュ、マージ、フェッチの数が爆発的に増加しました。
2023年後半には、モノレポにおいてプッシュの遅延、マージの失敗、90%を下回る信頼性といった問題が発生していました。
既存のスケーリング手法（3相コミットや共有の先行書き込みログなど）では、依然としてグローバルな調整や単一のマニフェストが必要であり、同時書き込みや読み取りのボトルネックとなっていました。
OpenAIは、Git互換のワークフローを維持し、改善がより広いコミュニティに還元されることを望んでいました。

「私たちは、使い慣れたワークフローを維持しつつ、異なるブランチへのプッシュを並行して処理し、同じ履歴を多くの読者に同時に提供できるようにバックエンドを再構築する方法を見出しました。」 – OpenAIブログ

Pandoの主要な設計目標

書き込みの水平スケーラビリティ – グローバルロックなしで、多くのブランチを同時に更新可能にする。
読み取りスループットの最大化 – 同じパックファイルを多くのクライアントに提供し、ネットワーク帯域幅を飽和させる。
Gitプロトコル互換性 – 既存のクライアントツールに変更を必要としない。

アーキテクチャ上のブレークスルー

1. グローバル整合性ではなく因果整合性

各ブランチの更新は、アップロードされたパックファイルとその依存関係を指す不変のref versionを作成します。
書き込みはrefごとにシリアライズされます。同じブランチへのプッシュのみが競合します。
読み取り側は因果整合性のあるビューを参照します。異なるブランチが異なる時点を反映している可能性がありますが、これは開発者がグローバルなスナップショットではなく、単一のrefに対する更新順序を重視するという現実のユースケースと一致しています。

2. クライアント間でのパックファイルの再利用

プッシュは、スケーラブルなオブジェクトストアに不変のBLOBとして保存されます。
フェッチは、クライアントのhave/wantセットを、必要なオブジェクトをすでに含む保存済みパックファイルにマッピングします。
Gitプロトコルのpackfile-uri拡張機能により、サーバーは既存の複数のパックへのURLを返すことができ、オンザフライでのパック生成を回避します。
結果：読み取り側のCPUとI/Oが劇的に削減され、単一のパックで数千のフェッチを処理できるようになりました。

3. 階層型コンパクション (L0-L4)

すべてのプッシュはL0パック（最小単位）を作成します。
バックグラウンドワーカーが、ログ構造化マージツリー形式のアルゴリズムを使用して、パックをより大きなカバー（L1-L4）にマージします。
カバーはフェッチ計画のためのスキップリストとして機能し、log-Δのメタデータ検索を可能にします（Δはクライアントの現在の先端と目的の先端との距離）。
コンパクションにより圧縮率が向上し、クライアントがダウンロードすべきパックURIの数が削減されます。

従来の手法との比較

手法	書き込みボトルネック	読み取りボトルネック	整合性モデル
3相コミット (3PC)	レプリカ間でのグローバルなクォーラム。無関係なブランチへのプッシュがシリアライズされる。	読み取りは高速（ローカルレプリカ）だが、高負荷時にレプリカディスクが飽和する。	強整合性、全refの時点スナップショット。
先行書き込みログ (WAL)	単一マニフェストの更新。比較交換（CAS）のレイテンシがプッシュレートを制限する。	サーバーがBLOBストアからパックを読み取りインデックス化する必要があり、フェッチレイテンシが悪化する。	全ref更新の強い順序付け。
Pando	refごとのアトミックな比較交換。refポインタのみが競合対象。	パックファイルの再利用とキャッシュローカルな配信により、ペタバイト規模でもフェッチレイテンシが低い。	因果整合性 – refごとにシリアライズ可能、グローバルスナップショットなし。

1,000人の同時書き込みユーザーを想定したシミュレーションでは、3PCが書き込みストール、WALが読み取りストールに陥る中、Pandoは低いプッシュ・フェッチレイテンシを維持しました。実際の運用環境でも、数千の同時プッシュが発生し、中央値レイテンシが約80%削減されたことが確認されています。

Pandoにおけるプッシュフロー

クライアントがパックファイルを作成し、git pushを実行する。
PandoはパックをBLOBストアにストリーミングしながら、単一パスで検証する。
マルチキー・トランザクションが新しいref version（メタデータ）を記録し、refポインタをアトミックに更新する。
同期的なメタデータ書き込みにより、read-your-own-write（書き込み後の読み取り）整合性が保証される。非同期処理（コンパクションのスケジュールなど）はバックグラウンドで実行される。

複雑性: プッシュサイズに関わらずO(1)のメタデータ読み取り/書き込み。

Pandoにおけるフェッチフロー

クライアントがhaveおよびwant IDを送信する。
Pandoはこれらをref versionのセットにマッピングし、最小のカバーパックファイルを選択する。
サーバーは空のインラインパックと、選択されたパックへのpackfile-uriリンクを返す。
クライアントはリージョナルキャッシュ（Express）から直接パックをダウンロードする。キャッシュヒット率は99%以上。

複雑性: O(log Δ)のメタデータ読み取り（Δはクライアント状態とターゲット間のref version数）。

パフォーマンス数値

プッシュレイテンシの中央値: 以前のシステムより約5倍高速（約80%削減）。
1日のデータ転送量: 約1PBのGitオブジェクト。
ピークスループット: 1時間で57TB以上のパックを転送。99%以上がローカルディスクキャッシュから提供。
ネットワーク利用率: クローン/フェッチ操作が汎用VM上の10Gbpsリンクを飽和させる。

導入の経験

Pandoは10週間でRustを使用して構築されました。コア設計は1人のエンジニアが担当し、実装はCodexが生成したコードによって支援されました。
初期ロールアウトでは、レガシーシステムとの同期を保つために読み取り専用プロキシを使用し、ダウンタイムゼロの移行を実現しました。
社内Gitラッパーが、開発者、CI、サードパーティ統合のための移行を段階的に進めました。
Codex主導の自動化により、開発者は簡単なコマンドで環境を移行できました。

Gitへの貢献

packfile-uriのアップストリームサポートを追加し、同時ダウンロード処理を改善しました。
「明示的なhaves」を実装し、プッシュが省略する可能性のある履歴とは別に、サーバーがブランチの先端をアドバタイズできるようにしました。
パックファイルダウンロードのトレースとバイト数メトリクスを追加し、パフォーマンスデバッグを支援しました。
すべてのパッチはOpenAIの公開Gitフォーク（https://github.com/openai/git）で利用可能であり、https://oai-git.openai.chatgpt.site/で追跡されています。

コミュニティの背景

OpenAIの取り組みは、以下のような大規模Gitエンジニアリングに関する一連の投稿に続くものです。

CursorのGit at Any Scale
GitHubのArchitecture Optimizationシリーズ
AnthropicのRedesigning Source Control
East River Source ControlのWhat Comes After Git

これらの取り組みは、巨大なモノレポ、AI生成コード、高スループットなソース管理の必要性という同じ課題を共有していますが、実装の詳細（Googleスタイルのモノレポサービス対Pandoの因果整合性など）が異なります。

まとめ

Pandoは、Gitクライアントを変更することなく、ペタバイト規模のトラフィックを処理するためにバックエンドを根本的に再設計できることを証明しました。
因果整合性はほとんどの開発者ワークフローにとって十分であり、グローバルな順序付けポイントの必要性を排除します。
パックファイルの再利用と階層型コンパクションにより、フェッチはCPU集約的なパック生成タスクではなく、キャッシュヒットの問題へと変換されます。
この設計は汎用ハードウェア上で水平方向にスケールするため、同様のモノレポの成長に直面しているあらゆる組織にとって実行可能な青写真となります。

今後の展望

OpenAIはPandoの一部をオープンソース化し、より広範なエージェント中心のユースケースを模索し、エコシステム全体に利益をもたらすためにGitへのアップストリーム貢献を継続する予定です。