from taiva
Kaip deployint servisą be downtime?
Sako man – reikia servisą naujint, bet taip naujint, kad nebūtų prastovų (downtime). Pirmiausia reikia žinot, kad garantijų, kad niekada nieko nesugadinsi – nėra, tad 0% downtime (arba 100% uptime) nebūna – visada anksčiau ar vėliau pasibaigs bloguoju ir dar neaišku ar su restart nuo 0 ar kaip ten kitaip. Internetuose informacijos ir melo, kad galima vis tik taip padaryt pilna, bet angliškai. O ne visi anglų kalbą moka, o būna, kad ir moka, bet skaito ir nieko nesupranta. Tad čia pusiau versta, pusiau iš atminties, bet įkvėpus dūmo taiva taip gaunas:
- Padaryti taip, kad būtų profilaktinės valandos/dienos/savaitgaliai ir neskaičiuoti to laiko, kaip prastovos. Nesąmonė, rėkia programeris, taip negalima! Galima – šitas būdas labai dažnai naudojamas bankų. Jie sako – savaitgalį atsiskaitymas kortelėmis neveiks ir ką tu jiems, špyga taukuota. Garantuotai ten šitas neveikimas neįtraukiamas į probleminį ir ten naujina tą servisą naujina, kol ateina pirmadienis ir kažkas sutvarko viską ir paleidžia veikti. Ne kartą taip buvo ir ne kartą taip bus.
- Mėlynai/Žali atnaujinimai. Arba kitaip – blue/green. Kai išleidžiama nauja versija, ji paleidžiama green serveriuose, virtualiose mašinose ar tiesiog zonoje, o vartotojų ar kitoks kreipinių srautas palaipsniui nukreipimas, kad pažaliuotų. Mėlyna (senoji) versija aptarnauja vis mažiau ir mažiau užklausų, kol galų gale lieka tik kaip atsarginis variantas (ale atsukti atgal, jei šūdas gavos), išjungiama arba gali tarnauti kaip vieta būsimai žaliai zonai. Beje, tai gali būti ir vienas serveris, kuris teikia paslaugą iš skirtingų direktorijų. Aišku, vienas serveris gali bet kada nulūžti ir paslauga sustos, bet deploymentas tai visvien bus zero downtime :)
- Uždususios kanarėlės strategija (cannary) – apie pavadinimą galima sužinoti čia. Panašiu principu veikia ir pats serviso naujinimas – nauja versija paleidžiama serveriuose, į kuriuos srautas kreipiamas po truputį ir stebima situacija: žurnalai (logs), metrikos, galbūt vartotojų nusiskundimai; nustatoma kažkokia tolerancijos riba (klaidų retai kada pavyksta išvengti) ir neskubant vis daugiau vartotojų naudoja naują versiją. Jei pasiekta klaidų riba ar koks kitoks kriterijus – galima lengvai srautą kreipti atgal į seną versiją ir sutvarkyt problemas. Dažniausiai kanarėles naudoja daug vartotojų turinčios įmonės, kur pakeitimai gali iššaukti sniego lavinos efektą. Dar vienas privalumas – kad lengva ištestuoti fyčerius – t.y., pasinaudoja ne tik technologai, bet ir marketingistai. Turbūt teko laukti kokios nors naujienos, kuri paleista Amerikėj, bet nėra dar Lietuvoj – tai va, stebi, ar kanarėlės dūsta, ar ne.
- Šešėlių valdovo strategija – nauja sistema pastatoma kartu su sena, bet srauto leidžiama tik kopija ir vartotojai nemato rezultato. Stebimi žurnalai, metrikos, bandoma įvertinti ar viskas veikia gerai. Čia toks panašesnis į testavimą su realiais vartotojais, bet klaidos nuo jų paslėptos. Kai jau manoma, kad nauja sistema veikia gerai – virsta į mėlynai pažaliavusį deploymentą. Šiaip, šitas būdas yra ganėtinai sudėtingas, galima sugadinti duomenis ar turėtų jų suvienodinimo problemų.
Yra ir dar keletas strategijų, kurios vienaip ar kitaip panašios į išvardintas. Čia parašiau šiek tiek apie srauto ir vartotojų perkėlimą, bet ką daryt su duomenų bazių migracijom (schemų pakeitimais)? Į vieną pusę tai aišku – pridėjai stulpą ir lauki, kol suvažiuos. Egzistuoja visokių įrankių, kad tos migracijos neblokuotų. Pridėti visada lengviau negu atimti, o atgal atsukti, jei kas nors nepavyko – sunkiau. Tai dažnai duomenų bazės auga, turi visokių šiukšlių, schemos neoptimizuojamos, kažkaip traška braška, kol neprireikia padaryt offline profilaktikos. Turbūt viena iš priežasčių, kodėl NoSQL ir panašios duomenų bazės mėgstamos – jos yra laisvesnės schemos ir pakeitimus galima daryt be migracijų. Yra ir naudojančių SQL variklį su duomenų bazių schemom, kurios neatspindi SQL fengshui. Prišikt, prišikt ir palikt.
Visa tai lengviau, jei yra aiškios procedūros, kurias galima automatizuoti. Automatika gerai tuo, kad, jei daro klaidas, tai paprastai tas pačias – Operatoriaus rezultatai būna mažiau nuspėjami (dar jų būna ne vienas ir skirtingo lygio/žinių apie sistemas). Galim tarti, kad bet kokios programinės įrangos naujos versijos paleidime norisi kuo mažiau neapibrėžtumo, aiškumo ir iš anksto suplanuotų procedūrų, ką daryti, jei kas nors nepavyko. Na, o kaip tai sekasi – pasidalinkit. Vieni nešioja marškinėlius su užrašu “mes leidžiam naujas versijas penktadieniais”, kaip garbės ženklą, o kiti iš tolo vengia kompanijų, kuriose dirba tokie žmonės.
Lengvo darbo!