इवान क्रुगलोव, प्रिंसिपल डेवलपर के साथ साक्षात्कार: सेवा मेष और "गैर-मानक" Booking.com उपकरण

इवान क्रुग्लोव , Booking.com के प्रिंसिपल डेवलपर, SRE ने थीम SRE के साथ SlOmer DevOps पर बात की, और बात करने के बाद, एक कप कॉफ़ी के ऊपर Kubernetes, Service Mesh, ओपन सोर्स और नॉन-स्टैंडर्ड सॉल्यूशंस पर बात करने के लिए सहमत हुए।

चूंकि SRE का विषय बहुत व्यापक हो गया था, इवान और उनके सहयोगी बेन टायलर, Booking.com के प्रिंसिपल डेवलपर, स्लम SRE के वक्ता बनने के लिए सहमत हुए , जो 3-5 फरवरी, 2020 को आयोजित किया जाएगा । यह एसएलआई / एसएलओ / त्रुटि बजट, पोस्टमार्टम विश्लेषण, आईटी घटनाओं के प्रभावी उन्मूलन, विश्वसनीय प्रणालियों के निर्माण (निगरानी और सतर्क, सुंदर गिरावट, विफलता-इंजेक्शन, क्षमता योजना, कैस्केडिंग विफलताओं को रोकने) के सिद्धांत और अभ्यास पर चर्चा करेगा। )।

और अब इवान को एक शब्द।

हाल ही में आपके लिए एक दिलचस्प पेशेवर चुनौती क्या रही है?

पिछले दो वर्षों में मैं दो चीजें कर रहा हूं। पहला: Booking.com के अंदरूनी बादल। इसे कुबेरनेट्स पर बनाया गया है। इस अवसर पर, मेरे पास हाईलोड पर एक लंबी और व्यापक रिपोर्ट थी।

हमारे पास एक लंबा और दिलचस्प तरीका था कि हमने अपना क्लाउड कैसे बनाया। यह मेरी पिछली परियोजना है, जिसे मैंने एक सहयोगी को छोड़ दिया है।

अब मैं Service Mesh नामक एक विषय के साथ काम कर रहा हूँ। यह वास्तव में, एक गर्म विषय है, क्योंकि बिग डेटा और कुबेरनेट एक समय में थे।

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

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

और क्या आपको लगता है कि यह तकनीक भविष्य है?

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

यही है, एक ही सफलता की तकनीक जैसा कि एक बार था, और अब कुबेरनेट हैं?

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

क्या आप निकट भविष्य में इस तकनीक का विकास करेंगे?

मैं अपने लिए बोल सकता हूं। मैं बुनियादी ढांचे में शामिल हूं। और बुनियादी ढांचे के संदर्भ में, अगले कुछ वर्षों में, यह मुख्य विषयों में से एक होगा - कुबेरनेट्स और सर्विस मेष।

क्या वे समानांतर विकसित होंगे?

निश्चित रूप से, क्योंकि वे एक दूसरे के पूरक हैं। कुबेरनेट्स रनटाइम करता है। सर्विस मेष इंटरऑपरेबिलिटी प्रदान करता है।

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

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

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

इस पूरी विविधता का प्रत्येक घटक विफल हो सकता है।

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

और आप इसे कैसे हल करते हैं?

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

आपकी कंपनी की विश्वसनीयता और उपलब्धता मीट्रिक क्या हैं?

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

जब आप वहां काम करने आए तो Booking.com पर आपने कौन से अनोखे समाधान देखे? या सब कुछ मानक है?

नहीं। हमारे पास बहुत सी चीजें हैं जो "गैर-मानक" हैं। आइए बताते हैं कि यह उद्धरण चिह्नों में मानक क्यों नहीं है। गैर-मानक कहां से आता है ... गैर-मानक अक्सर इस तथ्य से आता है कि कंपनी को बाजार की तुलना में पहले एक समस्या का सामना करना पड़ा, और इसलिए कोई "मानक" समाधान नहीं है। इस संबंध में, Booking.com, एक कंपनी होने के नाते जो 1997 से बाजार में काम कर रही है और एक ऐसे आकार में विकसित हुई है, एक समय में कई समस्याओं का सामना करना पड़ा, जो हल नहीं हुए थे।

उदाहरण के लिए, Google। मेरी टिप्पणियों के अनुसार, यह कुछ ऐसा दिखता है। अंदर वे प्रमुख विकास करते हैं, जो पांच या दस वर्षों में सार्वजनिक रूप से सामने आते हैं। उदाहरण के लिए, मैंने Google के उन लोगों से बात की, जिन्होंने लिनक्स कर्नेल को पैच किया था। तब मुझे टीसीपी स्टैक में कुछ समस्याएं थीं। मैं उन्हें बताता हूं: “यह स्पष्ट रूप से मुख्य समस्या है। आप इससे कैसे लड़ेंगे? ” वे कहते हैं: “आह, इसलिए हमारे पास एक गिरी हुई गिरी है। यहां हम सेटिंग को ट्विक कर सकते हैं। 2013 में, हमने इसे पैच किया। और हम इसे 2018 में ओपन-सोर्स में रोल कर रहे हैं। ”

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

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

उदाहरण के लिए, कौन सा?

प्रौद्योगिकी ब्रांड, निष्ठा, आसान ऑन-बोर्डिंग। वे महत्वपूर्ण हैं।

आप उन्हें सीधे गिन नहीं सकते

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

इस सवाल पर लौटते हुए, Booking.com में कितना मानक और गैर-मानक है। मैं यह कहूंगा कि बहुमत गैर-मानक नहीं है, लेकिन बहुत कुछ है। क्योंकि हम उन समस्याओं को हल कर रहे थे जो अभी भी बाजार में अज्ञात थीं, या अन्य कंपनियां केवल यात्रा की शुरुआत में थीं। बस कंपनी के लिए यह आसान और तेज है, और खुद के लिए समस्याओं को हल करने के लिए सस्ता है।

पुनश्च : एक प्रस्तुति में एसआरई के पूरे विषय को कवर करना संभव नहीं है। साधन ही नहीं है, दृष्टिकोण का दर्शन भी है। इसलिए, हमने इस विषय के लिए एक गहन गहन स्लम एसआरई पर प्रकाश डाला , जो 3-5 फरवरी, 2020 को आयोजित किया जाएगा । इवान क्रुग्लोव होंगे, जो कि Booking.com के प्रमुख डेवलपर हैं, उनके सहयोगी बेन टायलर, Booking.com के प्रिंसिपल डेवलपर, एडुआर्ड मेदवेदेव , टंगस्टन लैब्स में सीटीओ, यूजीन वरवा, Google के ब्रॉड-प्रोफाइल डेवलपर हैं।