將 PostgreSQL 擴展以支援 8 億 ChatGPT 用戶

OpenAI 已將 PostgreSQL 擴展至支援 8 億用戶與每秒數百萬次查詢（QPS），證明單主節點架構結合嚴謹的工程優化後，能可靠地處理大規模以讀取為主的工作負載。透過使用單一 Azure PostgreSQL flexible server 實例作為主節點，並在多個全球區域部署近 50 個讀取副本，OpenAI 維持了低雙位數毫秒 p99 客戶端延遲以及「五個九」的可用性。

克服單主節點限制

雖然單主節點架構對讀取密集的流量相當有效，但會成為寫入操作的瓶頸，且可能成為單點故障。OpenAI 透過以下策略解決這些挑戰：

緩解寫入負載

為防止主節點在寫入高峰時過載，OpenAI 將可分片且寫入密集的工作負載遷移至如 Azure Cosmos DB 等分片系統。組織現在禁止向現有 PostgreSQL 部署新增表格，所有新工作負載預設使用分片系統。此外，還實施了應用層面的優化——例如修正冗餘寫入與引入延遲寫入——以平緩流量高峰。

高可用性與故障緩解

為消除主節點作為完整單點故障的風險，OpenAI 將關鍵讀取查詢卸載至副本。即使主節點失效，讀取請求仍可使用。為完整復原，主節點以高可用性（HA）模式運行，搭配熱備援——一個已同步的副本，可立即升級以最小化停機時間。

高 QPS 的技術優化

OpenAI 實施了多層架構，以防止 PostgreSQL 因資源耗盡而導致效能下降。

連線池與延遲

使用 PgBouncer 作為語句或交易池模式的代理層，OpenAI 減少了活躍客戶端連線數，並將平均連線時間從 50ms 降至 5ms。為降低網路開銷，PgBouncer pod 與客戶端及副本同置於同一區域。

快取與「快取未命中風暴」

為防止快取未命中導致的讀取流量突增，OpenAI 實作了快取鎖定（租用）機制。此機制確保只有一個讀取特定缺失鍵的讀者會查詢 PostgreSQL 以重新填充快取，其他同時請求相同鍵的請求則會等待，而不會同時衝擊資料庫。

查詢與綱要管理

OpenAI 優化查詢以避免線上交易處理（OLTP）反模式，特別是避免複雜的多表聯接。曾有一次，聯接 12 個表的查詢被確定為高嚴重性事件的根因。團隊現在將複雜的聯接邏輯移至應用層，並使用 idle_in_transaction_session_timeout 防止長時間閒置查詢阻塞 autovacuum。

綱要變更受到嚴格管控：僅允許不會觸發完整表格重寫的輕量操作，且對所有綱要變更強制執行 5 秒的逾時限制。

擴展讀取副本與工作負載隔離

為維持全球效能，OpenAI 使用近 50 個讀取副本。然而，由於主節點必須將寫前日誌（WAL）資料串流至每個副本，進一步擴展最終可能使主節點的 CPU 與網路頻寬過載。

級聯複製

OpenAI 正與 Azure PostgreSQL 團隊合作實作級聯複製，讓中間副本將 WAL 資料轉發給下游副本。此舉旨在讓副本數量可擴展至超過 100 個，而不會使主節點負荷過重。

工作負載隔離

為防止「噪音鄰居」問題，OpenAI 透過將請求分為低優先級與高優先級層級，並導向不同實例來隔離工作負載。此舉確保資源密集的低優先級請求不會削弱關鍵高優先級功能的效能。

效能結果

透過這些優化，OpenAI 達成了以下生產指標：

• 可用性： 五個九的可用性。
• 延遲： 低雙位數毫秒 p99 客戶端延遲。
• 可靠性： 在過去 12 個月內僅發生一次 SEV-0 PostgreSQL 事件，該事件發生於 ChatGPT ImageGen 上線時，寫入流量激增超過 10 倍。