वेब आर्किटेक्चर इंटरनेट मैप्स

सभी को नमस्कार!

आपने शायद पहले ही इंटरनेट मैप के बारे में सुना होगा। यदि नहीं, तो आप इसे यहाँ देख सकते हैं, और आप इसके बारे में मेरी पिछली पोस्ट में पढ़ सकते हैं।

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

इंटरनेट मैप्स का प्रदर्शन इंटरनेट दिग्गजों की आधुनिक तकनीकों द्वारा समर्थित है: Google से Google मैप्स इंजन, मैप्स को दिखाता है, वेब पर Microsoft .net प्रौद्योगिकियों द्वारा संसाधित किया जाता है, और अमेज़न से अमेज़न वेब सेवाएँ होस्टिंग और सामग्री वितरण प्रदान करती हैं। कार्ड के सामान्य संचालन के लिए सभी तीन घटक महत्वपूर्ण हैं।

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

Amazon CloundFront और Google मैप्स

Google मैप्स तकनीक में टाइलों का उपयोग शामिल है - 256x256 पिक्सेल के छोटे चित्र जिसमें से मानचित्र चित्र बनता है। इन चित्रों के साथ मुख्य बिंदु यह है कि वास्तव में उनमें से बहुत सारे हैं। जब आप उच्च रिज़ॉल्यूशन के साथ अपनी स्क्रीन पर एक मानचित्र देखते हैं, तो यह सभी इन छोटी तस्वीरों के होते हैं। इसका मतलब है कि सर्वर को बहुत अधिक अनुरोधों को बहुत तेज़ी से संसाधित करने और एक ही समय में टाइल देने में सक्षम होना चाहिए ताकि क्लाइंट मोज़ेक को नोटिस न करे। नक्शे को प्रदर्शित करने के लिए आवश्यक टाइलों की कुल संख्या योग (4 ^ i) है, जहाँ मैं 0 से N तक के मानों से चलता हूँ, जहाँ N, zooms की कुल संख्या है। इंटरनेट मानचित्र के मामले में, शून्य की संख्या 14 है, अर्थात्। टाइल्स की कुल संख्या लगभग 358 मिलियन होनी चाहिए। सौभाग्य से, यह खगोलीय आंकड़ा 30 मिलियन तक कम हो गया था, खाली टाइल्स की पीढ़ी को छोड़ दिया। यदि आप ब्राउज़र कंसोल खोलते हैं, तो आपको कई 403 त्रुटियां दिखाई देंगी, ये वास्तव में वे हैं - मिस्ड टाइलें, लेकिन यह नक्शा दिखाई नहीं देता है क्योंकि यदि कोई टाइल नहीं है, तो वर्ग एक काली पृष्ठभूमि से भर जाता है। एक तरह से या किसी अन्य, 30 मिलियन टाइल भी एक महत्वपूर्ण आंकड़ा है।

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

यह पता चला है कि आपके डेटा को कई बार दोहराया जाता है और CloudFront सर्वर से डिलीवर होने की संभावना होती है, न कि आपके महंगे, कमजोर और अविश्वसनीय स्टोरेज की। इंटरनेट मैप के मामले में, क्लाउडफ्रंट कनेक्शन का वास्तव में मतलब था कि मेरी हार्ड ड्राइव के डेटा को शारीरिक रूप से सिंगापुर सिंपल स्टोरेज सर्विस (S3) सेगमेंट में कॉपी किया गया था, और फिर CloudFront में AWS कंसोल के माध्यम से एक वितरण बनाया गया था, जहां S3 को डेटा स्रोत के रूप में निर्दिष्ट किया गया था। (उत्पत्ति)। यदि आप इंटरनेट मैप पेज के कोड को देखते हैं, तो आप देख सकते हैं कि टाइलें CloudFront के पते d2h9tsxwphc7ip.cloudfront.net से ली गई हैं। निकटतम साइट का पता लगाना, सामग्री को अद्यतित रखना और इन सभी चीजों को CloudFront स्वचालित रूप से करता है। हुर्रे!



तस्वीर में आप देख सकते हैं कि मूल नक्शे को टाइलों में कैसे विभाजित किया गया है, टाइल्स को S3 में संग्रहीत किया जाता है, और वहां से उन्हें CloudFront पर अपलोड किया जाता है और इसके नोड्स से उपयोगकर्ताओं को वितरित किया जाता है।

Amazon rds

मानचित्र पर साइट खोज प्रदान करने के लिए, आपको एक डेटाबेस की आवश्यकता होती है जहां साइटों और उनके निर्देशांक के बारे में जानकारी संग्रहीत की जाएगी। इस स्थिति में, हमारे पास अमेज़न क्लाउड में MS SQL एक्सप्रेस है। इसे रिलेशनल डेटाबेस सर्विस (RDS) कहा जाता है। हमें वास्तव में निर्भरता की आवश्यकता नहीं है। हमारे पास केवल एक तालिका है, लेकिन पहिया को सुदृढ़ करने की तुलना में एक पूर्ण डेटाबेस होना बेहतर है। RDS आपको केवल MS SQL ही नहीं बल्कि Oracle, MySql और शायद कुछ और का उपयोग करने की अनुमति देता है।

तस्वीर में आप देख सकते हैं कि स्रोत मानचित्र आरडीएस डेटाबेस में एक तालिका में कैसे बदल जाता है।

अमेज़ॅन इलास्टिक बीनस्टॉक

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

इलास्टिक बीनस्टॉक सभी बुनियादी ढांचे के मुद्दों का ख्याल रखता है। वास्तव में, आप एमएस विज़ुअल स्टूडियो में प्लगइन डाल सकते हैं और विवरण के बारे में भूल सकते हैं। वह संस्करण नियंत्रण, तैनाती आदि का समर्थन करेगा। और अगर लोड बढ़ता है, तो यह आवश्यक के रूप में कई EC2 उदाहरण बनाएगा।
आरेख पर, इलास्टिक बीनस्टॉक एक बिंदीदार रेखा से घिरा हुआ है, अंदर आप ELB देख सकते हैं, जो आने वाले अनुरोधों को स्वीकार करता है और उन्हें EC2 उदाहरणों में IIS को वितरित करता है।

प्रदर्शन और कीमत

वेबसाइट Habrahabr.ru पर लेख के प्रकाशन के तुरंत बाद, आगंतुकों की एक धारा इंटरनेट मानचित्र पर चली गई। ग्राफ़ पर आप ट्रैफ़िक में बहुत तेज़ वृद्धि देख सकते हैं, पहले 6 घंटों में 30,000 लोगों ने साइट का दौरा किया, और पहले दिन लगभग 50,000, मुख्य रूप से रूस और पूर्व यूएसएसआर के देशों से। कुछ गलत लग रहा था, इलास्टिक बीनस्टॉक ने 10 EC2 उदाहरण बनाए और उन्होंने अच्छा काम किया। साइट तक पहुंच के साथ समस्याओं के बारे में शिकायतें बताई गई हैं। मानचित्र को स्वतंत्र रूप से देखा जा सकता है। लेकिन आरडीएस तुरंत मर गया: पहली बार में खोज बहुत धीरे-धीरे काम करना शुरू हुई, फिर रुक-रुक कर, और फिर पूरी तरह से बंद हो गई। पहले दिन का खाता लगभग $ 200 था। S3 + CloudFront के लिए लगभग 100 और EC2 और RDS के लिए 50।

प्राप्त अनुभव का अध्ययन करने के बाद, मैंने ऑटोस्कोलिंग मापदंडों के अनुकूलन और पुन: संयोजन को अंजाम दिया। और इससे मदद मिली। सप्ताह के दौरान, दुनिया भर से एक दिन में औसतन 30-50 हजार लोगों द्वारा साइट का दौरा किया गया और कुछ भी नहीं गिरा। सच है, पहले दिन की तरह इतनी तेज आमद नहीं थी।

तब किसी ने reddit.com पर कार्ड के बारे में जानकारी पोस्ट की और इससे ट्रैफ़िक में विस्फोटक वृद्धि हुई। रविवार को लगभग आधा मिलियन लोगों ने साइट का दौरा किया, और केवल एक छोटा उदाहरण EC2 और एक छोटा RDS उदाहरण काम किया। सच है, एक शिकायत थी कि कार्ड लोड नहीं करता है, लेकिन, मुझे लगता है कि इस तरह की लहर के लिए यह सामान्य है।



और यहाँ पहले सप्ताह के लिए बिल है

निष्कर्ष

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