Kuidas saime deploy-d nullini 502-vigadeni

Iga kord, kui deploy-sime Mythexi tagaosa, ebaõnnestus mõni päring veaga 502 Bad Gateway. Mitte palju — aga 502 deploy-i ajal tähendab, et kellegi klõps ei teinud midagi või ehitus, mida ta jälgis, jäi hetkeks seisma. Jälgisime selle kaks eraldi probleemini: isetervendav valvur, mis võitles meie deploy-dega, ja lõhe ajal, mil server lõpetas kuulamise, ja ajal, mil koormusjaotaja lõpetas talle liikluse saatmise. Kolme järjestikuse tootmise deploy-ga pärast parandusi langes arv 10-lt 6-ni ja seejärel 0-ni.

Seadistus

Meie API ja orkestraator töötavad konteinerina väikeses serverigrupis AWS Application Load Balanceri (ALB) taga. Deploy uuendab ühe serveri korraga: tühjendab vanad konteinerid, käivitab uued ja liigub edasi. Igal serveril on valvur, mis kontrollib, et konteinerid töötaksid, ja taaskäivitab need, mis ei tööta — see on olemas selleks, et kukkunud protsess kell kolm öösel tuleks tagasi ilma, et keegi ärkaks.

Mõlemad on iseseisvalt mõistlikud. Koos ei olnud nad.

Probleem 1: valvur võistles deploy-ga

Valvur käis kord minutis ja „parandas“ ühe ebaõnnestunud tervisekontrolli järel. Deploy tühjendab teenuseid tahtlikult kuni 150 sekundit — selle aja jooksul peab tervisekontroll just nimelt ebaõnnestuma. Seega käivitus valvur iga deploy-i ajal.

Enamasti kaotas ta võistluse kahjutult. Kord võitis ta: ta kirjutas ümber compose-faili (kirjelduse, milliseid konteinereid peaks käima) deploy-i keskel ja jättis serveri ilma väravakonteinerita, samal ajal kui deploy-töö teatas edust.

Parandused:

• Üks lukk. Deploy võtab nüüd sama faililuku, mis serveri bootstrap-skript, nii et valvur ja deploy ei saa kunagi koos käia.
• Neli hoiatust, mitte üks. Valvur vajab neli järjestikust ebaõnnestunud kontrolli enne tegutsemist. Tühjendatav teenus ei paista enam surnuna.
• Üks definitsioon. Compose-failil on nüüd täpselt üks allikas, mis avaldatakse serveritele, selle asemel et koopiad, mis võiksid lahkneda.
• Kontrolli, ära usalda. Deploy-töö ei õnnestu enam seetõttu, et käsk tagastas midagi. Enne edukaks saamist kontrollib ta iga serveri API-d, orkestraatorit, väravat ja avaldamise töötajat.

Probleem 2: server lahkus enne liiklust

Teine probleem oli vaiksem. Kui deploy tühjendab serveri, hakkab server oma tervise lõpp-punkti vastama 503-ga, et koormusjaotaja ta rotatsioonist välja võtaks. Meie server tegi seda 5 sekundit ja seejärel lülitus välja.

Aga ALB kontrollis tervist ainult aeg-ajalt ja vajas sihtmärgi suunamise lõpetamiseks mitut järjestikust ebaõnnestunud kontrolli — kokku umbes 60 sekundit. Seega umbes 55 sekundit saatis koormusjaotaja päris päringuid serverile, mis oli juba kuulamise lõpetanud. Need olid meie 502-d.

Parandus oli viia kaks ajajoont kokku:

• Sihtrühm kontrollib nüüd tervist iga 5 sekundi järel ja märgib sihtmärgi tervetuks pärast 2 ebaõnnestumist — märkamiseks umbes 10 sekundit.
• Tühjendus teenindab päris liiklust 15 sekundit pärast seda, kui tervisekontrollid hakkavad ebaõnnestuma, nii et kattuvus on alati olemas.
• Need seaded elavad skriptis, mis infrastruktuuri üles seab, mitte konsoolis, kuhu keegi kord klõpsas.

Arvude kokkuhoidmine

Sellised ajastused sõltuvad üksteisest. Tühjendus peab kestma kauem kui koormusjaotaja vajab selle märkamiseks; tühjendus koos seiskamisega peab lõppema enne, kui konteiner sunniviisiliselt tapetakse. Kuue kuu pärast on lihtne, et keegi muudab ühe arvu ja toob vea vaikselt tagasi.

Seetõttu kirjutasime need seosed testidena lahti: tühjendus peab olema pikem kui tervisekontrolli intervall korrutatuna ebaõnnestumiste lävega; aeg, mis kulub uuesti tervetuks märkimiseks, peab jääma lühikeseks; kogu tühjendus peab mahtuma konteineri seiskamise armuajasse. Muuda ühte arvu ilma teisteta ja CI ebaõnnestub. Testisime ka testide enda mutatsioonidega — muutsime iga arvu valeks väärtuseks ja kontrollisime, et test selle kinni püüdis.

Deploy mõõtmine on kerge valesti teha

Meie esimene mõõtmine ütles, et puhas deploy oli umbes 3% katki. Ei olnud. Me lugesime iga mitte-200 vastust ja tervisekontrolli 503 tühjendamise ajal ei ole viga — see on tühjendus, mis teeb oma tööd, öeldes koormusjaotajale, et ta seda serverit ei valiks, kuni see veel päris päringuid teenindab.

Kasutajad tunnevad 502-d: päring ei jõudnud kuhugi. Ainult neid lugedes saime õige pildi — 10, siis 6, siis 0 kolme tootmise deploy-ga.

Mida sellest õppisime

• Isetervendamine peab teadma planeeritud seisakust. Valvur, mis ei oska deploy-d kukkumisest eristada, võitleb lõpuks deploy-ga.
• Tühjendus on käteloksutus. Server peab teenindama, kuni koormusjaotaja on tõestatult liikluse saatmise lõpetanud, ja see ajastus seatakse koormusjaotajale, mitte serverile.
• Kodeeri invariandid testidena. Operatiivsed arvud lähevad lahku. Testid, mis seovad need üksteisega, ei lähe.
• Otsusta, mida mõõdad, enne kui mõõdad. „Vead“ oli vale mõõdik; „päringud, mis ei jõudnud kuhugi“ oli õige.

Kui avaldad Mythexis rakenduse, ei ole sulle see kõik nähtav — ja just see on mõte. Seotud: kuidas sinu avaldatud rakendus jääb üles ka siis, kui seda uuesti avaldad.