Jinsi Tulivyofikia Deploy Zenye Makosa 502 Sifuri

Kila mara tulipoweka backend ya Mythex kwenye deploy, idadi ndogo ya maombi ilishindwa kwa 502 Bad Gateway. Si mengi — lakini 502 wakati wa deploy inamaanisha kubofya kwa mtu hakukufanya kitu, au build aliyokuwa akiitazama ilisimama kwa muda. Tulifuatilia hadi matatizo mawili tofauti: watchdog ya kujiponya iliyokuwa ikipigana na deploys zetu, na pengo kati ya seva kuacha kusikiliza na load balancer kuacha kuipelekea trafiki. Katika deploys tatu mfululizo za uzalishaji baada ya marekebisho, idadi ilishuka kutoka 10 hadi 6 hadi 0.

Usanidi

API yetu na orchestrator zinaendeshwa kama containers kwenye kundi dogo la seva nyuma ya AWS Application Load Balancer (ALB). Deploy inasasisha seva moja baada ya nyingine: inaondoa containers za zamani kutoka kwenye trafiki, inaanzisha mpya, na kuendelea. Watchdog kwenye kila seva inakagua kwamba containers ziko hewani na kuanzisha upya chochote ambacho hakiko — ipo ili process iliyoanguka saa 3 usiku irudi bila mtu kuamshwa.

Zote mbili ni za busara zenyewe. Pamoja, hazikuwa.

Tatizo la 1: watchdog ilishindana na deploy

Watchdog ilikimbia mara moja kwa dakika na “ilijiponya” kwenye ukaguzi mmoja ulioshindwa. Deploy kwa makusudi huondoa huduma kutoka kwenye trafiki kwa hadi sekunde 150 — wakati ambao ukaguzi wa afya unatarajiwa kushindwa. Kwa hiyo watchdog ilijibu kwenye kila deploy.

Mara nyingi ilipoteza mbio bila madhara. Mara moja ilishinda: ilimwandikia upya faili la compose (maelezo ya containers zipi zinapaswa kuendeshwa) katikati ya deploy, na kuacha seva bila container ya gateway kabisa — wakati kazi ya deploy ilisema imefanikiwa.

Marekebisho:

• Kufuli moja. Deploy sasa inachukua kufuli ile ile ya faili kama script ya bootstrap ya seva, kwa hiyo watchdog na deploy haziwezi kukimbia kwa wakati mmoja.
• Migomo minne, si mmoja. Watchdog inahitaji ukaguzi nne mfululizo ulioshindwa kabla ya kuchukua hatua. Huduma inayoondolewa kwenye trafiki haionekani tena kama imekufa.
• Ufafanuzi mmoja. Faili la compose sasa lina chanzo kimoja tu, linalochapishwa kwa seva, badala ya nakala zinazoweza kutofautiana.
• Thibitisha, usiamini. Kazi ya deploy haipiti tena kwa sababu amri ilirudisha jibu. Inakagua API, orchestrator, gateway na worker wa uchapishaji wa kila seva kabla ya kufanikiwa.

Tatizo la 2: seva iliondoka kabla trafiki haijaondoka

Tatizo la pili lilikuwa kimya zaidi. Deploy inapoondoa seva kwenye trafiki, seva huanza kujibu endpoint yake ya afya kwa 503 ili load balancer iiondoe kwenye mzunguko. Yetu ilifanya hivyo kwa sekunde 5, kisha ikazima.

Lakini ALB ilikagua afya mara chache tu, na ilihitaji ukaguzi kadhaa mfululizo ulioshindwa kabla ya kuacha kuelekeza kwenye lengo — hadi takriban sekunde 60 kutoka mwanzo hadi mwisho. Kwa hiyo kwa takriban sekunde 55, load balancer iliendelea kutuma maombi halisi kwa seva ambayo tayari ilikuwa imeacha kusikiliza. Hayo ndiyo yalikuwa 502 zetu.

Marekebisho yalikuwa kufanya nyakati hizo mbili zikubaliane:

• Target group sasa inakagua kila sekunde 5 na inaweka lengo kuwa lisilo na afya baada ya ukaguzi 2 ulioshindwa — takriban sekunde 10 kugundua.
• Drain inaendelea kutoa trafiki halisi kwa sekunde 15 baada ya kuanza kushindwa ukaguzi wa afya, kwa hiyo daima kuna mwingiliano.
• Mipangilio hii inaishi kwenye script inayoandaa miundombinu, si kwenye console ambayo mtu aliibofya mara moja.

Kuhakikisha namba zinashikamana

Muda kama huu unategemeana. Drain lazima idumu zaidi ya muda ambao balancer inahitaji kugundua; drain pamoja na kuzima lazima zimalizike kabla container haijaulazimishwa kufungwa. Ni rahisi kwa mtu kubadilisha namba moja baada ya miezi sita na kurudisha hitilafu kimya kimya.

Kwa hiyo tuliandika uhusiano huo kama majaribio: drain lazima iwe ndefu kuliko muda wa ukaguzi mara kizingiti cha kushindwa; muda wa kurudi kuwa na afya lazima ubaki mfupi; drain yote lazima itoshe ndani ya muda wa neema wa kusimama wa container. Ukibadilisha namba moja bila nyingine, CI inashindwa. Tulijaribu majaribio yenyewe kwa mutation — tulibadilisha kila namba kuwa thamani mbaya na kuhakikisha jaribio moja linaikamata.

Kupima deploy ni rahisi kukosea

Kipimo chetu cha kwanza kilisema deploy safi ilikuwa imevunjika kwa takriban 3%. Haikuwa hivyo. Tulikuwa tunahesabu kila jibu lisilo 200, na 503 kutoka endpoint ya afya wakati wa drain si kushindwa — ni drain ikifanya kazi yake, ikiiambia balancer isichague seva hiyo wakati inaendelea kutoa maombi halisi.

Kinachohisiwa na watumiaji ni 502: ombi lilifika kwa chochote. Kuhesabu hizo pekee kulitoa picha halisi — 10, kisha 6, kisha 0 katika deploys tatu za uzalishaji.

Tulichojifunza

• Kujiponya kunahitaji kujua kuhusu kukatika kwa mpango. Watchdog isiyoweza kutofautisha deploy na ajali hatimaye itapigana na deploy.
• Drain ni mkono wa kupeana. Seva lazima iendelee kuhudumia hadi load balancer iwe imethibitishwa kuacha kutuma trafiki, na muda huo umewekwa kwenye balancer, si kwenye seva.
• Weka kanuni zisizobadilika kama majaribio. Namba za uendeshaji hupotoka. Majaribio yanayozihusianisha zenyewe hayapotoki.
• Amua unachopima kabla ya kupima. “Makosa” ilikuwa kipimo kibaya; “maombi yaliyofika kwa chochote” ilikuwa sahihi.

Ikiwa unachapisha app kwenye Mythex, hakuna kati ya haya kinachoonekana kwako — ndiyo lengo. Inayohusiana: jinsi app yako iliyochapishwa inavyobaki hewani unapoichapisha upya.