ChatGPTの8億ユーザーを支える「PostgreSQL」チューニング事例 OpenAIが解説：毎秒数百万クエリに対応

OpenAIは、ChatGPTやOpenAI APIを支えるPostgreSQLの拡張事例についてエンジニアリングブログで解説した。1年で負荷が10倍増すような環境においてPostgreSQLを最適化し、毎秒数百万クエリに対応してきた取り組みだ。

[＠IT]

　OpenAIは2026年1月22日（米国時間）、「ChatGPT」やOpenAI APIを支えるリレーショナルデータベース管理システム「PostgreSQL」のスケーリング手法をエンジニアリングブログで解説した。

　この1年でPostgreSQLに対する負荷は10倍以上増加したものの、単一プライマリー構成（Azure PostgreSQLフレキシブルサーバ）と約50のリードレプリカという構成を維持しながら、毎秒数百万件のクエリ処理を実現しているという。

大規模環境におけるPostgreSQLの課題

　OpenAIはChatGPT公開後のトラフィック急増に対し、これまで以下の手法で対応してきた。

• アプリケーション層とデータベース層の最適化
• インスタンスのスケールアップ
• リードレプリカ（読み取り専用の複製データベース）のスケールアウト

　しかし、単一プライマリー構成では書き込みが集中してリソースが逼迫（ひっぱく）すると、クエリのレイテンシ（遅延）が悪化してタイムアウトが発生し、そのリトライが負荷を増幅させるという悪循環に陥るリスクがあった。

負荷増大がさらなる負荷を呼ぶ悪循環のメカニズム（提供：OpenAI）

　加えて、PostgreSQLのマルチバージョン同時実行制御（MVCC）は、タプル（tuple）の更新時に（あるいは単一のフィールドであっても）行全体がコピーされて新しいバージョンが作られるため、書き込みが多いワークロードでは負荷が大きくなりやすいという課題もあった。この他、テーブルやインデックスの肥大化、自動メンテナンス機構「autovacuum」のチューニングなどの課題にも直面していた。

毎秒数百万クエリに対応する最適化の取り組み

　そこでOpenAIは、単一プライマリー構成を維持しつつも負荷に対応するため、システム全体にわたる徹底的な最適化に取り組んできたという。

読み取りと書き込みの役割分離

　プライマリーの負荷軽減として、読み取りトラフィックをレプリカにオフロードした。さらに、シャーディング（水平分割）可能な書き込み集約型ワークロードは「Azure Cosmos DB」などの分散システムへ段階的に移行し、PostgreSQL側の書き込み負荷を抑えている。

クエリ最適化

　過去に障害を引き起こした「12個のテーブルを結合するような高コストクエリ」を特定し、複雑な結合は極力避け、必要な場合はクエリを分解して結合ロジックをアプリケーション層に移行するようにした。

単一障害点の軽減

　単一障害点（SPOF）の影響を軽減するために、まず重要な読み取り処理をレプリカへオフロードし、プライマリーがダウンしても読み取りを継続できるようにした。さらに、プライマリーはHA（高可用性）モードで稼働させ、常に同期されたホットスタンバイを用意した上で、各リージョンに複数のレプリカを配置した。

ワークロード分離

　リクエストを優先度別に異なるインスタンスに振り分けることで、ノイジーネイバー問題（ある処理が他の処理の性能に悪影響を与えること）を回避した。

コネクションプールの導入

　プロキシレイヤーとしてコネクションプーリングツール「PgBouncer」を導入したことで、平均接続時間が50ミリ秒から5ミリ秒へと大幅に短縮された。

PgBouncerをプロキシとして活用したコネクションプーリングの構成（提供：OpenAI）

キャッシュロック機構の実装

　特定のキーでキャッシュミスが同時に多発した際、大量のクエリが直接データベースに殺到しないようロック機構を設け、1つのリクエストだけがデータベースからデータを取得してキャッシュを更新するように処理を変更した。

リードレプリカの拡張とカスケードレプリケーションの導入

　OpenAIは、遅延を最小限に抑えるために世界各地に約50のリードレプリカを運用している。しかし、全レプリカへWAL（Write Ahead Log）を直接送信し続けるとプライマリーが過負荷になるため、Microsoft Azureのチームと協力し、中間レプリカがWALを下流レプリカに中継する「カスケードレプリケーション」の導入を進めている。

プライマリーの負荷を抑えつつレプリカを増設する「カスケードレプリケーション」の仕組み（提供：OpenAI）

レート制限の導入

　突然のトラフィックの急増によってデータベースインスタンスが過負荷になり、連鎖的な障害が発生するのを防ぐため、アプリケーション、コネクションプーリング、プロキシ、クエリといった複数のレイヤーでレート制限を実装している。

　さらに、リトライストームを防ぐための間隔調整や、O/Rマッピングレイヤーを強化して特定の重いクエリを完全にブロックできる仕組みも導入した。

スキーマ変更の管理

　特定の列の追加や削除など、テーブル全体の書き換えを引き起こさない軽量なスキーマ変更のみを許可し、5秒のタイムアウトを設けた。

　こうした最適化に向けた取り組みにより、クライアント側レイテンシの99パーセンタイル（p99）を2桁ミリ秒台前半で維持し、99.999％（ファイブナイン）の可用性を実現した。過去12カ月間で発生した最も深刻な障害は、トラフィックが急増した際の1件のみに抑えられているという。

　「今後、書き込み集約型ワークロードの移行を推進するとともに、インフラの成長に合わせてシャーディング化されたPostgreSQLや他の分散システムの活用も視野に入れて検討する」と、OpenAIは述べている。