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