डिप्लॉय दरम्यान शून्य 502 errors कसे मिळवले

Mythex च्या backend चे प्रत्येक deploy करताना, मूठभर विनंत्या 502 Bad Gateway ने अयशस्वी होत होत्या. फार नाही — पण deploy दरम्यान 502 म्हणजे कोणाच्या क्लिकने काहीच केले नाही, किंवा कोणी पाहत असलेला build क्षणभर थांबला. आम्ही त्याचा माग दोन वेगळ्या समस्यांपर्यंत काढला: एक स्व-दुरुस्त करणारा watchdog जो आमच्या deploys शी भांडत होता, आणि सर्व्हरने ऐकणे थांबवल्यापासून ते load balancer ने त्याला ट्रॅफिक पाठवणे थांबवेपर्यंतच्या वेळेतील अंतर. दुरुस्त्यांनंतर सलग तीन production deploys मध्ये संख्या 10 वरून 6 आणि नंतर 0 झाली.

रचना

आमचे API आणि orchestrator AWS Application Load Balancer (ALB) मागे सर्व्हरच्या लहान गटावर containers म्हणून चालतात. एक deploy एका वेळी एक सर्व्हर अपडेट करतो: जुने containers drain करतो, नवे सुरू करतो, आणि पुढे जातो. प्रत्येक सर्व्हरवरील watchdog तपासतो की containers वर आहेत, आणि जे नाही ते पुन्हा सुरू करतो — रात्री 3 वाजता क्रॅश झालेली प्रक्रिया कोणालाही जागे न करता परत यावी यासाठी ते आहे.

दोन्ही स्वतःहून वाजवी आहेत. एकत्र ते वाजवी नव्हते.

समस्या 1: watchdog deploy सोबत शर्यत करत होता

Watchdog दर मिनिटाला चालत होता आणि एका अयशस्वी health check वर "उपचार" करत होता. Deploy जाणूनबुजून 150 सेकंदांपर्यंत services drain करतो — त्या काळात health check अयशस्वी व्हायला हवा. त्यामुळे watchdog प्रत्येक deploy दरम्यान फायर होत होता.

बहुतेक वेळा तो शर्यत निरुपद्रवीपणे हरत होता. एकदा तो जिंकला: deploy च्या मध्यात त्याने compose फाइल (कोणते containers चालले पाहिजेत त्याचे वर्णन) पुन्हा लिहिली, आणि एका सर्व्हरवर gateway container अजिबात उरले नाही — तरीही deploy job ने यशस्वी असल्याचे नोंदवले.

दुरुस्त्या:

• एक lock. Deploy आता सर्व्हरच्या bootstrap script सारखाच file lock घेतो, त्यामुळे watchdog आणि deploy कधीच एकाच वेळी चालू शकत नाहीत.
• एक नाही, चार वेळा. Watchdog कृती करण्यापूर्वी सलग चार अयशस्वी health checks हवे असतात. Drain होणारी सेवा आता मृत दिसत नाही.
• एक व्याख्या. Compose फाइलचा आता एकच स्रोत आहे, सर्व्हरना प्रकाशित केलेला, कॉपींऐवजी ज्या भिन्न होऊ शकत होत्या.
• गृहीत धरू नका, पडताळा. Deploy job आता फक्त एखादी command परत आली म्हणून पास होत नाही. यशस्वी होण्यापूर्वी प्रत्येक सर्व्हरवरील API, orchestrator, gateway आणि publish worker तपासते.

समस्या 2: सर्व्हर ट्रॅफिक संपण्यापूर्वी निघून गेला

दुसरी समस्या अधिक शांत होती. Deploy सर्व्हर drain करतो तेव्हा, सर्व्हर त्याच्या health endpoint वर 503 देऊ लागतो, जेणेकरून load balancer त्याला rotation मधून काढेल. आमचा सर्व्हर असे 5 सेकंद करत होता, मग बंद होत होता.

पण ALB ठराविक अंतराने health तपासत होता, आणि एखाद्या target ला राउटिंग थांबवण्यापूर्वी सलग अनेक अयशस्वी तपासण्या हव्या होत्या — टोक-ते-टोक सुमारे 60 सेकंदांपर्यंत. त्यामुळे सुमारे 55 सेकंद, load balancer ज्या सर्व्हरने ऐकणे थांबवले होते त्याला खऱ्या विनंत्या पाठवत राहिला. त्याच आमच्या 502s होत्या.

दुरुस्ती म्हणजे दोन timelines जुळवणे:

• Target group आता प्रत्येक 5 सेकंदांनी तपासतो आणि 2 अपयशांनंतर target ला unhealthy चिन्हांकित करतो — अपयश लक्षात येण्यासाठी सुमारे 10 सेकंद.
• Drain health checks अपयशी व्हायला लागल्यानंतर 15 सेकंद खरे ट्रॅफिक सेवा करत राहतो, त्यामुळे नेहमी overlap असतो.
• या सेटिंग्ज पायाभूत सुविधा प्रोव्हिजन करणाऱ्या script मध्ये राहतात, कोणीतरी एकदा क्लिक केलेल्या console मध्ये नव्हे.

संख्या एकमेकांना धरून ठेवणे

अशा timeouts एकमेकांवर अवलंबून असतात. Drain ला balancer ला अपयश लक्षात येण्यासाठी लागणाऱ्या वेळेपेक्षा जास्त टिकावे लागते; drain आणि shutdown मिळून container force-kill होण्यापूर्वी संपले पाहिजे. सहा महिन्यांनी कोणीतरी एक संख्या बदलून चुपचाप bug पुन्हा आणणे सोपे आहे.

म्हणून आम्ही त्या नात्यांना चाचण्या म्हणून लिहिले: drain हा health-check अंतर गुणिले अपयश मर्यादा यापेक्षा मोठा असला पाहिजे; पुन्हा healthy होण्याची वेळ लहान राहिली पाहिजे; संपूर्ण drain container च्या stop grace period मध्ये बसला पाहिजे. एक संख्या बदलली आणि बाकीच्या बदलल्या नाहीत तर CI अयशस्वी होतो. आम्ही चाचण्यांचीच mutation-चाचणी केली — प्रत्येक संख्या चुकीच्या मूल्यावर बदलली आणि चाचणीने ते पकडले का ते तपासले.

deploy मोजणे सहज चुकते

आमच्या पहिल्या मापनात स्वच्छ deploy सुमारे 3% तुटलेला होता असे आले. तो नव्हता. आम्ही प्रत्येक 200 नसलेला प्रतिसाद मोजत होतो, आणि drain दरम्यान health endpoint वरील 503 अपयश नव्हते — drain आपले काम करत होता, balancer ला सांगत होता की तो सर्व्हर निवडू नका, तो खऱ्या विनंत्या सेवा करत राहतो.

वापरकर्त्याला जे जाणवते ते 502 असते: विनंती काहीही पोहोचली नाही. फक्त त्यांची मोजणी केल्याने खरे चित्र मिळाले — तीन production deploys मध्ये 10, मग 6, मग 0.

त्यातून आम्ही काय शिकलो

• स्व-दुरुस्ती नियोजित डाउनटाइम ओळखायला हवी. Deploy आणि crash यात फरक करू न शकणारा watchdog कधीतरी deploy शी भांडेल.
• Drain हा हँडशेक आहे. सर्व्हरने load balancer ने ट्रॅफिक पाठवणे थांबवल्याचे सिद्ध होईपर्यंत सेवा करत राहिले पाहिजे, आणि ती वेळ सर्व्हरवर नव्हे तर balancer वर सेट होते.
• अपरिवर्तनीय गोष्टी चाचण्यांमध्ये लिहा. Operational संख्या भरकटतात. त्या एकमेकांशी जोडणाऱ्या चाचण्या भरकटत नाहीत.
• मोजण्यापूर्वी काय मोजायचे ते ठरवा. "Errors" हे चुकीचे मेट्रिक होते; "काहीही न पोहोचलेल्या विनंत्या" हे योग्य होते.

तुम्ही Mythex वर प्रकाशित ॲप प्रकाशित करत असाल, तर यातले काहीही तुम्हाला दिसत नाही — आणि तेच उद्दिष्ट आहे. संबंधित: तुम्ही प्रकाशित ॲप पुन्हा प्रकाशित करताना ते कसे सुरू राहते.