Kā panācām izvietošanu līdz nullei 502 kļūdu

Katru reizi, kad izvietojām Mythex backend, daži pieprasījumi neizdevās ar 502 Bad Gateway. Ne daudz, bet 502 izvietošanas laikā nozīmē, ka kāda klikšķis nedarīja neko vai būve, ko kāds vēroja, uz brīdi apstājās. Mēs to izsekojām līdz divām atsevišķām problēmām: pašdziedinošam uzraudzības procesam, kas cīnījās ar mūsu izvietošanām, un plaisai starp brīdi, kad serveris pārtrauca klausīties, un brīdi, kad slodzes sadalītājs pārtrauca tam sūtīt satiksmi. Pēc labojumiem trīs secīgās ražošanas izvietošanās skaits samazinājās no 10 līdz 6 un līdz 0.

Iestatījums

Mūsu API un orķestrators darbojas kā konteineri nelielā serveru grupā aiz AWS Application Load Balancer (ALB). Izvietošana atjaunina vienu serveri vienlaikus: tā iztukšo vecos konteinerus, palaiž jaunos un pāriet tālāk. Uzraudzības process katrā serverī pārbauda, vai konteineri darbojas, un restartē visu, kas nedarbojas. Tas pastāv, lai konteiners, kas 3 naktī nokrīt, atgrieztos bez tā, ka kādam jāpamostas.

Abas lietas atsevišķi ir saprātīgas. Kopā tās nebija.

1. problēma: uzraudzība sacentās ar izvietošanu

Uzraudzība darbojās reizi minūtē un „dziedināja“ pēc viena neizdevušās veselības pārbaudes. Izvietošana tīšām iztukšo pakalpojumus līdz 150 sekundēm, un tā laikā veselības pārbaudei vajadzētu neizdoties. Tātad uzraudzība aktivizējās katrā izvietošanā.

Vairumā gadījumu tā zaudēja sacensību nekaitīgi. Reiz tā uzvarēja: tā pārrakstīja compose failu (aprakstu, kuriem konteineriem jādarbojas) izvietošanas vidū un atstāja serveri bez vārtejas konteinera vispār, kamēr izvietošanas darbs ziņoja par veiksmi.

Labojumi:

• Viena bloķēšana. Izvietošana tagad ņem to pašu failu bloķēšanu, ko servera sagatavošanas skripts, tāpēc uzraudzība un izvietošana nekad nedarbojas vienlaikus.
• Četri trāpījumi, nevis viens. Uzraudzībai vajag četras secīgas neizdevušās pārbaudes, pirms tā rīkojas. Izvadīts pakalpojums vairs neizskatās miris.
• Viena definīcija. Compose failam tagad ir tieši viens avots, publicēts uz serveriem, nevis kopijas, kas var atšķirties.
• Pārbaudi, nevis paļaujies. Izvietošanas darbs vairs neizdodas, jo komanda atgrieza kodu. Tas pārbauda katra servera API, orķestratoru, vārteju un publicēšanas darbinieku, pirms var izdoties.

2. problēma: serveris aizgāja pirms satiksmes

Otrā problēma bija klusāka. Kad izvietošana iztukšo serveri, serveris sāk atbildēt uz savu veselības galapunktu ar 503, lai slodzes sadalītājs to izņemtu no rotācijas. Mūsējais to darīja 5 sekundes, tad izslēdzās.

Bet ALB pārbaudīja veselību tikai retāk un vajadzēja vairākas neizdevušās pārbaudes pēc kārtas, pirms pārstāja sūtīt uz mērķi: līdz aptuveni 60 sekundēm kopā. Tātad apmēram 55 sekundes slodzes sadalītājs turpināja sūtīt reālus pieprasījumus serverim, kas jau bija pārtraucis klausīties. Tie bija mūsu 502 kļūdas.

Labojums bija padarīt abas laika līnijas saskaņotas:

• Mērķu grupa tagad pārbauda ik pēc 5 sekundēm un atzīmē mērķi kā neveselīgu pēc 2 neveiksmēm, aptuveni 10 sekundēs, lai to pamanītu.
• Iztukšošana turpina apkalpot reālu satiksmi 15 sekundes pēc tam, kad sāk neizdoties veselības pārbaudes, lai vienmēr būtu pārklāšanās.
• Šie iestatījumi dzīvo skriptā, kas nodrošina infrastruktūru, nevis konsolē, kur kāds reiz noklikšķināja.

Lai skaitļi turētu viens otru

Šie taimauti ir atkarīgi viens no otra. Iztukšošanai jābūt ilgākai par laiku, kas vajadzīgs slodzes sadalītājam, lai pamanītu; iztukšošanai plus izslēgšanai jābeidzas pirms konteiners tiek piespiedu kārtā nogalināts. Ir viegli, ka kāds pēc sešiem mēnešiem nomaina vienu skaitli un klusi atjauno kļūdu.

Tāpēc šīs attiecības ierakstījām kā testus: iztukšošanai jābūt ilgākai par veselības pārbaudes intervālu reizinātu ar neveiksmju slieksni; laikam, lai atkal tiktu atzīmēts kā vesels, jāpaliek īsam; visai iztukšošanai jāietilpst konteinera apturēšanas grace periodā. Ja maini vienu skaitli bez pārējiem, CI neizdodas. Mēs pārbaudījām pašus testus, mainot katru skaitli uz nepareizu vērtību un pārbaudot, vai kāds tests to pamanīja.

Izvietošanas mērīšana ir viegli kļūdaināma

Mūsu pirmais mērījums teica, ka tīra izvietošana bija apmēram 3% salauzta. Tā nebija. Mēs skaitījām katru ne-200 atbildi, un 503 no veselības galapunkta iztukšošanas laikā nav kļūme; tā ir iztukšošana, kas dara savu darbu, liekot slodzes sadalītājam nepaņemt šo serveri, kamēr tas turpina apkalpot reālus pieprasījumus.

Lietotājs jūt 502: pieprasījums nesasniedza neko. Tikai to skaitot, dabūjām īsto ainu: 10, tad 6, tad 0 trīs ražošanas izvietošanās.

Ko no tā guvām

• Pašdziedināšanās jāzina par plānotu dīkstāvi. Uzraudzība, kas nevar atšķirt izvietošanu no avārijas, galu galā cīnīsies ar izvietošanu.
• Iztukšošana ir rokasspiediens. Serverim jāturpina apkalpot, līdz slodzes sadalītājs pierādīti pārtraucis sūtīt satiksmi, un šis laiks ir iestatīts pie sadalītāja, nevis servera.
• Kodē invariantus kā testus. Operacionālie skaitļi novirzās. Testi, kas tos saista viens ar otru, nē.
• Izlem, ko mēri, pirms mēri. „Kļūdas“ bija nepareizs rādītājs; „pieprasījumi, kas nesasniedza neko“ bija pareizais.

Ja publicē lietotni Mythex, nekas no tā nav redzams tev, un tas ir mērķis. Saistīts: kā tava publicētā lietotne paliek tiešraidē, kamēr to pārpublicē.