8億人のChatGPTユーザーを支えるPostgreSQLのスケーリング

OpenAIは、800 millionユーザーと毎秒数百万件のクエリ（QPS）をサポートできるようPostgreSQLをスケールさせ、単一プライマリアーキテクチャが厳格なエンジニアリング最適化と組み合わせることで、大規模なリードヘビーなワークロードを信頼性高く処理できることを実証しました。単一の Azure PostgreSQL flexible server インスタンスをプライマリとして使用し、複数のグローバルリージョンにわたって約50のリードレプリカを展開することで、OpenAIは二桁ミリ秒単位の低いp99クライアント側レイテンシと「five‑nines」可用性を維持しています。

単一プライマリの制限を克服する

単一プライマリアーキテクチャはリードヘビーなトラフィックに対しては効率的ですが、書き込み操作のボトルネックとなり、単一障害点（single point of failure）になる可能性があります。OpenAIは以下の戦略でこれらの課題に対処しました。

書き込み負荷の緩和

書き込みスパイク時にプライマリインスタンスが過負荷になるのを防ぐため、OpenAIはシャーディング可能で書き込みが多いワークロードを Azure Cosmos DB などのシャーデッドシステムへ移行しました。組織は既存のPostgreSQLデプロイに新しいテーブルを追加することを禁止し、すべての新規ワークロードはデフォルトでシャーデッドシステムに割り当てられます。さらに、冗長書き込みの修正やレイジー書き込みの導入といったアプリケーションレベルの最適化も実施し、トラフィックスパイクを平滑化しました。

高可用性と障害緩和

プライマリが完全な単一障害点になるのを防ぐため、OpenAIは重要なリードクエリをレプリカにオフロードしています。これにより、プライマリが障害を起こした場合でも読み取り専用リクエストは利用可能です。完全な復旧のため、プライマリは High‑Availability (HA) モードでホットスタンバイ（同期レプリカ）と共に稼働し、障害時には即座に昇格させてダウンタイムを最小化します。

高QPS向けの技術的最適化

OpenAIは、PostgreSQLがリソース枯渇や性能低下に陥らないよう、複数のアーキテクチャ層を導入しました。

接続プーリングとレイテンシ

ステートメントまたはトランザクションプーリングモードで PgBouncer をプロキシ層として使用することで、アクティブなクライアント接続数を削減し、平均接続時間を 50 ms から 5 ms に短縮しました。ネットワークオーバーヘッドを最小化するため、PgBouncer ポッドはクライアントとレプリカと同一リージョンに配置しています。

キャッシュと「キャッシュミスストーム」

キャッシュミスによって突発的にリードトラフィックが急増する事態を防ぐため、OpenAIはキャッシュロック（リース）機構を実装しました。これにより、特定の欠損キーを取得しようとするリーダーは1つだけがPostgreSQLに問い合わせてキャッシュを再構築でき、同じキーへの同時リクエストはデータベースへのヒットを待機させることで「キャッシュミスストーム」を回避します。

クエリとスキーマ管理

OpenAIは OLTP のアンチパターンを回避するためにクエリを最適化し、特に複雑なマルチテーブル結合を避けています。あるケースでは、12テーブルを結合するクエリが重大インシデントの原因となっていました。現在は、複雑な結合ロジックをアプリケーション層に移し、idle_in_transaction_session_timeout を使用して長時間アイドル状態のクエリが autovacuum をブロックしないようにしています。

スキーマ変更は厳格に管理され、フルテーブルリライトを伴わない軽量な操作のみが許可され、すべてのスキーマ変更に対して5秒のタイムアウトが強制されます。

リードレプリカのスケーリングとワークロード分離

グローバルなパフォーマンスを維持するため、OpenAIは約50のリードレプリカを使用しています。ただし、プライマリは Write Ahead Log (WAL) データをすべてのレプリカにストリームする必要があるため、さらにスケールアウトするとプライマリの CPU とネットワーク帯域が逼迫する可能性があります。

カスケーディングレプリケーション

OpenAIは Azure PostgreSQL チームと協力し、カスケーディングレプリケーション を実装しています。中間レプリカが WAL データを下流レプリカへ転送することで、プライマリインスタンスに過負荷をかけずに 100 以上のレプリカへスケールすることを目指しています。

ワークロード分離

「ノイジーネイバー」問題を防ぐため、OpenAIはリクエストを低優先度と高優先度の2層に分割し、別々のインスタンスへルーティングしています。これにより、リソース集約的な低優先度リクエストが重要な高優先度機能の性能を低下させることを防止します。

パフォーマンス結果

これらの最適化により、OpenAIは以下の本番指標を達成しました:

  • 可用性: 5つの9（99.999%）の可用性。
  • レイテンシ: 二桁ミリ秒単位の低いp99クライアント側レイテンシ。
  • 信頼性: 過去12か月で SEV-0 PostgreSQL インシデントは1件のみで、これは ChatGPT ImageGen のローンチ時に書き込みトラフィックが10倍以上に急増した際に発生しました。

Sources