जब AWS को नुकसान हुआ व्यापक विफलताओं की एक श्रृंखला अक्टूबर के अंत में इसके सिस्टम घंटों तक क्रैश हो गए, जिससे उद्योग को एक बार फिर प्रमुख हाइपरस्केलर्स पर अपनी अत्यधिक निर्भरता की याद आ गई। (मानो बात को साबित करने के लिए, माइक्रोसॉफ्ट को भी इसी तरह के पतन का सामना करना पड़ा कुछ दिनों के बाद।)
यह घटना इस बात पर भी असहज प्रकाश डालती है कि ये विशाल वातावरण कितने नाजुक हो गए हैं। अमेज़न में विस्तृत पोस्टमार्टम रिपोर्टक्लाउड दिग्गज ने नाजुक प्रणालियों की एक विशाल श्रृंखला का विवरण दिया जो वैश्विक संचालन को चालू रखता है – कम से कम, अधिकांश समय।
यह प्रभावशाली है कि सिस्टम का यह संयोजन वैसे ही काम करता है जैसे यह करता है – और यहीं समस्या है। इस वातावरण की नींव दशकों पहले बनाई गई थी। और जबकि अमेज़ॅन इस बात के लिए प्रशंसा का पात्र है कि जब इसे बनाया गया था तो यह प्रणाली कितनी शानदार थी, आज हाइपरस्केलर्स का सामना करने वाला पर्यावरण, पैमाना और जटिलता उन मूल डिजाइनरों की कल्पना से परे परिमाण के आदेश हैं।
बोल्ट-ऑन पैच दृष्टिकोण अब व्यवहार्य नहीं है। सभी हाइपरस्केलर्स – विशेषकर AWS – को पुनः-आर्किटेक्टेड सिस्टम की आवश्यकता है, यदि पूरी तरह से नए सिस्टम नहीं हैं जो 2026 और उससे आगे के लिए वैश्विक उपयोगकर्ताओं का समर्थन कर सकें।
क्रिस सियाबाराएथेना सिक्योरिटी के सीटीओ ने एडब्ल्यूएस पोस्टमार्टम पढ़ा और असहज होकर चले गए।
सिआबारा ने कहा, “अमेज़ॅन स्वीकार कर रहा है कि उसके एक ऑटोमेशन टूल ने उसके अपने नेटवर्क का एक हिस्सा नष्ट कर दिया है।” “आउटेज ने उजागर किया कि हमारे सिस्टम कितने गहरे परस्पर निर्भर और नाजुक हो गए हैं। यह कोई विश्वास नहीं देता है कि ऐसा दोबारा नहीं होगा। ‘बेहतर सुरक्षा उपाय’ और ‘बेहतर परिवर्तन प्रबंधन’ प्रक्रियात्मक सुधार की तरह लगते हैं, लेकिन वे वास्तुशिल्प लचीलेपन का प्रमाण नहीं हैं। यदि एडब्ल्यूएस उद्यम विश्वास को वापस जीतना चाहता है, तो उसे ठोस सबूत दिखाने की जरूरत है कि एक क्षेत्रीय घटना उसके वैश्विक नेटवर्क में दोबारा नहीं फैल सकती है। अभी, ग्राहक अभी भी उस जोखिम का अधिकांश हिस्सा खुद ही उठाते हैं।”
कैटालिन वोइकुN2W सॉफ्टवेयर के क्लाउड इंजीनियर ने भी कुछ ऐसी ही चिंताएं व्यक्त कीं।
वोइकू ने कहा, “अंतर्निहित वास्तुकला और नेटवर्क निर्भरता अभी भी वही बनी हुई है और तब तक दूर नहीं होगी जब तक कि एडब्ल्यूएस का संपूर्ण री-आर्किटेक्ट नहीं हो जाता।” “एडब्ल्यूएस इस कारण से 99.5% उपलब्धता का दावा करता है। वे समस्याओं पर बैंड एड लगा सकते हैं, लेकिन इन हाइपरस्केलर्स की प्रकृति यह है कि मुख्य सेवाएं विशिष्ट क्षेत्रों में वापस कॉल करती हैं। यह जल्द ही कभी भी बदलने वाला नहीं है।”
फॉरेस्टर प्रमुख विश्लेषक ब्रेंट एलिसपोस्टमॉर्टम की व्याख्या यह है कि AWS – अन्य हाइपरस्केलर्स के विपरीत नहीं है – ऐसी सेवाएँ हैं जो विफलता के एकल बिंदु हैं जो अच्छी तरह से प्रलेखित नहीं हैं।
हालांकि एलिस ने इस बात पर जोर दिया कि “एडब्ल्यूएस यहां आश्चर्यजनक मात्रा में ऑपरेशन कर रहा है,” उन्होंने कहा कि “कोई भी अच्छी तरह से डिज़ाइन नहीं किया गया है [technology] उन्हें इस समस्या से बचा लिया होता।”
एलिस दूसरों से सहमत थी कि AWS ने विस्तार से नहीं बताया क्यों यह व्यापक विफलता उस दिन हुई, जिससे एंटरप्राइज़ आईटी अधिकारियों के लिए यह विश्वास करना मुश्किल हो गया है कि एक महीने में ऐसा कुछ नहीं होगा। “उन्होंने इस बारे में बात की कि कौन सी चीजें विफल हुईं और किस कारण से विफलता हुई। आमतौर पर, इस तरह की विफलताएं पर्यावरण में बदलाव के कारण होती हैं। किसी ने एक स्क्रिप्ट लिखी और इसने कुछ बदल दिया या वे एक सीमा तक पहुंच गए। यह नोड्स में से एक में डिस्क विफलता के रूप में सरल हो सकता था। मुझे लगता है कि यह एक स्केलिंग समस्या है।”
एलिस की मुख्य बात: हाइपरस्केलर्स को प्रमुख वास्तुशिल्प परिवर्तनों पर गंभीरता से ध्यान देने की आवश्यकता है। एलिस ने कहा, “उन्होंने आंतरिक रूप से सामने आने वाली समस्याओं के लिए कई समाधान तैयार किए। इसका मतलब है कि पहला हाइपरस्केलर थोड़ा तकनीकी ऋण से पीड़ित है। वास्तुशिल्प निर्णय हमेशा के लिए नहीं रहते हैं।” “हम उस बिंदु पर पहुँच रहे हैं जहाँ और अधिक की आवश्यकता है।”
आइए देखें कि AWS ने क्या कहा। हालाँकि कई रिपोर्टों में व्यापक विफलताओं के लिए DNS मुद्दों को जिम्मेदार ठहराया गया है, लेकिन यह स्पष्ट नहीं है कि यह कितना सच है। वास्तव में ऐसा प्रतीत होता है कि DNS सिस्टम वहीं थे जहाँ समस्याएँ पहली बार देखी गईं, लेकिन AWS ने स्पष्ट रूप से यह नहीं बताया कि DNS समस्या का कारण क्या था।
एडब्ल्यूएस ने कहा कि समस्याएं उसके यूएस-ईस्ट-1 क्षेत्र में “बढ़ी हुई एपीआई त्रुटि दर” के साथ शुरू हुईं, जिसके तुरंत बाद एडब्ल्यूएस “नेटवर्क लोड बैलेंसर (एनएलबी) ने कुछ लोड बैलेंसरों के लिए बढ़ी हुई कनेक्शन त्रुटियों का अनुभव किया।” इसमें कहा गया है कि एनएलबी समस्याएं “एनएलबी बेड़े में स्वास्थ्य जांच विफलताओं के कारण हुईं, जिसके परिणामस्वरूप कुछ एनएलबी पर कनेक्शन त्रुटियां बढ़ गईं।” AWS ने तब पाया कि “नए EC2 इंस्टेंस लॉन्च विफल रहे” इसके बाद “कुछ नए लॉन्च किए गए इंस्टेंसेस में कनेक्टिविटी संबंधी समस्याएं आईं।”
वहां से बुरी चीजें पनपीं। “ग्राहकों ने एन. वर्जीनिया (यूएस-ईस्ट-1) क्षेत्र में Amazon DynamoDB API त्रुटि दर में वृद्धि का अनुभव किया। इस अवधि के दौरान, DynamoDB पर निर्भरता वाले ग्राहक और अन्य AWS सेवाएँ सेवा के लिए नए कनेक्शन स्थापित करने में असमर्थ थे। यह घटना सेवा की स्वचालित DNS प्रबंधन प्रणाली के भीतर एक गुप्त दोष के कारण शुरू हुई थी, जिसके कारण DynamoDB के लिए एंडपॉइंट रिज़ॉल्यूशन विफलताएँ हुईं।”
AWS ने तब इस सिद्धांत की पेशकश की: “इस समस्या का मूल कारण DynamoDB DNS प्रबंधन प्रणाली में एक अव्यक्त दौड़ की स्थिति थी, जिसके परिणामस्वरूप सेवा के क्षेत्रीय समापन बिंदु (dynamodb.us-east-1.amazonaws.com) के लिए एक गलत खाली DNS रिकॉर्ड हुआ, जिसे स्वचालन सुधारने में विफल रहा।”
और फिर यह प्यारी बात हुई: “जबकि समर्थन केंद्र डिजाइन के अनुसार दूसरे क्षेत्र में सफलतापूर्वक विफल हो गया, खाता मेटाडेटा के लिए जिम्मेदार एक सबसिस्टम ने प्रतिक्रियाएं प्रदान करना शुरू कर दिया, जिसने वैध उपयोगकर्ताओं को एडब्ल्यूएस समर्थन केंद्र तक पहुंचने से रोक दिया। जबकि हमने प्रतिक्रिया असफल होने पर इस प्रणाली को बायपास करने के लिए समर्थन केंद्र को डिजाइन किया है, इस घटना में, यह उपप्रणाली अमान्य प्रतिक्रियाएं लौटा रही थी। इन अमान्य प्रतिक्रियाओं के परिणामस्वरूप सिस्टम ने अप्रत्याशित रूप से वैध उपयोगकर्ताओं को समर्थन मामले के कार्यों तक पहुंचने से रोक दिया।”
यह अनुभाग काफ़ी लंबा है, लेकिन मैं AWS को इसे अपने शब्दों में समझाने देना चाहता हूँ:
“रेस की स्थिति में दो डीएनएस एनेक्टर्स के बीच एक अप्रत्याशित बातचीत शामिल है। सामान्य संचालन के तहत, एक डीएनएस एनेक्टर नवीनतम योजना चुनता है और इस योजना को लागू करने के लिए सेवा समापन बिंदुओं के माध्यम से काम करना शुरू कर देता है। यह प्रक्रिया आम तौर पर तेजी से पूरी होती है और डीएनएस स्थिति को नए सिरे से अद्यतन रखने का प्रभावी काम करती है। एक नई योजना लागू करने से पहले, डीएनएस एनेक्टर एक बार जांच करता है कि उसकी योजना पहले से लागू योजना की तुलना में नई है। जैसे ही डीएनएस एनएक्टर एंडपॉइंट की सूची के माध्यम से अपना रास्ता बनाता है, यह संभव है विलंब का सामना करना पड़ता है क्योंकि यह लेन-देन का प्रयास करता है और उसी एंडपॉइंट को अपडेट करने वाले किसी अन्य DNS एनएक्टर द्वारा अवरुद्ध किया जाता है, इन मामलों में, DNS एनएक्टर प्रत्येक एंडपॉइंट को तब तक पुनः प्रयास करेगा जब तक कि योजना सभी एंडपॉइंट पर सफलतापूर्वक लागू नहीं हो जाती।
“इस इवेंट के शुरू होने से ठीक पहले, एक DNS एनएक्टर को असामान्य रूप से उच्च विलंब का अनुभव हुआ, जिसके लिए कई DNS एंडपॉइंट्स पर अपने अपडेट को पुनः प्रयास करने की आवश्यकता थी। चूँकि यह धीरे-धीरे अंतिम बिंदुओं पर काम कर रहा था, कई अन्य चीजें भी हो रही थीं। सबसे पहले, डीएनएस प्लानर चलता रहा और योजनाओं की कई नई पीढ़ी तैयार करता रहा। दूसरा, अन्य DNS एनेक्टर्स में से एक ने नई योजनाओं में से एक को लागू करना शुरू किया और सभी अंतिम बिंदुओं के माध्यम से तेजी से प्रगति की। इन घटनाओं के समय ने अव्यक्त दौड़ की स्थिति को जन्म दिया। जब दूसरे एनएक्टर (नवीनतम योजना को लागू करने वाले) ने अपने समापन बिंदु अपडेट को पूरा किया, तो उसने योजना क्लीन-अप प्रक्रिया को लागू किया, जो उन योजनाओं की पहचान करती है जो अभी लागू की गई योजना से काफी पुरानी हैं और उन्हें हटा देती है। उसी समय जब इस सफ़ाई प्रक्रिया को लागू किया गया था, पहले एनएक्टर (जिसमें असामान्य रूप से देरी हो गई थी) ने अपनी बहुत पुरानी योजना को क्षेत्रीय डीडीबी समापन बिंदु पर लागू किया, नई योजना को अधिलेखित कर दिया। योजना आवेदन प्रक्रिया की शुरुआत में जो जाँच की गई थी, जो यह सुनिश्चित करती है कि योजना पहले से लागू योजना की तुलना में नई है, इस समय तक एनेक्टर प्रसंस्करण में असामान्य रूप से उच्च देरी के कारण पुरानी हो चुकी थी। “
इसलिए, इसने पुरानी योजना को नई योजना को अधिलेखित करने से नहीं रोका। दूसरे एनएक्टर की सफ़ाई प्रक्रिया ने इस पुरानी योजना को हटा दिया क्योंकि यह उस योजना से कई पीढ़ियाँ पुरानी थी जिसे उसने अभी लागू किया था। जैसे ही यह योजना हटाई गई, क्षेत्रीय समापन बिंदु के सभी आईपी पते तुरंत हटा दिए गए। इसके अतिरिक्त, क्योंकि सक्रिय योजना हटा दी गई थी, सिस्टम को एक असंगत स्थिति में छोड़ दिया गया था जिसने बाद के योजना अपडेट को किसी भी DNS एनएक्टर द्वारा लागू होने से रोक दिया था। इस स्थिति को सुधारने के लिए अंततः मैन्युअल ऑपरेटर के हस्तक्षेप की आवश्यकता थी।
रिपोर्ट के अंत में, एडब्ल्यूएस ने इस बारे में बात की कि वह स्थिति को ठीक करने के लिए क्या कर रहा है: “हम इस परिचालन घटना के परिणामस्वरूप कई बदलाव कर रहे हैं। हमने दुनिया भर में डायनमोडीबी डीएनएस प्लानर और डीएनएस एनएक्टर ऑटोमेशन को पहले ही अक्षम कर दिया है। इस ऑटोमेशन को फिर से सक्षम करने से पहले, हम दौड़ की स्थिति परिदृश्य को ठीक करेंगे और गलत डीएनएस योजनाओं के आवेदन को रोकने के लिए अतिरिक्त सुरक्षा जोड़ देंगे। एनएलबी के लिए, हम क्षमता को सीमित करने के लिए एक वेग नियंत्रण तंत्र जोड़ रहे हैं, जब स्वास्थ्य जांच विफलताओं के कारण एक एनएलबी हटा सकता है। फेलओवर। EC2 के लिए, हम अपने मौजूदा पैमाने के परीक्षण को बढ़ाने के लिए एक अतिरिक्त परीक्षण सूट का निर्माण कर रहे हैं, जो भविष्य में किसी भी प्रतिगमन की पहचान करने के लिए DWFM पुनर्प्राप्ति वर्कफ़्लो का उपयोग करेगा। हम उच्च भार की अवधि के दौरान सेवा की सुरक्षा के लिए प्रतीक्षा कतार के आकार के आधार पर आने वाले काम को सीमित करने के लिए अपने EC2 डेटा प्रसार सिस्टम में थ्रॉटलिंग तंत्र में सुधार करेंगे।
यह सब ठीक है और अच्छा है, लेकिन ऐसा लगता है कि तत्काल आग बुझाने की एक श्रृंखला चल रही है, और बिजली कटौती जैसी किसी भी घटना को दोबारा होने से रोकने के लिए कोई बड़ी योजना नहीं है। सीधे शब्दों में कहें तो, AWS कल की लड़ाई लड़ता हुआ प्रतीत होता है।
सच है, ये परिवर्तन इसे रोक सकते हैं एकदम सही समस्याओं का एक सेट फिर से होने से रोकता है, लेकिन अन्य समस्याओं की लगभग अनंत संख्या है जो उत्पन्न हो सकती हैं। और वह स्थिति बेहतर होने वाली नहीं है. जैसे-जैसे वॉल्यूम बढ़ता जा रहा है और जटिलता – हैलो, एजेंटिक एआई – बढ़ती जा रही है, इस तरह की ट्रेन दुर्घटनाएं बढ़ती आवृत्ति के साथ होंगी।
यदि AWS, Microsoft, Google और अन्य स्वयं को अपने वातावरण में इतना निवेशित पाते हैं कि वे यहां और वहां पैच लगाने के अलावा कुछ भी नहीं कर सकते हैं, तो कुछ चतुर स्टार्टअप के लिए एक साफ तकनीकी स्लेट के साथ आने और जो आवश्यक है उसका निर्माण करने का समय आ गया है।
तार्किक ख़तरा: इसे स्वयं ठीक करें, हाइपरस्केलर्स, या कुछ वीसी-वित्त पोषित स्टार्टअप को आपके लिए यह करने दें।