पहले से तय स्पाइक सेकंडों में चरम पर पहुँचता है, जबकि नया सर्वर तैयार होने में मिनट लगते हैं। जानिए अचानक दबाव में क्या scale होता है, reactive नियमों से pre-scaling क्यों बेहतर है, SSR और PHP-FPM परतें कैसे सजाएँ और load test कैसे करें।
Author
Anichur Rahaman
20 request प्रति सेकंड, बिल्कुल सपाट। फ़्लैश सेल खुलने से पहले की रात 11:59 पर एक ऑनलाइन स्टोर का traffic बस इतना ही है, और प्लैटफ़ॉर्म लीड dashboard देख रहा है। autoscaling का नियम तैयार है: CPU पाँच मिनट तक 70% से ऊपर रहे तो एक server जुड़ेगा। (यह एक काल्पनिक दृश्य है, कोई असली दुकान नहीं।)
आधी रात को सेल खुलती है और क़रीब एक हज़ार ख़रीदार एक ही मिनट में टूट पड़ते हैं। लोड छलाँग लगाकर 440 request प्रति सेकंड पर पहुँच जाता है। 12:01 पर dashboard अब भी हरा है, क्योंकि पाँच मिनट का औसत मुश्किल से हिला है। 12:03 पर checkout timeout दे रहा है। नया server 12:06 पर जुड़ता है, तब तक ख़रीदार किसी प्रतिद्वंद्वी की दुकान पर जा चुके हैं।
autoscaling लोड के बाद जवाब देता है, और पहले से तय स्पाइक उस जवाब से पहले आ जाता है। यह लेख बताता है कि अचानक दबाव में असल में क्या scale होता है, किससे scale करने की उम्मीद नहीं रखनी चाहिए, और इसे event के बीच में नहीं, उससे पहले कैसे परखें।
नीचे के आँकड़े मेरे अपने test से हैं, एक ही Laravel और Next.js सेटअप पर। ये तरीक़ा दिखाने के लिए हैं, हर जगह लागू होने वाला बेंचमार्क नहीं। अपने system पर ख़ुद चलाकर देखें।
यह पाँच भागों की सीरीज़ "हाई-वॉल्यूम system की इंजीनियरिंग" का पहला भाग है। इसमें एज से लेकर एप्लिकेशन तक request के रास्ते की बात है। queue, data टियर, observability और सुरक्षित deploy भाग 2 से 5 में आएँगे।
दो तरह के traffic के लिए दो अलग जवाब चाहिए। धीरे-धीरे बढ़ता लोड किसी भी कंट्रोल लूप को भाँपने और जवाब देने का वक़्त देता है। अचानक की सीढ़ी-छलाँग यह वक़्त नहीं देती। अगर एक मिनट के भीतर लोड 20 से 440 request प्रति सेकंड पर पहुँच जाए, तो पाँच मिनट का औसत CPU देखने वाला नियम तब तक कुछ देख ही नहीं पाया होता।
अच्छी बात यह है कि पहले से तय स्पाइक का अंदाज़ा लगाया जा सकता है। शुरू होने का समय आपको पता होता है, कितने लोग आएँगे यह मोटे तौर पर पता होता है, और पिछले event का request मिक्स अक्सर दोबारा चलाकर देखा जा सकता है। यही पहले से मिली जानकारी आपका सबसे बड़ा औज़ार है, और इस लेख का ज़्यादातर हिस्सा इसे काम में लाने के बारे में है।
क्या scale करना है, यह तय करने से पहले एक request का पूरा रास्ता खींच लें। मेरे चलाए सेटअप में यह कुछ ऐसा दिखता है: सबसे आगे CDN और WAF, फिर एक managed load balancer, दो बैकएंड वेब नोड, एक या ज़्यादा server-side rendering (SSR) फ़्रंटएंड नोड, बैकग्राउंड जॉब के लिए एक worker नोड, और सबके पीछे data टियर।
हर डिब्बे की अपनी ख़राबी होती है और अपना scale करने का तरीक़ा भी। सबको एक "server" मान लेने का नतीजा यह होता है कि जिस परत में कभी दिक़्क़त थी ही नहीं, उसी में RAM बढ़ा दी जाती है।
सबसे पहले आगे एक CDN लगाएँ। स्टैटिक फ़ाइलें, इमेज और हर गेस्ट के लिए एक जैसे दिखने वाले पेज स्पाइक के दौरान आपके server तक पहुँचने ही नहीं चाहिए। उसी परत पर WAF और बॉट-नियम स्क्रैपर्स को भी रोकते हैं, ताकि ख़रीदारों के लिए रखी गई क्षमता वे न खा जाएँ।
CDN के पीछे health check और connection draining वाला managed load balancer रखें। Health check बीमार नोड को अपने-आप बाहर कर देता है। Draining नोड को जाने से पहले चल रही request पूरी करने देता है, और इसी वजह से deploy और scale-in user को दिखते ही नहीं।
दो बारीक बातें जाँचने लायक़ हैं। पहली, बैलेंसिंग एल्गोरिदम। कई cloud load balancer डिफ़ॉल्ट में round robin चलाते हैं, जो मानकर चलता है कि हर request का ख़र्च बराबर है। checkout और सर्च बराबर नहीं होते। "Least outstanding requests" या "least connections" मोड अगली request उस नोड को भेजता है जिसके पास सबसे कम काम चल रहा हो। मिसाल के तौर पर AWS में Application Load Balancer का डिफ़ॉल्ट round robin है, और least outstanding requests एक target group की सेटिंग है। दूसरी, load balancer ख़ुद भी एक ऐसी सर्विस है जिसे scale होना पड़ता है। AWS के दस्तावेज़ों के मुताबिक़ एक Application Load Balancer क़रीब पाँच मिनट में अपनी क्षमता दोगुनी कर सकता है, और जिन event में पाँच मिनट से कम में traffic दोगुने से ज़्यादा होने वाला हो, उनके लिए पहले से क्षमता रिज़र्व करने की सुविधा है (capacity reservation गाइड देखें)। दूसरे प्रोवाइडर्स की भी ऐसी सीमाएँ होती हैं, इसलिए अपने वाले से पूछ लें।
मेरे load test में load balancer कभी रुकावट नहीं बना: सबसे ऊँची रेट पर भी CPU 8% या उससे कम रहा और एरर शून्य थे। यही आम तस्वीर है। पहले रास्ते में और आगे देखें।
दो वेब नोड load balancer के पीछे तभी रखे जा सकते हैं जब कोई भी नोड कोई भी request सँभाल सके। इस गुण को stateless कहते हैं। इसे शुरू से ठीक रखना सस्ता है, बाद में जोड़-तोड़ से ठीक करना तकलीफ़देह। दूसरा नोड जोड़ने से पहले यह चेकलिस्ट मिला लें।
StoreConsole जैसा self-hosted प्लैटफ़ॉर्म इसी वजह से सेशन और cache Redis में रखता है, ताकि नोड एक-दूसरे की जगह ले सकें।
यहीं मुझे सबसे ज़्यादा बार हैरानी हुई है। Next.js server पेज एक Node.js प्रोसेस में रेंडर करता है, और Node आपका JavaScript एक ही थ्रेड पर चलाता है। मशीन कितनी भी बड़ी हो, एक प्रोसेस रेंडरिंग में लगभग एक ही कोर इस्तेमाल कर पाता है।
मैंने पिछले एक पीक का असली request मिक्स k6 से सिर्फ़ एक फ़्रंटएंड प्रोसेस पर चलाया। वह लगभग 220 से 250 request प्रति सेकंड पर जवाब दे गया। उसके बाद p95 latency क़रीब 260 ms से उछलकर क़रीब 3 सेकंड हो गई और p99 6.4 सेकंड तक पहुँची। इस पूरे दौरान होस्ट पर दो से ज़्यादा कोर ख़ाली पड़े थे। असली event के पीक मिनट में क़रीब 440 request प्रति सेकंड चाहिए थे, यानी एक प्रोसेस ठीक उसी पल फ़ेल होता जब उसकी सबसे ज़्यादा ज़रूरत थी।
हल सीधा था: एक ही इमेज से कई एक जैसे फ़्रंटएंड container चलाना (मेरे मामले में तीन), आगे nginx में least_conn, जो हर request उस server को देता है जिस पर सबसे कम सक्रिय connection हों। फिर टार्गेट रेट पर दोबारा test। Next.js के लिए एक और बात: डिफ़ॉल्ट में हर इंस्टेंस अपना लोकल cache रखता है, इसलिए कई इंस्टेंस चलाएँ तो फ़्रेमवर्क के दस्तावेज़ में बताए तरीक़े से एक साझा cache स्टोर तय कर दें।
यहाँ क्षमता की योजना सीधा गुणा है। प्रति प्रोसेस नापी गई सीमा को प्रोसेस की संख्या से गुणा करें, फिर अपेक्षित पीक से हेडरूम समेत मिलाकर देखें।
| मद | मान (एक सेटअप) | टिप्पणी |
|---|---|---|
| पीक मिनट में ज़रूरत | ~440 req/s | पिछले असली event को दोबारा चलाकर मिला |
| एक SSR प्रोसेस, नापा हुआ | 220-250 req/s | इसके बाद p95 ~260 ms से ~3 s हो गया |
| तीन SSR प्रोसेस | ~660-750 req/s | पीक का लगभग डेढ़ गुना, हेडरूम के तौर पर |
| Load balancer CPU | 8% या कम | रुकावट नहीं था |
बैकएंड वेब परत की समस्या उल्टी है। PHP-FPM worker प्रोसेस का एक पूल चलाता है और हर worker एक बार में एक ही request सँभालता है। पूल छोटा हुआ तो request क़तार में खड़ी रहती हैं। बहुत बड़ा हुआ तो नोड की मेमोरी ख़त्म हो जाती है और स्वैपिंग या प्रोसेस किल शुरू हो जाते हैं।
काम चलाऊ अंगूठे का नियम: ज़रूरी busy worker ≈ request प्रति सेकंड × प्रति request का औसत समय। एक काल्पनिक मिसाल: 200 request प्रति सेकंड, हर एक 150 ms की, तो क़रीब 30 busy worker चाहिए, इसलिए 60 का पूल धीमी request के लिए गुंजाइश छोड़ता है। फिर मेमोरी जाँचें: एक worker क़रीब 100 MB लेता हो तो 60 worker को क़रीब 6 GB चाहिए, यानी नोड में इससे ज़्यादा होनी चाहिए।
एक सेटअप में मैंने ये मान रखे थे: pm.max_children=60, start_servers=30, min_spare_servers=20, max_spare_servers=30 और max_requests=1000, साथ में nginx से FPM तक keepalive (keepalive 16 और fastcgi_keep_conn on)। 30 से शुरू करना अहम है: जब लहर आती है तो पूल पहले से गरम होता है, दबाव में fork नहीं करना पड़ता।
दो आदतें और फ़ायदा देती हैं। प्रोडक्शन में validate_timestamps=0 के साथ OPcache चालू रखें, और deploy पर worker रीस्टार्ट करें। साथ ही fastcgi_next_upstream error timeout http_500 http_503 और fastcgi_next_upstream_tries 2 पर विचार करें; इससे FPM की क्षणिक गड़बड़ियाँ चुपचाप retry में निपट गईं। यह सिर्फ़ idempotent request के लिए सुरक्षित है। payment की POST request को retry करना हल नहीं, बग है।
अब असली बात। Reactive autoscaling एक metric देखता है, थ्रेशोल्ड का इंतज़ार करता है, मशीन चालू करता है, फिर उसके बूट होने, load balancer से जुड़ने और cache गरम होने का इंतज़ार करता है। व्यवहार में इसमें सबसे अच्छी हालत में भी एक से तीन मिनट लगते हैं। डिफ़ॉल्ट सेटिंग देरी और बढ़ा सकती हैं: जैसे AWS EC2 Auto Scaling में डिफ़ॉल्ट cooldown 300 सेकंड है, और basic monitoring इंस्टेंस की metric पाँच मिनट में एक बार ही देती है, जब तक आप पैसे देकर एक मिनट वाली detailed monitoring न लें।
पहले से तय स्पाइक सेकंडों में चरम पर पहुँचता है। इसलिए नई मशीन तब पहुँचती है जब लोग जा चुके होते हैं, या उससे भी बुरा, जब वे एरर देख चुके होते हैं। वर्चुअल मशीन की RAM भी रीबूट के बिना नहीं बढ़ाई जा सकती, इसलिए "जहाँ है वहीं बड़ा कर दो" भी काम नहीं करता।
पहले से तय event के लिए शुरू होने से पहले नोड की न्यूनतम संख्या बढ़ा दें और बाद में घटा दें। यह सुनने में जितना महँगा लगता है, उतना है नहीं: कुछ घंटों के लिए एक अतिरिक्त नोड का ख़र्च एक नाकाम सेल के नुक़सान के सामने मामूली है। यह किसी भी नियम से ज़्यादा भरोसेमंद भी है, क्योंकि यह इस पर निर्भर नहीं करता कि कोई metric वक़्त पर सीमा पार करेगी या नहीं।
Reactive नियम अनहोनी के लिए सुरक्षा-जाल के तौर पर रखें, मुख्य योजना के तौर पर नहीं। और वही scale करें जो जल्दी scale हो सके। container के भीतर के प्रोसेस सेकंडों में शुरू हो जाते हैं, मशीनें मिनटों में, इसीलिए मैं queue worker को मशीन से नहीं, प्रोसेस से scale करता हूँ (इस सीरीज़ के भाग 2 में)।
| तरीक़ा | प्रतिक्रिया का समय | किसके लिए बेहतर |
|---|---|---|
| Pre-scale (न्यूनतम संख्या बढ़ाना) | event से पहले तैयार | पहले से तय स्पाइक |
| Reactive VM autoscaling | 1-3 मिनट या ज़्यादा | धीरे बढ़ता लोड, अनियोजित traffic |
| प्रोसेस-स्तर का scaling | कुछ सेकंड | container के भीतर queue worker |
ऊपर का कोई भी आँकड़ा अंदाज़े से नहीं आया। ये उन test से आए हैं जो event जैसे दिखते थे। सिर्फ़ होमपेज पर हथौड़ा चलाने से लगभग कुछ साबित नहीं होता। यह क्रम अपनाएँ।
जब तक test न बता दे कि सीमा कहाँ है, हार्डवेयर अपग्रेड न करें। मेरे मामले में मशीनें ठीक थीं। सीमा सिंगल-थ्रेड वाला प्रोसेस था, और हल में कॉन्फ़िगरेशन के सिवा कुछ ख़र्च नहीं हुआ।
पहला दृश्य फिर से चलाइए, इस बार तैयारी पूरी करके। रात 11 बजे वेब नोड की न्यूनतम संख्या दो से तीन हो जाती है, और SSR परत में तीन प्रोसेस least_conn के पीछे चल रहे हैं। cache गरम है और FPM पूल में पहले से 30 worker हैं।
आधी रात को 440 request प्रति सेकंड आती हैं। नापी गई सीमा क़रीब 660 है, इसलिए p95 अपने सामान्य स्तर के आसपास रहता है और autoscaling का नियम एक बार भी नहीं चलता, क्योंकि उसकी ज़रूरत ही नहीं पड़ी। 12:30 पर न्यूनतम संख्या वापस घट जाती है। पूरे event की क़ीमत थी कुछ घंटे का एक अतिरिक्त नोड।
इस रास्ते के पीछे की परतें अलग तरह से टूटती हैं। अचानक दबाव में आम तौर पर सबसे पहले बैकग्राउंड जॉब टूटते हैं, और भाग 2 में बड़े पैमाने पर queue और worker की बात है। भाग 3 में दबाव में data टियर, भाग 4 में observability, और भाग 5 में सुरक्षा और zero-downtime deploy। कारोबार बढ़ने के साथ कितना बड़ा server चाहिए, यह तय करने के लिए server बढ़ाने के रोडमैप पर मेरा पुराना लेख देखें।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
