ज़ेपेलिन पर बादल: क्लाउड सेवा बनाने का अनुभव Mail.Ru Group

हमने जून 2012 में Mail.Ru क्लाउड पर काम करना शुरू कर दिया। डेढ़ साल तक, हमने पहले प्रोटोटाइप से एक सार्वजनिक सेवा के लिए एक लंबा और कांटेदार रास्ता तय किया है जो 60 जीबी / एस से अधिक भार का सामना कर सकता है। आज हम आपके साथ एक कहानी साझा करना चाहते हैं कि यह कैसी थी।

क्या आपको याद है कि यह सब कैसे शुरू हुआ

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

मेटाडेटा सर्वर

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

बेशक, हम पूरी तरह से समझ चुके हैं कि क्लाइंट सर्वर पर एक निरंतर टीसीपी कनेक्शन रखने का जोखिम नहीं उठा सकते हैं। इसके अलावा, उस समय हमारे पास कोई प्रमाणीकरण नहीं था: हमने ग्राहक पर भरोसा किया। यह विकास के लिए अच्छा था, लेकिन उत्पादन के लिए पूरी तरह से अस्वीकार्य है।

HTTP आवरण

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

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

इस स्तर पर भी, हमें तीसरे पक्ष के HTTP नोटिफ़ायर की आवश्यकता का सामना करना पड़ा। हमने Nginx HTTP Push-Module लिया - यह सूचना के लिए एक धूमकेतु सर्वर है - और अपने मेटाडेटा सर्वर से इसे सूचनाएं भेजना शुरू किया।

जब यह सिर्फ काम नहीं कर रहा था, लेकिन सामान्य रूप से धूमकेतु सर्वर के क्रैश और पुनरारंभ का अनुभव करने लगा, तो हम अगले चरण पर आगे बढ़ गए।

प्राधिकरण

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

हमें एक साथ दो अच्छे उपहार मिले: प्राधिकरण ने मेटाडेटा सर्वर के साथ काम करते समय और अधिसूचना सर्वर के साथ काम करते समय दोनों काम किया।

लोडर

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

नवंबर 2012 तक, वह दिन आ गया जब हम अब इस तथ्य से दूर नहीं जा सकते थे कि न केवल उपयोगकर्ता निर्देशिकाओं का पदानुक्रम महत्वपूर्ण था, बल्कि उस सामग्री को भी संग्रहीत किया गया था जिसे उसने संग्रहीत किया था।

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

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

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

ज़ेपेलिन: पायथन बनाम सी

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

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

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

समय के साथ ज़ेपेलिन की कार्यक्षमता का विस्तार हुआ, और आज यह मेटाड में अनुरोधों के लिए जिम्मेदार है, जो वेब लिंक के साथ काम कर रहा है, मेटाड और फ़ेसब के बीच डेटा को फिर से जोड़ रहा है, और प्राधिकरण।

थंबनेल जेनरेटर

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

अधिकतम गति सुनिश्चित करने के लिए, मशीन पर थंबनेल बनाए जाते हैं जहां फ़ाइल भौतिक रूप से स्थित होती है। चूँकि बहुत सी कहानियाँ हैं, इसलिए थंबनेल बनाने पर लोड लगभग समान रूप से "फैल गया" है, और, हमारी भावनाओं के अनुसार, जनरेटर बहुत जल्दी काम करता है (ठीक है, शायद, उन मामलों को छोड़कर जब 16,000 x 16,000 पिक्सेल फ़ाइल का अनुरोध किया जाता है)।

पहला तनाव चरण: बंद बीटा

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

दूसरा तनाव चरण: सार्वजनिक रिलीज

दूसरा प्रमुख परीक्षण एक सार्वजनिक रिलीज था: डिस्क के साथ समस्याएं लौट आईं, जिसे हमने एक बार फिर हल किया। समय के साथ, उत्साह फीका पड़ने लगा, लेकिन फिर नया साल बदल गया, और हमने सभी को एक टेराबाइट देने का फैसला किया। इस संबंध में, 20 दिसंबर बहुत खुशगवार निकला: यातायात हमारी सभी अपेक्षाओं को पार कर गया। उस समय, हमारे पास लगभग 100 कहानियाँ थीं जिनमें लगभग 2,400 डिस्क थे, जबकि व्यक्तिगत मशीनों का ट्रैफ़िक गीगाबिट से अधिक था। कुल ट्रैफ़िक 60 Gbps से अधिक हो गया।

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

संपत्ति का विवरण

इसलिए, इस समय हम उपयोग कर रहे हैं:

● स्व-लिखित डेटाबेस। आपको अपना आधार लिखने की आवश्यकता क्यों थी? प्रारंभ में, हम बड़ी संख्या में सस्ती मशीनों पर चलना चाहते थे, इसलिए विकास के दौरान, हमने प्रोसेसर के प्रत्येक घड़ी चक्र के लिए रैम के प्रत्येक बाइट के लिए लड़ाई लड़ी। मौजूदा कार्यान्वयन पर ऐसा करना, जैसे कि बाइनरी-पैक, जो JSON को स्टोर करता है, MongoDB, भोली होगी। इसके अलावा, हमें विशिष्ट संचालन की आवश्यकता थी, जैसे यूनिकोड केस फोल्डिंग, फ़ाइल संचालन का कार्यान्वयन।

यह मौजूदा noSQL डेटाबेस का विस्तार करके किया जा सकता है, लेकिन इस मामले में, vfs लॉजिक को कोड आधार के पहले से मौजूद ठोस मात्रा में जोड़ा जाना होगा, या अंतर्निहित स्क्रिप्टिंग भाषाओं के माध्यम से सर्वर की कार्यक्षमता का विस्तार करना होगा, जिसके प्रभाव से कई संदेह पैदा हुए हैं।

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

टारनटूल में स्ट्रिंग्स के रूप में सभी रास्तों को स्टोर करना संभव होगा, लेकिन यह दो कारणों से नुकसानदेह है। सबसे पहले, हम स्पष्ट रूप से सभी उपयोगकर्ताओं को रैम में फिट करने में सक्षम नहीं होंगे, और टारनटूल डेटा को स्टोर करते हैं; दूसरी बात, अगर आप पूरा रास्ता बनाए रखते हैं, तो हमें भारी भरकम फायदा मिलेगा।

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

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

● टारेंटूल की-वैल्यू स्टोरेज

● नगीनेक्स का व्यापक रूप से उपयोग किया जाता है (अद्भुत रूसी विकास, आदर्श जब तक आपको इसके लिए एक्सटेंशन नहीं लिखना होगा)

● Mail.Ru इमैजिन के आंतरिक विकास के लिए पुराना नोटिफ़ायर अस्थायी रूप से एक अल्पविकसित के रूप में उपयोग किया जाता है

● डिस्क के तीन हजार से अधिक जोड़े। उपयोगकर्ता फ़ाइलों और मेटाडेटा को विभिन्न मशीनों पर दो प्रतियों में संग्रहीत किया जाता है, जिनमें से प्रत्येक में 2 या 4 टीबी की क्षमता के साथ 24 डिस्क हैं (सभी नए सर्वर 4 टीबी ड्राइव के साथ स्थापित किए गए हैं)।

अनपेक्षित खोजें

हम प्रत्येक अनुरोध के लिए विस्तृत लॉग लिखते हैं। हमारे पास एक अलग टीम है जो एक विश्लेषक लिखती है जो समस्याओं की पहचान और विश्लेषण करने के लिए विभिन्न ग्राफ़ बनाता है। ग्राफ ग्रेफाइट में प्रदर्शित होते हैं, इसके अलावा हम रडार और अन्य प्रणालियों का उपयोग करते हैं।
हमारे क्लाउड का उपयोग करने के तरीके के बारे में बताते हुए, हमने कुछ दिलचस्प खोजें कीं। उदाहरण के लिए, क्लाउड में सबसे लोकप्रिय फ़ाइल एक्सटेंशन .jpg है। यह आश्चर्य की बात नहीं है - लोग फोटोचकी से प्यार करते हैं। अधिक दिलचस्प बात यह है कि शीर्ष 10 लोकप्रिय एक्सटेंशन में .php और .html शामिल हैं। हमें पता नहीं है कि वहां क्या संग्रहीत है - होस्टिंग से कोड आधार या बैकअप, लेकिन तथ्य यह है।

हम उन दिनों में ट्रैफ़िक में महत्वपूर्ण उछाल देखते हैं जब अपडेट किए गए मॉड दिखाई देते हैं, लोकप्रिय ऑनलाइन गेम के अपडेट के लिए जारी किए जाते हैं: कोई व्यक्ति अगले ऐड-ऑन को डाउनलोड करता है, और फिर गेमर्स की सेना इसे हमारे क्लाउड से डाउनलोड करती है। यह इस बात पर निर्भर करता है कि इन अपडेट को डाउनलोड करने के लिए कुछ दिनों में हमसे 30% तक की यात्रा की गई थी।

क्यू एंड ए

हमने उन सवालों की एक सूची के बारे में सोचा जो आप पूछना चाहते हैं।

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

फ़ाइल पहचानकर्ता के रूप में क्या उपयोग किया जाता है?
हमारे लिए फ़ाइल पहचानकर्ता SHA-1 है।

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

भविष्य के लिए आपकी क्या योजनाएं हैं?
हमारी तत्काल विकास योजनाओं में, WebDAV लॉन्च करें, आगे सब कुछ और सब कुछ अनुकूलित करें, और कई दिलचस्प विशेषताएं जो आप जल्द ही जानेंगे।

अगर हम कुछ याद करते हैं, तो हम टिप्पणियों में जवाब देने की कोशिश करेंगे।