प्रोडक्शन टेस्ट: नेटफ्लिक्स कैओस ऑटोमेशन प्लेटफॉर्म

उत्पादन में टेस्ट में हमारी जून की बैठक अराजकता इंजीनियरिंग के लिए समर्पित थी। लीड सॉफ्टवेयर इंजीनियर नोरा जोन्स ने शुरू किया कि नेटफ्लिक्स उत्पादन में परीक्षण कैसे करता है।

"कैओस इंजीनियरिंग ... ये उत्पादन में प्रयोग कर रहे हैं इससे पहले कि वे ग्राहकों के लिए एक सेवा अनुपयुक्त बनाने के लिए एक प्रणाली में कमजोरियों को खोजने के लिए। नेटफ्लिक्स में, हम उन्हें ChAP नामक एक उपकरण का उपयोग करके चलाते हैं ... [यह] कमजोरियों को पकड़ता है और हमें सेवाओं और उत्पादन में विफलताओं को लागू करने की अनुमति देता है। ये विफलताएँ पूर्ण आउटेज पर जाने से पहले इन सेवाओं के बारे में मान्यताओं की पुष्टि करती हैं। "

एक प्रस्तुति देखें (या प्रतिलेख पढ़ें) कि कैसे उनकी टीम उपयोगकर्ताओं की मदद करती है - नेटफ्लिक्स इंजीनियर - उत्पादन में सुरक्षित रूप से परीक्षण करते हैं और अपने सिस्टम में कमजोरियों की पहचान करते हैं।

प्रतिलिपि

मैं आज यहां आकर बहुत खुश हूं।

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

हमारा लक्ष्य सेवाओं में कमजोरियों को खोजकर समयोपरि बढ़ाना है। हम उत्पादन में प्रयोगों के माध्यम से ऐसा करते हैं। टीम को विश्वास है कि कमजोरियों और समस्याओं की एक निश्चित श्रेणी का पता वास्तविक यातायात पर ही लगाया जा सकता है।

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

प्रत्येक रेखा एक निर्भरता का प्रतिनिधित्व करती है, और इन रेखाओं का विस्तार किया जा सकता है। यहाँ एक दिलचस्प उदाहरण है।



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

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





आपको कुछ संदर्भ देने के लिए, दूरस्थ Hystrix कमांड में नमूना-रेस्ट-क्लाइंट और नमूना-रेस्ट-क्लाइंट दोनों शामिल हैं। GET। Hystrix मध्यांतर 500 मिलीसेकंड पर सेट है। सैंपल-रेस्ट-क्लाइंट.गेट में एक रिट्री के साथ 200 एमएस का टाइमआउट है, जो अच्छा है, क्योंकि कुल 400 मिलीसेकंड है, जो हिस्ट्रिक्स सीमा में फिट बैठता है। दूसरे क्लाइंट में एक रिट्री के साथ 100 और 600 के टाइमआउट हैं।

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

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

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

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

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

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

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

आपका धन्यवाद