A kanári egy kis madár, amely folyamatosan énekel. Ezek a madarak érzékenyek a metánra és a szén-monoxidra. Még a levegőben lévő kis gázkoncentrációtól is elvesztik az eszméletüket vagy meghalnak. Az aranyásók és bányászok mindig magukkal vitték a madaraikat: amíg a kanárik énekeltek, lehetett dolgozni, ha elhallgattak — veszélyes volt a bányában a gáz, és ideje volt elmenekülni. A bányászok feláldozták ezeket a kis madarakat, hogy életben maradhassanak.
Hasonló gyakorlat az IT területén is fellelhető. Például a szolgáltatás vagy alkalmazás új verziójának termelési környezetbe történő telepítése előtt végzett tesztelési feladatok során. A tesztkörnyezet túlságosan drága lehet, az automatizált tesztek nem fedik le mindazt, amit szeretnénk, és a minőség feláldozása kockázatos. Ilyen esetekben segít a Canary Deployment megközelítés, amikor egy kis mennyiségű valós termelési forgalmat engednek a új verzióra. Ez a megközelítés segít biztonságosan ellenőrizni az új verziót a termelési környezetben, feláldozva egy keveset a nagyobb cél érdekében. Részletesebben, hogyan működik ez a megközelítés, miben hasznos és hogyan valósítható meg, elmondja Andreij Markelov (), a megvalósítás példáján keresztül az Infobip cégnél.
Andreij Markelov — a Infobip vezető programozó mérnöke, már 11 éve foglalkozik Java alapú alkalmazások fejlesztésével a pénzügyi és telekommunikációs területeken. Open Source termékeket fejleszt, aktívan részt vesz az Atlassian közösségi életében és plugineket ír az Atlassian termékekhez. A Prometheus, Docker és Redis evangelistája.
Az Infobip cégről
Ez egy globális telekommunikációs platform, amely lehetővé teszi bankok, kiskereskedők, online boltok és szállítmányozási cégek számára, hogy üzeneteket küldjenek ügyfeleiknek SMS, push, e-mailek és hangüzenetek révén. Ezen a piacon a stabilitás és megbízhatóság elengedhetetlen, hogy az ügyfelek időben megkapják az üzeneteket.
Az Infobip IT infrastruktúrája számokban:
- 15 adatközpont világszerte;
- 500 egyedi szolgáltatás használatban;
- 2500 szolgáltatás példány, ami sokkal több, mint a csapatok száma;
- 4,5 TB havi forgalom;
- 4,5 milliárd telefonszám;
A vállalkozás növekszik, és ezzel párhuzamosan a kiadások száma is. Naponta 60 kiadást végzünk, mert az ügyfelek több lehetőséget és kapacitást akarnak. De ez nehéz — sok szolgáltatás van, de kevés csapat. Gyorsan kell kódot írni, amelynek termelési környezetben hibamentesen kell működnie.
Kiadások
A tipikus kiadás nálunk így zajlik. Például vannak A, B, C, D és E szolgáltatások, mindegyiket külön csapat fejleszti.
Valamikor az A szolgáltatás csapata úgy dönt, hogy kiad egy új verziót, de a B, C, D és E szolgáltatások csapatai erről nem tudnak. Két lehetőség van arra, hogy az A szolgáltatás csapata mit tesz.
Levezeti a fokozatos kiadást: először egy verziót cserél, majd a másikat.
De van egy másik lehetőség: a csapat talál extra kapacitásokat és gépeket, kiadja az új verziót, majd átkapcsolja az útválasztót, és a verzió működni kezd a termelésben.
Bármelyik esetben a kiadás után szinte mindig felmerülnek problémák, még akkor is, ha a verzió tesztelve van. Kézi tesztelés, automatizált tesztelés, vagy akár a tesztelés kihagyása — a problémák bármikor fel fognak merülni. A legegyszerűbb és leghelyesebb módja a megoldásnak, ha visszatérünk a működő verzióra. Csak utána foglalkozhatunk a kárral, az okokkal és azok kijavításával.
Tehát mit szeretnénk?
A problémákra nincs szükségünk. Ha az ügyfelek hamarabb fedezik fel őket, az kárt okoz a hírnevünkben. Ezért nekünk kell gyorsabban észlelni a problémákat, mint az ügyfelek.. Proaktív munkával minimalizáljuk a kárt.
Ugyanakkor szeretnénk felgyorsítani a kiadást, hogy ez gyorsan, könnyen, magától értetődően és csapatnyomás nélkül történjen. Az mérnököket, DevOps mérnököket és programozókat meg kell óvni — az új verzió kiadása stresszes. A csapat nem elhasználódó anyag, törekszünk a humán erőforrások ésszerű kihasználására..
A kiadási problémák
Az ügyfélforgalom kiszámíthatatlan. Nem lehet előre megmondani, mikor lesz minimális az ügyfélforgalom. Nem tudjuk, hol és mikor kezdik el az ügyfelek a kampányaikat — talán ma este Indiában, holnap pedig Hongkongban. Figyelembe véve a jelentős időeltolódást, a kiadás 2 órakor éjjel sem garantálja, hogy az ügyfelek ne szenvedjenek.
A szolgáltatói problémák. A messengerek és szolgáltatók — a partnereink. Néha nekik is vannak leállásaik, amelyek hibákat okoznak az új verziók kiadása során.
A szétosztott csapatok. Az ügyféloldali és backend fejlesztő csapatok különböző időzónákban helyezkednek el. Ebből adódóan gyakran nem tudnak egyeztetni egymással.
A dátaközpontokat nem lehet a staging-en megismételni. Egy dátaközpontban 200 állvány található — ezt sandbox környezetben még körülbelül sem lehet megismételni.
Downtimeis unacceptable! We have an acceptable level of availability (Error Budget) where we operate 99.99% of the time, for example, and the remaining percentage is the 'margin for error'. Achieving 100% reliability is impossible, but it is important to constantly monitor failures and downtimes.
Classic Solutions
Writing bug-free code. When I was a young developer, managers would approach me asking to release without bugs, but that is not always possible.
Writing tests. Tests work, but sometimes not in the way the business desires. Making money is not the responsibility of tests.
Testing on stage. In my 3.5 years at Infobip, I have never seen the staging environment even partially match production.
We even tried to develop this idea: first, we had staging, then pre-production, and then pre-pre-production. But this didn't help either — they didn't match even in capacity. With staging, we can guarantee basic functionality, but we don’t know how it will perform under load.
The release is done by the developer. It’s a good practice: even if someone changes the name of a comment, it’s immediately added to production. This helps foster accountability and keeps track of changes made.
Additional complexities also exist. For the developer, it’s stressful — spending a lot of time to check everything manually.
Coordinated releases. This option is usually proposed by management: 'Let's agree that you will test and add new versions every day'. This doesn't work: there is always a team waiting for everyone else or vice versa.
Smoke tests
Another way to solve our deployment issues. Let’s consider how smoke tests work using the previous example when Team A wants to deploy a new version.
First, the team deploys one instance in production. The instance receives messages from mocks simulating real traffic, so that it matches normal daily traffic. If everything is fine, the team switches the new version to user traffic.
The second option is to deploy with additional hardware. The team tests it in production, then switches it, and everything works.
Disadvantages of smoke tests:
- A tesztelésre nem lehet építeni. Hol szerezhetnénk olyan forgalmat, mint a termelésen? Használhatunk tegnapi vagy egy héttel ezelőtti adatokat, de ezek nem mindig egyeznek a jelenlegi helyzettel.
- Nehezen fenntartható. Támogatni kell a tesztfiókokat, folyamatosan vissza kell állítani őket minden frissítés előtt, amikor az aktív rekordok a tárolóba kerülnek. Ez bonyolultabb, mint tesztet írni a saját homokozómba.
Az egyetlen előny itt — ellenőrizni lehet a teljesítményt.
Canary-kiadások
A smoke-tesztek hiányosságai miatt kezdtünk el canary-kiadásokat alkalmazni.
A gyakorlat, amely hasonló ahhoz, ahogyan a bányászok kanárikat használtak a gázszint indikálására, az IT-ben is megtalálta a magáét. Engedjük, hogy kevés valódi termelési forgalom érkezzen az új verzióra, miközben próbálunk megfelelni a Szolgáltatási Szint Megállapodásnak (SLA). Az SLA a mi "hibalehetőségünk", amit évente egyszer (vagy más időintervallumban) használhatunk. Ha minden rendben van, több forgalmat adunk hozzá. Ha nem, visszaállítjuk az előző verziót.
Megvalósítás és részletek
Hogyan valósítottuk meg a canary-kiadásokat? Például egy ügyfélcsoport üzeneteket küld a szolgáltatásunkon keresztül.
A telepítési folyamat így zajlik: eltávolítunk egy csomópontot az egyensúlyozóból (1), megváltoztatjuk a verziót (2), és külön engedünk némi forgalmat (3).
Összességében a csoportban mindenki boldog lesz, még akkor is, ha egy felhasználó elégedetlen. Ha minden rendben van, minden verziót frissítünk.
Megmutatom szemléletesen, hogyan néz ki ez a legtöbb esetben a mikro szolgáltatások esetében.
Van Szolgáltatás-felfedezés és még két szolgáltatás: S1N1 és S2. Az első szolgáltatás (S1N1) értesíti a Szolgáltatás-felfedezést, amikor elindul, és a Szolgáltatás-felfedezés tárolja. A második szolgáltatás, amely két csomópontból áll (S2N1 és S2N2), szintén értesíti a Szolgáltatás-felfedezést indításkor.
A második szolgáltatás az első számára szerverként működik. Az első a Szolgáltatás-felfedezéstől kéri az információt a szervereiről, és amikor kap, keres és ellenőrzi azokat ("health check"). Amikor ellenőrizte, üzeneteket küld nekik.
Amikor valaki új verziót szeretne telepíteni a második szolgáltatásból, értesíti a Szolgáltatás-felfedezést, hogy a második csomópont kanári-csomópont lesz: rá kevesebb forgalom fog érkezni, mert most fog zajlani a telepítés. Eltávolítjuk a kanári-csomópontot az egyensúlyozóból, és az első szolgáltatás nem küld rá forgalmat.
Megváltoztatjuk a verziót, és a Service Discovery tudja, hogy a második csomópont most canary — adhatunk neki kevesebb terhelést (5%). Ha minden rendben van, módosítjuk a verziót, visszaállítjuk a terheléseket, és folytatjuk a munkát.
Ehhez az alábbiakra van szükségünk:
- terheléselosztás;
- monitorozás, mivel fontos tudni, hogy mit vár el minden felhasználó, és hogyan működnek részletesen szolgáltatásaink;
- verzióelemzés, hogy megértsük, mennyire jól fog működni az új verzió a produkcióban;
- automatizálás — megírjuk a telepítési folyamat (deployment pipeline) lépéseit.
Terhelés
Ez az első dolog, amit meg kell fontolnunk. Két egyensúlyozási stratégia létezik.
A legegyszerűbb változat, amikor egy csomópont mindig canary. Ez a csomópont mindig kevesebb forgalmat kap, és innen kezdjük el a telepítést. Problémák esetén összehasonlítjuk a ténykedését a telepítés előtt és alatt. Például, ha a hibák száma megduplázódott, az azt jelenti, hogy a kár is megduplázódott.
A canary-csomópont a telepítési folyamat során van beállítva.. Amikor a telepítés befejeződik, és levesszük a canary-csomópont státuszát, a forgalom egyensúlya helyreáll. Kevesebb géppel tisztább elosztást kapunk.
Monitorozás
A canary-kiadások sarkalatos pontja. Pontosan meg kell értenünk, miért csináljuk ezt, és milyen metrikákat akarunk gyűjteni.
Metrikák példái, amelyeket a szolgáltatásainkból gyűjtünk.
- Hibák száma, amelyek a naplózásban keletkeznek. Ez nyilvánvaló mutatója annak, hogy minden úgy működik, ahogy kell. Általánosságban véve, ez egy jó metrika.
- Kérési végrehajtási idő (latency). Ezt a metrikát mindenki figyelemmel kíséri, mert mindenki gyorsan akar dolgozni.
- Sor mérete (throughput).
- Sikeres válaszok száma másodpercenként.
- A kérdések 95%-ának végrehajtási ideje.
- Üzleti metrikák: mennyi pénzt keres a vállalkozás egy adott idő alatt, vagy a felhasználók elvándorlása. Ezek a metrikák az új verziónk számára fontosabbak lehetnek, mint azok, amelyeket a mérnökök adnak hozzá.
Metrikák példái a legnépszerűbb monitoring rendszerekben.
Számláló. Ez egy fokozatosan növekvő mennyiség, például a hibák száma. Ezt a metrikát egyszerű interpolálni és tanulmányozni a grafikont: tegnap 2 hiba volt, ma pedig 500, tehát valami nem működik megfelelően.
Hibák száma percenként vagy másodpercenként, ez egy nagyon fontos mutató, amelyet a Számláló segítségével lehet kiszámítani. Ezek az adatok világos képet adnak a rendszer teljesítményéről az időtávlatban. Nézzük meg például a hibák számát másodpercenként két verzió grafikonján a produkciós rendszerben.
Az első verzióban kevés hiba volt, valószínűleg nem működött a rendszerellenőrzés. A második verzió sokkal rosszabb. Pontosan meg lehet mondani, hogy problémák vannak, ezért vissza kell állítanunk ezt a verziót.
Mérőeszköz. A metrikák hasonlítanak a Counter-re, de itt rögzítjük az értékeket, amelyek növekedhetnek és csökkenhetnek is. Például a lekérdezések végrehajtási ideje vagy a sor mérete.
A grafikonon a válaszidő (latency) példája látható. A grafikon alapján a verziók hasonlóak, használhatóak. De ha alaposabban megnézzük, észrevehető, hogy a nagyság változik. Ha a lekérdezések végrehajtási ideje nő a felhasználók számának növelésével, akkor azonnal világos, hogy problémák vannak — korábban ilyen nem volt.
Összefoglaló. Az egyik legfontosabb mutató az üzlet számára a percentilisek. A metrika azt mutatja, hogy 95%-os arányban a rendszerünk úgy működik, ahogy szeretnénk. Elfogadható, ha valahol problémák vannak, mert megértjük az általános tendenciát, hogy minden mennyire jól vagy rosszul működik.
Eszközök
ELK Stack. A canary-t az Elasticsearch használatával lehet megvalósítani — rögzítjük benne a hibákat, amikor események történnek. Egy egyszerű API hívással bármikor megszerezheti a hibák számát, és összehasonlíthatja a múltbéli időszakokkal: GET /applg/_cunt?q=level:errr.
Prometheus. Jól megmutatta magát az Infobip-ban. Lehetővé teszi a többrétegű metrikák megvalósítását, mivel címkéket használnak.
Használhatjuk szint, példányt, a SystemD inicializálási rendszer számára:, ezeket egy rendszerben kombinálva. A segítségével offset például egyetlen parancs segítségével meg lehet nézni, hogy egy hét múlva mi volt az érték GET /api/v1/query?query={query}, ahol {query}:
rate(logback_appender_total{
level="error",
instance=~"$instance"
}[5m] offset $offset_value)Verziók elemzése
Több stratégiát alkalmazhatunk a verziók elemzésére.
Csak a canary-nódokat nézzük. Az egyik legegyszerűbb lehetőség: új verziót telepítünk, és csak a működését tanulmányozzuk. De ha a mérnök közben elkezd logokat nézegetni, folyamatosan idegesen frissítve az oldalakat, akkor ez a megoldás nem különbözik a többitől.
A canary-nódát bármely más nodához hasonlítják. Ez összehasonlítás más példányokkal, amelyek teljes forgalmon működnek. Például, ha a kis forgalommal rendelkező esetek rosszabbul teljesítenek, vagy nem jobban, mint a valódi példányok, akkor valami nincs rendben.
A canary-nóda önmagát hasonlítja össze a múltjával. A canary-ra rendelkezésre álló csomópontokat történeti adatokkal lehet összehasonlítani. Például, ha egy héttel ezelőtt minden rendben volt, akkor ezen adatokra hivatkozhatunk, hogy megértsük a jelenlegi helyzetet.
Automatizálás
Szeretnénk felszabadítani az mérnökök kezét a manuális összehasonlítás alól, ezért fontos az automatizálás megvalósítása. A telepítési folyamat (deployment pipeline) általában így néz ki:
- elkezdeni;
- kivenni a csomópontot a terheléselosztóból;
- beállítani a canary-csomópontot;
- aktiválni a terheléselosztót már korlátozott forgalommal;
- összehasonlítani.
Ezen a szakaszon megvalósítjuk az automatikus összehasonlítást. Hogyan nézhet ez ki és miért jobb, mint a telepítés utáni ellenőrzés, egy Jenkins példáján keresztül vizsgáljuk meg.
Ez egy pipeline Groovy-hoz.
while (System.currentTimeMillis() < endCanaryTs) {
def isOk = compare(srv, canary, time, base, offset, metrics)
if (isOk) {
sleep DEFAULT SLEEP
} else {
echo "A canary megbukott, vissza kell állítani"
return false
}
} Itt a ciklusban megadjuk, hogy egy órán keresztül fogjuk összehasonlítani az új csomópontot. Ha a canary folyamat még nem fejeződött be — meghívjuk a függvényt. Ez jelzi, hogy minden rendben van vagy sem: def isOk = compare(srv, canary, time, base, offset, metrics).
Ha minden rendben van — sleep DEFAULT SLEEP, például egy másodpercre, és folytatjuk. Ha nem, kilépünk — a telepítés nem sikerült.
A metrika leírása. Nézzük meg, hogyan nézhet ki a compare függvény egy DSL példáján.
metric(
'errorCounts',
'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
{ baseValue, canaryValue ->
if (canaryValue > baseValue * 1.3) return false
return true
}
)Tegyük fel, hogy a hibák számát hasonlítjuk össze, és szeretnénk megtudni, hány hiba van másodpercenként az elmúlt 5 percben.
Két értékünk van: a bázis és a canary-csomópont. A canary-csomópont értéke — az aktuális. A bázis — baseValue — ez bármilyen más, nem canary-csomópont értéke. Az értékeket a tapasztalatunk és megfigyeléseink alapján megfogalmazott képlet alapján hasonlítjuk össze. Ha a canaryValue rossz, akkor a telepítés nem sikerült, és vissza kell állnunk.
Miért van szükség mindezekre?
Az ember nem képes ellenőrizni száz és ezer metrikát, főleg gyorsan. Az automatikus összehasonlítás segít ellenőrizni az összes metrikát és gyorsan értesíteni a problémákról. Az értesítési idő kritikus: ha valami történt az utolsó 2 másodpercben, akkor a kár nem olyan nagy, mintha 15 perccel ezelőtt történt volna. Míg valaki észleli a problémát, ír a támogatásnak, és a támogatás nekünk, hogy visszaállítsuk, ügyfeleket veszítünk.
Ha a folyamat sikeresen lezajlott, automatikusan telepítjük a többi csomópontot is. Ekkor az mérnökök nem csinálnak semmit. Csak amikor elindítják a canary-t, döntenek a mértékekről, mennyi ideig végezzenek összehasonlítást, milyen stratégiát alkalmazzanak.
Ha problémák merülnek fel, automatikusan visszagurítjuk a canary-csomópontot, a korábbi verziókkal dolgozunk, és kijavítjuk a felfedezett hibákat. A mértékek alapján ezek könnyen megtalálhatók, és látható a kár az új verziótól.
Akadályok
Ilyet megvalósítani természetesen nem egyszerű. Először is szükség van egy általános megfigyelőrendszerre. A mérnököknek saját mértékeik vannak, a támogatásnak és az elemzőknek mások, a vállalkozásnak pedig harmadik. Az általános rendszer egy közös nyelv, amin a vállalkozás és a fejlesztés kommunikál.
A gyakorlatban kell ellenőrizni a mértékek stabilitását. Az ellenőrzés segít megérteni, milyen minimális mértékek szükségesek a minőség biztosításához..
Hogyan érjük ezt el? Használni kell a canary-szolgáltatást nem a telepítés pillanatában. Hozzáadunk egy bizonyos szolgáltatást a régi verzióhoz, amely bármikor el tudja venni a kiválasztott csomópontot, és csökkentheti a forgalmat telepítés nélkül. Azután összehasonlítunk: tanulmányozzuk a hibákat, és keressük azt a határt, ahol elérjük a minőséget.
Milyen hasznot kaptunk a canary-kiadásokból?
Minimalizáltuk a hibák miatti kár százalékát. A telepítési hibák többsége adatinkonzisztenciából vagy prioritásokból adódik. Az ilyen hibák száma jelentősen csökkent, mert a problémát az első másodpercekben meg tudjuk oldani.
Optimalizáltuk a csapatok munkáját. A kezdőknek van „hibázási joguk”: hibázás nélkül telepíthetnek a termelésbe, ami extra kezdeményezést és motivációt ad a munkához. Ha valamit elrontanak, az nem kritikus, és őket nem rúgják ki.
Automatizáltuk a telepítést. Ez már nem manuális folyamat, mint régen, hanem igazi automatizált folyamat. De tovább tart.
Kiemeltük a fontos mértékeket. Az egész vállalat, a vállalkozástól az mérnökökig, megérti, mi számít igazán a termékünkben, például a felhasználók áramlása. Ellenőrizzük a folyamatot: teszteljük a mértékeket, újat vezetünk be, megnézzük, hogy a régiek működnek-e, hogy egy hatékonyabb rendszert építhessünk, amely pénzt keres.
Sok remek gyakorlatunk és rendszerünk van, amelyek segítenek nekünk. Ennek ellenére arra törekszünk, hogy szakemberek legyünk, és minőségi munkát végezzünk, függetlenül attól, hogy van-e olyan rendszerünk, amely segíthet, vagy sem.
Mérnöki megközelítések és gyakorlatok — . Ha már elérted a sikert a technikai tökéletesség útján, és készen állsz arra, hogy elmondjad, mi segített ebben, — .
Tervezünk egy megrendezését június 8-án. Megértjük, hogy most nehéz döntéseket hozni a konferencián való részvételről. Ugyanakkor úgy érezzük, hogy a karantén nem akadályozhatja meg a szakmai kommunikációt és fejlődést. Ezért mindenképpen megtaláljuk a módját, hogy beszélgessünk a tech lead feladatairól és megoldási megközelítéseikről — ha szükséges, online térbe lépünk és ott fejlesztjük a kapcsolatépítést!
Forrás: habr.com
