எங்கள் deploy-களை பூஜ்ஜிய 502 பிழைகளுக்குக் கொண்டுவந்தது எப்படி

Mythex-இன் backend-ஐ ஒவ்வொரு முறை deploy செய்யும்போதும், ஒரு சில கோரிக்கைகள் 502 Bad Gateway உடன் தோல்வியடைந்தன. அதிகமில்லை. ஆனால் deploy-இன் போது 502 என்றால், யாருடைய கிளிக் எதுவும் செய்யவில்லை அல்லது அவர் பார்த்துக்கொண்டிருந்த build ஒரு கணம் தேங்கியது என்று பொருள். அதை இரண்டு தனித்தனி பிரச்சினைகளாக அடையாளம் கண்டோம்: எங்கள் deploy-களுடன் போட்டியிட்ட ஒரு சுயமாகக் குணப்படுத்தும் watchdog, மற்றும் ஒரு சர்வர் கேட்பதை நிறுத்துவதற்கும் load balancer அதற்கு போக்குவரத்தை அனுப்புவதை நிறுத்துவதற்கும் இடையிலான இடைவெளி. திருத்தங்களுக்குப் பிறகு தொடர்ச்சியான மூன்று production deploy-களில், எண்ணிக்கை 10-இலிருந்து 6 ஆகி, பின்னர் 0 ஆனது.

அமைப்பு

எங்கள் API-உம் orchestrator-உம் AWS Application Load Balancer (ALB) பின்னால் உள்ள சிறிய சர்வர் குழுவில் containers-ஆக இயங்குகின்றன. ஒரு deploy ஒரு நேரத்தில் ஒரு சர்வரைப் புதுப்பிக்கிறது: பழைய containers-ஐ வடிகட்டுகிறது, புதியவற்றைத் தொடங்குகிறது, அடுத்ததுக்குச் செல்கிறது. ஒவ்வொரு சர்வரிலும் உள்ள ஒரு watchdog containers இயங்குகின்றனவா என்று சரிபார்த்து, இல்லாததை மறுதுவக்குகிறது. அதிகாலை 3 மணிக்கு செயலிழந்த ஒரு process, யாரும் எழாமலேயே திரும்ப வர அது இருக்கிறது.

இரண்டுமே தனியாகப் பார்த்தால் நியாயமானவை. ஒன்றாகச் சேர்ந்தபோது அவை நியாயமாக இல்லை.

பிரச்சினை 1: watchdog deploy-உடன் போட்டியிட்டது

Watchdog ஒவ்வொரு நிமிடமும் ஓடியது. ஒரே தோல்வியடைந்த health check-இல் "குணப்படுத்தியது". ஒரு deploy வேண்டுமென்றே 150 வினாடிகள் வரை services-ஐ வடிகட்டுகிறது. அந்த நேரத்தில் ஒரு health check தோல்வியடைவது எதிர்பார்க்கப்படுவது. எனவே ஒவ்வொரு deploy-இன் போதும் watchdog இயங்கியது.

பெரும்பாலும் அது போட்டியில் தீங்கின்றித் தோற்றது. ஒருமுறை அது வென்றது: deploy-இன் நடுவில் compose கோப்பை (எந்த containers இயங்க வேண்டும் என்ற விவரம்) மீண்டும் எழுதியது. deploy job வெற்றி என்று அறிவித்தபோதும், ஒரு சர்வரில் gateway container எதுவுமே இல்லாமல் போனது.

சரிசெய்தவை:

• ஒரே பூட்டு. deploy இப்போது சர்வரின் bootstrap script எடுக்கும் அதே கோப்புப் பூட்டை எடுக்கிறது. எனவே watchdog-உம் deploy-உம் ஒருபோதும் ஒரே நேரத்தில் இயங்க முடியாது.
• ஒன்றுக்கு அல்ல, நான்கு தவறுகளுக்கு. watchdog செயல்படுவதற்கு முன் தொடர்ச்சியாக நான்கு தோல்வியடைந்த சோதனைகள் தேவை. வடிகட்டப்படும் service இனி இறந்தது போலத் தெரியாது.
• ஒரே வரையறை. compose கோப்புக்கு இப்போது ஒரே ஒரு மூலம் உள்ளது. அது சர்வர்களுக்கு வெளியிடப்படுகிறது. விலகிப்போகக்கூடிய நகல்கள் இல்லை.
• நம்பாமல் சரிபாருங்கள். ஒரு கட்டளை திரும்பி வந்ததால் deploy job இனி வெற்றி பெறாது. வெற்றி பெறுவதற்கு முன், ஒவ்வொரு சர்வரின் API, orchestrator, gateway மற்றும் publish worker-ஐயும் சரிபார்க்கிறது.

பிரச்சினை 2: போக்குவரத்து செல்வதற்கு முன் சர்வர் வெளியேறியது

இரண்டாவது பிரச்சினை அமைதியானது. ஒரு deploy ஒரு சர்வரை வடிகட்டும்போது, load balancer அதை சுழற்சியிலிருந்து வெளியே எடுக்க, அந்தச் சர்வர் தன் health endpoint-க்கு 503 என்று பதில் சொல்லத் தொடங்குகிறது. எங்களுடையது 5 வினாடிகள் அப்படிச் செய்தது, பின்னர் மூடிக்கொண்டது.

ஆனால் ALB ஆரோக்கியத்தை அவ்வப்போதுதான் சரிபார்த்தது. ஒரு இலக்குக்கு போக்குவரத்தை நிறுத்துவதற்கு முன் தொடர்ச்சியாக பல தோல்விகள் தேவைப்பட்டன. முடிவிலிருந்து முடிவு வரை சுமார் 60 வினாடிகள் வரை. எனவே சுமார் 55 வினாடிகளுக்கு, load balancer ஏற்கனவே கேட்பதை நிறுத்திய ஒரு சர்வருக்கு உண்மையான கோரிக்கைகளை அனுப்பிக்கொண்டிருந்தது. அவைதான் எங்கள் 502 பிழைகள்.

இரண்டு காலக்கோடுகளையும் ஒத்துப்போகச் செய்வதே திருத்தம்:

• இலக்கு குழு இப்போது 5 வினாடிகளுக்கு ஒருமுறை சரிபார்க்கிறது. 2 தோல்விகளுக்குப் பின் ஓர் இலக்கு ஆரோக்கியமற்றதாகக் குறிக்கப்படுகிறது. கவனிக்க சுமார் 10 வினாடிகள்.
• தோல்வியடையத் தொடங்கிய பின்னும் வடிகட்டல் 15 வினாடிகளுக்கு உண்மையான போக்குவரத்தைத் தொடர்ந்து சேவை செய்கிறது. எனவே எப்போதும் ஒரு மேலடுக்கு இருக்கும்.
• இந்த அமைப்புகள் யாரோ ஒருமுறை கிளிக் செய்த console-இல் அல்ல, உள்கட்டமைப்பை ஏற்பாடு செய்யும் script-இல் உள்ளன.

எண்கள் ஒன்றையொன்று தாங்கிக்கொள்ளச் செய்தல்

இது போன்ற நேர முடிவுகள் ஒன்றையொன்று சார்ந்திருக்கின்றன. வடிகட்டல் balancer ஒரு சர்வரைக் கவனிக்கத் தேவைப்படும் நேரத்தைவிட நீடிக்க வேண்டும். வடிகட்டலும் நிறுத்தமும் சேர்ந்து container கட்டாயமாக நிறுத்தப்படுவதற்கு முன் முடிய வேண்டும். ஆறு மாதங்களில் யாராவது ஒரு எண்ணை மாற்றி, பிழையை அமைதியாக மீண்டும் கொண்டுவருவது எளிது.

எனவே அந்த உறவுகளை சோதனைகளாக எழுதினோம்: வடிகட்டல் health-check இடைவெளியை தோல்வி வரம்பால் பெருக்கியதைவிட நீளமாக இருக்க வேண்டும். மீண்டும் ஆரோக்கியமானதாகக் குறிக்கப்பட எடுக்கும் நேரம் குறுகியதாக இருக்க வேண்டும். முழு வடிகட்டலும் container-இன் நிறுத்த அவகாசத்துக்குள் பொருந்த வேண்டும். ஒரு எண்ணை மற்றவை இல்லாமல் மாற்றினால் CI தோல்வியடையும். சோதனைகளையே mutation-test செய்தோம். ஒவ்வொரு எண்ணையும் தவறான மதிப்புக்கு மாற்றி, ஒரு சோதனை அதைப் பிடிக்கிறதா என்று சரிபார்த்தோம்.

deploy-ஐ அளவிடுவது எளிதில் தவறாகும்

எங்கள் முதல் அளவீடு, சுத்தமான deploy சுமார் 3% உடைந்தது என்றது. அது உண்மையல்ல. 200 அல்லாத ஒவ்வொரு பதிலையும் எண்ணிக்கொண்டிருந்தோம். ஆனால் வடிகட்டலின் போது ஒரு health endpoint-இலிருந்து வரும் 503 தோல்வி அல்ல. அது வடிகட்டல் தன் வேலையைச் செய்வது: சர்வர் உண்மையான கோரிக்கைகளுக்கு இன்னும் சேவை செய்துகொண்டிருக்கும்போது, அதைத் தேர்ந்தெடுக்க வேண்டாம் என்று balancer-க்குச் சொல்வது.

பயனர்கள் உணர்வது 502. கோரிக்கை எதையும் அடையவில்லை. அவற்றை மட்டும் எண்ணியபோது உண்மையான படம் கிடைத்தது: மூன்று production deploy-களில் 10, பின்னர் 6, பின்னர் 0.

இதிலிருந்து நாங்கள் எடுத்துக்கொண்டவை

• சுயமாகக் குணப்படுத்துதலுக்கு திட்டமிட்ட செயலிழப்பு பற்றித் தெரிந்திருக்க வேண்டும். deploy-ஐ விபத்திலிருந்து வேறுபடுத்த முடியாத watchdog இறுதியில் deploy-உடன் போட்டியிடும்.
• வடிகட்டுதல் ஒரு கைகுலுக்கல். balancer போக்குவரத்தை அனுப்புவதை நிறுத்தியதை நிரூபிக்கும் வரை சர்வர் சேவை செய்துகொண்டே இருக்க வேண்டும். அந்த நேரம் சர்வரில் அல்ல, balancer-இல் அமைக்கப்படுகிறது.
• மாறாத விதிகளை சோதனைகளாக எழுதுங்கள். செயல்பாட்டு எண்கள் விலகிப்போகின்றன. அவற்றை ஒன்றோடொன்று தொடர்புபடுத்தும் சோதனைகள் விலகுவதில்லை.
• அளவிடும் முன் எதை அளவிடுகிறீர்கள் என்று முடிவு செய்யுங்கள். "பிழைகள்" தவறான அளவீடு; "எதையும் அடையாத கோரிக்கைகள்" சரியானது.

Mythex-இல் ஒரு ஆப்பை வெளியிட்டால், இவை எதுவும் உங்களுக்குத் தெரியாது. அதுதான் நோக்கம். தொடர்புடையது: மறுவெளியீடு செய்யும்போதும் உங்கள் வெளியிடப்பட்ட ஆப் எப்படி இயங்கிக் கொண்டிருக்கிறது.