AWS त्याच्या लवचिक सेवा कशा बनवते. नेटवर्क स्केलिंग

Amazon Web Services नेटवर्कचे स्केल जगभरातील 69 क्षेत्रांमध्ये 22 क्षेत्रे आहेत: यूएसए, युरोप, आशिया, आफ्रिका आणि ऑस्ट्रेलिया. प्रत्येक झोनमध्ये 8 पर्यंत डेटा केंद्रे आहेत - डेटा प्रक्रिया केंद्रे. प्रत्येक डेटा सेंटरमध्ये हजारो किंवा शेकडो हजारो सर्व्हर असतात. नेटवर्क अशा प्रकारे डिझाइन केले आहे की सर्व संभाव्य आउटेज परिस्थिती विचारात घेतल्या जातात. उदाहरणार्थ, सर्व प्रदेश एकमेकांपासून वेगळे आहेत आणि अनेक किलोमीटरच्या अंतरावर प्रवेशयोग्यता क्षेत्रे विभक्त आहेत. जरी तुम्ही केबल कापली तरी, सिस्टम बॅकअप चॅनेलवर स्विच करेल आणि माहितीचे नुकसान काही डेटा पॅकेट्समध्ये होईल. नेटवर्क कोणत्या इतर तत्त्वांवर बांधले आहे आणि ते कसे संरचित केले आहे याबद्दल वसिली पँट्युखिन बोलतील.

वसिली पंतुखिन .ru कंपन्यांमध्ये युनिक्स प्रशासक म्हणून सुरुवात केली, 6 वर्षे मोठ्या सन मायक्रोसिस्टम हार्डवेअरवर काम केले आणि EMC येथे 11 वर्षे डेटा-केंद्रित जगाचा प्रचार केला. हे नैसर्गिकरित्या खाजगी ढगांमध्ये विकसित झाले, नंतर सार्वजनिक ढगांमध्ये हलवले. आता, Amazon Web Services वास्तुविशारद म्हणून, तो AWS क्लाउडमध्ये जगण्यासाठी आणि विकसित करण्यात मदत करण्यासाठी तांत्रिक सल्ला देतो.

AWS ट्रोलॉजीच्या मागील भागात, वसिलीने भौतिक सर्व्हर आणि डेटाबेस स्केलिंगच्या डिझाइनमध्ये शोध घेतला. नायट्रो कार्ड्स, सानुकूल केव्हीएम-आधारित हायपरवाइजर, ऍमेझॉन अरोरा डेटाबेस - या सर्व गोष्टींबद्दल सामग्री "AWS त्याच्या लवचिक सेवा कशा बनवते. स्केलिंग सर्व्हर आणि डेटाबेस" संदर्भासाठी वाचा किंवा पहा व्हिडिओ टेप भाषणे

हा भाग नेटवर्क स्केलिंगवर लक्ष केंद्रित करेल, AWS मधील सर्वात जटिल प्रणालींपैकी एक. फ्लॅट नेटवर्कपासून व्हर्च्युअल प्रायव्हेट क्लाउडमध्ये उत्क्रांती आणि त्याची रचना, ब्लॅकफूट आणि हायपरप्लेनच्या अंतर्गत सेवा, गोंगाट करणाऱ्या शेजाऱ्याची समस्या आणि शेवटी - नेटवर्कचे प्रमाण, पाठीचा कणा आणि भौतिक केबल्स. कट अंतर्गत या सर्व बद्दल.

अस्वीकरण: खाली सर्व काही वासिलीचे वैयक्तिक मत आहे आणि Amazon वेब सेवांच्या स्थितीशी जुळत नाही.

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

AWS क्लाउड 2006 मध्ये लाँच करण्यात आले. त्याचे नेटवर्क अगदी आदिम होते - सपाट संरचनेसह. खाजगी पत्त्यांची श्रेणी सर्व क्लाउड भाडेकरूंसाठी सामान्य होती. नवीन व्हर्च्युअल मशीन सुरू करताना, तुम्हाला चुकून या श्रेणीतून उपलब्ध IP पत्ता प्राप्त झाला.

हा दृष्टिकोन अंमलात आणणे सोपे होते, परंतु मूलभूतपणे क्लाउडचा वापर मर्यादित केला. विशेषतः, जमिनीवर आणि AWS मध्ये खाजगी नेटवर्क एकत्रित करणारे हायब्रिड सोल्यूशन्स विकसित करणे खूप कठीण होते. आयपी अॅड्रेस रेंज ओव्हरलॅप करणे ही सर्वात सामान्य समस्या होती.

आभासी खाजगी मेघ

ढग मागणीत निघाले. स्केलेबिलिटी आणि लाखो भाडेकरूंद्वारे त्याचा वापर करण्याच्या शक्यतेबद्दल विचार करण्याची वेळ आली आहे. फ्लॅट नेटवर्क हा मोठा अडथळा बनला आहे. म्हणून, आम्ही नेटवर्क स्तरावर वापरकर्त्यांना एकमेकांपासून कसे वेगळे करायचे याचा विचार केला जेणेकरून ते स्वतंत्रपणे IP श्रेणी निवडू शकतील.

जेव्हा तुम्ही नेटवर्क अलगाव बद्दल विचार करता तेव्हा सर्वप्रथम कोणती गोष्ट मनात येते? नक्कीच व्हीएलएएन и VRF - व्हर्च्युअल राउटिंग आणि फॉरवर्डिंग.

दुर्दैवाने, ते कार्य केले नाही. VLAN आयडी फक्त 12 बिट्स आहे, जे आम्हाला फक्त 4096 वेगळे विभाग देते. सर्वात मोठे स्विच देखील जास्तीत जास्त 1-2 हजार VRF वापरू शकतात. VRF आणि VLAN एकत्र वापरल्याने आम्हाला फक्त काही दशलक्ष सबनेट मिळतात. लाखो भाडेकरूंसाठी हे निश्चितपणे पुरेसे नाही, ज्यापैकी प्रत्येकाने एकाधिक सबनेट वापरण्यास सक्षम असणे आवश्यक आहे.

आम्हाला मोठ्या बॉक्सची आवश्यक संख्या खरेदी करणे देखील परवडत नाही, उदाहरणार्थ, सिस्को किंवा जुनिपर. त्याची दोन कारणे आहेत: हे वेडेपणाचे महाग आहे आणि आम्ही त्यांच्या विकासाच्या आणि पॅचिंग धोरणांच्या दयेवर राहू इच्छित नाही.

फक्त एकच निष्कर्ष आहे - स्वतःचे निराकरण करा.

2009 मध्ये आम्ही घोषणा केली व्हीपीसी - आभासी खाजगी मेघ. नाव अडकले आणि आता बरेच क्लाउड प्रदाते देखील ते वापरतात.

VPC एक आभासी नेटवर्क आहे SDN (सॉफ्टवेअर परिभाषित नेटवर्क). आम्ही L2 आणि L3 स्तरांवर विशेष प्रोटोकॉलचा शोध न घेण्याचा निर्णय घेतला. नेटवर्क मानक इथरनेट आणि IP वर चालते. नेटवर्कवर ट्रान्समिशनसाठी, व्हर्च्युअल मशीन ट्रॅफिक आमच्या स्वतःच्या प्रोटोकॉल रॅपरमध्ये समाविष्ट केले आहे. ते भाडेकरूच्या VPC मधील आयडी सूचित करते.

साधं वाटतंय. तथापि, अनेक गंभीर तांत्रिक आव्हाने आहेत ज्यांवर मात करणे आवश्यक आहे. उदाहरणार्थ, व्हर्च्युअल MAC/IP पत्ते, VPC ID आणि संबंधित भौतिक MAC/IP मॅपिंगवर डेटा कुठे आणि कसा संग्रहित करायचा. AWS स्केलवर, हे एक मोठे टेबल आहे जे कमीतकमी प्रवेश विलंबांसह कार्य करते. यासाठी जबाबदार आहे मॅपिंग सेवा, जे संपूर्ण नेटवर्कमध्ये पातळ थरात पसरलेले आहे.

नवीन पिढीच्या मशीनमध्ये, हार्डवेअर स्तरावर नायट्रो कार्डद्वारे एन्कॅप्सुलेशन केले जाते. जुन्या उदाहरणांमध्ये, एन्कॅप्सुलेशन आणि डीकॅप्सुलेशन सॉफ्टवेअर-आधारित आहेत. 

हे सामान्य शब्दात कसे कार्य करते ते पाहू या. चला L2 पातळीपासून सुरुवात करूया. चला असे गृहीत धरू की आमच्याकडे 10.0.0.2 या भौतिक सर्व्हरवर IP 192.168.0.3 असलेले व्हर्च्युअल मशीन आहे. हे व्हर्च्युअल मशीन 10.0.0.3 वर डेटा पाठवते, जे 192.168.1.4 वर राहते. एआरपी विनंती व्युत्पन्न केली जाते आणि नेटवर्क नायट्रो कार्डवर पाठविली जाते. साधेपणासाठी, आम्ही असे गृहीत धरतो की दोन्ही व्हर्च्युअल मशीन एकाच "ब्लू" VPC मध्ये राहतात.

नकाशा स्वतःचा स्त्रोत पत्ता बदलतो आणि ARP फ्रेम मॅपिंग सेवेकडे अग्रेषित करतो.

मॅपिंग सेवा L2 भौतिक नेटवर्कवर प्रसारित करण्यासाठी आवश्यक असलेली माहिती परत करते.

ARP प्रतिसादातील नायट्रो कार्ड भौतिक नेटवर्कवरील MAC ला VPC मधील पत्त्यासह बदलते.

डेटा ट्रान्सफर करताना, आम्ही लॉजिकल MAC आणि IP VPC रॅपरमध्ये गुंडाळतो. आम्ही हे सर्व योग्य स्त्रोत आणि गंतव्यस्थान आयपी नायट्रो कार्ड वापरून भौतिक नेटवर्कवर प्रसारित करतो.

ज्या भौतिक मशीनला पॅकेज नियत आहे ते तपासते. अॅड्रेस स्पूफिंगची शक्यता टाळण्यासाठी हे आवश्यक आहे. मशीन मॅपिंग सेवेला विशेष विनंती पाठवते आणि विचारते: “फिजिकल मशीन 192.168.0.3 वरून मला एक पॅकेट मिळाले आहे जे निळ्या VPC मध्ये 10.0.0.3 साठी आहे. तो कायदेशीर आहे का? 

मॅपिंग सेवा तिचे संसाधन वाटप सारणी तपासते आणि पॅकेटमधून जाण्याची परवानगी देते किंवा नाकारते. सर्व नवीन उदाहरणांमध्ये, नायट्रो कार्ड्समध्ये अतिरिक्त प्रमाणीकरण अंतर्भूत केले आहे. सैद्धांतिकदृष्ट्या देखील त्यास बायपास करणे अशक्य आहे. म्हणून, दुसर्‍या VPC मधील संसाधनांसाठी स्पूफिंग कार्य करणार नाही.

पुढे, डेटा व्हर्च्युअल मशीनवर पाठविला जातो ज्यासाठी तो हेतू आहे. 

मॅपिंग सेवा वेगवेगळ्या सबनेटमध्ये व्हर्च्युअल मशीनमधील डेटा ट्रान्सफर करण्यासाठी लॉजिकल राउटर म्हणूनही काम करते. सर्व काही वैचारिकदृष्ट्या सोपे आहे, मी तपशीलात जाणार नाही.

असे दिसून आले की प्रत्येक पॅकेट प्रसारित करताना, सर्व्हर मॅपिंग सेवेकडे वळतात. अपरिहार्य विलंबांचा सामना कसा करावा? कॅशिंग, अर्थातच.

सौंदर्य हे आहे की आपल्याला संपूर्ण विशाल टेबल कॅशे करण्याची आवश्यकता नाही. भौतिक सर्व्हर तुलनेने कमी संख्येने VPCs मधून आभासी मशीन होस्ट करतो. तुम्हाला फक्त या VPC बद्दल माहिती कॅशे करणे आवश्यक आहे. "डीफॉल्ट" कॉन्फिगरेशनमधील डेटा इतर VPC वर हस्तांतरित करणे अद्याप वैध नाही. व्हीपीसी-पीअरिंगसारखी कार्यक्षमता वापरली असल्यास, संबंधित व्हीपीसीची माहिती कॅशेमध्ये अतिरिक्तपणे लोड केली जाते. 

आम्ही VPC मध्ये डेटाचे हस्तांतरण क्रमवारी लावले.

ब्लॅकफूट

ट्रॅफिक बाहेरून प्रसारित करणे आवश्यक आहे अशा प्रकरणांमध्ये काय करावे, उदाहरणार्थ इंटरनेटवर किंवा VPN द्वारे जमिनीवर? आम्हाला येथे मदत करते ब्लॅकफूट - AWS अंतर्गत सेवा. हे आमच्या दक्षिण आफ्रिकेच्या संघाने विकसित केले आहे. म्हणूनच या सेवेला दक्षिण आफ्रिकेत राहणाऱ्या पेंग्विनचे ​​नाव देण्यात आले आहे.

ब्लॅकफूट ट्रॅफिक डिकॅप्स्युलेट करतो आणि त्याच्यासोबत आवश्यक ते करतो. डेटा आहे तसा इंटरनेटवर पाठवला जातो.

VPN वापरताना डेटा डीकॅप्स्युलेट केला जातो आणि IPsec मध्ये पुन्हा गुंडाळला जातो.

डायरेक्ट कनेक्ट वापरताना, ट्रॅफिक टॅग केले जाते आणि योग्य VLAN वर पाठवले जाते.

हायपरप्लेन

ही अंतर्गत प्रवाह नियंत्रण सेवा आहे. अनेक नेटवर्क सेवांना देखरेखीची आवश्यकता असते डेटा प्रवाह स्थिती. उदाहरणार्थ, NAT वापरताना, प्रवाह नियंत्रणाने प्रत्येक IP:destination पोर्ट जोडीमध्ये एक अद्वितीय आउटगोइंग पोर्ट असल्याची खात्री करणे आवश्यक आहे. बॅलन्सरच्या बाबतीत NLB - नेटवर्क लोड बॅलन्सर, डेटा प्रवाह नेहमी त्याच लक्ष्य आभासी मशीनकडे निर्देशित केला पाहिजे. सुरक्षा गट हे एक स्टेटफुल फायरवॉल आहे. हे येणार्‍या रहदारीचे निरीक्षण करते आणि आउटगोइंग पॅकेट प्रवाहासाठी पोर्ट उघडते.

AWS क्लाउडमध्ये, ट्रान्समिशन लेटन्सी आवश्यकता अत्यंत उच्च आहेत. म्हणून हायपरप्लेन संपूर्ण नेटवर्कच्या कार्यक्षमतेसाठी महत्त्वपूर्ण.

हायपरप्लेन EC2 व्हर्च्युअल मशीनवर तयार केले आहे. येथे कोणतीही जादू नाही, फक्त धूर्त आहे. युक्ती अशी आहे की ही मोठी RAM असलेली आभासी मशीन आहेत. ऑपरेशन्स व्यवहारात्मक असतात आणि केवळ मेमरीमध्ये केल्या जातात. हे तुम्हाला फक्त दहापट मायक्रोसेकंदांचा विलंब साध्य करण्यास अनुमती देते. डिस्कसह कार्य केल्याने सर्व उत्पादकता नष्ट होईल. 

हायपरप्लेन ही अशा मोठ्या संख्येने EC2 मशीनची वितरित प्रणाली आहे. प्रत्येक आभासी मशीनची बँडविड्थ 5 GB/s आहे. संपूर्ण प्रादेशिक नेटवर्कवर, हे बँडविड्थचे अविश्वसनीय टेराबिट्स प्रदान करते आणि प्रक्रिया करण्यास अनुमती देते प्रति सेकंद लाखो कनेक्शन.

हायपरप्लेन केवळ प्रवाहांसह कार्य करते. त्यासाठी व्हीपीसी पॅकेट एन्कॅप्सुलेशन पूर्णपणे पारदर्शक आहे. या अंतर्गत सेवेतील संभाव्य असुरक्षा अजूनही VPC अलगाव खंडित होण्यापासून प्रतिबंधित करेल. खालील स्तर सुरक्षिततेसाठी जबाबदार आहेत.

गोंगाट करणारा शेजारी

अजूनही एक समस्या आहे गोंगाट करणारा शेजारी - गोंगाट करणारा शेजारी. समजा आपल्याकडे 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 गेटवे, Amazon EFS, AWS PrivateLink, AWS ट्रान्झिट गेटवे.

नेटवर्क स्केल

आता नेटवर्कच्याच स्केलबद्दल बोलूया. ऑक्टोबर 2019 साठी AWS त्याच्या सेवा ऑफर करते 22 प्रदेश, आणि आणखी 9 नियोजित आहेत.

• प्रत्येक प्रदेशात अनेक उपलब्धता झोन असतात. जगभरात त्यापैकी 69 आहेत.
• प्रत्येक AZ मध्ये डेटा प्रोसेसिंग सेंटर्स असतात. त्यापैकी एकूण 8 पेक्षा जास्त नाहीत.
• डेटा सेंटरमध्ये मोठ्या संख्येने सर्व्हर आहेत, काही 300 पर्यंत आहेत.

आता या सर्वांची सरासरी काढू, गुणाकार करू आणि प्रतिबिंबित करणारी एक प्रभावी आकृती मिळवू ऍमेझॉन क्लाउड स्केल.

उपलब्धता क्षेत्रे आणि डेटा सेंटरमध्ये अनेक ऑप्टिकल लिंक्स आहेत. आमच्या सर्वात मोठ्या प्रदेशांपैकी एकामध्ये, 388 चॅनेल फक्त एकमेकांमधील AZ संप्रेषणासाठी आणि इतर प्रदेशांशी संपर्क केंद्रे (ट्रान्झिट सेंटर) घातली गेली आहेत. एकूण हे वेडा देते 5000 Tbit.

बॅकबोन AWS विशेषतः क्लाउडसाठी तयार केले आहे आणि ऑप्टिमाइझ केले आहे. आम्ही ते वाहिन्यांवर बांधतो 100 जीबी / से. चीनमधील प्रदेशांचा अपवाद वगळता आम्ही त्यांच्यावर पूर्णपणे नियंत्रण ठेवतो. वाहतूक इतर कंपन्यांच्या लोडसह सामायिक केली जात नाही.

अर्थात, खाजगी बॅकबोन नेटवर्क असलेले आम्ही एकमेव क्लाउड प्रदाता नाही. अधिकाधिक मोठ्या कंपन्या हा मार्ग अवलंबत आहेत. स्वतंत्र संशोधकांनी याची पुष्टी केली आहे, उदाहरणार्थ टेलीजिओग्राफी.

आलेख दर्शवितो की सामग्री प्रदाते आणि क्लाउड प्रदाते यांचा वाटा वाढत आहे. यामुळे, बॅकबोन प्रदात्यांचा इंटरनेट ट्रॅफिकचा वाटा सतत कमी होत आहे.

हे का घडते ते मी समजावून सांगेन. पूर्वी, बहुतेक वेब सेवा थेट इंटरनेटवरून प्रवेश करण्यायोग्य आणि वापरल्या जात होत्या. आजकाल, अधिकाधिक सर्व्हर क्लाउडमध्ये स्थित आहेत आणि त्याद्वारे प्रवेशयोग्य आहेत जागा - सामग्री वितरण नेटवर्क. संसाधनात प्रवेश करण्यासाठी, वापरकर्ता इंटरनेटद्वारे फक्त जवळच्या CDN PoP वर जातो - उपस्थिती बिंदू. बहुतेकदा ते जवळपास कुठेतरी असते. मग ते सार्वजनिक इंटरनेट सोडते आणि अटलांटिक ओलांडून खाजगी पाठीच्या कणामधून उडते, उदाहरणार्थ, आणि थेट संसाधनापर्यंत पोहोचते.

मला आश्चर्य वाटते की जर हा ट्रेंड असाच चालू राहिला तर 10 वर्षांत इंटरनेट कसे बदलेल?

भौतिक चॅनेल

ब्रह्मांडातील प्रकाशाचा वेग कसा वाढवायचा हे शास्त्रज्ञांना अद्याप सापडलेले नाही, परंतु ऑप्टिकल फायबरद्वारे ते प्रसारित करण्याच्या पद्धतींमध्ये त्यांनी मोठी प्रगती केली आहे. आम्ही सध्या 6912 फायबर केबल्स वापरतो. हे त्यांच्या स्थापनेची किंमत लक्षणीयरीत्या अनुकूल करण्यास मदत करते.

काही प्रदेशांमध्ये आम्हाला विशेष केबल्स वापरावी लागतात. उदाहरणार्थ, सिडनी प्रदेशात आम्ही दीमकांविरूद्ध विशेष कोटिंगसह केबल्स वापरतो. 

त्रासांपासून कोणीही सुरक्षित नाही आणि कधीकधी आमचे चॅनेल खराब होतात. उजवीकडील फोटो अमेरिकन प्रदेशातील एका ऑप्टिकल केबल्स दाखवतो ज्या बांधकाम कामगारांनी फाडल्या होत्या. या अपघातामुळे केवळ 13 डेटा पॅकेट्स हरवल्या, ही आश्चर्याची बाब आहे. पुन्हा एकदा - फक्त 13! सिस्टम अक्षरशः त्वरित बॅकअप चॅनेलवर स्विच केले - स्केल कार्यरत आहे.

आम्ही Amazon च्या काही क्लाउड सेवा आणि तंत्रज्ञानातून पुढे गेलो. मला आशा आहे की आमच्या अभियंत्यांनी सोडवलेल्या कार्यांच्या स्केलची तुम्हाला किमान कल्पना असेल. व्यक्तिशः, मला हे खूप रोमांचक वाटते. 

AWS यंत्राविषयी Vasily Pantyukhin यांच्या त्रयींचा हा अंतिम भाग आहे. IN पहिला भाग सर्व्हर ऑप्टिमायझेशन आणि डेटाबेस स्केलिंगचे वर्णन करतात आणि मध्ये दुसरा - सर्व्हरलेस फंक्शन्स आणि फायरक्रॅकर.

वर HighLoad++ नोव्हेंबरमध्ये Vasily Pantyukhin Amazon डिव्हाइसचे नवीन तपशील सामायिक करेल. तो सांगेन अयशस्वी होण्याच्या कारणांबद्दल आणि Amazon वर वितरित सिस्टमच्या डिझाइनबद्दल. 24 ऑक्टोबर अजूनही शक्य आहे बुक करणे चांगल्या किमतीत तिकीट आणि नंतर पैसे द्या. HighLoad++ वर आम्ही तुमची वाट पाहत आहोत, चला गप्पा मारू!

स्त्रोत: www.habr.com