Testiramo na produkciji: Canary Deployment

Kanarin — majhna ptica, ki nenehno poje. Te ptice so občutljive na metan in ogljikov monoksid. Tudi že ob majhni koncentraciji odvečnih plinov v zraku izgubijo zavest ali umrejo. Zlatarji in rudarji so nosili ptice s seboj: dokler kanarini pojejo, se lahko dela, če utihnejo — v rudniku je plin in čas je, da se umaknejo. Rudarji so žrtvovali majhne ptice, da so si zagotovili varno vrnitev iz rudnikov.

Podobna praksa se je uveljavila tudi v IT. Na primer, pri običajni nalogi uvajanja nove različice storitve ali aplikacije v produkcijo, s testiranjem pred tem. Testno okolje je lahko predrago, avtomatizirani testi ne pokrivajo vsega, kar bi želeli, ne testirati pa in žrtvovati kakovost je tvegano. Prav v takšnih primerih pomaga pristop Canary Deployment, pri katerem se na novo različico spusti malo pravega produkcijskega prometa. Ta pristop pomaga varno preveriti novo različico v produkciji, žrtvovati malo v imenu velikega cilja. Več o tem, kako pristop deluje, kako je koristen in kako ga uresničiti, bo razložil Andrej Markelov (Andrey_V_Markelov), na primeru implementacije v podjetju Infobip.

Andrej Markelov — vodilni inženir-programer v Infobipu, ki se že 11 let ukvarja z razvojem aplikacij v Javi na področju financ in telekomunikacij. Razvija Open Source produkte, aktivno sodeluje v Atlassian Community in piše vtičnike za Atlassianove produkte. Evangelist Prometheus, Docker in Redis.

O podjetju Infobip

Gre za globalno telekomunikacijsko platformo, ki bankam, trgovini, spletnim trgovinam in transportnim podjetjem omogoča pošiljanje sporočil strankam preko SMS-ov, push obvestil, e-pošte in glasovnih sporočil. V takšnem poslu sta stabilnost in zanesljivost ključnega pomena, da stranke pravočasno prejemajo sporočila.

IT-infrastruktura Infobipa v številkah:

• 15 podatkovnih centrov po vsem svetu;
• 500 edinstvenih storitev v obratovanju;
• 2500 primerkov storitev, kar je veliko več kot ekip;
• 4,5 TB mesečnega prometa;
• 4,5 milijarde telefonskih številk;

Poslovanje raste, skupaj s številom izdaj. Izvajamo 60 izdaj na dan, ker stranke želijo več možnosti in zmogljivosti. A to je težavno — storitev je veliko, ekip pa premalo. Moramo hitro pisati kodo, ki mora delovati v produkciji brez napak.

Izdaje

Tipična izdaja kod nas se odvija ovako. Na primer, postoje servisi A, B, C, D i E, od kojih svaki razvija zasebna ekipa.

U nekom trenutku, ekipa servisa A odlučuje da implementira novu verziju, ali ekipe servisa B, C, D i E o tome ne znaju. Ekipa servisa A ima dve mogućnosti.

Izvršiće inkrementalnu izdaju: prvo će zameniti jednu verziju, a zatim drugu.

Ali postoji i druga mogućnost: ekipa pronađe dodatne resurse i servere, implementira novu verziju, a zatim prebacuje usmerivač, i verzija počinje da radi u produkciji.

U svakom slučaju, nakon implementacije gotovo uvek se javljaju problemi, čak i ako je verzija testirana. Testirati se može ručno, može automatizovano, ili se može i ne testirati — problemi će se javiti u svakom slučaju. Najjednostavniji i najispravniji način da se reše — vratiti se na radnu verziju. Tek potom se može razmatrati o šteti, uzrocima i otkloniti ih.

Dakle, šta želimo?

Problemi nam nisu potrebni. Ako klijenti otkriju probleme brže od nas, to će uticati na reputaciju. Zato moramo pronalaziti probleme brže od klijenata.Radeći na vreme, minimizujemo štetu.

U isto vreme, želimo ubrzanju implementacije, kako bi sve išlo brzo, lako, prirodno i bez napora za tim. Inženjeri, DevOps inženjeri i programeri treba da se čuvaju — izdavanje nove verzije je stres. Tim nije potrošni materijal, težimo racionalnom korišćenju ljudskih resursa..

Problemi s implementacijom

Klijentski saobraćaj je nepredvidiv.Nemoguće je predvideti kada će klijentski saobraćaj biti minimalan. Ne znamo kada i gde će klijenti započeti svoje kampanje — možda noćas u Indiji, a sutra u Hong Kongu. Uzimajući u obzir veliku razliku u vremenskim zonama, implementacija čak i u 2 sata ujutru ne garantuje da klijenti neće biti pogođeni.

Problemi dobavljača.Mesindžeri i dobavljači su naši partneri. Ponekad imaju prekide koji izazivaju greške tokom implementacije novih verzija.

Raspodeljene ekipe.Ekipa koja razvija klijentsku stranu i backend nalaze se u različitim vremenskim zonama. Zbog toga često ne mogu da se dogovore međusobno.

Data centri se ne mogu ponoviti na stendu.U jednom data centru ima 200 ormara — to nije moguće ponoviti u pesku čak ni približno.

Nedovoljni prekidinisu dozvoljeni! Imamo dozvoljeni nivo dostupnosti (Error Budget), kada radimo 99,99% vremena, a preostali procenti predstavljaju 'pravo na grešku'. Postizanje 100% pouzdanosti je nemoguće, ali je važno stalno pratiti padove i prekide.

Klasične metode rešenja

Pisati kod bez grešaka. Kada sam bio mladi programer, menadžeri su dolazili kod mene sa zahtevom da se sprovede verzija bez grešaka, ali to nije uvek moguće.

Pisati testove. Testovi funkcionišu, ali ponekad ne onako kako želi biznis. Zarađivanje novca nije zadatak testova.

Testirati na stejdžu. Tokom 3,5 godine mog rada u Infobip-u, nisam ni jednom video da stanje na stejdžu barem delimično odgovara onome u produkciji.

Čak smo pokušali razviti ovu ideju: prvo smo imali stejdž, zatim preprodukciju, a onda preprodukciju preprodukcije. Ali to nije pomoglo - nisu se poklapali ni po kapacitetu. Sa stejdžom možemo garantovati osnovnu funkcionalnost, ali ne znamo kako će ona raditi pod opterećenjem.

Izlaznu verziju pravi onaj koji je razvio. To je dobra praksa: čak i ako neko menja naziv komentara, odmah se dodaje u produkciju. To pomaže razvijanju odgovornosti i ne zaboravljanju na izvršene izmene.

Dodatne komplikacije takođe postoje. Za programera je to stres - potrošiti mnogo vremena da sve proveri ručno.

Dogovorene verzije. Ova opcija obično dolazi od menadžmenta: 'Dogovorimo se da svakodnevno testirate i dodajete nove verzije'. To ne funkcioniše: uvek postoji tim koji čeka na ostale ili obrnuto.

Smoke testovi

Još jedan način da rešimo naše probleme sa deploy-om. Razmotrimo kako funkcionišu smoke testovi na prethodnom primeru, kada tim A želi da implementira novu verziju.

Prvo tim implementira jedan instans na produkciju. Porukama u instans od mock-a imitira se pravi saobraćaj, kako bi se poklopio sa normalnim svakodnevnim saobraćajem. Ako je sve u redu, tim prebacuje novu verziju na korisnički saobraćaj.

Druga opcija - implementirati sa dodatnim hardverom. Tim ga testira na produkciji, zatim prebacuje, i sve funkcioniše.

Nedostaci smoke testova:

• Testom se ne može vjerovati. Gdje nabaviti isti promet kao na produkciji? Mogu se koristiti jučerašnji ili tjedni promet, ali to ne mora uvijek odgovarati trenutnom.
• Teško se održava. Morat ćemo održavati testne račune, stalno ih resetirati prije svake implementacije, kada se u skladište šalju aktivni zapisi. To je teže nego napisati test u vlastitoj pijeskovitoj igri.

Jedina prednost ovdje je — možemo provjeriti performanse.

Canary objave

Zbog nedostataka smoke testova počeli smo koristiti canary objave.

Praksa, slično tome kako su rudari koristili kanarince za indikaciju razine plinova, našla je svoje mjesto i u IT-u. Pustili smo malo pravog produkcijskog prometa na novu verziju, nastojeći se uklopiti u Ugovor o razini usluge (SLA). SLA je naše ‘pravo na grešku’ koje možemo iskoristiti jednom godišnje (ili u nekom drugom vremenskom periodu). Ako sve prođe dobro, dodajemo više prometa. Ako ne — vraćamo prethodne verzije.

Implementacija i nijanse

Kako smo implementirali canary objave? Na primjer, grupa klijenata šalje poruke putem naše usluge.

Implementacija izgleda ovako: uklanjamo jednu čvor iz ravnoteže opterećenja (1), mijenjamo verziju (2) i posebno puštamo malo prometa (3).

U načelu, u grupi će svi biti sretni, čak i ako jedan korisnik bude nezadovoljan. Ako je sve u redu — mijenjamo sve verzije.

Prikazat ću shematski kako to izgleda za mikroslužbe u većini slučajeva.

Postoji Otkriće usluga i još dvije usluge: S1N1 i S2. Prva usluga (S1N1) obavještava Otkriće usluga kada pokrene, a Otkriće usluga je pamti. Druga usluga s dva čvora (S2N1 i S2N2) također obavještava Otkriće usluga prilikom pokretanja.

Druga usluga za prvu funkcionira kao poslužitelj. Prva traži od Otkrića usluga informacije o svojim poslužiteljima, a kada ih primi — pronalazi ih i provjerava (‘health check’). Kada provjeri, šalje im poruke.

Kada netko želi implementirati novu verziju druge usluge, obavještava Otkriće usluga da će druga čvora biti canary čvora: na nju će se slati manje prometa jer će sada doći do implementacije. Uklanjamo canary čvor iz ravnoteže opterećenja i prva usluga ne šalje promet prema njoj.

Menjamo verzijo in Service Discovery ve, da je druga vozlišča zdaj canary - lahko ji dodelimo manj obremenitve (5%). Če je vse v redu, spremenimo verzijo, povrnemo obremenitve in nadaljujemo z delom.

Za to potrebujemo:

• balansiranje;
• nadzor, saj je pomembno vedeti, kaj pričakuje vsak uporabnik in kako podrobno delujejo naše storitve;
• analizo verzij, da razumemo, kako dobro bo nova verzija delovala v proizvodnji;
• avtomatizacija — napišemo zaporedje uvajanja (deployment pipeline).

Uravnoteženje

To je prvo, o čemer se moramo zamisliti. Obstajata dve strategiji balansiranja.

Najenostavnejša različica, kjer eno vozlišče vedno deluje kot canary. To vozlišče vedno prejema manj prometa in začnemo uvajati z njega. V primeru težav bomo primerjali njegovo delovanje pred uvajanjem in med njim. Na primer, če se število napak podvoji, se je povečala tudi škoda.

Canary vozlišče se določi med uvajanjem. Ko se uvajanje konča in mu odstranjujemo status canary vozlišča, se ravnotežje prometa obnovi. Z manjšim številom naprav bomo dobili pošteno porazdelitev.

Nadzor

Temelj canary izdaj. Natančno moramo razumeti, zakaj to počnemo in katere metrike želimo zbirati.

Primeri metrik, ki jih zbiramo iz naših storitev.

• Število napak, ki se zapisujejo v dnevnike. To je očiten pokazatelj, da vse deluje, kot bi moralo. Na splošno je to dobra metrike.
• Čas izvrševanja poizvedb (latency). To metriko spremljajo vsi, ker si vsi želijo delati hitro.
• Velikost vrste (throughput).
• Število uspešnih odgovorov na sekundo.
• Čas izvajanja 95% vseh poizvedb.
• Poslovne metrike: koliko denarja podjetje zasluži v določenem času ali odtok uporabnikov. Te metrike so za našo novo različico lahko pomembnejše od tistih, ki jih dodajajo inženirji.

Primeri metrik v večini priljubljenih sistemov za spremljanje.

Counter. To je neka naraščajoča količina, na primer, število napak. To metriko je enostavno interpolirati in proučevati graf: včeraj je bilo 2 napaki, danes pa 500, kar pomeni, da nekaj ni v redu.

Število napak na minuto ali na sekundo, to je najpomembnejši kazalnik, ki ga je mogoče izračunati z uporabo Counter. Ti podatki dajejo jasno sliko o delovanju sistema na daljavo. Poglejmo na primeru grafa števila napak na sekundo za dve verziji proizvodnega sistema.

V prvi različici je bilo malo napak, morda audita ni deloval. V drugi različici pa je vse precej slabše. Lahko z gotovostjo trdimo, da so težave, zato moramo povrniti to različico.

Merilo. Metrične enote so podobne štetjem, vendar beležimo vrednosti, ki se lahko povečujejo ali zmanjšujejo. Na primer, čas izvrševanja poizvedb ali velikost vrste.

Na grafu je primer časa odziva (latenca). Na grafu je vidno, da so različice podobne, z njimi je mogoče delati. Toda ob natančnejšem pregledu je opazna sprememba. Če se čas izvrševanja poizvedb povečuje ob dodajanju uporabnikov, je takoj jasno, da so težave — tega prej ni bilo.

Povzetek. Eden najpomembnejših kazalnikov za podjetje so percentili. Metrična enota kaže, da v 95% primerov naš sistem deluje tako, kot želimo. Smo pripravljeni sprejeti, da kje obstajajo težave, ker razumemo splošni trend, kako dobro ali slabo gre.

Orodja

ELK Stack. Izvajanje kanarčka je možno s pomočjo Elasticsearch — beležimo napake, ko se zgodijo dogodki. S preprostim API klicem lahko dobimo število napak v katerem koli trenutku in to primerjamo s preteklimi obdobji: GET /applg/_count?q=level:error.

Prometheus. Dobro se je izkazal pri Infobip. Omogoča izvajanje večdimenzionalnih metrik, saj se uporabljajo oznake.

Lahko uporabimo level, instance, service, jih kombiniramo v enem sistemu. S pomočjo offset lahko na primer pregledujemo vrednost količine pred enim tednom z enako ali eno ekipo. GET /api/v1/query?query={query}, gde {query}:

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

Analiza različic

Obstaja več strategij za analizo različic.

Gledamo metrike samo kanarčne vozlišča. Ena od najpreprostejših možnosti: implementiramo novo različico in preučujemo samo njeno delovanje. Ampak če inženir v tem času začne pregledovati dnevnike in nenehno nervozno osvežuje strani, ta rešitev ni nič drugačna od drugih.

Kanarčno vozlišče se primerja z vsakim drugim vozliščem. To je primerjava z drugimi instancami, ki delujejo s polnim prometom. Na primer, če se z malim prometom stvari slabo obnašajo ali niso boljše kot pri realnih instancah, nekaj ni v redu.

Kanarčno vozlišče se primerja s seboj v preteklosti. Nodi, dodeljene za canary, je mogoče primerjati z zgodovinskimi podatki. Na primer, če je bilo pred tednom vse v redu, se lahko zanašamo na te podatke, da razumemo trenutno situacijo.

Avtomatizacija

Želimo osvoboditi inženirje ročnega primerjanja, zato je pomembno uvesti avtomatizacijo. Proces uvajanja (deployment pipeline) običajno izgleda tako:

• začnemo;
• odstranimo nod iz pod uravnoteževalnika;
• nastavimo canary-nod;
• vključimo uravnoteževalnik z omejenim številom prometa;
• primerjamo.

Na tej točki izvajamo avtomatsko primerjavo. Kako lahko izgleda in zakaj je bolje kot preverjanje po uvajanju, bomo obravnavali na primeru iz Jenkins.

To je pipeline za Groovy.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary neuspešen, potrebno je vrniti"  
        return false
    }
}

Tu v zanki določamo, da bomo primerjali novo nodo eno uro. Če canary proces še ni končan — pokličemo funkcijo. Ta sporoča, ali je vse v redu ali ne: def isOk = compare(srv, canary, time, base, offset, metrics).

Če je vse v redu — sleep DEFAULT SLEEP, na primer, eno sekundo, in nadaljujemo. Če ne, izstopimo — uvajanje ni uspelo.

Opis metrike. Poglejmo, kako lahko izgleda funkcija compare na primeru DSL.

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

Recimo, da primerjamo število napak in želimo vedeti število napak na sekundo v zadnjih 5 minutah.

Imamo dve vrednosti: osnovno in canary-nodo. Vrednost canary-node je trenutna. Osnovna — baseValue — je vrednost katere koli druge ne canary-node. Primerjamo vrednosti med seboj po formuli, ki jo postavimo na podlagi svojega znanja in opazovanj. Če je vrednost canaryValue slaba, potem uvajanje ni uspelo in se vrnemo nazaj.

Zakaj je to vse potrebno?

Človek ne more preveriti stotine in tisoče metrik, še posebej hitro. Avtomatsko primerjanje pomaga preveriti vse metrike in hitro obvesti o težavah. Čas obvestila je kritičen: če se je kaj zgodilo v zadnjih 2 sekundah, bo škoda manjša, kot če bi se to zgodilo pred 15 minutami. Medtem ko nekdo opazi težavo, napiše podpori, in podpora se obrne na nas, da se vrnemo nazaj, lahko izgubimo stranke.

Če je postopek uspel in je vse v redu, samodejno uvedemo vse druge vozlišča. V tem času inženirji ne delajo ničesar. Šele ko zagnajo canary, se odločijo, katere metrike uporabiti, koliko časa naj traja primerjava in katero strategijo uporabiti.

Če se pojavijo težave, samodejno vrnemo canary vozlišče, delamo na prejšnjih različicah in odpravljamo napake, ki smo jih našli. Po metrikah jih je enostavno najti in opaziti škodo nove različice.

Ovir

Vsekakor ni enostavno uresničiti tega. Predvsem potrebujemo splošni sistem nadzora. Inženirji imajo svoje metrike, podpora in analitiki druge, podjetje tretje. Splošni sistem je skupen jezik, ki ga uporabljata podjetje in razvoj.

Treba je preveriti v praksi stabilnost metrik. Preverjanje pomaga razumeti, kakšen minimalen niz metrik potrebujemo za zagotavljanje kakovosti..

Kako to doseči? Uporabiti canary storitev ne ob uvedbi. Dodamo v stari različici neko storitev, ki lahko kadarkoli prevzame katero koli določen vozlišče in zmanjša promet brez uvedbe. Po tem primerjamo: preučujemo napake in iščemo mejo, kadar dosežemo kakovost.

Kakšno korist smo dobili od canary izdaj

Minimizirali smo odstotek škode zaradi napak. Večina napak pri uvedbi se zgodi zaradi neskladnosti nekaterih podatkov ali prioritet. Takšnih napak je postalo precej manj, ker lahko težavo rešimo v prvih sekundah.

Optimizirali smo delo ekip. Novinci imajo "pravico do napake": lahko uvedejo v produkcijo brez strahu pred napakami, pojavijo se dodatne pobude in spodbude za delo. Če kaj pokvarijo, to ne bo kritično, tisti, ki je naredil napako, ne bo odpuščen.

Samodejno smo uvedli. To ni več ročni proces kot prej, ampak prava avtomatizirana. Poteka pa dlje.

Določili smo pomembne metrike. Celo podjetje, od poslovanja do inženirjev, razume, kaj je res pomembno v našem produktu, katere metrike, na primer odtok in pritok uporabnikov. Nadzorujemo proces: testiramo metrike, uvajamo nove, gledamo, kako delujejo stare, da zgradimo sistem, ki bo bolj dobičkonosen.

Imamo veliko število odličnih praks in sistemov, ki nam pomagajo. Kljub temu si prizadevamo biti profesionalci in opraviti svoje delo kakovostno, ne glede na to, ali imamo sistem, ki nam pomaga, ali ne.

Inženirski pristopi in prakse — glavna osredotočenost konference TechLead Conf. Če ste dosegli uspehe na poti k tehnični odličnosti in ste pripravljeni deliti, kaj vam je pri tem pomagalo, — se prijavite za predavanje.

Načrtujemo izvedbo TechLead Conf 8. junija. Zavedamo se, da je trenutno težko sprejemati odločitve o sodelovanju na konferenci. A hkrati menimo, da karantena ni razlog za ustavljanje profesionalne komunikacije in razvoja. Zato bomo v vsakem primeru našli način, kako razpravljati o nalogah tehničnih vodij in pristopih k njihovemu reševanju — če bo treba, bomo prešli na splet in tam razvili mrežno povezovanje!

Izvor: habr.com