🐘

8億人が使うChatGPTを支えるPostgreSQLのスケーリング戦略

に公開
PostgreSQL
Database
SRE
OpenAI
ChatGPT
idea

今回は、OpenAIが2026年1月に公開した「8億人のユーザーを抱えるChatGPTが、どうやってPostgreSQL（ポスグレ）をスケールさせているか」という記事が非常に示唆に富んでおり、エンジニアにとって「基本の大切さ」を再確認できる内容だったので、その要点を分かりやすく解説します。

「世界トップクラスのAI企業だし、何か聞いたこともない特殊な分散データベースを使っているのでは？」

そう思う方も多いかもしれません。
しかし、彼らのコアシステムは驚くことに 単一のPostgreSQL（シングル構成） で動いています。
なぜそのような構成で、これほどの大規模トラフィックを捌けるのか？そのアーキテクチャと運用戦略を紐解いていきます。

3行でわかる要約

  1. 基本に忠実: 複雑な分散DBを使わず、「1台の書き込み用DB + 50台の読み込み用DB」というシンプルな構成を採用。
  2. 書き込みの工夫: 書き込み負荷の高い処理はPostgreSQLから別のDB（CosmosDB）へ移行し、PostgreSQLは「読み取り」と「リレーショナルデータ」に特化させた。
  3. 運用の徹底: コネクションプーリング(PgBouncer)の最適化や、スロークエリの徹底排除など、泥臭いチューニングをやりきっている。

1. 驚きのアーキテクチャ：実は「普通の構成」だった

通常、ユーザーが数億人規模になると、データを複数のサーバーに分割して保存する「シャーディング」という技術を検討するのが一般的です。
しかし、OpenAIは現時点でPostgreSQLのシャーディングをしていません。

現在の構成

  • Primary (書き込み用): 1台 (Azure PostgreSQL Flexible Server)
  • Read Replica (読み込み用): 約50台

なんと、書き込みを一手に引き受ける親玉（Primary）はたったの1台です。
これを約50台の読み込み専用サーバー（Replica）が支えるという、教科書に出てくるような「基本のマスター・スレーブ構成（Primary-Replica構成）」を極限までチューニングして運用しています。

ここでの学び

最初から複雑なアーキテクチャ（マイクロサービスの過度な分割やNoSQLの乱用）を選ばず、「使い慣れた技術（Boring Technology）を限界まで使い倒す」ことの重要性が示されています。

2. どうやって負荷を分散しているのか？

単一の書き込みサーバーで耐えるために、彼らが実践した具体的な戦術は以下の通りです。

戦術①：重い「書き込み」は別の場所に逃がす

PostgreSQLはMVCC（多版型同時実行制御）という仕組み上、「書き込み」が増えるとパフォーマンスへの影響が出やすくなります。
そこでOpenAIは以下の判断を行いました。

  • 新規テーブルの制限: PostgreSQLに新しい機能用のテーブルを安易に追加しない。
  • 書き込みのオフロード: ベクトルデータやログなど、大量に書き込まれるデータはCosmosDBなどのシャーディング可能なシステムへ移行する。

つまり、 「PostgreSQLには、本当に重要なリレーショナルデータ（ユーザー情報や決済情報など）だけを残す」 という明確な役割分担を行ったのです。

戦術②：読み込みの徹底的なキャッシュ戦略

「キャッシュミス」が発生した際、大量のリクエストが一度にDBへ押し寄せる現象（Thundering Herd問題）は致命的です。
これを防ぐため、 「Cache Locking」 という仕組みを導入しました。

  • 対策なし: 100人が同時にアクセス → キャッシュがない → 100人が同時にDBへ問い合わせ → DBが高負荷でダウン
  • OpenAIの対策: 100人が同時にアクセス → キャッシュがない → 「代表者1人」だけがDBへ問い合わせ → 残りの99人はその結果を待つ → DB負荷は最小限

3. 明日から使える！実践的なチューニング技術

OpenAIのような大規模環境でなくとも、日々の開発・運用で役立つ具体的なテクニックも紹介されています。

🔌 PgBouncer (コネクションプーリング) の導入

DBへの「接続（コネクション）」確立は、サーバーリソース（CPU/メモリ）を消費するコストの高い処理です。
接続・切断を頻繁に繰り返すと、それだけでDBのパフォーマンスが低下します。

そこでPgBouncerというツールを導入し、「DBへの接続を維持し、複数のリクエストで使い回す」仕組みを構築しました。
これにより、接続にかかるレイテンシが50msから5msへ、1/10に短縮されたとのことです。

🧹 スキーマ変更の厳格なルール

稼働中の本番DBに対して「カラム追加」などの変更を行う際、不適切なSQLはテーブル全体をロックし、サービス停止を招きます。
OpenAIでは以下のルールを徹底して運用しています。

  1. 5秒ルール: 5秒以上かかる変更クエリは強制タイムアウトさせる。
  2. テーブル書き換え禁止: 全行のデータを書き換えるような重い変更は許可しない。
  3. インデックス作成は CONCURRENTLY で: サービスを止めずにインデックスを作成するオプションを必須とする。

⏱️ idle_in_transaction のタイムアウト設定

「トランザクションを開始したまま放置された接続」は、PostgreSQLの内部掃除プロセス（VACUUM）を阻害し、パフォーマンス低下の原因（Bloat）になります。
これを防ぐため、idle_in_transaction_session_timeout を設定し、一定時間放置されたトランザクションを自動的に切断するようにしています。

4. 今後の展望：シャーディングはしないのか？

記事によると、 「将来的にはシャーディングも検討するが、現時点では不要」 とのことです。
ここまでの最適化によって、現在のシングル構成でもまだ成長に耐えられる余地があるためです。

ただし、レプリカ（読み込み用サーバー）の台数が増え続けると、Primaryが「全てのレプリカに更新データ（WAL）を転送する処理」だけでパンクしてしまいます。
これに対応するため、 「Cascading Replication（カスケードレプリケーション）」 の導入を進めているそうです。
（Primary → 中間Replica → 末端Replica というように、バケツリレー形式でデータを同期し、Primaryの負荷を下げる手法です）

まとめ

この記事から得られる最大の知見は、 「魔法のような解決策はない」 ということです。
8億人が使う巨大サービスであっても、その安定稼働を支えているのは、以下のような堅実な積み重ねでした。

  1. クエリの最適化（複雑なJoinを避け、アプリケーション側で処理する）。
  2. リソース管理の徹底（コネクションプーリング、タイムアウト設定）。
  3. アーキテクチャの整理（適材適所でDBを使い分ける）。

これらは規模の大小に関わらず、信頼性の高いシステムを作る上で普遍的に重要な要素と言えます。

*元記事: Scaling PostgreSQL to power 800 million ChatGPT users | OpenAI*

Discussion