CDN और WAF से प्राइवेट नेटवर्क तक सुरक्षा की परतें, और rolling व blue/green deploy तथा expand and contract माइग्रेशन वाली डिलीवरी पाइपलाइन। अंत में स्पाइक वाले दिन के लिए go-live चेकलिस्ट।
Author
Anichur Rahaman
चौथे भाग की checkout वाली शिकायत से सत्रह मिनट पहले, उसी release की सुबह 9:44 बजे, टिकट-बिक्री साइट के ऑन-कॉल इंजीनियर के सामने एक अलग मुसीबत है। बिक्री 10:00 बजे शुरू होगी और क़रीब 1,000 ख़रीदार एक ही मिनट में टूट पड़ेंगे। एक developer order email की एक वर्तनी-ग़लती सुधारने के लिए एक लाइन का फ़िक्स भेजना चाहता है। 9:52 पर dashboard दिखाता है कि मुट्ठी भर पतों से हर मिनट 4,000 login कोशिशें हो रही हैं, यानी कोई स्कैल्पर स्क्रिप्ट गरम हो रही है। (यह काल्पनिक दृश्य है, असली घटना नहीं।)
उस सुबह क्या होगा, यह हफ़्तों पहले लिए गए दो फ़ैसले तय करते हैं: इंटरनेट system का कितना हिस्सा छू सकता है, और deploy के लिए साइट रोकनी पड़ती है या नहीं। जवाब अगर "सब कुछ" और "हाँ" है, तो इंजीनियर को फ़िक्स लौटाना पड़ता है और उम्मीद करनी पड़ती है कि स्क्रिप्ट ख़ुद थक जाए।
इस आख़िरी लेख में दोनों बातें हैं: इंटरनेट से data तक एक मज़बूत किया हुआ रास्ता, और ऐसी डिलीवरी पाइपलाइन जो साइट को कभी बंद नहीं करती। आधार मेरे अपने फ़ील्ड नोट्स हैं, उन platform से जिन्हें मैंने फ़्लैश सेल, टिकट release या परीक्षा शुरू होने जैसे तय स्पाइक के लिए तैयार किया। ये एक ख़ास सेटअप के सबक़ हैं, हर जगह लागू होने वाला नुस्ख़ा नहीं।
यह "हाई-वॉल्यूम system की इंजीनियरिंग" सीरीज़ का 5वाँ और आख़िरी भाग है। पिछले भाग: भाग 1, वेब टियर और autoscaling; भाग 2, queue और worker; भाग 3, data टियर; भाग 4, ऑब्ज़र्वेबिलिटी।
कोई एक product पूरा system सुरक्षित नहीं करता। फ़ायरवॉल लीक हुए password का इलाज नहीं है, और मज़बूत password भी बेकार है अगर database इंटरनेट के लिए खुला पड़ा हो। व्यावहारिक रास्ता परतों का है, जहाँ हर परत मानकर चलती है कि उसके आगे वाली परत कभी-कभी चूकेगी।
यहाँ OWASP Top 10 हक़ीक़त की अच्छी कसौटी है। मौजूदा संस्करण OWASP Top 10:2025 में पहले नंबर पर Broken Access Control है और दूसरे पर Security Misconfiguration। दोनों इस बारे में हैं कि system कैसे जोड़ा गया है, किसी अनोखे एक्सप्लॉइट के बारे में नहीं। मेरा अनुभव भी यही कहता है: ज़्यादातर घटनाओं के पीछे खुला छूटा पोर्ट, न बदली गई डिफ़ॉल्ट सेटिंग या ज़रूरत से बड़ी permission होती है।
जो कुछ भी पब्लिक है, उसके आगे वेब ऐप्लिकेशन फ़ायरवॉल (WAF) वाला CDN लगाइए। यह भारी बाढ़ सोख लेता है, कैश्ड पेज आपके server को छुए बिना परोस देता है, और आम हमलों के पैटर्न आपके कोड तक पहुँचने से पहले रोक देता है। स्पाइक में यह आपकी क्षमता भी बचाता है: जिस request का जवाब एज दे देता है, उसे आपके वेब नोड देखते ही नहीं।
तीन सेटिंग बाक़ी सबसे ज़्यादा मायने रखती हैं:
Origin को ऐसे ताला लगाइए कि वह सिर्फ़ एज network का traffic ले। अगर आपके server इंटरनेट पर किसी को भी सीधे जवाब देते हैं, तो WAF सुझाव भर है, नियंत्रण नहीं।
ट्रांज़िट में सब कुछ एन्क्रिप्ट कीजिए। जहाँ क्लाइंट सपोर्ट करें वहाँ TLS 1.3 चलाइए और TLS 1.2 को न्यूनतम सीमा रखिए। PCI DSS 4.0 पब्लिक network पर कार्डहोल्डर data के लिए मज़बूत क्रिप्टोग्राफ़ी माँगता है और SSL व पुराने TLS संस्करणों को बाहर रखता है, इसलिए अगर आप कार्ड से payment लेते हैं तो TLS 1.0 और 1.1 बंद कर दीजिए।
डिज़ाइन का असली सवाल यह है कि TLS कहाँ ख़त्म होता है। कई सेटअप में वह CDN पर ख़त्म होता है, फिर होस्ट के reverse proxy पर दोबारा, और उसके बाद container तक सादा HTTP जाता है। यह आख़िरी हॉप प्राइवेट होस्ट network पर ठीक है, पर तभी जब आपको पक्का पता हो कि वह सच में प्राइवेट है। traffic अगर ऐसे network से गुज़रे जो आपके क़ाबू में नहीं, तो उस हॉप को भी एन्क्रिप्ट कीजिए।
एक और जाल है आपस में न मिलती सीमाएँ। जो एक platform मैंने चलाया, उसमें दो nginx परतें एक के बाद एक थीं: होस्ट प्रॉक्सी, जहाँ TLS ख़त्म होता था, और container का प्रॉक्सी, PHP-FPM के आगे। होस्ट की डिफ़ॉल्ट बॉडी लिमिट 1 MB थी, इसलिए अपलोड चुपचाप फ़ेल होते रहे, जब तक हर परत एक सुर में नहीं हुई: दोनों प्रॉक्सी में client_max_body_size, और PHP में post_max_size व upload_max_filesize। यह भरोसेमंदी का बग है, पर इससे लोग आँख मूँदकर लिमिट बढ़ाने को ललचाते हैं। अधिकतम सीमा एक बार तय कीजिए, हर परत में लगाइए और लिख रखिए।
सबसे क़ीमती नियम सबसे फीका भी है: एज और load balancer के सिवा कुछ भी पब्लिक नहीं। वेब नोड, worker, database, कैश और सर्च नोड प्राइवेट network में रहें। मैनेज्ड database और कैश सिर्फ़ उसी network से connection लें, ताकि अकेला लीक हुआ password हमलावर को अंदर का रास्ता न दे दे।
इसके ऊपर फ़ायरवॉल नियम लगाइए जो बताएँ कि कौन किससे बात कर सकता है, जैसे:
| कॉम्पोनेंट | कौन कनेक्ट कर सकता है | पब्लिक? |
|---|---|---|
| CDN / WAF | इंटरनेट | हाँ |
| Load balancer | सिर्फ़ एज network की रेंज | हाँ, सीमित |
| वेब और SSR नोड | सिर्फ़ load balancer | नहीं |
| worker और scheduler | बाहर से कोई नहीं | नहीं |
| database और कैश | वेब नोड और worker, प्राइवेट पते से | नहीं |
| SSH और admin एक्सेस | jump host या VPN, सिर्फ़ की से | नहीं |
टोपोलॉजी बदलते ही इस टेबल को दोबारा देखिए। "हम एक महीने तक खुले पड़े थे" वाली ज़्यादातर कहानियाँ एक जल्दबाज़ी के बदलाव से शुरू होती हैं, जिसे किसी ने लिखा नहीं।
network आइसोलेशन सिर्फ़ इंटरनेट की बात नहीं है। एक होस्ट पर मैंने देखा कि कई पड़ोसी प्रोजेक्ट एक ही Docker network में थे, और हर प्रोजेक्ट ने अपनी PHP सर्विस का नाम app रखा था। प्रॉक्सी request पोर्ट 9000 पर app को भेज रहा था, और यह नाम कई containers पर रिज़ॉल्व हो रहा था। आधी request दूसरे प्रोजेक्ट के PHP-FPM तक पहुँच रही थीं।
कुछ क्रैश नहीं हुआ। पेज बस ग़लत कोड से आ रहे थे, ग़लत कॉन्फ़िगरेशन के साथ, और कभी-कभी ग़लत database से। यह एक साथ भरोसेमंदी की समस्या भी है और data लीक की भी।
इलाज सीधा है। हर प्रोजेक्ट को अपना अलग network दीजिए, सर्विस के नाम अनोखे रखिए, और जिस सर्विस को सिर्फ़ किसी और तक पहुँचना है, उसे किसी network पर मत खोलिए। किसी deployment की समीक्षा करते समय सीधा सवाल पूछिए: क्या यह container ऐसी किसी चीज़ तक पहुँच सकता है जिस तक पहुँचने की उसे कोई वजह नहीं?
तीन आदतें नुक़सान का बड़ा हिस्सा रोक देती हैं।
आख़िर में मानकर चलिए कि कभी न कभी कुछ बिगड़ेगा। ऐसे backup रखिए जिन तक हमलावर उन्हीं क्रेडेंशियल से न पहुँच सके, और रीस्टोर का अभ्यास कीजिए। यह बात मैंने बिज़नेस system के लिए रैनसमवेयर-तैयार backup में अलग से लिखी है। यहाँ बस इतना जोड़ूँगा: जिस रीस्टोर को आपने कभी आज़माया नहीं, वह योजना नहीं, उम्मीद है।
डरावना deploy लोगों को पैच और बदलाव से बचना सिखा देता है, इसलिए लक्ष्य बोरिंग deploy होना चाहिए। पहला नियम: एक बार बिल्ड कीजिए और हू-ब-हू वही आर्टिफ़ैक्ट भेजिए। इमेज एक मशीन पर बनाइए, पुश कीजिए, और हर नोड वही इमेज खींचे। traffic स्विच करने से पहले सभी नोड के image ID मिलाइए। traffic सँभाल रहे नोड पर कभी सोर्स अपडेट और बिल्ड मत चलाइए: एक घंटे के फ़र्क़ से बने दो नोड चुपचाप अलग हो सकते हैं, और बीच में फ़ेल हुआ बिल्ड चालू server को बिगाड़ सकता है।
कॉन्फ़िगरेशन इमेज से अलग चलता है, इसलिए वही आर्टिफ़ैक्ट स्टेजिंग से प्रोडक्शन तक बिना बदले जाता है। इसी से आप कह पाते हैं कि जो test किया, वही release हुआ।
"ज़ीरो डाउनटाइम" अक्सर database बदलावों पर टूटता है। rolling deploy के दौरान पुराना और नया कोड एक ही स्कीमा पर साथ चलते हैं, इसलिए माइग्रेशन को दोनों के लिए चलना होगा।
मानक जवाब है expand and contract पैटर्न, जिसे parallel change भी कहते हैं:
एक हिसाब वाला उदाहरण, काल्पनिक संख्याओं के साथ। 24 लाख पंक्तियों वाली customers टेबल में phone कॉलम का नाम बदलकर contact_phone करना है। Expand: nullable कॉलम contact_phone जोड़िए। Migrate: नया कोड हर सेव पर दोनों कॉलम में लिखता है, और एक बैकग्राउंड जॉब 5,000 पंक्तियों के batch में कॉपी करता है। यानी 480 batch; हर batch क़रीब दो सेकंड का मानें तो कुल लगभग 16 मिनट, और किसी user के लिए टेबल लॉक नहीं होती। रीड बदलने से पहले जाँचिए कि जिन पंक्तियों में phone भरा है पर contact_phone ख़ाली, उनकी गिनती शून्य है। तभी contract कीजिए।
ड्रॉप इकलौता ऐसा क़दम है जो पलटा नहीं जा सकता, इसलिए वह इंतज़ार करता है। माइग्रेशन तब चलाइए जब साइट traffic सँभाल रही हो, और नतीजा जाँचिए: पहले-बाद की पंक्तियों की गिनती, और यह जाँच कि कुछ आधा-बदला न छूटा हो। विंडो से पहले ताज़ा database डंप लीजिए, और कोड के लिए भी रोलबैक रेफ़रेंस रखिए।
अलग टियर को अलग रणनीति चाहिए। stateless PHP बैकएंड के लिए मैं rolling deploy करता हूँ, एक बार में एक नोड:
दो नोड हों तो साइट के पास हमेशा एक सेहतमंद server रहता है। idempotent request के लिए प्रॉक्सी का retry नियम अस्थायी गड़बड़ी को user से छिपा सकता है, पर कार्ड चार्ज करने वाली request पर इसे चालू मत कीजिए।
server-रेंडर्ड फ़्रंटएंड के लिए मुझे blue/green पसंद है। नया वर्ज़न पुराने के बग़ल में चालू कीजिए, अलग से test कीजिए, फिर प्रॉक्सी की एक फ़ाइल बदलकर graceful reload से स्विच कीजिए। rollback वही क़दम उलटी दिशा में है, क़रीब एक सेकंड। StoreConsole भी अपना प्रोडक्शन इसी तरह चलाता है।
worker और scheduler को अपनी अलग देखभाल चाहिए। worker बदलने से पहले queue ड्रेन कीजिए: नए जॉब लेना बंद कीजिए, चल रहे जॉब को ख़त्म होने के लिए उदार grace period दीजिए, फिर नया वर्ज़न चालू कीजिए। Scheduler सबसे आख़िर में चालू कीजिए, ठीक एक नोड पर, ताकि आधा-deploy हुआ system कोई दोहराया जाने वाला टास्क दो बार या ग़लत कोड पर न चला दे।
कमांड लौट आने पर deploy पूरा नहीं होता, साबित करने पर होता है। ऐसी end-to-end जाँच चलाइए जिसमें एक असली ख़रीदारी या सबमिशन हो, देखिए कि queue आगे बढ़ रही हैं, फिर soak कीजिए: काम पूरा कहने से पहले तय समय तक एरर रेट, p95 लेटेंसी और queue की उम्र देखते रहिए। इस सीरीज़ के भाग 4 के dashboard इस्तेमाल कीजिए, और किसी डरावने alert पर कदम उठाने से पहले उसे असली प्रोसेस से मिलाकर देख लीजिए।
हाई-वॉल्यूम event से पहले मैं यह चेकलिस्ट चलाता हूँ:
वापस 9:44 पर। यह सब हो तो इंजीनियर वर्तनी-फ़िक्स को हाँ कह सकता है। इमेज घंटा भर पहले बनी और test हुई थी, नोड एक-एक करके रोल होते हैं, और हर मिनट की 4,000 login कोशिशें सिर्फ़ login पाथ की चुनौती से टकराती हैं, जबकि ख़रीदार बेरोक-टोक ब्राउज़ करते हैं। database का कोई पब्लिक पता नहीं, इसलिए एज के पीछे स्क्रिप्ट को ढूँढने लायक़ कुछ नहीं मिलता। फ़िक्स लाइव होकर 9:55 तक soak पूरा कर लेता है, बिक्री शुरू होने से पाँच मिनट पहले।
नीचे की टेबल दिखाती है कि हर परत कैसे टूटती है और उसे जल्दी कैसे जाँचा जाए।
| परत | आम चूक | तेज़ जाँच |
|---|---|---|
| एज | Origin सीधे पहुँच में | एज network के बाहर से origin के पते पर request भेजिए |
| network | database इंटरनेट पर खुला | बाहरी होस्ट से पोर्ट स्कैन |
| होस्ट | साझा सर्विस alias | देखिए हर नाम किन containers पर रिज़ॉल्व होता है |
| सीक्रेट | इमेज में बैठे क्रेडेंशियल | इमेज की परतों और रिपॉज़िटरी हिस्ट्री में खोजिए |
| Deploy | नोड पर अलग-अलग बिल्ड | हर नोड के image ID मिलाइए |
| database | लोड में विनाशकारी माइग्रेशन | expand and contract के हिसाब से समीक्षा; कॉपी पर रिहर्सल |
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
