Testime tootmises: Canary Deployment

Kanarialind on väike lind, kes laulab pidevalt. Need linnud on metaani ja vingugaasi suhtes tundlikud. Isegi väikese gaaside kontsentratsiooni korral õhus kaotavad nad teadvuse või surevad. Kulda otsijad ja kaevurid võtsid endaga linnud kaevandusse: kui kanarialind laulab, saab töötada, kui nad vaikivad — kaevanduses on gaas ja tuleb lahkuda. Kaevurid ohverdavad väikese lauluva lindu, et eluga kaevandusest välja pääseda.

Sarnane praktika on levinud ka IT-sektoris. Näiteks tavapärases ülesandes uue teenuse või rakenduse versiooni tootmisse juurutamiseks koos eelneva testimisega. Testimisvõimekus võib olla liiga kallis, automatiseeritud testid ei kata kõiki soovitud aspekte ja testimata jätmine ning kvaliteedi ohverdamine on riskantne. Just sellistes olukordades aitab kanaride juurutamise lähenemine, kus natuke tõelist tootmistegevust suunatakse uuele versioonile. Lähenemine aitab turvaliselt kontrollida uut versiooni tootmises, ohverdades natuke suurema eesmärgi nimel. Lähemalt, kuidas see lähenemine töötab, millist kasu see toob ja kuidas seda rakendada, räägib Andrei Markelov (Andrey_V_Markelov), tuues näite rakendamisest ettevõttes Infobip.

Andrei Markelov — juhtiv tarkvarainsener Infobipis, kellel on juba 11 aastat kogemust rakenduste arendamisel Java väljakutes finanssektoris ja telekommunikatsioonis. Ta arendab avatud lähtekoodiga tooteid, osaleb aktiivselt Atlassiani kogukonnas ja kirjutab pluginaid Atlassiani toodete jaoks. Prometheuse, Dockeri ja Redise evangelist.

Ettevõttest Infobip

See on globaalne telekommunikatsiooniplatvorm, mis võimaldab pankadel, jaekaubandusel, veebipoodidel ja transpordiettevõtetel edastada sõnumeid oma klientidele SMS-ide, push-teatete, e-kirjade ja häälteatega. Sellises äritegevuses on oluline stabiilsus ja usaldusväärsus, et kliendid saaksid sõnumid õigeaegselt.

Infobipi IT-infrastruktuur numbrites:

• 15 andmekeskust üle terve maailma;
• 500 ainulaadset teenust kasutuses;
• 2500 teenuse eksemplari, mis on palju rohkem kui meeskondi;
• 4,5 Tbyte kuus liiklust;
• 4,5 miljardit telefoninumbrit;

Äri kasvab ja koos sellega ka väljaannete arv. Teeme ligikaudu 60 väljaannet päevas, kuna kliendid soovivad rohkem võimalusi ja võimsust. Kuid see on keeruline — teenuseid on palju, aga meeskondi vähe. Peame kiiresti kirjutama koodi, mis peab tootmises töötama ilma vigadeta.

Väljalaske

Tüüpiline väljaanne toimub meil nii. Näiteks on meil teenused A, B, C, D ja E, millest igaüht arendab eraldi meeskond.

Mõnes hetkes otsustab teenuse A meeskond rakendada uut versiooni, kuid teenuste B, C, D ja E meeskonnad ei tea sellest. Teenuse A meeskonna jaoks on kaks varianti.

Teeb inkrementaalset väljaannet: esiteks asendab ühe versiooni ja siis teise.

Aga on teine variant: meeskond leidnud täiendavaid ressursse ja masineid, rakendab uue versiooni ja seejärel suunab ruuteri, ning versioon hakkab töötama tootmises.

Igatpidi, pärast rakendamist tekivad peaaegu alati probleemid, isegi kui versioon on testitud. Testida saab käsitsi, automatiseeritult või mitte testida — probleemid tekivad igal juhul. Kõige lihtsam ja õigem viis neid lahendada on naasta töötavale versioonile. Alles pärast seda saab tegeleda kahjude ja põhjustega ning need parandada.

Nii et, mida me soovime?

Probleemid pole meile vajalikud. Kui kliendid avastavad need kiiremini kui meie, kahjustab see meie mainet. Seetõttu peame leidma probleemid kiiremini kui kliendid.. Töötades ettepoole, minimaliseerime kahjud.

Samal ajal soovime me kiirendada rakendamist, et see toimuks kiiresti, lihtsalt, iseenesest ja ilma meeskonna stressita. Inseneride, DevOpsi inseneride ja programmide jaoks on oluline, et meeskonda hoida — uue versiooni väljaanne on stressirohke. Meeskond ei ole kuluartikkel, meie eesmärk on mõistlikult kasutada inimressursse..

Rakendamise probleemid

Kliendi liiklus on ettearvamatu. Ei ole võimalik ennustada, millal kliendi liiklus on minimaalne. Me ei tea, kus ja millal kliendid oma kampaaniaid käivitavad — võib-olla täna öösel Indias ja homme Hongkongis. Arvestades suurt ajavahet, ei taga isegi 2 tunni kohaliku rakendamise aeg, et kliendid ei kannata.

Teenusepakkujate probleemid. Messengrid ja teenusepakkujad on meie partnerid. Mõnikord esinevad neil tõrked, mis põhjustavad uusi versioone rakendades vigu.

Jagatud meeskonnad. Meeskonnad, kes töötavad kliendi osa ja tagaplaani kallal, asuvad erinevates ajavööndites. Seetõttu ei saa nad sageli omavahel kokku leppida.

Andmete keskuste kordamine arengutes. Ühes andmekeskuses on 200 riidet, seda isegi ligikaudselt testida ei õnnestu.

Aegidei ole lubatud! Meil on lubatud kättesaadavuse tase (Error Budget), kui me töötame 99,99% ajast, näiteks, ja ülejäänud protsendid on «veaõigus». 100% usaldusväärsuse saavutamine ei ole võimalik, kuid on oluline pidevalt jälgida kokkuvarisemisi ja seise.

Klassikalised lahenduse variandid

Kirjutada koodi ilma vigadeta. Kui olin noor arendaja, tulid minu juurde juhid palvega teha väljaanne ilma vigadeta, kuid see ei ole alati võimalik.

Kirjutada teste. Testid töötavad, kuid mõnikord mitte nii, nagu ettevõte soovib. Raha teenimine ei ole testide ülesanne.

Testida etapis. Kolme ja poole aasta jooksul, mil ma töötasin Infobipis, ei ole ma kunagi näinud, et etapi staatus vähemalt osaliselt kattuks tootmisega.

Me proovisin isegi seda ideed arendada: esmalt meil oli etapp, siis eelprojekteerimine ja seejärel eelprojekteerimise eelprojekteerimine. Kuid isegi see ei aidanud - need ei kattunud isegi võimsusest. Etapi puhul suudame tagada baastegevuse, kuid ei tea, kuidas see töötab koormuste korral.

Väljalasu teeb see, kes arendas. See on hea praktika: isegi kui keegi muudab kommentaari nime, lisab ta kohe tootmisse. See aitab arendada vastutust ja mitte unustada tehtud muudatusi.

Lisaks on ka täiendavaid keerukusi. Arendajale on see stress - kulutada palju aega, et kõik käsitsi kontrollida.

Kokkulepitud väljalasud. See variant pakub tavaliselt juhtkond: «Kokkulepe, et iga päev testite ja lisate uusi versioone». See ei toimi: alati on meeskond, kes ootab teisi või vastupidi.

Smoke-testid

Veel üks võimalus meie juurutamisprobleemide lahendamiseks. Vaatame, kuidas smoke-testid töötavad eelneva näite põhjal, kui meeskond A soovib juurutada uut versiooni.

Esiteks juurutab meeskond ühe instantsi tootmisse. Sõnumite instantsi kaudu simuleeritakse reaalset liiklust, et see kattuks normaalse igapäevase liiklusega. Kui kõik on korras, lülitab meeskond uue versiooni kasutajaliiklusele.

Teine variant - juurutada täiendava riistvaraga. Meeskond testib seda tootmises, siis lülitab selle sisse ja kõik töötab.

Smoke-testide puudused:

• Testidele ei saa usaldada. Kust saada sama liiklust nagu tootmises? Võib kasutada eilset või nädala vanust, kuid see ei pruugi alati vastata praegusele.
• Raskesti toetatav. Peab hoidma testkonto, pidevalt neid nullima enne iga juurutamist, kui salvestusse saadetakse aktiivsed kirjed. See on keerulisem kui kirjutada test oma liivakastis.

Ainus boonus on siin — saab kontrollida jõudlust.

Canary-julitised

Smoke-testide puuduste tõttu hakkasime kasutama canary-julitisi.

Praktika, sarnane sellele, kuidas kaevurid kasutasid kanareid gaasitaseme näitamiseks, on leidnud tee IT-sse. Me suuname veidi tõelist tootmisliiklust uue versiooni peale, püüdes samal ajal jääda teenuse taseme kokkuleppe (SLA) piiridesse. SLA on meie „veaõigus”, mida saame kasutada kord aastas (või mõne teise ajavahemiku jooksul). Kui kõik läheb hästi, lisame rohkem liiklust. Kui ei — taastame eelnevad versioonid.

Rakendamine ja nüansid

Kuidas me rakendasime canary-julitisi? Näiteks grupi kliendid saadavad sõnumeid meie teenuse kaudu.

Juurutamine käib nii: eemaldame ühe sõlme koormustasakaalust (1), muudame versiooni (2) ja suuname eraldi veidi liiklust (3).

Üldiselt on grupis kõik õnnelikud, isegi kui üks kasutaja on rahulolematu. Kui kõik on hästi — muudame kõik versioonid.

Näitan skeemiliselt, kuidas see enamasti mikroteenustes välja näeb.

On teenuse leidmine ja kaks teenust: S1N1 ja S2. Esimene teenus (S1N1) teatab teenuse leidmisele, kui käivitub, ja teenuse leidmine salvestab selle. Teine teenus kahe sõlmega (S2N1 ja S2N2) teatab samuti teenuse leidmisele käivitamisel.

Teine teenus esimese jaoks töötab serverina. Esimene küsib teenuse leidmiselt teavet oma serverite kohta, ja kui ta seda saab, otsib ja kontrollib neid („tervise kontroll”). Kui ta on kontrollinud, saadab ta neile sõnumeid.

Kui keegi tahab juurutada uut versiooni teisest teenusest, teatab ta teenuse leidmisele, et teine sõlm saab olema canary-sõlm: sinna suunatakse vähem liiklust, sest juurutamine toimub. Eemaldame canary-sõlme koormustasakaalust ja esimene teenus ei suuna sinna liiklust.

Muudame versiooni ja Service Discovery teab, et teine sõlm on nüüd canary — võime anda sellele vähem koormust (5%). Kui kõik on hästi, vahetame versiooni, taastame koormuse ja töötame edasi.

Selleks, et kogu see teostada, vajame:

• tasakaalustamine;
• monitooring, kuna on oluline teada, mida iga kasutaja ootab ja kuidas meie teenused täpselt töötavad;
• versioonide analüüs, et mõista, kui hästi uus versioon tootmises töötada saab;
• automaatika — kirjutame üles seadistamise järjekorra (deployment pipeline).

Tasakaalustamine

See on esimene asi, millele peaksime mõtlema. On olemas kaks tasakaalustamise strateegiat.

Lihtsaim variant, kui üks sõlm on alati canary. See sõlm saab alati vähem liiklust ja alustame deploy’d sellest. Probleemide korral võrdleme selle tööd enne ja ajal deploy’d. Näiteks, kui vigu on saanud kaks korda rohkem, siis on kahju kasvanud samuti kaks korda.

Canary-sõlm määratakse deploy käigus. Kui deploy on lõpule viidud ja me eemaldame selle canary-sõlme staatuse, taastub liikluse tasakaal. Vähemate masinate puhul saame ausa jaotuse.

Jälgimine

Canary-releases’i nurgakivi. Peame täpselt mõistma, miks me seda teeme ja milliseid mõõdikuid soovime koguda.

Mõõdikud, mida me oma teenustest kogume.

• Vigade arv, mis kirjutatakse logidesse. See on ilmne näitaja, et kõik töötab nii nagu peab. Üldiselt on see hea mõõdik.
• Päringute täitmise aeg (latency). Seda mõõdikut jälgitakse kõikjal, kuna kõik tahavad töötada kiiresti.
• Järjekorra suurus (throughput).
• Edukas vastuste arv sekundis.
• 95% kõigist päringutest täidavad ettenähtud aega.
• Ärimõõdikud: kui palju raha äri teenib teatud aja jooksul või kasutajate loobumine. Need mõõdikud meie uue versiooni jaoks võivad olla olulisemad kui need, mida insenerid lisavad.

Mõned näited mõõdikutest enamikes populaarsetes jälgimissüsteemides.

Counter. See on teatud tõusmine näiteks vigade arvu osas. Seda mõõdikut on lihtne interpoleerida ja graafikut uurida: eile oli 2 viga, aga täna 500, see tähendab, et midagi läks valesti.

Vigade arv minutis või sekundis, see on kõige olulisem näitaja, mille saab arvutada kasutades Counter’it. Need andmed annavad selge ülevaate süsteemi toimimisest ajas. Vaatame näiteks vigade arvu graafikut sekundis kahe tootmissüsteemi versiooni jaoks.

Esimeses versioonis oli vähe vigu, võib-olla ei töötanud audit. Teises versioonis on kõik palju hullem. On selge, et esinevad probleemid, seega peame selle versiooni tagasivoolama.

Gauge. Mõõdikud sarnanevad Counteriga, kuid me salvestame väärtusi, mis võivad nii suureneda kui ka väheneda. Näiteks päringute täitmise aeg või järjekorra suurus.

Graafikul on näide latentsusajast. Graafikult on näha, et versioonid on sarnased, nendega on võimalik töötada. Kuid kui tähelepanelikult vaadata, on märgata, kuidas suurus muutub. Kui päringute täitmise aeg suureneb koos kasutajate arvu suurenemisega, on kohe selge, et esinevad probleemid — varem seda ei olnud.

Kokkuvõte. Üks kõige olulisemaid äri näitajaid on protsentiilid. Näitaja näitab, et 95% juhtudest meie süsteem töötab nii, nagu soovime. Saame leppida, kui kuskil esinevad probleemid, kuna mõistame üldist suundumust, kui hästi või halvasti kõik on.

Tööriistad

ELK Stack. Canary rakendamine on võimalik, kasutades Elasticsearchi — salvestame sinna vead, kui sündmused toimuvad. Lihtsa API kõne abil saab igal ajal saada vigade arvu ja võrrelda seda varasemate ajavahemikega: GET /applg/_cunt?q=level:errr.

Prometheus. Tõestas end hästi Infobipis. See võimaldab ellu viia mitmemõõtmelisi mõõdikuid, kuna kasutatakse silte.

Saame kasutada level, instance, teenus, kombineerides need ühes süsteemis. Kasutades offset saame näiteks vaadata, mis oli väärtus nädal tagasi, lihtsalt ühe käsu abil GET /api/v1/query?query={query}, kus {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Versioonide analüüs

On mitmeid versioonide analüüsi strateegiaid.

Vaadata mõõdikud ainult canary-node'i kohta. Üks lihtsamaid variante: tõstsime üles uue versiooni ja uurime ainult selle tööd. Kuid kui insener sel ajal hakkab logisid uurima, pidevalt närviliselt lehti värskendades, siis ei erine see lahendus ülejäänutest.

Canary-node'I võrreldakse mis tahes teise node'iga. See on võrreldes teiste instantsidega, mis töötavad täiskoormusel. Näiteks, kui väiksema liikluse korral on olukord halvem või mitte parem kui tegelikel instantsidel, siis on midagi valesti.

Canary-node'i võrreldakse iseendaga minevikus. Canary'le eraldatud noodid on võrreldavad ajalooliste andmetega. Näiteks, kui nädal tagasi oli kõik hästi, saame neid andmeid kasutada, et mõista hetkeolukorda.

Automatiseerimine

Soovime vabastada insenerid käsitsi võrdlemisest, seetõttu on oluline rakendada automatiseerimist. Deploi (deploy pipeline) protsess näeb tavaliselt välja selline:

• alustame;
• eemaldame noodist koormustasakaalust;
• seame canary-noodi;
• lülitame koormustasakaalu piiritletud liiklusega;
• võrdleme.

Selles etapis rakendame automaatset võrdlemist. Kuidas see välja näeb ja miks on see parem kui kontrollimine pärast deploi'i, vaatame Jenkins'i näite põhjal.

See on pipeline Groovy'le.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary ebaõnnestus, tuleb tagasi pöörduda"  
        return false
    }
}

Siin tsüklis määrame, et võrreldeme uut nooti tunni jooksul. Kui canary protsess ei ole veel lõppenud — kutsume funktsiooni. See teatab, kas kõik on hästi või mitte: def isOk = compare(srv, canary, time, base, offset, metrics).

Kui kõik on hästi — sleep DEFAULT SLEEP, näiteks ühe sekundi ja jätkame. Kui mitte, siis välisma — deploi ei õnnestunud.

Mõõdiku kirjeldus. Vaatame, kuidas funktsioon compare näeb välja DSL'i näitel.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Oletame, et võrdleme vigade arvu ja tahame teada vigade arvu sekundis viimase 5 minuti jooksul.

Meil on kaks väärtust: baasile ja canary-noodile. Canarı-noodi väärtus — praegune. Alusväärtus — baseValue — on väärtus igast muust mitte canary-noodist. Võrdleme väärtusi omavahel oma kogemuste ja vaatlustest tuleneva valemi järgi. Kui canaryValue väärtus on halb, deploi ebaõnnestus ja me peame tagasi pöörduma.

Miks seda kõike on vaja?

Inimene ei saa kontrollida sadu ja tuhandeid mõõdikuid, veel vähem teha seda kiiresti. Automaatne võrdlemine aitab kontrollida kõiki mõõdikuid ja kiiruselt probleemidest teavitada. Teavitamise aeg on kriitiline: kui midagi juhtus viimase 2 sekundi jooksul, on kahju väiksem, kui see oleks juhtunud 15 minutit tagasi. Seni, kuni keegi probleemist märku annab, kirjutab tuge, ja tugiteenus soovib, et pöördume tagasi, võime kliente kaotada.

Kui protsess on läbitud ja kõik on hästi, deploy-ime kõik ülejäänud node'id automaatselt. Sel ajal ei tee insenerid midagi. Ainult siis, kui nad käivitavad canary, otsustavad nad, millised mõõdikud võtta, kui kaua võrreldakse ja millist strateegiat kasutada.

Kui tekivad probleemid — tagastame automaatselt canary-node'i, töötame varasemate versioonide peal ja parandame leitud vead. Mõõdikute põhjal on neid lihtne leida ja uusi versioone mõjutavaid probleeme näha.

Takistused

Seda ellu viia on muidugi keeruline. Esiteks on vajalik üldine jälgimissüsteem. Inseneridel on oma mõõdikud, tugiteenusel ja analüütikutel on teised, ning äril kolmandad. Ühine süsteem on ühine keel, millega äri ja arendus räägivad.

Peame praktikas kontrollima mõõdikute stabiilsust. Kontrollimine aitab mõista, milline minimaalne mõõdikute komplekt on vajalik kvaliteedi tagamiseks..

Kuidas seda saavutada? Kasutada canary-teenust mitte deploy hetkel. Lisame vanale versioonile mingi teenuse, mis igal hetkel suudab võtta mistahes eraldatud node'i, vähendada liiklust ilma deploy'ta. Seejärel võrreldame: uurime vigu ja otsime seda piiri, mil saavutame kvaliteedi.

Millist kasu oleme saanud canary-väljalaskmistest

Minimeerisime veadest tulenevate kahjude protsenti. Enamik deploy vigu toimub andmete ebakõlade või prioriteetide tõttu. Selliseid vigu on nüüd palju vähem, sest suudame probleemi lahendada esimestel sekunditel.

Optimeerisime meeskondade tööd. Uutel liikmetel on "viga teha": nad saavad deploy'ida tootmisse hirmu tundmata, tekkib lisainitsiatiiv ja stiimul töötada. Kui nad midagi rikuvad, siis see ei ole kriitiline ja vale teinud isikut ei vallandata.

Automatiseerisime deploy. See ei ole enam nagu varem käsitsi protsess, vaid tõeline automatiseeritud. Kuid see võtab kauem aega.

Toime on prioriseeritud oluliste mõõdikute. Kogu ettevõte, alates äri ja inseneridest, mõistab, mis on meie tootes tõeliselt oluline, näiteks kasutajate väljavool ja sissetulek. Me kontrollime protsessi: testime mõõdikuid, sisestame uusi, jälgime, kuidas vanad töötavad, et luua süsteem, mis teenib raha efektiivsemalt.

Meil on palju lahedaid praktikaid ja süsteeme, mis aitavad meid. Sellegipoolest püüame olla professionaalid ja teha oma tööd kvaliteetselt, olenemata sellest, kas meil on süsteem, mis aitab, või mitte.

Inseneritehnilised lähenemised ja praktikad — TechLead Conf konverentsi peamine fookus. Kui olete saavutanud edusamme tehnilise täiuslikkuse poole ja olete valmis rääkima, mis teid selles aitas, — esitage taotlus ettekande jaoks.

Plaanime korraldada TechLead Conf 8. juunil. Mõistame, et praegu on keeruline teha otsuseid konverentsil osalemise kohta. Kuid samas usume, et karantiin ei ole põhjus kutseaegset suhtlemist ja arengut peatada. Seetõttu leiame igal juhul viisi arutada tech lead'i ülesandeid ja nende lahendamise lähenemisviise — kui on vajalik, liikuge veebisisse ja käivitame seal võrgustiku!

Allikas: habr.com