AWS अपनी इलास्टिक सेवाएँ कैसे बनाती है। नेटवर्क स्केलिंग

अमेज़ॅन वेब सर्विसेज नेटवर्क का पैमाना दुनिया भर के 69 क्षेत्रों में 22 ज़ोन है: संयुक्त राज्य अमेरिका, यूरोप, एशिया, अफ्रीका और ऑस्ट्रेलिया। प्रत्येक ज़ोन में 8 डेटा केंद्र - डेटा प्रोसेसिंग केंद्र होते हैं। प्रत्येक डेटा सेंटर में हजारों या सैकड़ों हजारों सर्वर होते हैं। नेटवर्क को इस तरह से डिज़ाइन किया गया है कि सभी असंभावित आउटेज परिदृश्यों को ध्यान में रखा जा सके। उदाहरण के लिए, सभी क्षेत्र एक-दूसरे से अलग-थलग हैं, और पहुंच क्षेत्र कई किलोमीटर की दूरी पर अलग-अलग हैं। यहां तक ​​कि अगर आप केबल काटते हैं, तो भी सिस्टम बैकअप चैनलों पर स्विच हो जाएगा, और जानकारी का नुकसान कुछ डेटा पैकेटों के बराबर होगा। वासिली पेंट्युखिन इस बारे में बात करेंगे कि नेटवर्क किन अन्य सिद्धांतों पर बना है और इसकी संरचना कैसे की गई है।

वसीली पेंट्युखिन .ru कंपनियों में यूनिक्स प्रशासक के रूप में शुरुआत की, 6 वर्षों तक बड़े सन माइक्रोसिस्टम हार्डवेयर पर काम किया, और EMC में 11 वर्षों तक डेटा-केंद्रित दुनिया का प्रचार किया। यह स्वाभाविक रूप से निजी बादलों में विकसित हुआ, फिर सार्वजनिक बादलों में चला गया। अब, एक अमेज़ॅन वेब सर्विसेज आर्किटेक्ट के रूप में, वह AWS क्लाउड में रहने और विकसित होने में मदद करने के लिए तकनीकी सलाह प्रदान करता है।

AWS त्रयी के पिछले भाग में, वसीली ने भौतिक सर्वर और डेटाबेस स्केलिंग के डिज़ाइन पर गहराई से चर्चा की। नाइट्रो कार्ड, कस्टम केवीएम-आधारित हाइपरवाइजर, अमेज़ॅन ऑरोरा डेटाबेस - इस सब के बारे में सामग्री में "AWS अपनी इलास्टिक सेवाएँ कैसे बनाती है। स्केलिंग सर्वर और डेटाबेस" संदर्भ के लिए पढ़ें या देखें वीडियो रिकॉर्डिंग भाषण.

यह भाग नेटवर्क स्केलिंग पर ध्यान केंद्रित करेगा, जो AWS में सबसे जटिल प्रणालियों में से एक है। एक फ़्लैट नेटवर्क से वर्चुअल प्राइवेट क्लाउड तक का विकास और उसका डिज़ाइन, ब्लैकफ़ुट और हाइपरप्लेन की आंतरिक सेवाएँ, शोर मचाने वाले पड़ोसी की समस्या, और अंत में - नेटवर्क का पैमाना, बैकबोन और भौतिक केबल। इस सब के बारे में कटौती के तहत।

अस्वीकरण: नीचे दी गई हर बात वसीली की निजी राय है और अमेज़ॅन वेब सर्विसेज की स्थिति से मेल नहीं खा सकती है।

नेटवर्क स्केलिंग

AWS क्लाउड 2006 में लॉन्च किया गया था। उनका नेटवर्क काफी आदिम था - एक सपाट संरचना के साथ। निजी पतों की सीमा सभी क्लाउड किरायेदारों के लिए सामान्य थी। एक नई वर्चुअल मशीन शुरू करते समय, आपको गलती से इस श्रेणी से एक उपलब्ध आईपी पता प्राप्त हो गया।

इस दृष्टिकोण को लागू करना आसान था, लेकिन मूल रूप से क्लाउड का उपयोग सीमित था। विशेष रूप से, जमीन पर और AWS में निजी नेटवर्क को संयोजित करने वाले हाइब्रिड समाधान विकसित करना काफी कठिन था। सबसे आम समस्या आईपी एड्रेस रेंज को ओवरलैप करने की थी।

वर्चुअल प्राइवेट क्लाउड

बादल मांग में निकला। स्केलेबिलिटी और लाखों किरायेदारों द्वारा इसके उपयोग की संभावना के बारे में सोचने का समय आ गया है। फ्लैट नेटवर्क एक बड़ी बाधा बन गया है. इसलिए, हमने सोचा कि नेटवर्क स्तर पर उपयोगकर्ताओं को एक-दूसरे से कैसे अलग किया जाए ताकि वे स्वतंत्र रूप से आईपी रेंज चुन सकें।

जब आप नेटवर्क अलगाव के बारे में सोचते हैं तो सबसे पहले आपके दिमाग में क्या आता है? निश्चित रूप से VLAN и वीआरएफ - वर्चुअल रूटिंग और फ़ॉरवर्डिंग.

दुर्भाग्य से, यह काम नहीं किया. वीएलएएन आईडी केवल 12 बिट्स है, जो हमें केवल 4096 पृथक खंड देता है। यहां तक ​​कि सबसे बड़े स्विच भी अधिकतम 1-2 हजार वीआरएफ का उपयोग कर सकते हैं। वीआरएफ और वीएलएएन का एक साथ उपयोग करने से हमें केवल कुछ मिलियन सबनेट मिलते हैं। यह निश्चित रूप से लाखों किरायेदारों के लिए पर्याप्त नहीं है, जिनमें से प्रत्येक को एकाधिक सबनेट का उपयोग करने में सक्षम होना चाहिए।

हम उदाहरण के लिए, सिस्को या जुनिपर से आवश्यक संख्या में बड़े बक्से खरीदने का जोखिम भी नहीं उठा सकते हैं। इसके दो कारण हैं: यह अत्यधिक महंगा है, और हम उनकी विकास और पैचिंग नीतियों की दया पर निर्भर नहीं रहना चाहते हैं।

केवल एक ही निष्कर्ष है - अपना समाधान स्वयं बनाएं।

2009 में हमने घोषणा की VPC - वर्चुअल प्राइवेट क्लाउड. नाम अटक गया और अब कई क्लाउड प्रदाता भी इसका उपयोग करते हैं।

वीपीसी एक वर्चुअल नेटवर्क है SDN (सॉफ़्टवेयर परिभाषित नेटवर्क)। हमने L2 और L3 स्तरों पर विशेष प्रोटोकॉल का आविष्कार नहीं करने का निर्णय लिया। नेटवर्क मानक ईथरनेट और आईपी पर चलता है। नेटवर्क पर ट्रांसमिशन के लिए, वर्चुअल मशीन ट्रैफ़िक को हमारे अपने प्रोटोकॉल रैपर में समाहित किया गया है। यह उस आईडी को इंगित करता है जो किरायेदार के वीपीसी से संबंधित है।

सरल लगता है. हालाँकि, कई गंभीर तकनीकी चुनौतियाँ हैं जिन्हें दूर करने की आवश्यकता है। उदाहरण के लिए, वर्चुअल मैक/आईपी पते, वीपीसी आईडी और संबंधित भौतिक मैक/आईपी मैपिंग पर डेटा कहां और कैसे संग्रहीत किया जाए। AWS पैमाने पर, यह एक विशाल तालिका है जिसे न्यूनतम पहुंच विलंब के साथ काम करना चाहिए। इसके लिए जिम्मेदार मानचित्रण सेवा, जो पूरे नेटवर्क में एक पतली परत में फैला हुआ है।

नई पीढ़ी की मशीनों में, हार्डवेयर स्तर पर एनकैप्सुलेशन नाइट्रो कार्ड द्वारा किया जाता है। पुराने उदाहरणों में, इनकैप्सुलेशन और डिकैप्सुलेशन सॉफ़्टवेयर-आधारित होते हैं। 

आइए जानें कि यह सामान्य शब्दों में कैसे काम करता है। आइए L2 स्तर से शुरू करें। आइए मान लें कि हमारे पास भौतिक सर्वर 10.0.0.2 पर आईपी 192.168.0.3 के साथ एक वर्चुअल मशीन है। यह वर्चुअल मशीन 10.0.0.3 को डेटा भेजता है, जो 192.168.1.4 पर रहती है। एक ARP अनुरोध उत्पन्न होता है और नेटवर्क नाइट्रो कार्ड को भेजा जाता है। सरलता के लिए, हम मानते हैं कि दोनों वर्चुअल मशीनें एक ही "नीले" वीपीसी में रहती हैं।

नक्शा स्रोत पते को अपने पते से बदल देता है और एआरपी फ्रेम को मैपिंग सेवा में भेज देता है।

मैपिंग सेवा वह जानकारी लौटाती है जो L2 भौतिक नेटवर्क पर प्रसारण के लिए आवश्यक है।

एआरपी प्रतिक्रिया में नाइट्रो कार्ड भौतिक नेटवर्क पर मैक को वीपीसी में एक पते से बदल देता है।

डेटा स्थानांतरित करते समय, हम तार्किक MAC और IP को VPC रैपर में लपेटते हैं। हम उपयुक्त स्रोत और गंतव्य आईपी नाइट्रो कार्ड का उपयोग करके यह सब भौतिक नेटवर्क पर प्रसारित करते हैं।

जिस भौतिक मशीन को पैकेज भेजा जाता है वह जांच करती है। एड्रेस स्पूफिंग की संभावना को रोकने के लिए यह आवश्यक है। मशीन मैपिंग सेवा को एक विशेष अनुरोध भेजती है और पूछती है: “भौतिक मशीन 192.168.0.3 से मुझे एक पैकेट प्राप्त हुआ जो नीले वीपीसी में 10.0.0.3 के लिए है। क्या वह वैध है? 

मैपिंग सेवा अपनी संसाधन आवंटन तालिका की जांच करती है और पैकेट को गुजरने की अनुमति देती है या अस्वीकार करती है। सभी नए उदाहरणों में, अतिरिक्त सत्यापन नाइट्रो कार्ड में अंतर्निहित है। सैद्धांतिक तौर पर भी इसे दरकिनार करना नामुमकिन है. इसलिए, किसी अन्य वीपीसी में संसाधनों की धोखाधड़ी से काम नहीं चलेगा।

इसके बाद, डेटा उस वर्चुअल मशीन को भेजा जाता है जिसके लिए इसका इरादा है। 

मैपिंग सेवा विभिन्न सबनेट में वर्चुअल मशीनों के बीच डेटा स्थानांतरित करने के लिए एक तार्किक राउटर के रूप में भी काम करती है। सब कुछ वैचारिक रूप से सरल है, मैं विस्तार में नहीं जाऊंगा।

यह पता चला है कि प्रत्येक पैकेट को प्रसारित करते समय, सर्वर मैपिंग सेवा की ओर रुख करते हैं। अपरिहार्य देरी से कैसे निपटें? कैशिंग, बेशक।

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

हमने वीपीसी में डेटा के स्थानांतरण को सुलझा लिया।

Blackfoot

ऐसे मामलों में क्या करें जहां ट्रैफ़िक को बाहर प्रसारित करने की आवश्यकता है, उदाहरण के लिए इंटरनेट पर या वीपीएन के माध्यम से जमीन पर? यहां हमारी मदद करता है Blackfoot - AWS आंतरिक सेवा। इसे हमारी दक्षिण अफ़्रीकी टीम द्वारा विकसित किया गया है। इसीलिए इस सेवा का नाम दक्षिण अफ्रीका में रहने वाले पेंगुइन के नाम पर रखा गया है।

ब्लैकफ़ुट ट्रैफ़िक को ख़त्म करता है और इसके साथ जो आवश्यक है वह करता है। डेटा वैसे ही इंटरनेट पर भेजा जाता है।

वीपीएन का उपयोग करते समय डेटा को डिकैप्सुलेट किया जाता है और आईपीसेक में फिर से लपेटा जाता है।

डायरेक्ट कनेक्ट का उपयोग करते समय, ट्रैफ़िक को टैग किया जाता है और उपयुक्त वीएलएएन पर भेजा जाता है।

हाइपरप्लेन

यह एक आंतरिक प्रवाह नियंत्रण सेवा है. कई नेटवर्क सेवाओं को निगरानी की आवश्यकता होती है डेटा प्रवाह स्थिति. उदाहरण के लिए, NAT का उपयोग करते समय, प्रवाह नियंत्रण को यह सुनिश्चित करना चाहिए कि प्रत्येक IP: गंतव्य पोर्ट जोड़ी में एक अद्वितीय आउटगोइंग पोर्ट हो। बैलेंसर के मामले में एनएलबी - नेटवर्क लोड बैलेंसर, डेटा प्रवाह को हमेशा एक ही लक्ष्य वर्चुअल मशीन की ओर निर्देशित किया जाना चाहिए। सुरक्षा समूह एक स्टेटफुल फ़ायरवॉल है. यह आने वाले ट्रैफ़िक की निगरानी करता है और आउटगोइंग पैकेट प्रवाह के लिए पोर्ट खोलता है।

AWS क्लाउड में, ट्रांसमिशन विलंबता आवश्यकताएँ बहुत अधिक हैं। इसीलिए हाइपरप्लेन संपूर्ण नेटवर्क के प्रदर्शन के लिए महत्वपूर्ण।

हाइपरप्लेन EC2 वर्चुअल मशीनों पर बनाया गया है। यहां कोई जादू नहीं है, केवल चालाकी है। चाल यह है कि ये बड़ी रैम वाली वर्चुअल मशीनें हैं। ऑपरेशन लेन-देन संबंधी होते हैं और विशेष रूप से मेमोरी में निष्पादित होते हैं। यह आपको केवल दसियों माइक्रोसेकंड की देरी प्राप्त करने की अनुमति देता है। डिस्क के साथ काम करने से सारी उत्पादकता खत्म हो जाएगी। 

हाइपरप्लेन बड़ी संख्या में ऐसी EC2 मशीनों की एक वितरित प्रणाली है। प्रत्येक वर्चुअल मशीन की बैंडविड्थ 5 GB/s है। पूरे क्षेत्रीय नेटवर्क में, यह अविश्वसनीय टेराबाइट बैंडविड्थ प्रदान करता है और प्रसंस्करण की अनुमति देता है प्रति सेकंड लाखों कनेक्शन.

हाइपरप्लेन केवल स्ट्रीम के साथ काम करता है। वीपीसी पैकेट एनकैप्सुलेशन इसके लिए पूरी तरह से पारदर्शी है। इस आंतरिक सेवा में संभावित भेद्यता अभी भी वीपीसी अलगाव को टूटने से रोकेगी। नीचे के स्तर सुरक्षा के लिए जिम्मेदार हैं।

शोर मचाने वाला पड़ोसी

अभी भी एक समस्या है शोर मचाने वाला पड़ोसी - शोर मचाने वाला पड़ोसी. आइए मान लें कि हमारे पास 8 नोड हैं। ये नोड सभी क्लाउड उपयोगकर्ताओं के प्रवाह को संसाधित करते हैं। सब कुछ ठीक लग रहा है और लोड सभी नोड्स पर समान रूप से वितरित किया जाना चाहिए। नोड्स बहुत शक्तिशाली हैं और उन्हें ओवरलोड करना मुश्किल है।

लेकिन हम अपनी वास्तुकला का निर्माण असंभावित परिदृश्यों के आधार पर भी करते हैं। 

कम संभावना का मतलब असंभव नहीं है.

हम ऐसी स्थिति की कल्पना कर सकते हैं जिसमें एक या अधिक उपयोगकर्ता बहुत अधिक लोड उत्पन्न करेंगे। सभी हाइपरप्लेन नोड्स इस लोड को संसाधित करने में शामिल हैं और अन्य उपयोगकर्ता संभावित रूप से किसी प्रकार के प्रदर्शन हिट का अनुभव कर सकते हैं। यह क्लाउड की अवधारणा को तोड़ता है, जिसमें किरायेदारों के पास एक-दूसरे को प्रभावित करने की क्षमता नहीं होती है।

शोर मचाने वाले पड़ोसी की समस्या का समाधान कैसे करें? पहली चीज़ जो मन में आती है वह है शार्डिंग। हमारे 8 नोड्स तार्किक रूप से 4 नोड्स के 2 टुकड़ों में विभाजित हैं। अब एक शोरगुल वाला पड़ोसी सभी उपयोगकर्ताओं में से केवल एक चौथाई को ही परेशान करेगा, लेकिन यह उन्हें बहुत परेशान करेगा।

आइए चीजों को अलग तरीके से करें। हम प्रत्येक उपयोगकर्ता को केवल 3 नोड आवंटित करेंगे। 

चाल अलग-अलग उपयोगकर्ताओं को बेतरतीब ढंग से नोड्स आवंटित करने की है। नीचे दी गई तस्वीर में, नीला उपयोगकर्ता अन्य दो उपयोगकर्ताओं - हरे और नारंगी - में से एक के साथ नोड्स को काटता है।

8 नोड्स और 3 उपयोगकर्ताओं के साथ, शोर मचाने वाले पड़ोसी के किसी एक उपयोगकर्ता से टकराने की संभावना 54% है। यह इस संभावना के साथ है कि एक नीला उपयोगकर्ता अन्य किरायेदारों को प्रभावित करेगा। वहीं, इसके भार का केवल एक हिस्सा। हमारे उदाहरण में, यह प्रभाव कम से कम किसी तरह सभी के लिए नहीं, बल्कि सभी उपयोगकर्ताओं में से केवल एक तिहाई के लिए ध्यान देने योग्य होगा। यह पहले से ही एक अच्छा परिणाम है.

उन उपयोगकर्ताओं की संख्या जो प्रतिच्छेद करेंगे

संभावना प्रतिशत में

0

18% तक

1

54% तक

2

26% तक

3

2%

आइए स्थिति को वास्तविकता के करीब लाएं - आइए 100 नोड्स और 5 नोड्स पर 5 उपयोगकर्ता लें। इस मामले में, कोई भी नोड 77% की संभावना के साथ प्रतिच्छेद नहीं करेगा। 

उन उपयोगकर्ताओं की संख्या जो प्रतिच्छेद करेंगे

संभावना प्रतिशत में

0

77% तक

1

21% तक

2

1,8% तक

3

0,06% तक

4

0,0006% तक

5

0,00000013% तक

वास्तविक स्थिति में, बड़ी संख्या में हाइपरप्लेन नोड्स और उपयोगकर्ताओं के साथ, अन्य उपयोगकर्ताओं पर शोर मचाने वाले पड़ोसी का संभावित प्रभाव न्यूनतम होता है। इस विधि को कहा जाता है मिश्रण विखंडन - शफ़ल विखंडन. यह नोड विफलता के नकारात्मक प्रभाव को कम करता है।

कई सेवाएँ हाइपरप्लेन के आधार पर बनाई गई हैं: नेटवर्क लोड बैलेंसर, NAT गेटवे, अमेज़न EFS, AWS प्राइवेटलिंक, AWS ट्रांजिट गेटवे।

नेटवर्क पैमाना

अब बात करते हैं नेटवर्क के पैमाने की। अक्टूबर 2019 के लिए AWS अपनी सेवाएँ प्रदान करता है 22 क्षेत्र, और 9 और की योजना बनाई गई है।

• प्रत्येक क्षेत्र में कई उपलब्धता क्षेत्र होते हैं। दुनिया भर में इनकी संख्या 69 है।
• प्रत्येक AZ में डेटा प्रोसेसिंग केंद्र होते हैं। उनमें से कुल मिलाकर 8 से अधिक नहीं हैं।
• डेटा सेंटर में बड़ी संख्या में सर्वर होते हैं, कुछ में 300 तक सर्वर होते हैं।

आइए अब इन सबका औसत निकालें, गुणा करें और एक प्रभावशाली आंकड़ा प्राप्त करें जो दर्शाता है अमेज़ॅन क्लाउड स्केल.

उपलब्धता क्षेत्र और डेटा सेंटर के बीच कई ऑप्टिकल लिंक हैं। हमारे सबसे बड़े क्षेत्रों में से एक में, एक दूसरे के बीच और अन्य क्षेत्रों (ट्रांजिट सेंटर) के साथ संचार केंद्रों के बीच एज़ संचार के लिए 388 चैनल बिछाए गए हैं। कुल मिलाकर ये पागलपन देता है 5000 टीबीटी.

बैकबोन AWS विशेष रूप से क्लाउड के लिए बनाया और अनुकूलित किया गया है। हम इसे चैनलों पर बनाते हैं 100 जीबी / एस. चीन के क्षेत्रों को छोड़कर, हम उन पर पूरी तरह से नियंत्रण रखते हैं। ट्रैफ़िक को अन्य कंपनियों के भार के साथ साझा नहीं किया जाता है।

बेशक, हम निजी बैकबोन नेटवर्क वाले एकमात्र क्लाउड प्रदाता नहीं हैं। अधिक से अधिक बड़ी कंपनियाँ इस रास्ते पर चल रही हैं। उदाहरण के लिए, स्वतंत्र शोधकर्ताओं द्वारा इसकी पुष्टि की गई है टेलीग्राफी.

ग्राफ़ से पता चलता है कि सामग्री प्रदाताओं और क्लाउड प्रदाताओं की हिस्सेदारी बढ़ रही है। इसकी वजह से बैकबोन प्रोवाइडर्स की इंटरनेट ट्रैफिक की हिस्सेदारी लगातार कम हो रही है।

मैं समझाऊंगा कि ऐसा क्यों होता है. पहले, अधिकांश वेब सेवाएँ सीधे इंटरनेट से पहुँच योग्य और उपभोग की जाती थीं। आजकल, अधिक से अधिक सर्वर क्लाउड में स्थित हैं और इनके माध्यम से पहुंच योग्य हैं CDN - सामग्री वितरण नेटवर्क. किसी संसाधन तक पहुँचने के लिए, उपयोगकर्ता इंटरनेट के माध्यम से केवल निकटतम CDN PoP तक जाता है - मौजूदगी का स्थान. अक्सर यह कहीं आस-पास होता है। फिर यह सार्वजनिक इंटरनेट को छोड़ देता है और उदाहरण के लिए, अटलांटिक के पार एक निजी रीढ़ की हड्डी के माध्यम से उड़ जाता है, और सीधे संसाधन तक पहुंच जाता है।

मुझे आश्चर्य है कि अगर यह प्रवृत्ति जारी रही तो 10 वर्षों में इंटरनेट कैसे बदल जाएगा?

भौतिक चैनल

वैज्ञानिक अभी तक यह पता नहीं लगा पाए हैं कि ब्रह्मांड में प्रकाश की गति को कैसे बढ़ाया जाए, लेकिन उन्होंने ऑप्टिकल फाइबर के माध्यम से इसे प्रसारित करने के तरीकों में काफी प्रगति की है। वर्तमान में हम 6912 फाइबर केबल का उपयोग करते हैं। इससे उनकी स्थापना की लागत को महत्वपूर्ण रूप से अनुकूलित करने में मदद मिलती है।

कुछ क्षेत्रों में हमें विशेष केबलों का उपयोग करना पड़ता है। उदाहरण के लिए, सिडनी क्षेत्र में हम दीमकों के खिलाफ एक विशेष कोटिंग वाले केबल का उपयोग करते हैं। 

परेशानियों से कोई भी अछूता नहीं है और कभी-कभी हमारे चैनल खराब हो जाते हैं। दाईं ओर की तस्वीर अमेरिकी क्षेत्रों में से एक में ऑप्टिकल केबल दिखाती है जो निर्माण श्रमिकों द्वारा फाड़ दी गई थी। दुर्घटना के परिणामस्वरूप, केवल 13 डेटा पैकेट खो गए, जो आश्चर्यजनक है। एक बार फिर - केवल 13! सिस्टम सचमुच तुरंत बैकअप चैनलों पर स्विच हो गया - स्केल काम कर रहा है।

हमने अमेज़ॅन की कुछ क्लाउड सेवाओं और तकनीकों का लाभ उठाया। मुझे आशा है कि आपको कम से कम उन कार्यों के पैमाने का कुछ अंदाजा होगा जिन्हें हमारे इंजीनियरों को हल करना है। व्यक्तिगत रूप से, मुझे यह बहुत रोमांचक लगता है। 

यह AWS डिवाइस के बारे में वासिली पेंट्युखिन की त्रयी का अंतिम भाग है। में पहले भाग सर्वर अनुकूलन और डेटाबेस स्केलिंग का वर्णन करते हैं, और में दूसरा - सर्वर रहित फ़ंक्शन और फायरक्रैकर।

पर HighLoad ++ नवंबर में वसीली पेंट्युखिन अमेज़ॅन डिवाइस के नए विवरण साझा करेंगे। वह बताऊंगा अमेज़ॅन पर वितरित सिस्टम की विफलताओं के कारणों और डिज़ाइन के बारे में। 24 अक्टूबर अभी भी संभव है किताब अच्छी कीमत पर टिकट लें और बाद में भुगतान करें। हम हाईलोड++ पर आपका इंतजार कर रहे हैं, आइए और चैट करें!

स्रोत: www.habr.com