zero downtime deployment
TRANSCRIPT
Diegimas nestabdant sistemosTechnikos ir architektūros
Rolandas Jaskovikas Kaunas JUG 2017-01-18
Agenda
Įvadas - kam tai reikalinga ir …
Veikimo pagrindai
Prototipas ir jo architektūra
Versijos keitimo technikos
Architektūros
Naudingos smulkmenos
Kartais reikia paleisti iš naujo
Įvadas
Įvadas
Kam to reikia:
A. Kūrimo ar priežiūros (SLA) sutartyse reikalaujama > 99% up time’o.
B. Norime turėti pilnavertį “Continuous deployment” procesą
C. Norime pakeitimus diegti darbo metu
Kodėl nedarome:
Nėra poreikio – dauguma sistemų darbo laikas nuo 08 iki 17 valandos
Sudėtingesnis programavimas – neatneša naudos
Reikia patyrusių programuotojų
Nemokame – dėl aukščiau išvardintų priežasčių praktika nėra paplitusi
Įvadas
Reikalavimai:
A. Labai pageidaujamas automatizuotas “Continuos deployment” procesas
B. Diegimas mažais funkcionalumo gabaliukais – 15 diegimu per diena norma
C. Du ar daugiau aplikacijų serverių/konteinerių
Pastebėjimai:
A. Visiškai 100% sistemos nestabdymo pasiekti negalima
B. High availability nėra reikalingas, tačiau kartais HA gauname dovanų
Veikimo pagrindai
Veikimo pagrindai
Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
Veikimo pagrindai – keli procesai
Veikimo pagrindai
Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
B. Atliekamas kodo ir būsenos atskyrimas
Veikimo pagrindai – atskirta būsena
Veikimo pagrindai – būsenos nesuderinamos
Veikimo pagrindai
Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
B. Atliekamas kodo ir būsenos atskyrimas
C. Naudojamas karšto suderinamumo principas (angl: Hot compatibility)
Veikimo pagrindai – karštas suderinamumas
Veikimo pagrindai
Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistuojantys duomenys (būsena)
Spendimas:
A. Programa išskaidoma į kelis nepriklausomus procesus
B. Atliekamas kodo ir būsenos atskyrimas
C. Naudojamas karšto suderinamumo principas (angl: Hot compatibility)
Pastebėjimai:
A. Labai paprasta kuomet nėra būsenos – pakeitimas greitas ir paprastas
B. Laikui bėgant reikia nepamiršti išsivalyti seno kodo
Prototipas
Prototipas
Tarnybinė stotis:
Intel Atom x5-Z8300 – 1.84 GHz 4 branduoliai
2 GB RAM
32 GB SSD
Windows 10 Home
Prisijungimas per Wifi
SID: ZDD
PSWD : Zdd4Kjug
http://zdd/zdd
http://192.168.0.79/zdd
Prototipas - architektūra
Prototipas
Naudojama programinė įranga ir biblioketos:
Java 8
RedHat Jboss EAP 6.4
Pound 2.7 reverse proxy
MySql 5.7
Java EE 6.0 (EJB 3.0, JSF 2.1, JDBC…)
Infinispan 5.2
Jgroups 3.2
Python 2.7
Prototipas – vartotojo sąsaja
Prototipas – JSF forma, V1
Prototipas – JSF backing bean’as, V1
Prototipas – MessageService, V1
Prototipas – ZddDAO, V1
Versijos keitimo technikos
Būsena
Programos būseną sudaro:
Sesija
Įvairūs kešai (lokalūs ir globalūs)
Serviso sąsajos versija
Duomenų bazėse saugoma informacija
Formos (HTML puslapio) navigacijos būsena
Būsena – navigacijos būsena
Būsena – navigacijos būsena
Būsena – duomenų bazė
Stulpelio pridėjimas:
Pridedate stulpelį be jokių apribojimų su default reikšme
Sutvarkote programos kodą, kad teisingai pildytų naują stulpelį
Migruojate senuose įrašuose esančias stulpelio reikšmes
Uždedate reikiamus apribojimus
Stulpelio pašalinimas
Sutvarkote programos ir db kodą nenaudoti stulpelio
Nuimate apribojimus trukdančius stulpelio pašalinimui (indeksai ar kiti apribojimai)
Pašalinate stulpelį
Būsena – duomenų bazė
Stulpelio pakeitimas (pavadinimas, duomenų tipas ar kita):
Pridedate naują stulpelį pagal anksčiau aprašytą procedūrą
Sutvarkote programos kodą naudoti abu stulpelius
Ištrinate seną stulpelį pagal anksčiau aprašytą procedūrą
Duomenų migravimas
Migravimui reikia naudoti papildomą požymio stulpelį (0-seni, 1-migruoti)
Migruoti reikia mažomis įrašų porcijomis, kad neužrakinti lentelių
Būsena – duomenų bazė
Didelių lentelių keitimas:
Pridedant ar šalinant stulpelį yra rakinama lentelė
Lentelės rakinimo laikas yra tiesinė funkcija nuo įrašų skaičiaus O(n)
Labai didelės lentelės keičiamos kuriant naują lentelę ir atliekant lentelių sukeitimą
Atsargiai su indeksų kūrimu, galimas lentelės rakinimas
Stored procedūrų/paketų keitimas – prieš naudojantis JDBC connection objektu
jį reikia testuoti
NoSQL duomenų bazės turi menamą schemą – todėl galioja visi aukščiau
išvardinti principai
Būsena – prototipo DB migravimas
V1 ->
V2 ->
V1.5 ->
DB migravimo pavyzdys
Prototipas – ZddDAO, V2
Būsena – serviso sąsajos pasikeitimas
Funkcijos pridėjimas arba pašalinimas
Technologija/protokolas reikalauja naujos sąsajos versijos:
Pridėti naują sąsajos versiją
Sutvarkyti kodą naudoti naują sąsajos versiją
Išmesti seną sąsajos versiją
Technologija/protokolas nereikalauja naujos sąsajos versijos:
Pridėti naujas funkcijas
Sutvarkyti kodą naudoti naujas funkcijas ir nenaudoti senų
Išmesti senas funkcijas
Pastebėjimas:
Servisai turi neturėti būsenos
Servisų keitimas yra vienas paprasčiausių migravimų
Būsena – serviso sąsajos pasikeitimas
Duomenų migravimas realiu laiku
Senos funkcijos turi gražinti senus duomenis
Naujos funkcijos turi gražinti naujus duomenis
Serviso migravimo pavyzdys
Būsena – web serveris
Sesijos valdymas:
Iškelti sesiją iš WEB konteinerio atminties – laikyti db išorinimiame, kešo serveryje, …
Sesijoje turėti papildomą požymį, kuris nurodytų jos versiją
Migruoti neaktyvias sesijas
laukti, kol jos “timeout’ins”
palaikyti migravimo kodą keliomis versijomis atgal
Momentinis aplikacijos versijos perjungimas, kuomet naudojama ‘Node swap’ architektūra
Naudoti sinchronizuotą versijos perjungimo mechanizmą
Galima naudoti “sticky session” mechanizmą “load balanceryje” (nerekomenduoju)
Formų/puslapių, paveikslėlių ir kito turinio versijavimas.
Prototipas – JSF forma, V2
Prototipas – Backing bean’sas, V2
Prototipas – MessageService, V2
WEB migravimo pavyzdys
Seno kodo valymas
Reikia nepamiršti išvalyti seno kodo:
Priklausomai nuo aplikacijos galimas kelių versijų senumo kodo laikymas
Rekomenduojama turėti automatinius senų kodo versijų valymo įrankius
Prototipas – JSF forma, V3
Prototipas – JSF backing bean’as, V3
Prototipas – MessageService, V3
Prototipas – ZddDAO, V3
Išvalyto kodo diegimo pavyzdys
Architektūros
BlueGreen deployment
*Martin Fowler [https://martinfowler.com/bliki/BlueGreenDeployment.html]
Node swap
Canary deployment
Tomcat parallel deployment
Architektūrų privalumai ir trūkumai
BlueGreen
Privalumai:
Galimas lygiagretus visų stočių diegimas – didelis greitis
Versija persijungia visoms mašinoms iškarto – nereikalingas papildomas sinchronizavimas
Trūkumai
Reikalauja dvigubo resursų turėjimo – įsivaizduokite 500 mašinų klasterį
Naudojama skirtingos duomenų bazės – reikalingas duomenų sinchronizavimas
High availability reikia rūpintis atskirai
Architektūrų privalumai ir trūkumai
NodeSwap
Privalumai:
Perdiegimui reikia tik vienos mašinos
Naudojama ta pati duomenų bazė – nereikalingas sudėtingas duomenų sinchronizavimas
High availability gaunama, kaip dovana
Trūkumai:
Negalimas lygiagretus visu stočių diegimas – lėtas perdiegimas
Reikalingas papildomas mechanizmas versijos perdiegimui
Architektūrų privalumai ir trūkumai
Canary deployment
Tai tarpinis variantas tarp BlueGreen ir NodeSwap architektūrų – kuri architektūra
dominuos – tuos privalumus ir trūkumus turėsite.
Papildomas privalumas – galima ištestuoti naują versiją su pasirinktais naudotojais
Tomcat parallel deployment
Privalumai:
Užtenka vienos aplikacijos
Trūkumai:
Nėra high availability
Senos versijos gyvavimas gali užtrukti ilgai – kol atsijungs paskutinis vartotojas.
Naudingos smulkmenos
Naudingos smulkmenos
Didelių pakeitimų darymas:
Suskaidykite į mažus nepriklausomus pakeitimus
Darykite didelį pakeitimą, kaip atskirą nepriklausomą savybę (feature), kuri
diegiama pastoviai, o bus pasiekiama tik ją pilnai įgyvendinus
Versijos keitimas nestabdant pilna apimtimi yra sudėtingas, tačiau atvejis
nesikeičiant būsenai (duomenims) yra paprastas, todėl jį verta naudoti
Pakeitimų atstatymas (angl: rollback):
Jeigu nebuvo duomenų migravimo – galima tiesiog sugrįžti prie senos versijos
Jeigu buvo duomenų migravimas – grįžimas galimas tik migruojant duomenis į seną
versiją.
Naudingos smulkmenos
Web tarnybinės stoties išėmimas iš “reverse proxy”:
Keičiant “reverse proxy” konfigūraciją
Dažnas “reverse proxy” turi “life detection” mechanizmą
“Reverse proxy” vienam TCP prisijungimui naudoja 2 socket’us –
susiskaičiuokite poreikį, nes OS palaiko ribotą socket’ų skaičių.
Galima nesunkiai atlikti testavimą gamyboje, testuojant jau sudiegtą, bet
neprijungtą prie “reverse proxy” web tarnybinę stotį.
Pakeitimai kuriems būtinas stabdymas
Duomenų bazės serverio versijos keitimas
Dideli aplikacijos arba duomenų bazės schemos pakeitimai
Didelio duomenų kiekio lentelių keitimas arba indeksų kūrimas
Aplikacijos ar jos pagrindinių elementų topologijos ar architektūros keitimas
Kešo serverių topologijos keitimas
DB replikavimo mechanizmo keitimas
Klausimai