AWS नीचे: स्वर्ग क्यों गिर गया

21 अप्रैल को 01:41 प्रशांत समय में, अमेज़ॅन वेब सेवा डेटा केंद्रों में से एक में कई साइटों के लिए "क्लाउड" में एक गंभीर विफलता थी। कुछ बड़ी परियोजनाएं (रेडिट, क्वोरा, फोरस्क्वेयर) ऑफ़लाइन हो गईं या उन्हें बहुत नुकसान हुआ। मैंने पहले ही संकेत के साथ गलत सूचनाओं का एक गुच्छा देखा है कि प्रभावित साइटों की समस्याएं केवल इन परियोजनाओं के इंजीनियरों के आलस्य के साथ जुड़ी हुई हैं, लेकिन इस मामले में कारण अलग है। और यहाँ क्यों है।

AWS की पहुँच से संबंधित दो अवधारणाएँ हैं: क्षेत्र और उपलब्धता Zones, AZ। पाँच क्षेत्र हैं: दो संयुक्त राज्य अमेरिका (पश्चिमी और पूर्वी तटों) में, एक यूरोप (आयरलैंड) में और दो एशिया (टोक्यो, सिंगापुर) में हैं। प्रत्येक क्षेत्र में, कई AZ स्थित हैं, जिन्हें एक दूसरे से अलग किया जाना चाहिए और विफलता का एक सामान्य बिंदु नहीं होना चाहिए, प्राकृतिक आपदा या समान पैमाने के कुछ को छोड़कर।

AWS का कहना है कि "अलग-अलग AZs में उदाहरण स्थापित करके, आप अपने अनुप्रयोगों को किसी विशेष स्थान पर विफलता से बचा सकते हैं।" "स्थान" से उनका तात्पर्य है "एक दूसरे और स्वतंत्र बुनियादी ढाँचे से पहुँच क्षेत्र की भौतिक स्वतंत्रता "। जाहिरा तौर पर, ये अलग-अलग डेटा केंद्र हैं ( हालांकि, अमेज़ॅन के वर्णन से, यह स्पष्ट नहीं है - शायद ये अलग-अलग चैनलों / स्वतंत्र चैनलों के साथ डेटा केंद्र में अलग-अलग फ़र्श / कमरे हैं - लगभग प्रति। )। उन्हें एक-दूसरे के साथ एक ही समय में नहीं गिरना चाहिए, जब तक कि एक तबाही न हो जो पूरे क्षेत्र को कवर करती है।

उपलब्धता क्षेत्र "समान क्षेत्र में उपलब्धता क्षेत्रों के बीच कम-लागत, कम विलंबता कनेक्टिविटी" भी प्रदान करते हैं। दूसरी ओर, अंतर-संयोजकीय कनेक्टिविटी, खुले इंटरनेट के माध्यम से जाती है, और अपेक्षाकृत महंगी, धीमी और अविश्वसनीय है।

ये "खेल के नियम" हैं। इसलिए यदि आप AWS के नियमों के अनुसार खेलते हैं और मास्टर / स्लेव MySQL डेटाबेस (सबसे सामान्य उदाहरण लेने के लिए) उठाते हैं, तो, तार्किक रूप से, आपको एक ही क्षेत्र में मास्टर और गुलाम रखना चाहिए, लेकिन सुनिश्चित करें कि वे अलग-अलग क्षेत्रों में हैं उपलब्धता। आप उन्हें अलग-अलग क्षेत्रों में नहीं रखेंगे, अन्यथा आपको क्षेत्रों के बीच धीमी और महंगी चैनलों के माध्यम से ट्रैफ़िक चलाना होगा, और सबसे अधिक संभावना है कि आपको डेटाबेस को सिंक्रनाइज़ करने में अधिक समस्याएं होंगी। आप केवल जोखिम लेते हैं, उदाहरण के लिए, एक तूफान पूर्वी तट पर दुर्घटनाग्रस्त हो जाता है और डेटा सेंटर (एस) को नष्ट कर देता है, लेकिन इसके अपवाद के साथ, सब कुछ क्रम में होना चाहिए - कम से कम अगर एडब्ल्यूएस वादों का सम्मान किया जाता है।

इसलिए, अंत में, हमें एक समस्या मिली। कल, पूर्वी तट क्षेत्र में कई क्षेत्र दुर्गम थे। एडब्ल्यूएस ने उपलब्धता विफलता परिदृश्यों के अपने वादे को तोड़ दिया है। इसका मतलब यह है कि AWS के पास कुछ प्रकार की सामान्य विफलता है (यह मानते हुए कि कुछ बिल्कुल अविश्वसनीय परिदृश्य जैसे एक साथ कई स्वतंत्र अवसंरचनाओं को शारीरिक क्षति नहीं हुई)। साइटें जो अभी भी नीचे हैं, "खेल के नियमों" की अपनी शर्तों को काफी सही ढंग से पूरा करती हैं, समस्या यह है कि एडब्ल्यूएस ने अपने स्वयं के विनिर्देशों का पालन नहीं किया। यह अक्षमता या बेईमानी, या कुछ अधिक बहाने के कारण हुआ, हमें फिलहाल पता नहीं है। लेकिन Quora, Foursquare और Reddit के डेवलपर्स बहुत सक्षम हैं और उनके प्रति आरोपों को निर्देशित करना गलत होगा।

बेशक, खुद को भयावह विफलताओं (कई पहुंच क्षेत्रों) से बचाने के लिए सैद्धांतिक रूप से संभव है, लेकिन अधिकांश व्यवसायों के लिए ये अतिरिक्त विकास लागत और खर्च इसके लायक नहीं हैं (या सिस्टम को उलझाकर उलटा भी हो सकता है)। मुझे यकीन है कि अब नीचे आने वाली सभी साइटों में बैकअप हैं। समस्या यह है कि ऑनलाइन पर उनकी वापसी मुश्किल और जोखिम भरी हो सकती है - व्यवहार में, आपको सब कुछ दूसरे क्षेत्र में स्थानांतरित करने की आवश्यकता है, अन्यथा आपके सर्वर के बीच नेटवर्क देरी बहुत बड़ी होगी। AWS पर, यह अत्यंत कठिन है: विभिन्न क्षेत्रों में सर्वरों पर - विकल्पों का एक अलग सेट, विभिन्न एएमआई पहचानकर्ता, मुझे लगता है कि आरक्षित उदाहरणों को डेटा केंद्रों के बीच बिल्कुल नहीं ले जाया जा सकता है - वास्तव में, किसी अन्य क्षेत्र पर नियंत्रण स्थानांतरित करना लगभग असंभव है। संभवतः, यह एक ही राशि के प्रयास के बारे में ले जाएगा जब पूरी तरह से अलग बादल में पलायन होता है, जो संभवतः ऐसी आपदा से उबरने के लिए सबसे अच्छा विकल्प है। जहां तक ​​हम जानते हैं, Quora ने यह प्रक्रिया शुरू की थी कि AWS दुर्घटनाग्रस्त हो गया और इसे अब तक पूरा नहीं किया - एक दिन लग सकता है।

तो, संक्षेप में, यहां दोष विशेष रूप से AWS का है, जिसने उल्लंघन की शर्तों की "गारंटी" दी। गलतियाँ होती हैं, लेकिन यहाँ ठीक AWS त्रुटि है।

और यह क्लाउड होस्टिंग की गलती नहीं है। यह मामला दिखाता है कि आपको एक प्रदाता को सावधानीपूर्वक चुनने की आवश्यकता है। मुझे लगता है कि कई लोग AWS के पक्ष में अपनी पसंद पर पुनर्विचार करेंगे।

कुछ और विचार:

• पूर्वी तट क्षेत्र में इतनी सारी साइटों को होस्ट करने का कारण यह है कि यह यहाँ है कि एडब्ल्यूएस पहली बार नई सुविधाओं को रोल आउट करता है। वह सबसे सस्ता भी है। और यह संभवतः यातायात की सेवा करने का सबसे अच्छा क्षेत्र है (उत्तरी अमेरिका के लिए सामान्य प्रदर्शन, यूरोप के लिए सहनीय प्रदर्शन)
• विफलता का कारण वास्तव में ईबीएस (इलास्टिक ब्लॉक स्टोर) डिस्क सरणियां थीं, जो अपने उपयोग की शुरुआत से ही विश्वसनीयता के मामले में विनाशकारी साबित हुईं। लेकिन यह पूरी तरह से अलग लेख का विषय है!
• ईबीएस सरणियां केवल एक उपलब्धता क्षेत्र में हो सकती हैं और उन तक पहुंच केवल इस क्षेत्र से ही जा सकती है। स्पष्ट रूप से, वितरित अमेज़ॅन आरडीएस डेटाबेस गुप्त एपीआई का उपयोग करता है जो आपको अन्य क्षेत्रों से ईबीएस तक पहुंचने की अनुमति देता है, लेकिन ये इंटरफेस आरडीएस को छोड़कर किसी के लिए भी सुलभ नहीं हैं (हम्म ... एक सिएटल कंपनी जो प्रतिस्पर्धी लाभ प्राप्त करने के लिए गुप्त एपीआई का उपयोग करती है जैसे- क्या वह परिचित है?)