Badoo में फ़ोटो संग्रहीत करने और साझा करने के लिए वास्तुकला

आर्टेम डेनिसोव ( bo0rsh201, Badoo)

Badoo दुनिया की सबसे बड़ी डेटिंग साइट है। वर्तमान में हमारे पास दुनिया भर में लगभग 330 मिलियन पंजीकृत उपयोगकर्ता हैं। लेकिन आज की हमारी बातचीत के संदर्भ में जो बात अधिक महत्वपूर्ण है वह यह है कि हम लगभग 3 पेटाबाइट उपयोगकर्ता फ़ोटो संग्रहीत करते हैं। हर दिन हमारे उपयोगकर्ता लगभग 3,5 मिलियन नई तस्वीरें अपलोड करते हैं, और पढ़ने का भार लगभग है प्रति सेकंड 80 हजार अनुरोध. यह हमारे बैकएंड के लिए काफी है और कभी-कभी इसमें दिक्कतें भी आती हैं।

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

अब चलिए शुरू करते हैं.

जैसा कि मैंने कहा, यह एक पूर्वव्यापी होगा, और इसे कहीं से शुरू करने के लिए, आइए सबसे सामान्य उदाहरण लें।

हमारा एक सामान्य कार्य है, हमें उपयोगकर्ता फ़ोटो को स्वीकार करना, संग्रहीत करना और भेजना है। इस रूप में, कार्य सामान्य है, हम कुछ भी उपयोग कर सकते हैं:

• आधुनिक क्लाउड स्टोरेज,
• एक डिब्बा बंद समाधान, जो अब भी बहुत सारे हैं;
• हम अपने डेटा सेंटर में कई मशीनें स्थापित कर सकते हैं और उन पर बड़ी हार्ड ड्राइव लगा सकते हैं और वहां तस्वीरें संग्रहीत कर सकते हैं।

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

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

हम अपने संग्रहण में उपयोगकर्ताओं के बारे में जानकारी के साथ कुछ फ़ील्ड जोड़ते हैं। यह शार्डिंग कुंजी होगी. हमारे मामले में, हमने इसे प्लेस_आईडी कहा, और यह प्लेस आईडी उस स्थान को इंगित करता है जहां उपयोगकर्ता की तस्वीरें संग्रहीत हैं। हम मानचित्र बनाते हैं.

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

यह बिल्कुल मामूली योजना है, लेकिन इसके काफी महत्वपूर्ण फायदे हैं। पहला यह है कि यह सरल है, जैसा कि मैंने कहा, और दूसरा यह है कि इस दृष्टिकोण के साथ हम नई कारों को वितरित करके और उन्हें मानचित्र में जोड़कर आसानी से क्षैतिज रूप से स्केल कर सकते हैं। आपको कुछ और करने की जरूरत नहीं है.

कुछ समय तक हमारे लिए ऐसा ही था।

ये 2009 के आसपास की बात है. उन्होंने कारें वितरित कीं, वितरित कीं...

और कुछ बिंदु पर हमने नोटिस करना शुरू किया कि इस योजना के कुछ नुकसान भी हैं। क्या हैं नुकसान?

सबसे पहले, सीमित क्षमता है. हम एक भौतिक सर्वर पर उतनी हार्ड ड्राइव नहीं भर सकते जितनी हम चाहें। और यह समय के साथ और डेटासेट की वृद्धि के साथ एक निश्चित समस्या बन गई है।

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

यह सब 2009 के लिए था, लेकिन, सिद्धांत रूप में, ये आवश्यकताएँ आज भी प्रासंगिक हैं। हमारे पास पूर्वव्यापी है, इसलिए 2009 में सब कुछ पूरी तरह से खराब था।

और आखिरी बिंदु कीमत है।

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

और अंत में, हम तथाकथित स्टोरेज एरिया नेटवर्क का उपयोग करने पर सहमत हुए।

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

इस निर्णय के स्पष्ट लाभ थे। यह एसएचडी है. इसका उद्देश्य फ़ोटो संग्रहीत करना है. यह मशीनों को हार्ड ड्राइव से लैस करने की तुलना में सस्ता काम करता है।

दूसरा प्लस.

इसका मतलब यह है कि क्षमता बहुत बड़ी हो गई है, यानी। हम बहुत कम मात्रा में अधिक भंडारण को समायोजित कर सकते हैं।

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

जैसा कि हमारी तस्वीरों के मामले में है, क्योंकि तस्वीरों का अनुरोध असंगत रूप से किया जाता है, और इससे उनके प्रदर्शन पर बहुत प्रभाव पड़ेगा।

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

अनुकूलित करने के लिए, हमने उस समय निर्णय लिया, जाहिर है, लोड प्रोफाइल को देखने के लिए - सामान्य तौर पर क्या हो रहा है, क्या अनुकूलित करने की आवश्यकता है।

और यहाँ सब कुछ हमारे हाथ में खेलता है।

मैंने पहली स्लाइड में पहले ही कहा था: हमारे पास प्रति सेकंड 80 हजार पढ़ने के अनुरोध हैं और प्रति दिन केवल 3,5 मिलियन अपलोड हैं। यानी यह परिमाण के तीन क्रमों का अंतर है। यह स्पष्ट है कि पढ़ने को अनुकूलित करने की आवश्यकता है और यह व्यावहारिक रूप से स्पष्ट है कि कैसे।

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

वे। हमारे पास एक बहुत छोटा हॉट डेटासेट है। लेकिन साथ ही उनके लिए बहुत सारी फरमाइशें भी आ रही हैं. और यहां एक पूरी तरह से स्पष्ट समाधान कैश जोड़ना है।

एलआरयू वाला कैश हमारी सभी समस्याओं का समाधान कर देगा। हम क्या कर रहे हैं?

हम भंडारण के साथ अपने बड़े क्लस्टर के सामने एक और अपेक्षाकृत छोटा जोड़ते हैं, जिसे फोटोकैश कहा जाता है। यह मूलतः केवल एक कैशिंग प्रॉक्सी है।

यह अंदर से कैसे काम करता है? यहाँ हमारा उपयोगकर्ता है, यहाँ भंडारण है। सब कुछ पहले जैसा ही है. हम बीच में क्या जोड़ते हैं?

यह भौतिक स्थानीय डिस्क वाली एक मशीन मात्र है, जो तेज़ है। उदाहरण के लिए, यह SSD के साथ है। और इस डिस्क पर किसी प्रकार का स्थानीय कैश संग्रहीत होता है।

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

लेकिन यह बहुत साधारण है और यह स्पष्ट नहीं है कि अंदर क्या हो रहा है। यह कुछ इस तरह काम करता है.

कैश को तार्किक रूप से तीन परतों में विभाजित किया गया है। जब मैं "तीन परतें" कहता हूं, तो इसका मतलब यह नहीं है कि किसी प्रकार की जटिल प्रणाली है। नहीं, ये फ़ाइल सिस्टम में सशर्त रूप से केवल तीन निर्देशिकाएँ हैं:

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

इसे काम करने के लिए, हमें किसी तरह इस कैश को प्रबंधित करना होगा, हमें इसमें फ़ोटो को पुनर्व्यवस्थित करना होगा, आदि। यह भी एक बहुत ही आदिम प्रक्रिया है.

Nginx बस प्रत्येक अनुरोध के लिए RAMDisk access.log को लिखता है, जिसमें यह उस फोटो के पथ को इंगित करता है जिसे उसने वर्तमान में परोसा है (सापेक्ष पथ, निश्चित रूप से), और यह किस विभाजन में परोसा गया था। वे। यह "फोटो 1" कह सकता है और फिर या तो एक बफर, या एक हॉट कैश, या एक ठंडा कैश, या एक प्रॉक्सी कह सकता है।

इसके आधार पर, हमें किसी तरह यह तय करना होगा कि फोटो के साथ क्या करना है।

हमारे पास प्रत्येक मशीन पर चलने वाला एक छोटा डेमॉन है जो लगातार इस लॉग को पढ़ता है और अपनी मेमोरी में कुछ तस्वीरों के उपयोग पर आंकड़े संग्रहीत करता है।

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

जिन फ़ोटो का अनुरोध शायद ही कभी किया जाता है और जिनका अनुरोध कम बार किया जाता है, उन्हें धीरे-धीरे गर्म कैश से ठंडे कैश में धकेल दिया जाता है।

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

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

शेष प्रश्न यह है कि इन सर्वरों पर अनुरोधों को कैसे वितरित किया जाए।

मान लीजिए कि बीस स्टोरेज मशीनों और तीन कैशिंग सर्वरों का एक क्लस्टर है (यह इसी तरह हुआ)।

हमें किसी तरह यह निर्धारित करने की आवश्यकता है कि कौन से अनुरोध किन तस्वीरों के लिए हैं और उन्हें कहां लगाया जाए।

सबसे आम विकल्प राउंड रॉबिन है। या यह गलती से करें?

जाहिर तौर पर इसके कई नुकसान हैं क्योंकि ऐसी स्थिति में हम कैश का उपयोग बहुत ही अकुशलता से कर रहे होंगे। अनुरोध कुछ यादृच्छिक मशीनों पर आएंगे: यहां इसे कैश किया गया था, लेकिन अगले पर यह अब नहीं है। और अगर ये सब चलता रहा तो बहुत बुरा होगा. क्लस्टर में कम संख्या में मशीनों के साथ भी।

हमें किसी तरह स्पष्ट रूप से यह निर्धारित करने की आवश्यकता है कि कौन सा सर्वर किस अनुरोध को प्राप्त करेगा।

एक सामान्य तरीका है. हम यूआरएल से हैश लेते हैं या हमारी शार्डिंग कुंजी से हैश लेते हैं, जो यूआरएल में है, और इसे सर्वर की संख्या से विभाजित करते हैं। काम करेगा? इच्छा।

वे। हमारे पास 2% अनुरोध है, उदाहरण के लिए, कुछ "example_url" के लिए यह हमेशा इंडेक्स "XNUMX" के साथ सर्वर पर आएगा, और कैश को यथासंभव सर्वोत्तम तरीके से निपटाया जाएगा।

लेकिन ऐसी स्कीम में रीशेयरिंग को लेकर दिक्कत होती है. पुनः साझा करना - मेरा मतलब सर्वरों की संख्या बदलना है।

आइए मान लें कि हमारा कैशिंग क्लस्टर अब सामना नहीं कर सकता है और हम एक और मशीन जोड़ने का निर्णय लेते हैं।

आइए जोड़ें.

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

यह विकल्प भी हमें शोभा नहीं देता.

वह। काय करते? हमें किसी तरह कैश का कुशल उपयोग करना चाहिए, एक ही अनुरोध को एक ही सर्वर पर बार-बार लाना चाहिए, लेकिन पुनः साझाकरण के प्रति प्रतिरोधी होना चाहिए। और एक ऐसा समाधान है, जो उतना जटिल नहीं है। इसे लगातार हैशिंग कहा जाता है.

यह कैसा दिखता है?

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

प्रत्येक सर्वर को एक बिंदु द्वारा परिभाषित किया जाता है, और जो सेक्टर उसके पास दक्षिणावर्त जाता है, तदनुसार, इस होस्ट द्वारा परोसा जाता है। जब अनुरोध हमारे पास आते हैं, तो हम तुरंत देखते हैं कि, उदाहरण के लिए, अनुरोध ए - इसमें एक हैश है - और यह सर्वर 2 द्वारा परोसा जाता है। अनुरोध बी - सर्वर 3 द्वारा। और इसी तरह।

पुनः साझाकरण के दौरान इस स्थिति में क्या होता है?

हम पहले की तरह पूरे कैश को अमान्य नहीं करते हैं, और सभी कुंजियों को स्थानांतरित नहीं करते हैं, लेकिन हम प्रत्येक सेक्टर को थोड़ी दूरी पर स्थानांतरित करते हैं ताकि, अपेक्षाकृत रूप से कहें तो, हमारा छठा सर्वर, जिसे हम जोड़ना चाहते हैं, खाली स्थान में फिट हो जाता है, और हम इसे वहां जोड़ते हैं.

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

एकमात्र प्रश्न इनकारों का है। आइए मान लें कि किसी प्रकार की कार ख़राब है।

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

यह कैशिंग सिस्टम के बारे में है. आइए नतीजों पर नजर डालें.

ऐसा लगेगा कि यहां कुछ भी जटिल नहीं है। लेकिन कैश को प्रबंधित करने की इस पद्धति ने हमें लगभग 98% की ट्रिक दर प्रदान की। वे। प्रति सेकंड इन 80 हजार अनुरोधों में से केवल 1600 ही भंडारण तक पहुंचते हैं, और यह पूरी तरह से सामान्य भार है, वे इसे शांति से सहन करते हैं, हमारे पास हमेशा एक रिजर्व होता है।

हमने इन सर्वरों को अपने तीन डीसी में रखा, और उपस्थिति के तीन बिंदु प्राप्त किए - प्राग, मियामी और हांगकांग।

वह। वे कमोबेश हमारे प्रत्येक लक्षित बाज़ार में स्थानीय रूप से स्थित हैं।

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

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

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

वैसे, हमने हाई-लोड सिस्टम के डेवलपर्स के सम्मेलन के पिछले पांच वर्षों की वीडियो रिकॉर्डिंग सार्वजनिक रूप से उपलब्ध कराई है HighLoad ++. देखें, सीखें, साझा करें और सदस्यता लें यूट्यूब चैनल.

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

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

यह तस्वीरों की वापसी से संबंधित है। यहां सब कुछ बिल्कुल स्पष्ट और स्पष्ट है। मुझे लगता है कि मैंने अमेरिका की खोज नहीं की, लगभग कोई भी सीडीएन इसी तरह काम करता है।

और, सबसे अधिक संभावना है, एक परिष्कृत श्रोता के पास एक प्रश्न हो सकता है: क्यों न सब कुछ सीडीएन में बदल दिया जाए? यह लगभग वैसा ही होगा; सभी आधुनिक सीडीएन ऐसा कर सकते हैं। और इसके कई कारण हैं.

पहली है तस्वीरें.

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

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

दूसरा निष्कर्ष भी ऐतिहासिक है, क्योंकि सिस्टम लंबे समय से विकसित हो रहा है, और विभिन्न चरणों में कई अलग-अलग व्यावसायिक आवश्यकताएं थीं, और वे हमेशा सीडीएन अवधारणा में फिट नहीं होती हैं।

और जो बात पिछले वाले से मिलती है वो ये है

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

यह क्या निष्कर्ष सुझाता है? हमारे मामले में, सीडीएन बहुत अच्छा विकल्प नहीं है।

और आपके मामले में, यदि आपकी कोई विशिष्ट व्यावसायिक आवश्यकता है, तो जो मैंने आपको स्वयं दिखाया है, आप उसे आसानी से लागू कर सकते हैं। और यह समान लोड प्रोफ़ाइल के साथ पूरी तरह से काम करेगा।

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

और आधुनिक सीडीएन में लगभग वह सब कुछ है जिसके बारे में मैंने आपको अभी बताया है। कुछ सुविधाओं को प्लस या माइनस के अपवाद के साथ।

यह तस्वीरें देने के बारे में है।

आइए अब अपने पूर्वव्यापी परिप्रेक्ष्य में थोड़ा आगे बढ़ें और भंडारण के बारे में बात करें।

2013 बीत रहा था.

कैशिंग सर्वर जोड़े गए, प्रदर्शन संबंधी समस्याएं दूर हो गईं। और सब ठीक है न। डेटासेट बढ़ रहा है. 2013 तक, हमारे पास स्टोरेज से जुड़े लगभग 80 सर्वर थे, और प्रत्येक डीसी में लगभग 40 कैशिंग सर्वर थे। यह प्रत्येक डीसी पर 560 टेराबाइट डेटा है, यानी। कुल मिलाकर लगभग एक पेटाबाइट।

और डेटासेट की वृद्धि के साथ, परिचालन लागत में उल्लेखनीय वृद्धि होने लगी। इसका क्या मतलब था?

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

सबसे पहले, स्टोरेज एरिया नेटवर्क (SAN) ही है, जो विफल हो सकता है।

दूसरे, यह प्रकाशिकी के माध्यम से अंतिम मशीनों से जुड़ा हुआ है। ऑप्टिकल कार्ड और स्पार्क प्लग में समस्याएँ हो सकती हैं।

बेशक, उनमें से उतने नहीं हैं जितने SAN के साथ हैं, लेकिन, फिर भी, ये विफलता के बिंदु भी हैं।

आगे मशीन ही है, जो स्टोरेज से जुड़ी है। यह असफल भी हो सकता है.

कुल मिलाकर, हमारी विफलता के तीन बिंदु हैं।

इसके अलावा, विफलता के बिंदुओं के अलावा, भंडारण का भारी रखरखाव भी होता है।

यह एक जटिल बहु-घटक प्रणाली है, और सिस्टम इंजीनियरों को इसके साथ काम करने में कठिनाई हो सकती है।

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

मान लीजिए कि हमारा फ़ाइल सिस्टम टूट गया है। सबसे पहले, इसकी पुनर्प्राप्ति में लंबा समय लगता है - बड़ी मात्रा में डेटा के साथ इसमें एक सप्ताह लग सकता है। और दूसरी बात, अंत में हमारे पास समझ से परे फाइलों का एक समूह होगा, जिन्हें किसी तरह उपयोगकर्ता तस्वीरों में संयोजित करने की आवश्यकता होगी। और हम डेटा खोने का जोखिम उठाते हैं। खतरा काफी ज्यादा है. और जितनी अधिक बार ऐसी परिस्थितियाँ घटित होती हैं, और इस पूरी श्रृंखला में जितनी अधिक समस्याएँ उत्पन्न होती हैं, यह जोखिम उतना ही अधिक होता है।

इस बारे में कुछ तो करना ही था. और हमने निर्णय लिया कि हमें केवल डेटा का बैकअप लेना होगा। यह वास्तव में एक स्पष्ट और अच्छा समाधान है। हमने क्या किया है?

जब हमारा सर्वर पहले स्टोरेज से जुड़ा था तो ऐसा दिखता था। यह एक मुख्य खंड है, यह सिर्फ एक ब्लॉक डिवाइस है जो वास्तव में ऑप्टिक्स के माध्यम से रिमोट स्टोरेज के लिए एक माउंट का प्रतिनिधित्व करता है।

हमने अभी दूसरा खंड जोड़ा है।

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

यहां हम बस पास में एक अतुल्यकालिक कतार बनाते हैं।

वह बहुत व्यस्त नहीं है. हम जानते हैं कि हमारे पास पर्याप्त रिकॉर्ड नहीं हैं। क्यू MySQL में एक तालिका मात्र है जिसमें "आपको इस फोटो का बैकअप लेना होगा" जैसी पंक्तियाँ लिखी होती हैं। किसी भी बदलाव या अपलोड के साथ, हम एसिंक्रोनस या किसी प्रकार के बैकग्राउंड वर्कर का उपयोग करके मुख्य विभाजन से बैकअप तक कॉपी करते हैं।

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

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

और हमने एक तीसरी डिस्क जोड़ी, जो एक छोटी एसएसडी है, और इसे बफर कहा।

अब यह कैसे काम करता है.

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

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

खैर, और सबसे महत्वपूर्ण बात: हमने डेटा खोना बंद कर दिया।

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

सबसे पहले, यह भौतिक मेजबान के रूप में विफलता का एक बिंदु है जिस पर यह सारी मशीनरी चलती है; यह दूर नहीं हुआ है।

दूसरे, SAN के साथ अभी भी समस्याएँ हैं, उनका भारी रखरखाव आदि बना हुआ है। ऐसा नहीं था कि यह एक महत्वपूर्ण कारक था, लेकिन मैं किसी तरह इसके बिना जीने की कोशिश करना चाहता था।

और हमने तीसरा संस्करण (वास्तव में, वास्तव में दूसरा) बनाया - आरक्षण संस्करण। यह किस तरह का दिखाई दे रहा है?

यह वही था -

हमारी मुख्य समस्याएँ इस तथ्य से हैं कि यह एक भौतिक होस्ट है।

सबसे पहले, हम SAN हटा रहे हैं क्योंकि हम प्रयोग करना चाहते हैं, हम केवल स्थानीय हार्ड ड्राइव आज़माना चाहते हैं।

यह पहले से ही 2014-2015 है, और उस समय डिस्क और एक होस्ट में उनकी क्षमता की स्थिति काफी बेहतर हो गई थी। हमने तय किया कि क्यों न इसे आज़माया जाए।

और फिर हम बस अपना बैकअप विभाजन लेते हैं और इसे भौतिक रूप से एक अलग मशीन में स्थानांतरित करते हैं।

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

यह इसलिए अच्छा काम करता है क्योंकि हमारे पास कुछ रिकॉर्ड हैं। वे। यदि लिखना पढ़ने के बराबर होता, तो शायद हमारे पास किसी प्रकार का नेटवर्क ओवरहेड और समस्याएं होतीं। कम लिखना है, बहुत पढ़ना है - यह विधि अच्छी तरह से काम करती है, यानी। हम शायद ही कभी इन दो सर्वरों के बीच फ़ोटो कॉपी करते हैं।

यदि आप थोड़ा और विस्तार से देखें तो यह कैसे काम करता है।

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

काम थोड़ा और कठिन है.

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

यदि यह वहां नहीं है, तो हम बस अपने पड़ोसी से अनुरोध करते हैं और वहां से इसे प्राप्त करने की गारंटी दी जाती है।

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

हमारी स्थिति में, यह धीरे-धीरे काम नहीं करता है.

हम इस प्रणाली पर मेट्रिक्स का एक समूह एकत्र करते हैं, और ऐसे तंत्र की सशर्त स्मार्ट दर लगभग 95% है। वे। इस बैकअप का अंतराल छोटा है, और इसके कारण हमें लगभग गारंटी है कि फोटो अपलोड होने के बाद हम इसे पहली बार में ही उठा लेंगे और दो बार कहीं नहीं जाना पड़ेगा।

तो हमारे पास और क्या है जो वास्तव में अच्छा है?

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

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

जहाँ तक दोष सहनशीलता का प्रश्न है। दरअसल, हमने मुख्य रूप से इसी के लिए लड़ाई लड़ी। दोष-सहिष्णुता के साथ, यहाँ सब कुछ बढ़िया हो गया।

एक कार खराब हो गई.

कोई बात नहीं! एक सिस्टम इंजीनियर शायद रात में भी नहीं जागेगा, वह सुबह तक इंतजार करेगा, कुछ भी बुरा नहीं होगा।

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

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

इस अतिरेक योजना से क्या निष्कर्ष निकाला जा सकता है?

हमें दोष सहनशीलता प्राप्त हुई।

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

हमें दोहरा पढ़ने का भत्ता मिला।

दोष सहनशीलता के अतिरिक्त यह एक बहुत अच्छा बोनस है।

लेकिन समस्याएं भी हैं. अब हमारे पास इससे संबंधित कुछ सुविधाओं का अधिक जटिल विकास है, क्योंकि सिस्टम अंततः 100% सुसंगत हो गया है।

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

और यहां फिर कुछ द्वंद्व खड़ा हो जाता है.

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

हां, दरअसल, समय के साथ स्थिति में काफी बदलाव आया है और अब इस दृष्टिकोण के कई फायदे हैं। सबसे पहले, हमें बहुत सरल ऑपरेशन मिलता है।

दूसरे, यह अधिक उत्पादक है, क्योंकि हमारे पास ये स्वचालित नियंत्रक या डिस्क शेल्फ़ से कनेक्शन नहीं हैं।

वहां बड़ी मात्रा में मशीनरी है, और ये केवल कुछ डिस्क हैं जिन्हें यहां मशीन पर एक छापे में इकट्ठा किया गया है।

लेकिन नुकसान भी हैं।

यह आज की कीमतों पर भी SAN का उपयोग करने से लगभग 1,5 गुना अधिक महंगा है। इसलिए, हमने अपने पूरे बड़े क्लस्टर को स्थानीय हार्ड ड्राइव वाली कारों में साहसपूर्वक परिवर्तित नहीं करने का निर्णय लिया और एक हाइब्रिड समाधान छोड़ने का निर्णय लिया।

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

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

आइए एक संक्षिप्त सारांश लें कि हमने क्या हासिल किया, हमने क्या संघर्ष किया और क्या हम सफल हुए।

परिणाम

हमारे पास लगभग 33 मिलियन उपयोगकर्ता हैं।

हमारी उपस्थिति के तीन बिंदु हैं - प्राग, मियामी, हांगकांग।

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

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

इसके बाद स्टोरेज लेयर आती है, जिस पर हमारे पास मशीनों के जोड़े के समूह होते हैं जो एक-दूसरे का बैकअप लेते हैं, जब भी फ़ाइलें बदलती हैं तो उन्हें एसिंक्रोनस रूप से एक से दूसरे में कॉपी किया जाता है।

इसके अलावा, इनमें से कुछ मशीनें स्थानीय हार्ड ड्राइव के साथ काम करती हैं।

इनमें से कुछ मशीनें SAN से जुड़ी हैं।

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

हमें क्या मिला और यह सब कैसे विकसित हुआ, इसकी वास्तुकला का यह एक संक्षिप्त अवलोकन है।

कप्तान की ओर से कुछ और युक्तियाँ, बहुत सरल।

सबसे पहले, यदि आप अचानक निर्णय लेते हैं कि आपको अपने फोटो बुनियादी ढांचे में तत्काल सब कुछ सुधारने की आवश्यकता है, तो पहले माप लें, क्योंकि शायद कुछ भी सुधार करने की आवश्यकता नहीं है।

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

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

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

पहले हमने इसे मापा, फिर हमने इसमें सुधार किया।

आगे। हम कैश के साथ पढ़ने, शार्डिंग के साथ लिखने को अनुकूलित करते हैं, लेकिन यह एक स्पष्ट बिंदु है।

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

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

अगला बिंदु. तुरंत आकार बदलने के बारे में।

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

हमने केवल तीन मुख्य आकार छोड़े: छोटे, मध्यम और बड़े। हम बस उस आकार से बाकी सभी चीज़ों को डाउनस्केल कर देते हैं जो उस आकार के पीछे है जो हमसे यूपोर्ट में पूछा गया था, हम बस डाउनस्केल करते हैं और इसे उपयोगकर्ता को दे देते हैं।

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

और वृद्धिशील अतुल्यकालिक बैकअप अच्छा है.

जैसा कि हमारे अभ्यास से पता चला है, यह योजना बदली हुई फ़ाइलों की विलंबित प्रतिलिपि के साथ बढ़िया काम करती है।

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

संपर्कों

» bo0rsh201
» बदू ब्लॉग

यह रिपोर्ट हाई-लोड सिस्टम के डेवलपर्स के सम्मेलन में सर्वश्रेष्ठ भाषणों में से एक की प्रतिलिपि है HighLoad ++. हाईलोड++ 2017 सम्मेलन होने में एक महीने से भी कम समय बचा है।

हमारे पास यह पहले से ही तैयार है सम्मेलन कार्यक्रम, शेड्यूल अब सक्रिय रूप से बनाया जा रहा है।

इस वर्ष हम आर्किटेक्चर और स्केलिंग के विषय पर शोध जारी रखेंगे:

• एक अरब उपयोगकर्ताओं को कैसे सेवा प्रदान करें और टेराबिट ट्रैफ़िक कैसे प्रदान करें / इगोर वासिलिव
• VKontakte व्यक्तिगत संदेश डेटाबेस को स्क्रैच से कैसे फिर से लिखें और बिना डाउनटाइम के इसमें माइग्रेट करें / दिमित्री ईगोरोव
• बिक्री से मृत्यु: कैसे Yandex.Money ने ब्लैक फ्राइडे तक तेजी लाने और जीवित रहने की कोशिश की / अनातोली प्लास्कोव्स्की
• बैंक के फ्रंट-एंड सिस्टम की दोष-सहिष्णु वास्तुकला / रोमन शेखोव्त्सोव, एलेक्सी ग्रोमाचिकोव
• भुगतान प्रणाली वास्तुकला: लगभग उद्यम / फिलिप डेलगाडो

हम इनमें से कुछ सामग्रियों का उपयोग उच्च-लोड सिस्टम विकसित करने पर अपने ऑनलाइन प्रशिक्षण पाठ्यक्रम में भी करते हैं हाईलोड.गाइड विशेष रूप से चयनित पत्रों, लेखों, सामग्रियों, वीडियो की एक श्रृंखला है। हमारी पाठ्यपुस्तक में पहले से ही 30 से अधिक अद्वितीय सामग्रियां शामिल हैं। जोड़ना!

स्रोत: www.habr.com