డిప్లాయ్‌లను జీరో 502 ఎర్రర్‌లకు ఎలా తీసుకొచ్చాము

Mythex బ్యాకెండ్‌ను డిప్లాయ్ చేసిన ప్రతిసారి, కొన్ని రిక్వెస్ట్‌లు 502 Bad Gateway తో విఫలమయ్యేవి. చాలా కాదు — కానీ డిప్లాయ్ సమయంలో 502 అంటే ఎవరో క్లిక్ చేస్తే ఏమీ జరగకపోవడం, లేదా ఎవరో చూస్తున్న బిల్డ్ క్షణకాలం ఆగిపోవడం. దానిని మేము రెండు వేరు సమస్యలకు గుర్తించాము: డిప్లాయ్‌తో పోటీ పడిన స్వీయ-స్వస్థత వాచ్‌డాగ్, మరియు ఒక సర్వర్ వినడం ఆపిన క్షణానికి, లోడ్ బ్యాలెన్సర్ దానికి ట్రాఫిక్ పంపడం ఆపే క్షణానికి మధ్య ఉన్న అంతరం. పరిష్కారాల తర్వాత వరుసగా మూడు ప్రొడక్షన్ డిప్లాయ్‌లలో, సంఖ్య 10 నుంచి 6కి, తర్వాత 0కి వెళ్లింది.

సెటప్

మా API మరియు ఆర్కెస్ట్రేటర్ AWS Application Load Balancer (ALB) వెనుక ఉన్న కొన్ని సర్వర్ల గ్రూప్‌పై కంటైనర్లుగా రన్ అవుతాయి. డిప్లాయ్ ఒక్కో సర్వర్‌ను అప్‌డేట్ చేస్తుంది: పాత కంటైనర్లను డ్రెయిన్ చేస్తుంది, కొత్తవి ప్రారంభిస్తుంది, తర్వాత ముందుకు వెళ్తుంది. ప్రతి సర్వర్‌పై ఒక వాచ్‌డాగ్ కంటైనర్లు పైకి ఉన్నాయో లేదో తనిఖీ చేసి, ఏది పైకి లేదో దాన్ని రీస్టార్ట్ చేస్తుంది — అది ఉంది కాబట్టి అర్ధరాత్రి 3 గంటలకు క్రాష్ అయిన ప్రాసెస్ ఎవరినీ లేపకుండానే తిరిగి వస్తుంది.

రెండూ విడిగా సహేతుకమే. కలిసి మాత్రం కాదు.

సమస్య 1: వాచ్‌డాగ్ డిప్లాయ్‌తో పోటీ పడింది

వాచ్‌డాగ్ నిమిషానికి ఒకసారి రన్ అయ్యేది, మరియు ఒకే విఫలమైన హెల్త్ చెక్‌పై “హీల్” చేసేది. డిప్లాయ్ ఉద్దేశపూర్వకంగా సేవలను 150 సెకన్ల వరకు డ్రెయిన్ చేస్తుంది — ఆ సమయంలో హెల్త్ చెక్ విఫలమవ్వాలి. కాబట్టి వాచ్‌డాగ్ ప్రతి డిప్లాయ్ సమయంలోనూ కాల్పులు జరిపింది.

ఎక్కువ సార్లు అది హానిలేకుండా పోటీలో ఓడిపోయింది. ఒకసారి గెలిచింది: డిప్లాయ్ మధ్యలో కంపోజ్ ఫైల్ (ఏ కంటైనర్లు రన్ కావాలో వివరించేది) తిరిగి రాసింది, మరియు ఒక సర్వర్‌కు గేట్‌వే కంటైనర్ లేకుండా వదిలేసింది — డిప్లాయ్ జాబ్ విజయం అని నివేదిస్తూనే.

పరిష్కారాలు:

• ఒకే లాక్. డిప్లాయ్ ఇప్పుడు సర్వర్ బూట్‌స్ట్రాప్ స్క్రిప్ట్ వాడే అదే ఫైల్ లాక్‌ను తీసుకుంటుంది, కాబట్టి వాచ్‌డాగ్ మరియు డిప్లాయ్ ఎప్పుడూ ఒకేసారి రన్ కావు.
• ఒకటి కాదు, నాలుగు స్ట్రైక్‌లు. వాచ్‌డాగ్ చర్య తీసుకోవడానికి నాలుగు వరుస విఫలమైన హెల్త్ చెక్‌లు అవసరం. డ్రెయిన్ అవుతున్న సేవ ఇకపై చనిపోయినట్టు కనిపించదు.
• ఒకే నిర్వచనం. కంపోజ్ ఫైల్ ఇప్పుడు సర్వర్లకు ప్రచురించబడిన ఒకే మూలం నుంచి వస్తుంది, విడిపోయే కాపీలకు బదులు.
• నమ్మవద్దు, ధృవీకరించండి. డిప్లాయ్ జాబ్ ఇప్పుడు ఒక కమాండ్ తిరిగి వచ్చిందని మాత్రమే పాస్ అవ్వదు. విజయం సాధించే ముందు, ప్రతి సర్వర్ యొక్క API, ఆర్కెస్ట్రేటర్, గేట్‌వే మరియు ప్రచురణ వర్కర్‌ను తనిఖీ చేస్తుంది.

సమస్య 2: సర్వర్ ట్రాఫిక్ కంటే ముందే వెళ్లిపోయింది

రెండవ సమస్య నిశ్శబ్దమైనది. డిప్లాయ్ ఒక సర్వర్‌ను డ్రెయిన్ చేసినప్పుడు, సర్వర్ తన హెల్త్ ఎండ్‌పాయింట్‌కు 503 తో స్పందించడం మొదలుపెడుతుంది, తద్వారా లోడ్ బ్యాలెన్సర్ దానిని రొటేషన్ నుంచి తీసేస్తుంది. మాది 5 సెకన్ల పాటు అలా చేసి, తర్వాత ఆగిపోయేది.

కానీ ALB అప్పుడప్పుడు మాత్రమే హెల్త్ తనిఖీ చేసేది, మరియు ఒక టార్గెట్‌కు ట్రాఫిక్ ఆపే ముందు వరుసగా అనేక విఫలమైన చెక్‌లు అవసరం — మొత్తం ముగింపు-నుంచి-ముగింపు సుమారు 60 సెకన్ల వరకు. కాబట్టి సుమారు 55 సెకన్ల పాటు, లోడ్ బ్యాలెన్సర్ అప్పటికే వినడం ఆపేసిన సర్వర్‌కు నిజమైన రిక్వెస్ట్‌లు పంపుతూనే ఉంది. అవి మా 502లు.

పరిష్కారం రెండు కాలరేఖలను ఒప్పించడం:

• టార్గెట్ గ్రూప్ ఇప్పుడు ప్రతి 5 సెకన్లకు తనిఖీ చేస్తుంది, మరియు 2 విఫలాల తర్వాత టార్గెట్‌ను అనారోగ్యంగా గుర్తిస్తుంది — గమనించడానికి సుమారు 10 సెకన్లు.
• డ్రెయిన్ హెల్త్ చెక్‌లు విఫలమవ్వడం ప్రారంభించిన తర్వాత 15 సెకన్ల పాటు నిజమైన ట్రాఫిక్‌కు సేవ చేస్తూనే ఉంటుంది, కాబట్టి ఎప్పుడూ అతివ్యాప్తి ఉంటుంది.
• ఈ సెట్టింగ్‌లు కన్సోల్‌లో ఎవరో ఒకసారి క్లిక్ చేసిన చోట కాకుండా, మౌలిక సదుపాయాలను ప్రొవిజన్ చేసే స్క్రిప్ట్‌లో ఉంటాయి.

సంఖ్యలు ఒకదానికొకటి నిలబడేలా చేయడం

ఈ టైమ్‌అవుట్‌లు ఒకదానిపై ఒకటి ఆధారపడతాయి. డ్రెయిన్ బ్యాలెన్సర్ గమనించడానికి పట్టే సమయం కంటే ఎక్కువగా ఉండాలి; డ్రెయిన్ మరియు షట్‌డౌన్ కలిపి, కంటైనర్ బలవంతంగా చంపబడకముందే పూర్తవాలి. ఆరు నెలల తర్వాత ఎవరో ఒక నంబర్ మార్చి, బగ్‌ను నిశ్శబ్దంగా మళ్లీ తీసుకురావడం సులభం.

కాబట్టి ఆ సంబంధాలను టెస్ట్‌లుగా రాశాము: డ్రెయిన్ హెల్త్-చెక్ ఇంటర్వల్ × విఫల థ్రెషోల్డ్ కంటే ఎక్కువగా ఉండాలి; మళ్లీ ఆరోగ్యంగా మారడానికి పట్టే సమయం తక్కువగా ఉండాలి; మొత్తం డ్రెయిన్ కంటైనర్ స్టాప్ గ్రేస్ పీరియడ్‌లో సరిపోవాలి. ఒక నంబర్ మార్చి, మిగతావి మార్చకపోతే CI విఫలమవుతుంది. టెస్ట్‌లనే మ్యుటేషన్-టెస్ట్ చేశాము — ప్రతి నంబర్‌ను తప్పు విలువకు మార్చి, ఒక టెస్ట్ దాన్ని పట్టుకుంటుందో తనిఖీ చేశాము.

డిప్లాయ్‌ను కొలవడం సులభంగా తప్పవచ్చు

మా మొదటి కొలత శుభ్రమైన డిప్లాయ్ సుమారు 3% విరిగిందని చెప్పింది. అది నిజం కాదు. మేము ప్రతి 200 కాని ప్రతిస్పందనను లెక్కిస్తున్నాము, మరియు డ్రెయిన్ సమయంలో హెల్త్ ఎండ్‌పాయింట్ నుంచి వచ్చే 503 విఫలం కాదు — అది డ్రెయిన్ తన పని చేయడం, లోడ్ బ్యాలెన్సర్‌కు ఆ సర్వర్‌ను ఎంచుకోవద్దని చెబుతూ, నిజమైన రిక్వెస్ట్‌లకు సేవ చేస్తూనే ఉంటుంది.

వినియోగదారులు అనుభవించేది 502. రిక్వెస్ట్ ఏదీ చేరలేదు. వాటిని మాత్రమే లెక్కించడం నిజమైన చిత్రాన్ని ఇచ్చింది — మూడు ప్రొడక్షన్ డిప్లాయ్‌లలో 10, తర్వాత 6, తర్వాత 0.

మేము ఏమి నేర్చుకున్నాము

• స్వీయ-స్వస్థతకు ప్రణాళికాబద్ధమైన డౌన్‌టైమ్ గురించి తెలియాలి. డిప్లాయ్ మరియు క్రాష్ మధ్య తేడా చెప్పలేని వాచ్‌డాగ్ చివరికి డిప్లాయ్‌తో పోరాడుతుంది.
• డ్రెయినింగ్ ఒక హ్యాండ్‌షేక్. లోడ్ బ్యాలెన్సర్ ట్రాఫిక్ పంపడం ఆపిందని నిరూపించబడే వరకు సర్వర్ సేవ చేస్తూనే ఉండాలి, మరియు ఆ టైమింగ్ సర్వర్‌పై కాదు, బ్యాలెన్సర్‌పై సెట్ చేయబడుతుంది.
• మార్పులేని నియమాలను టెస్ట్‌లుగా ఎన్‌కోడ్ చేయండి. ఆపరేషనల్ నంబర్లు విడిపోతాయి. వాటిని ఒకదానితో ఒకటి సంబంధించే టెస్ట్‌లు విడిపోవు.
• కొలవడానికి ముందే మీరు ఏమి కొలుస్తున్నారో నిర్ణయించండి. “ఎర్రర్లు” తప్పు మెట్రిక్; “ఏదీ చేరని రిక్వెస్ట్‌లు” సరైనది.

మీరు Mythex పై ఒక యాప్ ప్రచురిస్తే, వీటిలో ఏదీ మీకు కనిపించదు — అదే లక్ష్యం. సంబంధిత: మీరు మళ్లీ ప్రచురిస్తున్నప్పుడు మీ ప్రచురించిన యాప్ ఎలా అందుబాటులో ఉంటుంది.