CursorがS3 WALでGitを秒間300プッシュへ高速化、CI/CDのボトルネックを打破

• CursorがS3をWAL（先行書き込みログ）として活用する新Gitストレージ「Continuity」を発表。
• S3 Express One Zoneの採用により、秒間300プッシュ以上のスループットと線形的な読み取り拡張性を実現。
• ローカルNVMeをキャッシュと見なす設計へ転換し、CI負荷の高い巨大リポジトリやAI生成コードの急増に対応。

深夜のデプロイ作業中、CIパイプラインがGitのプッシュ待ちでタイムアウトし、冷や汗をかいた経験はないだろうか。GitHubのSpokesアーキテクチャが長年支えてきた「NVMeレプリカの同期」というモデルは、現代のAIエージェントが生成する膨大なコミット数や、CIの頻度に対して明らかに限界を迎えつつある。Cursorが今回発表した「Continuity」は、このレプリカ間同期という呪縛を断ち切り、S3を真実のソース（Source of Truth）として据えるという、極めて大胆なアーキテクチャの転換だ。

従来のGitホスティングは、複数のNVMeレプリカを維持し、三相コミット（Three-phase commit）で整合性を担保してきた。しかし、レプリカ数が増えるほど調整コスト（オーバーヘッド）は指数関数的に増大する。Continuityはこのモデルを捨て、S3をWAL（Write-Ahead Log）として活用する。プッシュはS3への書き込みが完了した時点で「永続化済み」と見なされ、ACKが返される。この設計により、ローカルのNVMeは「権威あるコピー」ではなく、あくまで「ウォームキャッシュ」へと格下げされた。この発想の転換こそが、秒間300プッシュという驚異的な数値を叩き出す鍵となっている。

エンジニアとして注目すべきは、この設計が「データベースの設計思想」をGitに持ち込んだ点だ。Rendezvousハッシュによるノード選択と、S3上でのアトミックなCompare-and-Swap操作により、どのサーバーでもプッシュを受け入れ可能にしている。UDPゴシッププロトコルによる更新伝播と、S3の条件付き読み取りによる状態検証を組み合わせることで、たとえゴシップが欠落してもS3が正当性を保証する。この「整合性の境界をレプリカ層からオブジェクトストレージへ移動させる」というアプローチは、分散システムを設計する我々にとって、今後のスケーラビリティ確保における一つの強力な解法となるだろう。

Cursorが提示した数値は、単なる改善の域を超えている。特にS3 Express One Zoneを活用した際のパフォーマンスは圧巻だ。以下の表は、Cursorが公開したテスト環境におけるスループットの比較である。この数値は、特に大規模なモノレポを抱えるチームや、AIエージェントが頻繁にコードを生成・コミットする開発環境において、劇的な改善をもたらす可能性を秘めている。

特筆すべきは、この高負荷環境下でのボトルネックが「Gitのコンパクション（圧縮）」に移行したという点だ。これは、ストレージのI/Oがもはやボトルネックではなくなったことを意味する。従来、Gitのプッシュはレプリカ間の同期待ちで詰まるのが常だったが、Continuityでは「プライマリのみがコンパクションを実行し、レプリカは結果のパックファイルをS3からダウンロードする」という戦略をとる。これにより、CPUリソースを節約しつつ、帯域幅を有効活用するトレードオフを選択している。

また、このアーキテクチャは「オンデマンドでのリポジトリ構築」を可能にする。アイドル状態のリポジトリは実体を持たず、必要に応じてWALから再構築すればよい。これは、数千もの小さなリポジトリを生成するAIエージェントのワークフローと極めて相性が良い。ただし、LiatrioのCasey Lee氏が指摘するように、これらの数値はあくまでCursorの合成テスト環境下のものであり、実運用におけるエッジケースや、ネットワーク遅延が複雑に絡み合う現実の環境でどこまで線形性を維持できるかは、我々エンジニアが慎重に見極めるべきポイントだ。特に、force-push時のトランザクション整合性や、ポイントインタイムリカバリの挙動については、さらなる詳細な検証が待たれる。

CursorのContinuityが突きつけたのは、単なるストレージの最適化ではない。「Gitの整合性をどこで担保すべきか」という、分散システムにおける根本的な問いである。我々はこれまで、Gitのローカルコピーこそが正義であると信じて疑わなかった。しかし、AIがコードを書き、CIが秒単位で回る現代において、その「ローカルの正義」は、もはやボトルネックという名の足枷になりつつあるのではないか。

このアーキテクチャを採用することで、我々は「レプリカの同期」という複雑な調整から解放される代わりに、「オブジェクトストレージの可用性とレイテンシ」という新たな依存関係を背負うことになる。S3がダウンすれば、あるいはS3へのアクセスが遅延すれば、開発者のプッシュは即座に止まる。これは、インフラの責任範囲が「Gitサーバーの管理」から「クラウドストレージの信頼性」へとシフトしたことを意味する。明日から我々が取るべき対策は、単に新しいツールを導入することではない。自社のCI/CDパイプラインが、どの程度の整合性レベルを要求しており、どの程度のレイテンシを許容できるのかを再定義することだ。

最後に、読者諸氏に問いたい。もしあなたの開発環境が、レプリカの同期に依存せず、常にクラウド上のWALから最新の状態を即座に復元できるとしたら、現在のスパゲッティ化したCIパイプラインをどう再設計するだろうか？ ツールが進化するたびに、我々は「何が真実のソースなのか」を問い直さなければならない。この技術的転換点において、あなたは「既存のレプリカモデルの保守」に安住するのか、それとも「クラウドネイティブなストレージ設計」へと舵を切るのか。その選択が、数年後のあなたのチームの生産性を決定づけることになるだろう。