कुबेरनेट्स के लिए टिंडर की चाल

द्वारा लिखित: क्रिस ओ'ब्रायन, इंजीनियरिंग प्रबंधक | क्रिस थॉमस, इंजीनियरिंग प्रबंधक | Jinyong ली, वरिष्ठ सॉफ्टवेयर इंजीनियर | द्वारा संपादित: कूपर जैक्सन, सॉफ्टवेयर इंजीनियर

क्यों

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

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

यह आसान नहीं था। 2019 की शुरुआत में हमारे प्रवास के दौरान, हम अपने कुबेरनेट्स क्लस्टर के भीतर महत्वपूर्ण द्रव्यमान तक पहुँच गए और यातायात की मात्रा, क्लस्टर आकार और डीएनएस के कारण विभिन्न चुनौतियों का सामना करने लगे। हमने 200 सेवाओं को स्थानांतरित करने और 1,000 नोड्स, 15,000 पॉड्स, और 48,000 रनिंग कंटेनरों के पैमाने पर कुबेरनेट क्लस्टर चलाने के लिए दिलचस्प चुनौतियों का समाधान किया।

किस तरह

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

कुबेरनेट्स के लिए भवन चित्र

कुबेरनेट क्लस्टर में चल रहे माइक्रोसर्विस के लिए 30 से अधिक स्रोत कोड रिपॉजिटरी हैं। इन रिपॉजिटरी में कोड अलग-अलग भाषाओं में लिखे जाते हैं (जैसे, Node.js, Java, Scala, Go) एक ही भाषा के लिए कई रनटाइम वातावरण के साथ।

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

चित्रा 1-1 बिल्डर कंटेनर के माध्यम से मानकीकृत निर्माण प्रक्रिया

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

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

कुछ सेवाओं के लिए, हमें रन-टाइम वातावरण (जैसे, Node.js bcrypt लाइब्रेरी स्थापित करने से प्लेटफ़ॉर्म-विशिष्ट बाइनरी कलाकृतियों का निर्माण होता है) के साथ संकलन-समय के माहौल से मेल करने के लिए बिल्डर के भीतर एक और कंटेनर बनाने की आवश्यकता थी। संकलन-समय की आवश्यकताएं सेवाओं में भिन्न हो सकती हैं और अंतिम डॉकरीफाइल मक्खी पर बना है।

कुबेरनेट्स क्लस्टर वास्तुकला और प्रवासन

क्लस्टर आकार

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

हम पर बसे:

  • निगरानी के लिए m5.4xlarge (प्रोमेथियस)
  • C5.4 Node.js वर्कलोड (एकल-थ्रेडेड वर्कलोड) के लिए बढ़ाना
  • जावा और गो के लिए c5.2xlarge (बहु-थ्रेडेड वर्कलोड)
  • नियंत्रण विमान के लिए c5.4xlarge (3 नोड्स)

प्रवास

कुबेरनेट्स के लिए हमारी विरासत बुनियादी ढांचे से प्रवास के लिए तैयारी के चरणों में से एक विशिष्ट वर्चुअल प्राइवेट क्लाउड (VPC) सबनेट में बनाए गए नए इलास्टिक लोड बैलेंसर (ELB) को इंगित करने के लिए मौजूदा सेवा-से-सेवा संचार को बदलना था। इस सबनेट को Kubernetes VPC को दिया गया था। इसने हमें सेवा निर्भरता के लिए विशिष्ट आदेश के संबंध में बिना किसी माड्यूल के माइग्रेट करने के लिए मॉड्यूल की अनुमति दी।

इन समापन बिंदुओं को भारित DNS रिकॉर्ड सेटों का उपयोग करके बनाया गया था, जिसमें प्रत्येक नए ELB की ओर इशारा करने वाला CNAME था। कटओवर करने के लिए, हमने एक नया रिकॉर्ड जोड़ा, नई कुबेरनेट्स सेवा ईएलबी की ओर इशारा करते हुए, 0. के वजन के साथ, हमने रिकॉर्ड करने के लिए सेट टू टाइम (लाइव (टीटीएल)) को सेट किया। 0. पुराने और नए वज़न को फिर धीरे-धीरे समायोजित किया गया अंत में नए सर्वर पर 100% के साथ समाप्त होता है। कटओवर पूरा होने के बाद, TTL को कुछ और उचित के लिए सेट किया गया था।

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

सीख

नेटवर्क फैब्रिक सीमाएँ

8 जनवरी, 2019 की सुबह के शुरुआती घंटों में टिंडर के प्लेटफॉर्म को लगातार नुकसान उठाना पड़ा। उस सुबह प्लेटफ़ॉर्म लेटेंसी में असंबद्ध वृद्धि के जवाब में, क्लस्टर पर पॉड और नोड काउंट को स्केल किया गया था। इसके परिणामस्वरूप हमारे सभी नोड्स पर ARP कैश की थकावट हो गई।

ARP कैश के लिए प्रासंगिक तीन लिनक्स मूल्य हैं:

श्रेय

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

हम कुबेरनेट्स में अपने नेटवर्क फैब्रिक के रूप में फलालैन का उपयोग करते हैं। पैकेट VXLAN के माध्यम से अग्रेषित किए जाते हैं। VXLAN एक लेयर 3 नेटवर्क पर 2 परत उपरिशायी योजना है। यह लेयर 2 डी सेगमेंट का विस्तार करने के लिए साधन प्रदान करने के लिए मैक एड्रेस-इन-यूजर डेटाग्राम प्रोटोकॉल (मैक-इन-यूडीपी) एनकैप्सुलेशन का उपयोग करता है। भौतिक डेटा केंद्र नेटवर्क पर परिवहन प्रोटोकॉल IP प्लस UDP है।

चित्रा 2-1 फलालैन आरेख (क्रेडिट)

चित्र 2-2 VXLAN पैकेट (क्रेडिट)

प्रत्येक कुबेरनेट्स कार्यकर्ता नोड एक बड़ा / 9 ब्लॉक से बाहर वर्चुअल वर्चुअल स्पेस का अपना / 24 आवंटित करता है। प्रत्येक नोड के लिए, यह 1 मार्ग तालिका प्रविष्टि, 1 एआरपी तालिका प्रविष्टि (फलालैन.1 इंटरफ़ेस पर), और 1 अग्रेषण डेटाबेस (FDB) प्रविष्टि में परिणाम करता है। ये तब जोड़े जाते हैं जब कार्यकर्ता नोड पहले लॉन्च होता है या प्रत्येक नए नोड की खोज की जाती है।

इसके अलावा, नोड-टू-पॉड (या पॉड-टू-पॉड) संचार अंततः eth0 इंटरफ़ेस (ऊपर फ़्लेनेल रेखा चित्र में दर्शाया गया है) पर बहता है। यह प्रत्येक संबंधित नोड स्रोत और नोड गंतव्य के लिए एआरपी तालिका में एक अतिरिक्त प्रविष्टि का परिणाम देगा।

हमारे पर्यावरण में, इस प्रकार का संचार बहुत आम है। हमारे Kubernetes सेवा ऑब्जेक्ट के लिए, एक ELB बनाया जाता है और Kubernetes ELB के साथ प्रत्येक नोड को पंजीकृत करता है। ELB पॉड के प्रति जागरूक नहीं है और चयनित नोड पैकेट का अंतिम गंतव्य नहीं हो सकता है। ऐसा इसलिए है क्योंकि जब नोड ELB से पैकेट प्राप्त करता है, तो यह सेवा के लिए अपने iptables नियमों का मूल्यांकन करता है और बेतरतीब ढंग से दूसरे नोड पर एक पॉड का चयन करता है।

आउटेज के समय, क्लस्टर में कुल 605 नोड्स थे। ऊपर उल्लिखित कारणों के लिए, यह डिफ़ॉल्ट gc_thresh3 मान को ग्रहण करने के लिए पर्याप्त था। एक बार ऐसा होने पर, न केवल पैकेट गिराए जा रहे हैं, बल्कि एआरपी टेबल से पूरे फ्लैनेल / 24 एस वर्चुअल एड्रेस स्पेस गायब हैं। फली संचार के लिए नोड और DNS लुकअप विफल। (DNS को क्लस्टर के भीतर होस्ट किया गया है, जैसा कि इस लेख में बाद में अधिक विस्तार से बताया जाएगा।)

हल करने के लिए, gc_thresh1, gc_thresh2, और gc_thresh3 मान बढ़ाए जाते हैं और फ़्लेनेल को लापता नेटवर्क को फिर से पंजीकृत करने के लिए पुनः आरंभ किया जाना चाहिए।

स्केल पर अनपेक्षित रूप से DNS चलाना

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

जब हमने कुबेरनेट्स में अधिक से अधिक सेवाओं की शुरुआत की, तो हमने खुद को एक DNS सेवा चलाते हुए पाया जो प्रति सेकंड 250,000 अनुरोधों का जवाब दे रहा था। हम अपने अनुप्रयोगों के भीतर रुक-रुक कर और प्रभावी DNS लुकअप टाइमआउट का सामना कर रहे थे। यह एक संपूर्ण ट्यूनिंग प्रयास और DNS प्रदाता द्वारा CoreDNS परिनियोजन के लिए स्विच करने के बावजूद हुआ, जो कि एक बार में 120 कॉर्ड का उपभोग करने वाली 1,000 पॉड्स पर पहुंच गया था।

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

समस्या स्रोत और गंतव्य नेटवर्क पता अनुवाद (SNAT और DNAT) और बाद में सम्मिलन तालिका में प्रविष्टि के दौरान होती है। आंतरिक रूप से चर्चा करने और समुदाय द्वारा प्रस्तावित एक वर्कअराउंड को कार्यकर्ता नोड पर DNS को स्थानांतरित करना था। इस मामले में:

  • SNAT आवश्यक नहीं है, क्योंकि यातायात नोड पर स्थानीय रूप से रहता है। यह eth0 इंटरफ़ेस के पार प्रेषित करने की आवश्यकता नहीं है।
  • DNAT आवश्यक नहीं है क्योंकि गंतव्य IP नोड के लिए स्थानीय है और iptables नियमों के अनुसार यादृच्छिक रूप से चयनित पॉड नहीं है।

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

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

बेहतर लोड संतुलन हासिल करने के लिए दूत का उपयोग करना

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

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

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

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

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

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

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

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

चित्रा 3-1 सीपीयू में एक सेवा के लिए कटओवर के दौरान अभिसरण

अंत परिणाम

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

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

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

यह सभी देखें

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