OpenAI: 80 करोड़ उपयोगकर्ताओं को संभालने के लिए PostgreSQL को बड़े पैमाने पर स्केल करने की रणनीति

सारांश:

• OpenAI एक single Primary और लगभग 50 Read Replica (Azure Flexible Server) के साथ सैकड़ों लाख QPS और 80 करोड़ उपयोगकर्ताओं को संभाल रहा है।
• write load को बाँटने के लिए sharding-योग्य workloads को Azure Cosmos DB में माइग्रेट किया गया, और application level पर 'Lazy Write' जैसी तकनीकों से writes को optimize किया गया।
• PgBouncer को अपनाकर connection latency को 50ms से 5ms तक घटाया गया, और cache miss storm को रोकने के लिए cache lock (Cache Locking) mechanism लागू किया गया।
• complex join queries को हटाने, 5 सेकंड से कम के सख्त schema change timeout, और traffic priority के आधार पर workload isolation के जरिए stability सुनिश्चित की गई।

विस्तृत सारांश:
1. पृष्ठभूमि और आर्किटेक्चर की वर्तमान स्थिति
OpenAI का PostgreSQL ट्रैफिक पिछले 1 साल में 10 गुना से अधिक बढ़ा है, और अब यह 80 करोड़ उपयोगकर्ताओं तथा सैकड़ों लाख QPS (प्रति सेकंड queries) को संभाल रहा है। हैरानी की बात यह है कि यह स्केल single Primary instance और दुनिया भर में फैले लगभग 50 Read Replica की संरचना पर चल रहा है। शुरुआती डिज़ाइन में दरारें न आएँ, इसके लिए OpenAI ने infrastructure और application layer, दोनों स्तरों पर बड़े पैमाने पर optimization किए।

2. मुख्य bottleneck समाधान और optimization रणनीतियाँ

• write load का वितरण:

  • PostgreSQL की single Writer संरचना में scale की सीमा है, और MVCC (Multi-Version Concurrency Control) के कारण write amplification की समस्या भी होती है।
  • समाधान के रूप में, horizontally partition किए जा सकने वाले write-intensive workloads को Azure Cosmos DB जैसे systems में माइग्रेट किया गया।
  • मौजूदा PostgreSQL में नई tables बनाने पर रोक लगाई गई, और application bugs को ठीक करने के साथ Lazy Write (traffic spikes को smooth करने के लिए writes को delay करना) लागू किया गया ताकि Primary पर load कम से कम रहे।

• query optimization और ORM प्रबंधन:

  • अतीत में 12 tables को join करने वाली query ने outage (SEV) पैदा किया था, इसलिए complex multi-join से बचते हुए logic को application layer में अलग किया गया।
  • ORM द्वारा generate की जाने वाली inefficient queries की लगातार समीक्षा की जाती है, और idle_in_transaction_session_timeout setting के जरिए idle queries को Autovacuum ब्लॉक करने से रोका गया।

• connection pooling (PgBouncer):

  • Azure PostgreSQL की connection limit (5,000) और connection storm को रोकने के लिए PgBouncer को proxy layer में deploy किया गया।
  • transaction/statement pooling mode का उपयोग कर connection reusability बढ़ाई गई, और औसत connection time को 50ms से 5ms तक घटाया गया।

• cache miss रोकथाम (Cache Locking):

  • cache expire होने पर बड़ी संख्या में requests के एक साथ DB पर टूट पड़ने वाली 'Thundering Herd' समस्या को रोकने के लिए cache lock (Leasing) mechanism अपनाया गया।
  • किसी specific key पर cache miss होने पर केवल एक request को DB access का अधिकार (lock) मिलता है ताकि वह data refresh करे, और बाकी requests इंतज़ार करें—इस तरह DB load को रोका गया।

3. स्थिरता और संचालन नीतियाँ

• single point of failure (SPOF) को कम करना: Primary failure की स्थिति में भी read requests को Replica के जरिए serve किया जाता है, जिससे outage severity कम होती है; वहीं Primary high availability (HA) mode में Hot Standby बनाए रखता है ताकि तेज failover सुनिश्चित हो सके।
• workload isolation: 'Noisy Neighbor' समस्या को रोकने के लिए traffic को महत्व (Low/High Priority) के आधार पर अलग-अलग instances की ओर route किया जाता है।
• सख्त schema management: full table rewrite कराने वाले बदलावों पर रोक है, और schema changes के समय 5 सेकंड का सख्त timeout लागू किया जाता है ताकि service latency न बढ़े।

4. आगे की योजना (The Road Ahead)
मौजूदा संरचना से पर्याप्त scalability मिल चुकी है, लेकिन आगे और अधिक Read Replica विस्तार के लिए उस संरचना का परीक्षण किया जा रहा है जिसमें Primary हर Replica को सीधे WAL भेजने के बजाय, बीच का Replica नीचे की ओर WAL आगे बढ़ाता है—इसे Cascading Replication कहा जाता है। लंबी अवधि में PostgreSQL के sharding पर भी विचार किया जा रहा है.