OpenAI、Git互換バックエンド「Pando」でプッシュ遅延を約5分の1に

OpenAIは、Codexによる並行開発の増加に対応するGit互換バックエンド「Pando」を構築し、同社のモノレポ全体で運用を始めました。本番環境でプッシュの中央値レイテンシをほぼ5倍短縮し、1日あたりほぼ1ペタバイトのGitデータを配信しています。

CodexはOpenAIが提供するコーディングエージェントで、プロジェクト内のファイルを読み、コードを変更し、コマンドを実行して開発作業を進めます。

何が新しいか

Pandoは、OpenAIのモノレポで全開発を支えるGitリポジトリ用の新バックエンドです。OpenAIはエンジニアリング作業を中断せず、チームのGitの使い方も変えずに移行しました。GitプロトコルとGitクライアントとの互換性を保っているため、エンジニアとエージェントは既存のGitワークフローのままPandoを使えます。

数値と設計目標

項目	内容
プッシュ中央値レイテンシ	本番でほぼ5倍削減
配信データ量	1日あたりほぼ1ペタバイト
書き込み	多数の異なるブランチへの同時プッシュを水平スケール
読み取り	クライアントが利用可能なネットワーク帯域を飽和させる速度でダウンロード
従来システムの信頼性	時に90%未満

仕組み: 因果一貫性とpackfile再利用

Pandoは、多くのGitシステムが前提とする2点を緩めました。

• リポジトリ全体の一貫性: 全refの更新に単一の順序を付ける代わりに、因果一貫性(causal consistency)を採用し、ブランチごとに独立して更新を調整します。関連しないブランチへの更新は並行に進みます。トレードオフとして、複数ブランチを見る読者には各ブランチが異なる時点の状態で見える場合があります。
• クライアントごとの固有packfile: クライアントごとにpackfileを生成せず、フェッチ間でpackfileを再利用します。クライアントが既に持つオブジェクトを一部ダウンロードすることはありますが、サーバーは少ない計算で同じバイト列を多数のクライアントに配信でき、キャッシュから読み取りを提供できます。

プッシュ時、Pandoは受け取ったpackfileを不変のblobとしてblobストアに保存し、ブランチが動くたびに新しいtip、それを供給したpack、そのpackが依存する以前のref versionを含む「ref version」をメタデータストアに記録します。blobストアとメタデータストアはどちらも水平スケール可能です。

OpenAIは設計時に、three-phase commit(3PC)でレプリカ間のref更新を調整する方式と、blobストア上の共有write-ahead log(WAL)で更新を順序付ける方式も検討しました。3PCはref更新が1つずつになり、プッシュごとに複数往復が必要です。WALは関連しないブランチへのプッシュでも同じマニフェストの更新を奪い合います。

背景

Codexによりエンジニアが多くの作業を並行して進められるようになり、ブランチ、プッシュ、マージ、そして開発環境・研究ジョブ・CIからのフェッチやクローンが増えました。1人のエンジニアが複数の変更を同時にCIへ出し、1回のプッシュが同じコミットをフェッチする複数ジョブを起動します。前年末ごろから従来のモノレポ基盤は追いつかなくなり、フェッチやプッシュの遅延、マージ失敗が起き、信頼性は時に90%を下回りました。

OpenAIは、Gitクライアントの改善を独自のGitコピー(openai/git)から上流へ貢献し、コミュニティと共有するとしています。