नोट। अनुवाद।: अगस्टको शुरुमा, Red Hat ले अघिल्लो महिनाहरूमा यसको सेवाका प्रयोगकर्ताहरूले सामना गरेका पहुँच समस्याहरू समाधान गर्ने बारे सार्वजनिक रूपमा कुरा गर्यो। (यो कन्टेनर छविहरूको लागि रजिस्ट्रीमा आधारित छ, जुन कम्पनीले CoreOS को खरिदसँगै प्राप्त गरेको थियो)। यस सेवामा तपाईंको रुचि जस्तोसुकै भए तापनि, कम्पनीका SRE इन्जिनियरहरूले दुर्घटनाको कारणहरू पत्ता लगाउन र हटाउनको लागि चालेको मार्ग शिक्षाप्रद छ।
मे १९ मा, बिहान सबेरै (पूर्वी डेलाइट समय, EDT), quay.io सेवा क्र्यास भयो। दुर्घटनाले quay.io उपभोक्ताहरू र सफ्टवेयर निर्माण र वितरणको लागि प्लेटफर्मको रूपमा quay.io प्रयोग गर्ने खुला स्रोत परियोजनाहरू दुवैलाई असर गर्यो। Red Hat ले दुबैको विश्वासलाई महत्व दिन्छ।
SRE ईन्जिनियरहरूको टोली तुरुन्तै संलग्न भयो र Quay सेवालाई सकेसम्म चाँडो स्थिर गर्ने प्रयास गर्यो। यद्यपि, तिनीहरूले यो गरिरहँदा, ग्राहकहरूले नयाँ छविहरू पुश गर्ने क्षमता गुमाए, र केवल कहिलेकाहीं तिनीहरू अवस्थितहरूलाई तान्न सक्षम थिए। केही अज्ञात कारणले गर्दा, quay.io डाटाबेसलाई पूर्ण क्षमतामा सेवा स्केल गरेपछि अवरुद्ध गरिएको थियो।
«के परिवर्तन भयो?"- यो पहिलो प्रश्न हो जुन सामान्यतया यस्ता केसहरूमा सोधिन्छ। हामीले देख्यौं कि मुद्दाको केही समय अघि, OpenShift समर्पित क्लस्टर (जसले quay.io चलाउँछ) संस्करण 4.3.19 मा अद्यावधिक गर्न थाल्यो। quay.io Red Hat OpenShift Dedicated (OSD) मा चल्ने हुनाले, नियमित अपडेटहरू दिनचर्या थिए र कहिले पनि समस्याहरू आएनन्। यसबाहेक, विगत छ महिनाहरूमा, हामीले सेवामा कुनै अवरोध बिना क्वे क्लस्टरहरूलाई धेरै पटक अपग्रेड गरेका छौं।
हामीले सेवा पुनर्स्थापना गर्ने प्रयास गर्दा, अन्य इन्जिनियरहरूले सफ्टवेयरको अघिल्लो संस्करणको साथ नयाँ OSD क्लस्टर तयार गर्न थाले, ताकि यदि केही भयो भने, तिनीहरूले यसमा सबै कुराहरू प्रयोग गर्न सकून्।
जड विश्लेषण
विफलताको मुख्य लक्षण दसौं हजारौं डाटाबेस जडानहरूको हिमस्खलन थियो, जसले MySQL उदाहरणलाई प्रभावकारी रूपमा निष्क्रिय बनायो। यसले समस्याको निदान गर्न गाह्रो बनायो। हामीले SRE टोलीलाई मुद्दाको मूल्याङ्कन गर्न मद्दत गर्न ग्राहकहरूबाट जडानहरूको अधिकतम संख्यामा सीमा तोकेका छौं। हामीले डेटाबेसमा कुनै असामान्य ट्राफिक देखेनौं: वास्तवमा, धेरै अनुरोधहरू पढिएका थिए, र थोरै मात्र लेखिएका थिए।
हामीले डाटाबेस ट्राफिकमा एउटा ढाँचा पहिचान गर्ने प्रयास गर्यौं जसले यो हिमपहिरो निम्त्याउन सक्छ। यद्यपि, हामीले लगहरूमा कुनै ढाँचाहरू फेला पार्न सकेनौं। OSD 4.3.18 को साथ नयाँ क्लस्टर तयार हुनको लागि प्रतिक्षा गर्दा, हामीले quay.io pods सुरु गर्ने प्रयास जारी राख्यौं। प्रत्येक पटक क्लस्टर पूर्ण क्षमतामा पुग्दा, डाटाबेस फ्रिज हुनेछ। यसको मतलब सबै quay.io pods को अतिरिक्त RDS उदाहरण पुन: सुरु गर्न आवश्यक थियो।
साँझसम्म, हामीले सेवालाई पढ्ने मात्र मोडमा स्थिर गर्यौं र डाटाबेसमा लोड कम गर्न सकेसम्म धेरै गैर-आवश्यक कार्यहरू (उदाहरणका लागि, नेमस्पेस फोहोर संकलन) असक्षम पार्यौं। चिसो रोकिएको छ तर कारण कहिल्यै फेला परेन। नयाँ OSD क्लस्टर तयार थियो, र हामीले सेवा माइग्रेट गर्यौं, ट्राफिक जोड्यौं र अनुगमन जारी राख्यौं।
Quay.io ले नयाँ OSD क्लस्टरमा स्थिर रूपमा काम गर्यो, त्यसैले हामी डाटाबेस लगहरूमा फर्कियौं, तर अवरोधहरू व्याख्या गर्ने सहसंबंध फेला पार्न सकेनौं। OpenShift इन्जिनियरहरूले Red Hat OpenShift 4.3.19 मा परिवर्तनहरू Quay मा समस्या निम्त्याउन सक्छ कि भनेर बुझ्न हामीसँग काम गरे। तर, केही फेला परेन, र प्रयोगशाला अवस्थामा समस्या पुन: उत्पादन गर्न सम्भव थिएन.
दोस्रो असफलता
मे 28 मा, EDT दिउँसोको केही समय अघि, quay.io उही लक्षणको साथ फेरि क्र्यास भयो: डाटाबेस ब्लक गरिएको थियो। र फेरि हामीले अनुसन्धानमा हाम्रा सबै प्रयासहरू फ्याँक्यौं। सबै भन्दा पहिले, यो सेवा पुनर्स्थापित गर्न आवश्यक थियो। यद्यपि यस पटक RDS रिबुट गर्ने र quay.io pods पुन: सुरु गर्दा केही गरेन: जडानको अर्को हिमस्खलनले आधारलाई ओगटेको छ। तर किन?
Quay पाइथनमा लेखिएको छ र प्रत्येक पोड एकल मोनोलिथिक कन्टेनरको रूपमा सञ्चालन गर्दछ। कन्टेनर रनटाइमले धेरै समानान्तर कार्यहरू एकैसाथ चलाउँछ। हामी पुस्तकालय प्रयोग गर्छौं gevent under gunicorn वेब अनुरोधहरू प्रशोधन गर्न। जब एक अनुरोध Quay मा आउँछ (हाम्रो आफ्नै API मार्फत, वा Docker's API मार्फत), यो एक gevent कार्यकर्ता नियुक्त गरिन्छ। सामान्यतया यो कार्यकर्ताले डाटाबेसलाई सम्पर्क गर्नुपर्छ। पहिलो असफलता पछि, हामीले पत्ता लगायौं कि gevent कार्यकर्ताहरू पूर्वनिर्धारित सेटिङहरू प्रयोग गरेर डाटाबेसमा जडान गर्दै थिए।
Quay pods को महत्त्वपूर्ण संख्या र प्रति सेकेन्ड हजारौं आगमन अनुरोधहरूलाई दिईयो, डाटाबेस जडानहरूको ठूलो संख्याले सैद्धान्तिक रूपमा MySQL उदाहरणलाई ओभर गर्न सक्छ। निगरानीको लागि धन्यवाद, यो थाहा थियो कि Quay प्रति सेकेन्ड 5 हजार अनुरोधहरूको औसत प्रक्रिया गर्दछ। डाटाबेसमा जडानहरूको संख्या लगभग उस्तै थियो। 5 हजार जडानहरू हाम्रो RDS उदाहरणको क्षमताहरू भित्र राम्ररी थिए (जसलाई हजारौंको बारेमा भन्न सकिँदैन)। केही कारणले जडानहरूको संख्यामा अप्रत्याशित स्पाइकहरू थिएतथापि, हामीले आगमन अनुरोधहरूसँग कुनै सम्बन्ध देखेका छैनौं।
यस पटक हामी समस्याको स्रोत पत्ता लगाउन र हटाउन कटिबद्ध थियौं, र आफूलाई रिबुटमा सीमित नगर्ने। Quay कोडबेसमा प्रत्येक कार्यकर्ताको लागि डाटाबेसमा जडानहरूको संख्या सीमित गर्न परिवर्तनहरू गरियो gevent। यो संख्या कन्फिगरेसन मा एक प्यारामिटर भयो: यो नयाँ कन्टेनर छवि निर्माण बिना उडान मा परिवर्तन गर्न सम्भव भयो। कति जडानहरू यथार्थवादी रूपमा ह्यान्डल गर्न सकिन्छ भनेर पत्ता लगाउन, हामीले स्टेजिङ वातावरणमा धेरै परीक्षणहरू चलायौं, यसले लोड परीक्षण परिदृश्यहरूलाई कसरी असर गर्छ भनेर हेर्नको लागि विभिन्न मानहरू सेट गर्यौं। फलस्वरूप, यो पत्ता लाग्यो Quay ले 502 त्रुटिहरू फ्याँक्न थाल्छ जब जडानहरूको संख्या 10 हजार भन्दा बढी हुन्छ।
हामीले तुरुन्तै यो नयाँ संस्करण उत्पादनमा तैनात गर्यौं र डाटाबेस जडान तालिका अनुगमन सुरु गर्यौं। विगतमा करिब २० मिनेटपछि आधार बन्द गरिन्थ्यो । 20 समस्या-मुक्त मिनेट पछि हामीसँग आशा थियो, र एक घण्टा पछि हामी आत्मविश्वास थियो। हामीले साइटमा ट्राफिक पुनर्स्थापित गर्यौं र पोस्टमार्टम विश्लेषण सुरु गर्यौं।
अवरुद्ध हुने समस्यालाई बाइपास गर्न व्यवस्थित गरिसकेपछि, हामीले यसको वास्तविक कारणहरू पत्ता लगाएका छैनौं। यो पुष्टि भयो कि यो OpenShift 4.3.19 मा कुनै पनि परिवर्तनहरूसँग सम्बन्धित छैन, किनकि संस्करण 4.3.18 मा समान कुरा भयो, जुन पहिले Quay सँग कुनै समस्या बिना काम गर्यो।
क्लस्टरमा अरू केही लुकेको स्पष्ट थियो।
विस्तृत अध्ययन
Quay.io ले कुनै पनि समस्या बिना छ वर्षको लागि डाटाबेसमा जडान गर्न पूर्वनिर्धारित सेटिङहरू प्रयोग गर्यो। के परिवर्तन भयो? यो स्पष्ट छ कि यो सबै समय quay.io मा ट्राफिक लगातार बढ्दै गएको छ। हाम्रो मामला मा, यो केहि थ्रेसहोल्ड मान पुगेको जस्तो देखिन्थ्यो, जसले जडानको हिमस्खलनको लागि ट्रिगरको रूपमा सेवा गर्यो। हामीले दोस्रो असफलता पछि डाटाबेस लगहरू अध्ययन गर्न जारी राख्यौं, तर कुनै ढाँचा वा स्पष्ट सम्बन्धहरू फेला पारेनौं।
यस बीचमा, SRE टोलीले क्वेको अनुरोध अवलोकन योग्यता र समग्र सेवा स्वास्थ्यमा सुधारहरूमा काम गरिरहेको छ। नयाँ मेट्रिक्स र ड्यासबोर्डहरू तैनाथ गरिएका छन्, Quay को कुन भागहरु ग्राहकहरु बाट धेरै माग मा छन् देखाउँदै।
Quay.io ले जुन 9 सम्म राम्रो काम गर्यो। आज बिहान (EDT) हामीले फेरि डाटाबेस जडानहरूको संख्यामा उल्लेखनीय वृद्धि देख्यौं। यसपटक डाउनटाइम थिएन, किनकि नयाँ प्यारामिटरले तिनीहरूको संख्या सीमित गरेको छ र तिनीहरूलाई MySQL थ्रुपुट भन्दा बढि अनुमति दिँदैन। यद्यपि, लगभग आधा घण्टाको लागि, धेरै प्रयोगकर्ताहरूले quay.io को ढिलो प्रदर्शन नोट गरे। हामीले थप गरिएको अनुगमन उपकरणहरू प्रयोग गरेर सबै सम्भावित डेटाहरू द्रुत रूपमा सङ्कलन गर्यौं। अचानक एउटा ढाँचा देखा पर्यो।
जडानहरूमा बृद्धि हुनु अघि, एप रजिस्ट्री एपीआईमा ठूलो संख्यामा अनुरोधहरू गरिएका थिए। एप रजिस्ट्री quay.io को एक सानो ज्ञात सुविधा हो। यसले तपाईंलाई हेल्म चार्टहरू र धनी मेटाडेटा भएका कन्टेनरहरू जस्ता चीजहरू भण्डारण गर्न अनुमति दिन्छ। धेरै जसो quay.io प्रयोगकर्ताहरूले यो सुविधासँग काम गर्दैनन्, तर Red Hat OpenShift सक्रिय रूपमा यसलाई प्रयोग गर्दछ। OpenShift को भागको रूपमा OperatorHub ले एप रजिस्ट्रीमा सबै अपरेटरहरूलाई भण्डारण गर्दछ। यी अपरेटरहरूले OpenShift वर्कलोड इकोसिस्टम र साझेदार-केन्द्रित अपरेटिङ मोडेल (दिन 2 सञ्चालन) को आधार बनाउँछन्।
प्रत्येक OpenShift 4 क्लस्टरले स्थापनाको लागि उपलब्ध अपरेटरहरूको सूची प्रकाशित गर्न र पहिले नै स्थापना गरिएकाहरूलाई अद्यावधिकहरू प्रदान गर्न निर्मित अपरेटरहबबाट अपरेटरहरू प्रयोग गर्दछ। OpenShift 4 को बढ्दो लोकप्रियता संग, विश्वभर यस मा क्लस्टर को संख्या पनि बढेको छ। यी प्रत्येक क्लस्टरहरूले ब्याकइन्डको रूपमा quay.io भित्र एप रजिस्ट्री प्रयोग गरेर बिल्ट-इन OperatorHub चलाउन अपरेटर सामग्री डाउनलोड गर्दछ। समस्याको स्रोतको लागि हाम्रो खोजमा, हामीले यो तथ्य गुमायौं कि OpenShift बिस्तारै लोकप्रियतामा बढ्दै जाँदा, दुर्लभ रूपमा प्रयोग हुने quay.io प्रकार्यहरू मध्ये एकमा लोड पनि बढ्यो।.
हामीले एप रजिस्ट्री अनुरोध ट्राफिकको केहि विश्लेषण गर्यौं र रजिस्ट्री कोडमा एक नजर राख्यौं। तुरुन्तै, कमजोरीहरू प्रकट भए, जसको कारण डेटाबेसमा प्रश्नहरू इष्टतम रूपमा गठन भएनन्। लोड कम हुँदा उनीहरूलाई कुनै समस्या भएन, तर जब लोड बढ्यो, समस्याको स्रोत बन्यो। एप रेजिस्ट्रीमा दुईवटा समस्याग्रस्त अन्तबिन्दुहरू देखा पर्यो जसले बढ्दो लोडलाई राम्रोसँग प्रतिक्रिया नगरेको थियो: पहिलोले भण्डारमा सबै प्याकेजहरूको सूची प्रदान गर्यो, दोस्रोले प्याकेजको लागि सबै ब्लबहरू फिर्ता गर्यो।
कारणहरूको उन्मूलन
अर्को हप्तामा हामीले एप रजिस्ट्रीको कोड र यसको वातावरणलाई अप्टिमाइज गर्न बितायौं। स्पष्ट रूपमा अप्रभावी SQL प्रश्नहरू पुन: काम गरियो र अनावश्यक आदेश कलहरू हटाइयो tar (यो प्रत्येक पटक ब्लबहरू पुनःप्राप्त गर्दा चलाइएको थियो), जहाँ सम्भव भएसम्म क्यासिङ थपियो। हामीले त्यसपछि व्यापक प्रदर्शन परीक्षण सञ्चालन गर्यौं र परिवर्तनहरू अघि र पछि एप रजिस्ट्रीको गति तुलना गर्यौं।
पहिले आधा मिनेटसम्म लाग्ने API अनुरोधहरू अब मिलिसेकेन्डमा पूरा हुन्छन्। अर्को हप्ता हामीले उत्पादनमा परिवर्तनहरू तैनात गर्यौं, र त्यसपछि quay.io स्थिर रूपमा काम गरिरहेको छ। यस समयमा, त्यहाँ एप रेजिस्ट्री अन्त्य बिन्दुमा ट्राफिकमा धेरै तीव्र स्पाइकहरू थिए, तर सुधारहरूले डाटाबेस आउटेजलाई रोक्यो।
हामीले के सिकेका छौं?
यो स्पष्ट छ कि कुनै पनि सेवाले डाउनटाइमबाट बच्न प्रयास गर्छ। हाम्रो अवस्थामा, हामी विश्वास गर्छौं कि भर्खरको आउटेजले quay.io लाई अझ राम्रो बनाउन मद्दत गरेको छ। हामीले केहि मुख्य पाठहरू सिकेका छौं जुन हामी साझा गर्न चाहन्छौं:
- तपाईंको सेवा कसले प्रयोग गर्छ र कसरी प्रयोग गर्छ भन्ने बारेको डेटा कहिल्यै अनावश्यक हुँदैन। क्वेले "भर्खरै काम गरेको" हुनाले, हामीले ट्राफिकलाई अनुकूलन गर्न र लोड व्यवस्थापन गर्न कहिले पनि समय खर्च गर्नु परेन। यी सबैले सुरक्षाको गलत भावना सिर्जना गर्यो कि सेवा अनिश्चित कालसम्म मापन गर्न सक्छ।
- सेवा ठप्प हुँदा, यसलाई फिर्ता लिनु र चलाउनु शीर्ष प्राथमिकता हो।। किनकी Quay ले पहिलो आउटेजको समयमा लक गरिएको डाटाबेसबाट पीडित रह्यो, हाम्रो मानक प्रक्रियाहरूले अपेक्षित प्रभाव पारेन र हामीले तिनीहरूलाई प्रयोग गरेर सेवा पुनर्स्थापना गर्न असमर्थ थियौं। यसले एक अवस्थाको नेतृत्व गर्यो जहाँ कार्यात्मकता पुनर्स्थापनामा सबै प्रयासहरू केन्द्रित गर्नुको सट्टा मूल कारण फेला पार्ने आशामा डाटा विश्लेषण र सङ्कलन गर्न समय खर्च गर्नुपर्ने थियो।
- प्रत्येक सेवा सुविधाको प्रभाव मूल्याङ्कन गर्नुहोस्। ग्राहकहरूले विरलै एप रजिस्ट्री प्रयोग गर्थे, त्यसैले यो हाम्रो टोलीको लागि प्राथमिकता थिएन। जब केहि उत्पादन सुविधाहरू मुश्किलले प्रयोग गरिन्छ, तिनीहरूका बगहरू विरलै देखा पर्छन्, र विकासकर्ताहरूले कोड निगरानी गर्न रोक्छन्। यो यस्तो हुनुपर्छ भन्ने गलत धारणाको शिकार हुन सजिलो छ - जबसम्म अचानक त्यो कार्यले आफैलाई प्रमुख घटनाको केन्द्रमा फेला पार्दैन।
के अर्को छ?
सेवाको स्थिरता सुनिश्चित गर्ने काम कहिल्यै रोकिने छैन र हामी यसलाई निरन्तर सुधार गर्दैछौं। quay.io मा ट्राफिकको मात्रा बढ्दै जाँदा, हामीले हाम्रा ग्राहकहरूको विश्वासमा बाँच्न सक्ने सबै कुरा गर्ने जिम्मेवारी हामीसँग छ भनी बुझ्छौं। त्यसकारण, हामी हाल निम्न कार्यहरूमा काम गरिरहेका छौं:
- प्राथमिक RDS उदाहरणको साथ समस्याको अवस्थामा सेवालाई उपयुक्त ट्राफिक ह्यान्डल गर्न मद्दत गर्न पढ्न-मात्र डाटाबेस प्रतिकृतिहरू प्रयोग गर्नुहोस्।
- RDS उदाहरण अद्यावधिक गर्दै। हालको संस्करण आफैमा समस्या होइन। बरु, हामी केवल झूटा ट्रेल हटाउन चाहन्छौं (जसलाई हामीले असफलताको बेला पछ्यायौं); सफ्टवेयरलाई अद्यावधिक राख्नाले भविष्यमा आउटेजको घटनामा अर्को कारकलाई हटाउनेछ।
- सम्पूर्ण क्लस्टरमा अतिरिक्त क्यासिङ। हामी क्षेत्रहरू खोज्न जारी राख्छौं जहाँ क्यासिङले डाटाबेसमा लोड घटाउन सक्छ।
- quay.io मा को जडान भइरहेको छ र किन हेर्नको लागि वेब अनुप्रयोग फायरवाल (WAF) थप्दै।
- अर्को रिलीजको साथ सुरु गर्दै, Red Hat OpenShift क्लस्टरहरूले quay.io मा उपलब्ध कन्टेनर छविहरूमा आधारित अपरेटर क्याटलगहरूको पक्षमा एप रजिस्ट्री त्याग्नेछ।
- एप रजिस्ट्रीको लागि दीर्घकालीन प्रतिस्थापन ओपन कन्टेनर इनिसिएटिभ (ओसीआई) आर्टिफ्याक्ट विशिष्टताहरूको लागि समर्थन हुन सक्छ। यो हाल नेटिभ क्वे प्रकार्यताको रूपमा लागू गरिएको छ र प्रयोगकर्ताहरूलाई उपलब्ध हुनेछ जब निर्दिष्टीकरण आफैंलाई अन्तिम रूप दिइन्छ।
माथिका सबै Red Hat को quay.io मा चलिरहेको लगानीको अंश हो किनकि हामी सानो "स्टार्टअप-शैली" टोलीबाट परिपक्व SRE-संचालित प्लेटफर्ममा जान्छौं। हामीलाई थाहा छ कि हाम्रा धेरै ग्राहकहरू आफ्नो दैनिक काममा (Red Hat! सहित) quay.io मा भर पर्छन् र हामी भर्खरैका आउटेजहरू र सुधारका लागि जारी प्रयासहरूको बारेमा सकेसम्म पारदर्शी हुने प्रयास गर्छौं।
अनुवादकबाट PS
हाम्रो ब्लगमा पनि पढ्नुहोस्:
- «»;
- «»;
- «"।
स्रोत: www.habr.com