🎆 🌮 📬 दोष इंजेक्शन: आपका सिस्टम अविश्वसनीय है यदि आपने इसे तोड़ने की कोशिश नहीं की है 🔴 ✋🏼 ❇️

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

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

हमें यह सब क्यों चाहिए?

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

ज्ञापन क्या है? Memcached - कुंजी द्वारा संग्रहीत वस्तुओं के उपयोग के साथ यादृच्छिक अभिगम स्मृति में एक हैश तालिका। उदाहरण के लिए, आपको एक उपयोगकर्ता प्रोफ़ाइल प्राप्त करने की आवश्यकता है। आवेदन पहुंच (2) को याद किया। यदि इसमें कोई ऑब्जेक्ट है, तो यह तुरंत उपयोगकर्ता को वापस कर दिया जाता है। यदि कोई वस्तु नहीं है, तो डेटाबेस (3) के लिए एक अपील की जाती है, ऑब्जेक्ट का गठन किया जाता है और मेमकाटेड (4) में डाल दिया जाता है। फिर, अगली कॉल पर, हमें अब डेटाबेस के लिए संसाधन-महंगा कॉल करने की आवश्यकता नहीं है - हमें रैम से तैयार वस्तु प्राप्त होगी - मेमेकैच्ड।

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

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

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

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

नई Sberbank आईटी प्रणाली

कुछ साल पहले, Sberbank ने एक नया IT सिस्टम बनाना शुरू किया। क्यों? सेंट्रल बैंक की वेबसाइट के आंकड़े इस प्रकार हैं:

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

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

मैं इस तकनीक की कुछ विशेषताओं को सूचीबद्ध करूंगा:

रैम में स्टोरेज और डाटा प्रोसेसिंग
डिस्क भंडारण
एसक्यूएल समर्थन
वितरित कार्य निष्पादन
क्षैतिज स्केलिंग

प्रौद्योगिकी अपेक्षाकृत नई है, इसलिए इसे विशेष ध्यान देने की आवश्यकता है।

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

क्लस्टर के अंदर तथाकथित कोशिकाओं में विभाजित है। एक सेल 8 नोड्स है। प्रत्येक डेटा सेंटर में 4 नोड होते हैं।

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

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

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

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

अद्यतन खो दिया है

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

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

CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC); try (IgniteCache<Integer, Account> cache = ignite.getOrCreateCache(cfg)) {   for (int i = 1; i <= ENTRIES_COUNT; i++)       cache.put(i, new Account(i, 100));   System.out.println("Accounts before transfers");   printAccounts(cache);   printTotalBalance(cache);   for (int i = 1; i <= 100; i++) {       int pairOfAccounts[] = getPairOfRandomAccounts();       transferMoney(cache, pairOfAccounts[0], pairOfAccounts[1]);   } } ... private static void transferMoney(IgniteCache<Integer, Account> cache, int fromAccountId, int toAccountId) {   Account fromAccount = cache.get(fromAccountId);   Account toAccount = cache.get(toAccountId);   int amount = getRandomAmount(fromAccount.balance);   if (amount < 1) {       return;   }   fromAccount.withdraw(amount);   toAccount.deposit(amount);   cache.put(fromAccountId, fromAccount);   cache.put(toAccountId, toAccount); }

फिर हम इन 10 खातों के बीच 100 यादृच्छिक मनी ट्रांसफर करते हैं। उदाहरण के लिए, $ 50 को खाता A से दूसरे खाते B में स्थानांतरित किया जाता है। योजनाबद्ध रूप से, इस प्रक्रिया को निम्नानुसार दर्शाया जा सकता है:

प्रणाली बंद है, स्थानान्तरण केवल आंतरिक रूप से किए जाते हैं, अर्थात। कुल शेष $ 1000 के बराबर होना चाहिए।

एप्लिकेशन लॉन्च करें।

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

 CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC); cfg.setCacheMode(CacheMode.PARTITIONED); cfg.setIndexedTypes(Integer.class, Account.class); try (IgniteCache<Integer, Account> cache = ignite.getOrCreateCache(cfg)) {  // Initializing the cache.  for (int i = 1; i <= ENTRIES_COUNT; i++)    cache.put(i, new Account(i, 100));  System.out.println("Accounts before transfers");  System.out.println();  printAccounts(cache);  printTotalBalance(cache);  IgniteRunnable run1 = new MyIgniteRunnable(cache, ignite,1);  IgniteRunnable run2 = new MyIgniteRunnable(cache, ignite,2);  List<IgniteRunnable> arr = Arrays.asList(run1, run2);  ignite.compute().run(arr); } ... private void transferMoney(int fromAccountId, int toAccountId) {  Account fromAccount = cache.get(fromAccountId);  Account toAccount = cache.get(toAccountId);  int amount = getRandomAmount(fromAccount.balance);  if (amount < 1) {      return;  }  int fromAccountBalanceBeforeTransfer = fromAccount.balance;  int toAccountBalanceBeforeTransfer = toAccount.balance;  fromAccount.withdraw(amount);  toAccount.deposit(amount);  cache.put(fromAccountId, fromAccount);  cache.put(toAccountId, toAccount); }

कुल शेष $ 1296 है। ग्राहक खुश होते हैं, बैंक को नुकसान होता है। ऐसा क्यों हुआ?

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

एप्लिकेशन को काम करने के लिए जैसा कि होना चाहिए, हमारे डेटाबेस को ACID लेनदेन का समर्थन करना चाहिए और हमारे कोड को इसे ध्यान में रखना चाहिए।

आइए हमारे आवेदन के लिए एसीआईडी गुणों को देखें यह समझने के लिए कि यह इतना महत्वपूर्ण क्यों है।

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

इसलिए, ट्रांसफर मेनी विधि में, हम लेन-देन के भीतर धन हस्तांतरण करेंगे।

 private void transferMoney(int fromAccountId, int toAccountId) {  try (Transaction tx = ignite.transactions().txStart()) {      Account fromAccount = cache.get(fromAccountId);      Account toAccount = cache.get(toAccountId);      int amount = getRandomAmount(fromAccount.balance);      if (amount < 1) {          return;      }      int fromAccountBalanceBeforeTransfer = fromAccount.balance;      int toAccountBalanceBeforeTransfer = toAccount.balance;          fromAccount.withdraw(amount);      toAccount.deposit(amount);          cache.put(fromAccountId, fromAccount);      cache.put(toAccountId, toAccount);          tx.commit();  } catch (Exception e){      e.printStackTrace();  } }

एप्लिकेशन लॉन्च करें।

हम्म। लेन-देन में मदद नहीं मिली। कुल शेष $ 6951 है! इस एप्लिकेशन व्यवहार के साथ समस्या क्या है?

सबसे पहले, उन्होंने एटोमिक कैश प्रकार चुना, अर्थात। बिना ACID लेनदेन समर्थन:

 CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.TOMIC);

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

 try (Transaction tx = ignite.transactions().txStart( ,  )) { Account fromAccount = cache.get(fromAccountId); Account toAccount = cache.get(toAccountId); ...  tx.commit(); }

आप LOCK METHOD पैरामीटर के मान के रूप में PESSIMISTIC (निराशावादी लॉक) या OPTIMISTIC (आशावादी लॉक) का उपयोग कर सकते हैं। वे अवरुद्ध करने के तत्काल में भिन्न होते हैं। PESSIMISTIC का उपयोग करते समय, ताला पहली बार पढ़ने / लिखने पर लगाया जाता है और लेनदेन के प्रतिबद्ध होने तक आयोजित किया जाता है। उदाहरण के लिए, जब निराशावादी लॉक के साथ लेन-देन खाता ए से खाता बी में हस्तांतरण करता है, तो अन्य लेनदेन तब तक इन खातों के मूल्यों को पढ़ने या लिखने में सक्षम नहीं होंगे जब तक कि हस्तांतरण करने के लिए लेनदेन प्रतिबद्ध नहीं है। यह स्पष्ट है कि यदि अन्य लेनदेन ए और बी खातों का उपयोग करना चाहते हैं, तो वे लेनदेन को पूरा करने के लिए इंतजार करने के लिए मजबूर होते हैं, जिसका आवेदन के समग्र प्रदर्शन पर नकारात्मक प्रभाव पड़ता है। आशावादी लॉकिंग अन्य लेनदेन के लिए डेटा तक पहुंच को प्रतिबंधित नहीं करता है, हालांकि, प्रतिबद्ध के लिए लेनदेन की तैयारी के चरण के दौरान (तैयार चरण, अपाचे इग्नाइट 2PC प्रोटोकॉल का उपयोग करता है), एक जांच की जाएगी - क्या अन्य लेनदेन के साथ डेटा बदल गया है? और यदि परिवर्तन हुआ, तो लेनदेन रद्द कर दिया जाएगा। प्रदर्शन के मामले में, OPTIMISTIC तेजी से चलेगा, लेकिन उन अनुप्रयोगों के लिए अधिक उपयुक्त है जहां डेटा के साथ कोई प्रतिस्पर्धा नहीं है।

इन्सुलेशन स्तर पैरामीटर एक दूसरे से लेनदेन के अलगाव की डिग्री निर्धारित करता है। SQL ANSI / ISO मानक 4 प्रकार के अलगाव को परिभाषित करता है, और प्रत्येक अलगाव स्तर के लिए, एक ही लेन-देन परिदृश्य विभिन्न परिणामों को जन्म दे सकता है।

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

कई आधुनिक DBMS (Microsoft SQL Server, PostgreSQL और Oracle) के लिए, डिफ़ॉल्ट आइसोलेशन स्तर READ_COMMITTED है। हमारे उदाहरण के लिए, यह घातक होगा, क्योंकि यह हमें खोए हुए अपडेट से नहीं बचाएगा। परिणाम वही होगा जैसे हमने लेन-देन का उपयोग नहीं किया था।

अपाचे से लेन-देन के दस्तावेज प्रज्वलित करें , यह हमारे लिए लॉक विधि और अलगाव स्तर के संयोजन का उपयोग करने के लिए उपयुक्त है:

PASSIMISTIC REPEATABLE_READ - लॉक को डेटा के पहले पढ़ने या लिखने पर लगाया जाता है और पूरा होने तक आयोजित किया जाता है।
PESSIMISTIC SERIALIZABLE - PESSIMISTIC REPEATABLE_READ के समान कार्य करता है
वैकल्पिक अनुक्रमिक - पहले पढ़ने के बाद प्राप्त डेटा का संस्करण याद किया जाता है, और अगर यह संस्करण प्रतिबद्ध के लिए तैयारी के चरण के दौरान अलग है (डेटा को किसी अन्य लेनदेन द्वारा बदल दिया गया था), तो लेनदेन रद्द कर दिया जाएगा। आइए इस विकल्प का प्रयास करें।

 private void transferMoney(int fromAccountId, int toAccountId) { try (Transaction tx = ignite.transactions().txStart(OPTIMISTIC, SERIALIZABLE)) { Account fromAccount = cache.get(fromAccountId); Account toAccount = cache.get(toAccountId); int amount = getRandomAmount(fromAccount.balance); if (amount < 1) { return; } int fromAccountBalanceBeforeTransfer = fromAccount.balance; int toAccountBalanceBeforeTransfer = toAccount.balance; fromAccount.withdraw(amount); toAccount.deposit(amount); cache.put(fromAccountId, fromAccount); cache.put(toAccountId, toAccount); tx.commit(); } catch (Exception e){ e.printStackTrace(); } }

उम्मीद के मुताबिक हुर्रे को $ 1,000 मिले। तीसरे प्रयास पर।

लोड के तहत परीक्षण

अब हम अपने परीक्षण को अधिक यथार्थवादी बनाएंगे - हम लोड के तहत परीक्षण करेंगे। और एक अतिरिक्त सर्वर नोड जोड़ें। तनाव परीक्षण करने के लिए कई उपकरण हैं, Sberbank में हम HP प्रदर्शन केंद्र का उपयोग करते हैं। यह एक काफी शक्तिशाली उपकरण है, जो 50 से अधिक प्रोटोकॉल का समर्थन करता है, बड़ी टीमों के लिए डिज़ाइन किया गया है और इसमें बहुत पैसा खर्च होता है। मैंने JMeter पर अपना उदाहरण लिखा - यह मुफ़्त है और हमारी समस्या को 100% हल करता है। मैं जावा में कोड को फिर से लिखना नहीं चाहूंगा, इसलिए मैं JSR223 नमूना का उपयोग करूंगा।

हम अपने एप्लिकेशन की कक्षाओं से एक JAR संग्रह बनाएंगे और इसे परीक्षण योजना में लोड करेंगे। कैश बनाने और पॉप्युलेट करने के लिए, CreateCache क्लास चलाएं। कैश को इनिशियलाइज़ करने के बाद, आप JMeter स्क्रिप्ट को चला सकते हैं।

सब कुछ शांत है, $ 1,000 मिला है।

क्लस्टर नोड आपातकालीन शटडाउन

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

यह क्या है? 553 डॉलर है। ग्राहक भयभीत हैं, बैंक प्रतिष्ठा की हानि करता है। इस बार हमने क्या गलत किया है?

अपाचे इग्नाइट में कैश प्रकार हैं:

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

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

 CacheConfiguration<Integer, Account> cfg = new CacheConfiguration<>(CACHE_NAME); cfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL); cfg.setCacheMode(CacheMode.PARTITIONED); cfg.setBackups(1);

हमने एप्लिकेशन लॉन्च किया। मैं आपको याद दिलाता हूं कि स्थानांतरण से पहले हमारे पास $ 1000 हैं। हम शुरू करते हैं और ऑपरेशन के दौरान हम नोड्स में से एक को "बुझा" देते हैं

Visor उपयोगिता में, हम $ 1000 का कुल बैलेंस पाने के लिए SQL क्वेरी बनाते हैं। सब कुछ महान काम किया!

विश्वसनीयता के मामले

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

इसके अलावा, यह पूरी तरह से अलग कारणों से हो सकता है। उदाहरण के लिए, कोई अनुप्रयोग क्रैश हो सकता है, JVM क्रैश, OS क्रैश या हार्डवेयर विफलता।

हमने विफलताओं के सभी संभावित मामलों को 4 समूहों में विभाजित किया है:

उपकरण
नेटवर्क
सॉफ्टवेयर
अन्य

वे उनके लिए परीक्षण लेकर आए और उन्हें विश्वसनीयता के मामले कहा। एक विशिष्ट विश्वसनीयता के मामले में परीक्षणों से पहले प्रणाली की स्थिति का वर्णन होता है, विफलता को पुन: पेश करने के लिए कदम और विफलता के दौरान अपेक्षित व्यवहार का विवरण।

विश्वसनीयता के मामले: उपकरण

इस समूह में ऐसे मामले शामिल हैं:

बिजली की विफलता
हार्ड ड्राइव तक पहुंच का पूरा नुकसान
एक हार्ड ड्राइव पहुंच पथ की विफलता
सीपीयू, रैम, डिस्क, नेटवर्क लोड

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

और क्या हो सकता है? सेल में रैक का नुकसान।

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

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

विश्वसनीयता के मामले: नेटवर्क

नेटवर्क विखंडन से संबंधित मामलों का परीक्षण करने के लिए, हम iptables का उपयोग करते हैं। और NetEm उपयोगिता का उपयोग करके हम अनुकरण करते हैं:

नेटवर्क विभिन्न वितरण फ़ंक्शन के साथ देरी करता है
पैकेट खोना
पैकेट रिट्री
पैकेट को फिर से चालू करना
पैकेट विरूपण

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

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

हमारे मामले में, विभाजित मस्तिष्क की स्थिति को सही ढंग से नियंत्रित किया जाना चाहिए। एक ग्रिड एक विभाजित मस्तिष्क की पहचान करता है - एक क्लस्टर को दो भागों में विभाजित करता है। एक आधा रीड मोड में चला जाता है। यह वह आधा है जहां अधिक जीवित नोड हैं या समन्वयक स्थित है (क्लस्टर में सबसे पुराना नोड)।

विश्वसनीयता के मामले: सॉफ्टवेयर

ये विभिन्न उप-प्रणालियों की विफलता से संबंधित मामले हैं:

डीपीएल ओआरएम - डेटा एक्सेस मॉड्यूल, जैसे हाइबरनेट ओआरएम
इंटरमॉड्यूलर ट्रांसपोर्ट - मॉड्यूल (माइक्रोसर्विसेज) के बीच मैसेजिंग
लॉगिंग सिस्टम
पहुंच प्रणाली
अपाचे इग्नाइट क्लस्टर
...

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

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

अन्य मामले

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

डेटा के स्नैपशॉट (बैकअप) बनाने की उपयोगिता - पूर्ण और वृद्धिशील स्नैपशॉट का परीक्षण।
समय में एक विशिष्ट बिंदु पर रिकवरी - PITR (पॉइंट-इन-टाइम रिकवरी) तंत्र।

गलती इंजेक्शन के लिए उपयोगिताएँ

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

चौखटे:

कॉन्फ़िगरेशन प्रबंधन:

लिनक्स उपयोगिताओं:

NetEm (tc)
तनाव एनजी
iperf
मारना -9
iptables

लोड परीक्षण उपकरण:

JMeter

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

दोष इंजेक्शन: आपका सिस्टम अविश्वसनीय है यदि आपने इसे तोड़ने की कोशिश नहीं की है