अमेज़ॅन क्लाउड्स और एमपीएलएस ट्रांसपोर्ट के बारे में

क्लाउड सेवाओं पर आधारित एक परियोजना के विकास के दौरान, अमेज़ॅन को एक समस्या से निपटना पड़ा जो सार्वजनिक डोमेन में नहीं मिल सकती थी - अमेज़ॅन आरडीएस सेवा तक पहुंचने में महत्वपूर्ण देरी। हालांकि, इससे निपटने में मेरी मदद करने के लिए, मुझे एक उद्योग अनुसंधान संस्थान में काम करने के दौरान प्राप्त डेटा ट्रांसफर की तकनीक के ज्ञान से मदद मिली।





तो, पहले रोगी का निदान करें। क्लाइंट एप्लिकेशन के साथ एक आईटी प्रणाली विकसित की जा रही है। सिस्टम एक सर्वर है जिसे Amazon क्लाउड में EC2 सेवा के रूप में होस्ट किया गया है। यह सर्वर MySQL डेटाबेस के साथ इंटरैक्ट करता है, जो RDS (रिलेशनल डेटाबेस सर्विस) सर्विस पर उसी क्षेत्र (यूएस-वेस्ट) में स्थित है। एक मोबाइल एप्लिकेशन सर्वर के साथ इंटरैक्ट करता है, जो सर्वर के माध्यम से रजिस्टर होता है और कुछ डेटा डाउनलोड करता है। इस एप्लिकेशन के संचालन के दौरान, संचार त्रुटियों को अक्सर देखा जाता है, जिससे एप्लिकेशन कनेक्शन त्रुटि के साथ एक पॉपअप प्रदर्शित करता है। उसी समय, उपयोगकर्ता एप्लिकेशन के धीमे संचालन के बारे में शिकायत करते हैं। यह स्थिति संयुक्त राज्य अमेरिका और रूस दोनों में उपयोगकर्ताओं के बीच उत्पन्न होती है।

पूरे सिस्टम को स्वतंत्र होस्टिंग (सबसे आम, सबसे सस्ता) के हस्तांतरण के लिए काफी तेजी से आवेदन संचालन और अमेज़ॅन आरडीएस देरी की अनुपस्थिति का कारण बना। विभिन्न मंचों में एक खोज ने इस व्यवहार के कारणों के बारे में जवाब नहीं दिया।

अनुप्रयोग और सर्वर और डेटाबेस के बीच बातचीत की प्रक्रिया की समय विशेषताओं को इकट्ठा करने के लिए, एक स्क्रिप्ट लिखी गई थी जिसने MySQL डेटाबेस में एक पंक्ति में 10 बार क्वेरी की थी। क्वेरी कैशिंग की स्थिति को समाप्त करने के लिए, SQL_NO_CACHE कथन को क्वेरी में जोड़ा गया था। हालाँकि, डेटाबेस ऐसी सेलेक्ट क्वेरी को कैश नहीं करता है। इसकी अवधि का अनुरोध और माप निम्नलिखित फ़ंक्शन द्वारा किया जाता है, जो खाते की नेटवर्क देरी में लेनदेन की अवधि को मापता है।

function query_execute ($link) { $time = microtime (true); $res = mysqli_query ($link, «SELECT SQL_NO_CACHE ui.* FROM `user_item_id` ui INNER JOIN `users` u ON u.`user_id`=ui.`user_id` WHERE u.`username`='any@user.com';»); return array («rows» => mysqli_num_rows ($res), «time» => sprintf («%4f», microtime (true) — $time)); } 

यह स्क्रिप्ट रूसी होस्टिंग पर अपलोड की गई थी, और लॉन्च की गई थी। परिणाम निम्नानुसार है (स्क्रिप्ट - रूस, डीबीएमएस - अमेज़ॅन आरडीएस, कैलिफोर्निया)।

उपाय करने के लिए समय शुरू करें
पंक्तियाँ: 10, अवधि: 2.659313
पंक्तियाँ: 10, अवधि: 0.594934
पंक्तियाँ: 10, अवधि: 0.595982
पंक्तियाँ: 10, अवधि: 0.594558
पंक्तियाँ: 10, अवधि: 0.397052
पंक्तियाँ: 10, अवधि: 0.399988
पंक्तियाँ: 10, अवधि: 0.399615
पंक्तियाँ: 10, अवधि: 0.396856
पंक्तियाँ: 10, अवधि: 0.399138
पंक्तियाँ: 10, अवधि: 0.396113
- औसत अवधि: 0.6833549

तुलना के लिए - एक ही चीज, लेकिन एक अलग होस्टिंग साइट से - फ्रांस में (स्क्रिप्ट - फ्रांस, डीबीएमएस - अमेज़ॅन आरडीएस, कैलिफोर्निया)।

उपाय करने के लिए समय शुरू करें
पंक्तियाँ: 14, अवधि: 1.980444
पंक्तियाँ: 14, अवधि: 0.472865
पंक्तियाँ: 14, अवधि: 0.318233
पंक्तियाँ: 14, अवधि: 0.417172
पंक्तियाँ: 14, अवधि: 0.342588
पंक्तियाँ: 14, अवधि: 0.303614
पंक्तियाँ: 14, अवधि: 0.908241
पंक्तियाँ: 14, अवधि: 1.809397
पंक्तियाँ: 14, अवधि: 0.497458
पंक्तियाँ: 14, अवधि: 0.316923
- औसत अवधि: 0.7366935

यह स्थिति बेहद आश्चर्यजनक थी, और मुझे एसक्यूएल प्रश्नों के बारे में संदर्भ जानकारी में तल्लीन कर दिया। लेकिन सभी शोधों ने एक बात कही - स्क्रिप्ट सही ढंग से लिखी गई थी। स्थिति दिलचस्प है। सब कुछ समझ में आता है, लेकिन बहुत छोटी बात स्पष्ट नहीं है: क) क्या हो रहा है, और ख) कम से कम समर्थन के लिए अनुरोध कैसे करें?

सब ठीक है। अगला प्रयोग इस स्क्रिप्ट को स्थानीय रूप से कैलिफोर्निया के उसी अमेज़ॅन डेटा सेंटर में एक सर्वर पर चलाने के लिए है। निश्चित रूप से सर्वर शारीरिक रूप से पास हैं, और सब कुछ बहुत जल्दी होना चाहिए। हम कोशिश करते हैं (स्क्रिप्ट और DBMS - Amazon AWS, California)।

उपाय करने के लिए समय शुरू करें
पंक्तियाँ: 10, अवधि: 0.024818
पंक्तियाँ: 10, अवधि: 0.009796
पंक्तियाँ: 10, अवधि: 0.006747
पंक्तियाँ: 10, अवधि: 0.005163
पंक्तियाँ: 10, अवधि: 0.007998
पंक्तियाँ: 10, अवधि: 0.006088
पंक्तियाँ: 10, अवधि: 0.009614
पंक्तियाँ: 10, अवधि: 0.007938
पंक्तियाँ: 10, अवधि: 0.008052
पंक्तियाँ: 10, अवधि: 0.007804
- औसत अवधि: 0.0094018

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

अभी भी क्या दखल दे रहा है यह जांचने के लिए, डेटाबेस को अमेजन आरडीएस से अलग होस्टिंग (सबसे सस्ता) में माइग्रेट किया गया था। और यहां एक छोटे आश्चर्य की प्रतीक्षा की गई - पहले और बाद के लेनदेन की समान गति (स्क्रिप्ट - रूस, डीबीएमएस - यूएसए में कम लागत वाली होस्टिंग)।

लाइनकोड माप के लिए समय शुरू करें
पंक्तियाँ: 10, अवधि: 0.018506
पंक्तियाँ: 10, अवधि: 0.017285
पंक्तियाँ: 10, अवधि: 0.011917
पंक्तियाँ: 10, अवधि: 0.011928
पंक्तियाँ: 10, अवधि: 0.027923
पंक्तियाँ: 10, अवधि: 0.011141
पंक्तियाँ: 10, अवधि: 0.072708
पंक्तियाँ: 10, अवधि: 0.011934
पंक्तियाँ: 10, अवधि: 0.007816
पंक्तियाँ: 10, अवधि: 0.008045
- औसत अवधि: 0.0199203

मैं थोड़ा विचलित था - सबसे अच्छी स्थिति तब थी जब सर्वर खुद इस कमजोर होस्टिंग पर स्थापित किया गया था, सामान्य तौर पर (स्क्रिप्ट और डीबीएमएस संयुक्त राज्य अमेरिका में एक ही सस्ती होस्टिंग हैं)।

लाइनकोड माप के लिए समय शुरू करें
पंक्तियाँ: 10, अवधि: 0.008159
पंक्तियाँ: 10, अवधि: 0.000344
पंक्तियाँ: 10, अवधि: 0.000317
पंक्तियाँ: 10, अवधि: 0.000309
पंक्तियाँ: 10, अवधि: 0.000269
पंक्तियाँ: 10, अवधि: 0.000282
पंक्तियाँ: 10, अवधि: 0.000260
पंक्तियाँ: 10, अवधि: 0.000263
पंक्तियाँ: 10, अवधि: 0.000303
पंक्तियाँ: 10, अवधि: 0.000297
- औसत अवधि: 0.0010803

यहां आप एक समान स्थिति देख सकते हैं, लेकिन मिलीसेकंड की इकाइयों में ओएस के विलंब, और नेटवर्क नहीं, पहले से ही प्रभावी हो रहे हैं। इसलिए, आपको इस पर ध्यान नहीं देना चाहिए।

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

उपाय करने के लिए समय शुरू करें
पंक्तियाँ: 10, अवधि: 0.098134
पंक्तियाँ: 10, अवधि: 0.016168
पंक्तियाँ: 10, अवधि: 0.011697
पंक्तियाँ: 10, अवधि: 0.007868
पंक्तियाँ: 10, अवधि: 0.008148
पंक्तियाँ: 10, अवधि: 0.010468
पंक्तियाँ: 10, अवधि: 0.033403
पंक्तियाँ: 10, अवधि: 0.011947
पंक्तियाँ: 10, अवधि: 0.012217
पंक्तियाँ: 10, अवधि: 0.008185
- औसत अवधि: 0.0218235

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

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

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

रूटिंग क्या है? मान लीजिए कि चार नेटवर्क नोड हैं। पहले से दूसरे तक, एक आईपी पैकेट प्रेषित होता है। यह कैसे निर्धारित किया जाए कि इसे कहां निर्देशित किया जाए - 3 या 4 को नोड करने के लिए? नोड 2 मार्ग तालिका के अंदर दिखता है, गंतव्य पता (ईथरनेट पोर्ट) की तलाश करता है, और पैकेट को स्थानांतरित करता है - आंकड़ा 4 में, नोड 4 (पते के साथ 48.136.23.03)।



इस विधि के नुकसान निम्न कारणों से कम पैकेट रूटिंग गति हैं: ए) आपको लाखों आईपी पैकेट को पार्स करने और उनसे एक पता निकालने की आवश्यकता है, ख) आपको प्रत्येक पैकेट को डेटाबेस (रूटिंग टेबल) में चलाने की आवश्यकता है, जहां आईपी पता ईथरनेट नेटवर्क इंटरफ़ेस नंबर से मेल खाता है।

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

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



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

वास्तव में, प्रत्येक मध्यवर्ती नोड पर इस तरह के स्विचिंग टेबल के निर्माण के कारण, एक "सुरंग" बनाया जाता है जिसके साथ रूटिंग टेबल का उपयोग किए बिना, आगे डेटा ट्रांसमिशन किया जाता है।

इस विधि के फायदे नेटवर्क विलंबता में एक महत्वपूर्ण कमी है।

और अब मुख्य बात ...

माइनस - पहले पैकेटों को राउटिंग विधि द्वारा प्रेषित किया जाता है, उनके पीछे लेबल की "सुरंग" का निर्माण होता है, और केवल अगले पैकेट पहले से ही जल्दी से प्रसारित होते हैं। यह वह तस्वीर है जिसका हम ऊपर अवलोकन करते हैं। यह संभावना नहीं है कि एक सस्ते हॉस्टल में एमपीएलएस उपकरण हैं। परिणामस्वरूप, हम पहले और बाद के अनुरोधों की समान अवधि देखते हैं। लेकिन अमेज़ॅन में, ऐसा लगता है कि एमपीएलएस प्रोटोकॉल केवल खुद को प्रकट कर रहा है - पहले अनुरोध भेजने से बाद के लोगों की तुलना में 3-5 गुना अधिक समय लगता है।

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

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

• मैं जिस एप्लिकेशन के बारे में लिख रहा हूं, वह अब संस्करण 1.0 है। सबसे अधिक संभावना है, और यहां तक ​​कि सुनिश्चित करने के लिए, हमारे पास अब एक उप-डेटाबेस डेटाबेस क्वेरी संरचना है। भविष्य में, इसे अनुकूलित किया जाएगा, और इसके कारण हमें गति में लाभ मिलेगा। लेकिन अब, ऐसा लगता है, एक ने दूसरे के साथ ओवरलैप किया है।
• यह मानते हुए कि बड़े सामाजिक नेटवर्क अमेज़न पर आधारित हैं, अभी भी अजीब है। सबसे अधिक संभावना है, ऐसी प्रणालियों की वास्तुकला भौगोलिक रूप से वितरित की जाती है, और जानकारी केवल अमेज़ॅन डेटा केंद्रों पर अतुल्यकालिक रूप से झुंड कर सकती है। कम से कम, मास्को फेसबुक से ट्रेसिंग आयरिश सर्वर को एक समापन बिंदु के रूप में दिखाता है, ट्विटर - अपनी खुद की कुछ साइट, Pinterest - तेलिया नेटवर्क पर और इसी तरह।
• सोशल नेटवर्क के बड़े नोड्स के बीच, स्थिर मार्गों की सबसे अधिक संभावना होती है।

किसी भी स्थिति में, स्थिति के लिए मेरे पास कोई अन्य स्पष्टीकरण नहीं है।

लेकिन एक उपाय है। तीन हफ्ते पहले, सिस्टम को OVH होस्टिंग प्रदाता के कनाडाई समर्पित सर्वरों में माइग्रेट किया गया था। इस समस्या को हल किया गया था: सब कुछ तेजी से काम किया और किसी और ने कनेक्शन त्रुटि नहीं देखी।