एडब्ल्यूएस आर्किटेक्चर जब बहु-क्षेत्र

Question

मुझे हाल ही में एडब्ल्यूएस में पेश किया गया है और मुझे वास्तव में यह पसंद आया। हालांकि, मैं बहु-क्षेत्रों के लिए आर्किटेक्चरिंग के बारे में कुछ सवाल पूछ रहा हूं (जो बेवकूफ हो सकता है)।

मान लें कि यूरोप और एशियाई लोगों द्वारा एक एप्लिकेशन का उपयोग किया जाता है। मेरा पहला विचार यूरोप में ईसी 2 उदाहरणों के साथ-साथ एस 3 बाल्टी को स्थिर डेटा और एसक्यूएस कतार और यूरोप में एलिस्टी कैश रखने के लिए था। यह यूरोपीय लोगों के लिए तेजी से तेजी से होगा, लेकिन एशियाई लोगों के लिए धीमा है।

इसे हल करने के लिए, मैं स्थिर डेटा के लिए क्लाउडफ्रंट जोड़ूंगा, ताकि छवियों को एशियाई लोगों के लिए भी जल्दी से सेवा दी जा सके। हालांकि, सर्वर (अजाक्स अनुरोध ...) के लिए अनुरोध अभी भी कुछ विलंबता होने जा रहे हैं, इसलिए समाधान सिंगापुर/टोक्यो क्षेत्र में भी ईसी 2 उदाहरण जोड़ना होगा।

हालांकि, नई समस्या उत्पन्न होती है: यदि टोक्यो ईसी 2 उदाहरण के लिए अनुरोध भेजा गया है, तो अगर उसे यूरोप में संग्रहीत एसक्यूएस से संदेश प्राप्त करने की आवश्यकता है या ElastiCache डेटा => विलंबता फिर से + अंतर-क्षेत्र हस्तांतरण के लिए लागत । तो हमें एशिया में एसक्यूएस और एलिस्टी कैश भी जोड़ना होगा?

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

वैसे भी, क्या मैं इसे सही ढंग से समझता हूं? क्या आपके पास बहु-क्षेत्रों को लक्षित करने वाले आर्किटेक्चर अनुप्रयोगों के बारे में कोई संसाधन है?

धन्यवाद :)

Answer 1

ये बेवकूफ सवाल नहीं हैं! यह हिस्सा बिल्कुल सही है:

Maybe I miss something, and cross-regions AWS requests are super-fast, but from 
what I've understood, if we want fast experience for multi-regions, we basically 
need to duplicate all services too every regions 

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

उपयोगकर्ताओं को उचित क्षेत्र में रूट करने के लिए, आप Route 53 पर देखना चाहते हैं, जो एडब्ल्यूएस परिवार का एक और हिस्सा है। मार्ग 53 के बारे में This announcement उन क्षेत्रों के बीच विलंबता-आधारित रूटिंग का वर्णन करता है जिनकी आपको आवश्यकता होगी। एक बार जब उपयोगकर्ता उपयुक्त ईसी 2 उदाहरणों पर जाते हैं, तो आपके द्वारा तैनात किए गए प्रत्येक क्षेत्र को अलग किया जाना चाहिए। आप यूरोपीय क्षेत्र (ईयू-वेस्ट -1) से सभी ईसी 2, एसक्यूएस, लोचदार, और किसी अन्य एडब्ल्यूएस पेशकश के साथ अपनी यूरोपीय तैनाती को कॉन्फ़िगर करेंगे। आपके एशियाई परिनियोजन के लिए, आप इसे एपी-दक्षिणपूर्व -1 क्षेत्र में होस्ट कर सकते हैं। एक बार मार्ग 53 एशियन उपयोगकर्ता को एपी 2 उदाहरण के साथ एसी 2 उदाहरण के साथ जोड़ता है, एसक्यूएस, लोचदार, आदि के अनुरोध एक ही क्षेत्र के भीतर होंगे और इस प्रकार बहुत तेज़ होंगे।

Answer 2

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

यह आपके द्वारा उपयोग किए जाने वाले कार्यों के लिए भुगतान करने के रूप में अधिक महंगा नहीं होगा, और यदि आप क्षेत्रों के बीच लोड वितरित करते हैं, तो आपके पास समान लागत कम होगी। उदाहरण के लिए, यदि आपको अपने उपयोगकर्ताओं की सेवा के लिए 10 सर्वर की आवश्यकता है, तो आपके पास यूरोप में 5 सर्वर और सिंगापुर में 5 सर्वर हो सकते हैं। से अधिक; auto-scaling का उपयोग करके लोड के घंटे के आधार पर आपके पास विभिन्न क्षेत्रों में सर्वरों की अलग-अलग संख्या हो सकती है। उदाहरण के लिए, यूरोप में 8 सर्वर जब यूरोप जागता है और सिंगापुर में केवल 2 ही रात में होता है, और इसके विपरीत।

अमेज़ॅन क्लाउडफ्रंट (सीडीएन) और रूट 53 (डीएनएस) के साथ उपरोक्त बहु-क्षेत्र सेवाओं (ईसी 2, एस 3, लोचदार कैश, आरडीएस ...) के संयोजन के साथ आप उत्कृष्टता के साथ एक बहुत ही स्केलेबल और किफायती सेवा बना सकते हैं विलंबता वैश्विक स्तर पर (यूरोप, एशिया, उत्तरी और दक्षिण अमेरिका ...)।