- OpenAI ने ChatGPT और API ट्रैफ़िक में तेज़ बढ़ोतरी से निपटने के लिए PostgreSQL इन्फ्रास्ट्रक्चर को बड़े पैमाने पर स्केल किया, और एकल Azure PostgreSQL Flexible Server तथा लगभग 50 read replicas के साथ हर सेकंड लाखों QPS संभाले
- रीड-केंद्रित वर्कलोड के लिए अनुकूलित संरचना बनाए रखते हुए, write load कम करने के लिए कुछ वर्कलोड को Azure Cosmos DB पर माइग्रेट किया
- PgBouncer connection pooling, cache locking, rate limiting, workload isolation जैसी विभिन्न optimization के जरिए स्थिरता और latency में सुधार किया
- single-primary architecture की सीमाओं को पार करने के लिए high availability (HA) configuration, hot standby, और cascading replication की टेस्टिंग साथ-साथ की गई
- इस तरीके से 99.999% availability और दो अंकों वाली millisecond p99 latency हासिल की गई, और आगे sharded PostgreSQL या distributed systems तक विस्तार की संभावना बनाई गई
PostgreSQL विस्तार का अवलोकन
- PostgreSQL, ChatGPT और OpenAI API की मुख्य data system है, और पिछले 1 साल में load 10 गुना से अधिक बढ़ा
- एक single-primary instance और दुनिया भर में फैली लगभग 50 read replicas के साथ 80 करोड़ उपयोगकर्ताओं के अनुरोध प्रोसेस किए गए
- रीड-केंद्रित संरचना बनाए रखते हुए write load कम करने के लिए कुछ वर्कलोड को Azure Cosmos DB पर शिफ्ट किया गया
- नई tables जोड़ना प्रतिबंधित है, और नए वर्कलोड को डिफ़ॉल्ट रूप से sharding systems पर रखा जाता है
single-primary architecture की चुनौतियाँ और उनका समाधान
- single-writer structure में write scalability की सीमा और single point of failure (SPOF) की समस्या होती है
- read traffic को replicas में बाँटा गया, और write traffic में से shardable workloads को Cosmos DB पर माइग्रेट किया गया
- failure की स्थिति में तेज़ promotion (failover) के लिए hot standby के साथ high availability configuration लागू की गई
- read load में तेज़ उछाल के दौरान cache miss storm की वजह से CPU saturation की समस्या आई
- cache locking mechanism लागू करके एक ही key पर duplicate queries को रोका गया
क्वेरी और resource optimization
- जटिल multi-join queries CPU का अत्यधिक उपयोग कर रही थीं, जिससे service latency बढ़ रही थी
- ORM द्वारा जनरेट किए गए inefficient SQL की समीक्षा की गई, और जटिल join logic को application layer में शिफ्ट किया गया
- idle_in_transaction_session_timeout setting से लंबे समय तक idle queries को रोका गया
- “Noisy neighbor” समस्या को हल करने के लिए ट्रैफ़िक को priority-आधारित instances में अलग किया गया
- low-priority requests का high-priority services पर असर न पड़े, इसके लिए isolation लागू किया गया
connection management और load control
- Azure PostgreSQL की 5,000 connections limit की समस्या हल करने के लिए PgBouncer को proxy layer के रूप में लागू किया गया
- connection reuse से औसत connection time 50ms → 5ms तक घटा
- inter-region network latency कम करने के लिए proxy, client और replica को एक ही region में रखा गया
- rate limiting को application, proxy और query level पर लागू कर अचानक ट्रैफ़िक spikes को रोका गया
- ORM layer में भी कुछ query digests को block करने की क्षमता जोड़ी गई
replication और schema change management
- primary को सभी replicas तक WAL logs stream करने पड़ते हैं, इसलिए replicas बढ़ने पर network load भी बढ़ता है
- cascading replication का Azure टीम के साथ मिलकर परीक्षण किया जा रहा है
- intermediate replicas नीचे की replicas तक WAL पहुँचाकर 100 से अधिक replicas तक स्केल करने की संभावना बनाते हैं
- full table rewrite करवाने वाले schema changes पर रोक है
- 5-second timeout के भीतर केवल हल्के बदलावों की अनुमति है, और index create/delete को concurrently किया जा सकता है
- backfill के दौरान भी कड़े rate limits लागू किए जाते हैं
उपलब्धियाँ और आगे की योजना
- PostgreSQL ने हर सेकंड लाखों QPS संभालते हुए दहाइयों millisecond p99 latency और 99.999% availability हासिल की
- पिछले 12 महीनों में केवल एक SEV-0 incident हुआ (ChatGPT ImageGen लॉन्च के समय)
- बाकी बचे write-heavy workloads को भी चरणबद्ध तरीके से Cosmos DB पर माइग्रेट किया जा रहा है
- cascading replication पूरा होने के बाद replica scalability और stability को और मज़बूत करने की योजना है
- भविष्य में sharded PostgreSQL या वैकल्पिक distributed systems अपनाने की संभावना पर विचार किया जा रहा है
अभी कोई टिप्पणी नहीं है.