क्यूकॉन सम्मेलन। मास्टरिंग कैओस: द नेटफ्लिक्स गाइड टू माइक्रोसर्विसेज। भाग 4

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

क्यूकॉन सम्मेलन। मास्टरिंग कैओस: द नेटफ्लिक्स गाइड टू माइक्रोसर्विसेज। भाग 1
क्यूकॉन सम्मेलन। मास्टरिंग कैओस: द नेटफ्लिक्स गाइड टू माइक्रोसर्विसेज। भाग 2
क्यूकॉन सम्मेलन। मास्टरिंग कैओस: द नेटफ्लिक्स गाइड टू माइक्रोसर्विसेज। भाग 3

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

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

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

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

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

इन परिवर्तनों की लागत काफी बड़ी है और इसमें निम्नलिखित कारक शामिल हैं:

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

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

हम लगातार उन सिद्ध तकनीकों का उपयोग करने के अवसरों की तलाश में थे जो एक ही स्थान पर और अन्य समान स्थितियों में खुद को साबित कर चुकी थीं।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

थोड़ा विज्ञापन

हमारे साथ रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक रोचक सामग्री देखना चाहते हैं? आदेश देकर या मित्रों को अनुशंसा करके हमारा समर्थन करें, डेवलपर्स के लिए क्लाउड VPS $4.99 से शुरू, प्रवेश स्तर के सर्वरों का एक अनूठा एनालॉग, जिसका आविष्कार हमने आपके लिए किया था: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps के बारे में पूरी सच्चाई $19 से या सर्वर कैसे साझा करें? (RAID1 और RAID10 के साथ उपलब्ध, 24 कोर तक और 40GB DDR4 तक)।

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com