Overview of techniques and architectures used in applications with zero downtime deployment. Talk was given on Kaunas Java User Group meetup #33 (http://kaunas-jug.lt/).

1. Diegimas nestabdant sistemos
Technikos ir architektūros
Rolandas Jaskovikas Kaunas JUG 2017-01-18

2. 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

3. Įvadas

4. Į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

5. Į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ų

6. Veikimo pagrindai

7. 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

8. Veikimo pagrindai – keli procesai

9. 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

10. Veikimo pagrindai – atskirta būsena

11. Veikimo pagrindai – būsenos nesuderinamos

12. 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)

13. Veikimo pagrindai – karštas suderinamumas

14. 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

15. Prototipas

16. 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

17. Prototipas - architektūra

18. 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

19. Prototipas – vartotojo sąsaja

20. Prototipas – JSF forma, V1

21. Prototipas – JSF backing bean’as, V1

22. Prototipas – MessageService, V1

23. Prototipas – ZddDAO, V1

24. Versijos keitimo technikos

25. 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

26. Būsena – navigacijos būsena

27. Būsena – navigacijos būsena

28. 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į

29. 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ų

30. 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

31. Būsena – prototipo DB migravimas
V1 ->
V2 ->
V1.5 ->

32. DB migravimo pavyzdys

33. Prototipas – ZddDAO, V2

34. 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ų

35. Būsena – serviso sąsajos pasikeitimas
 Duomenų migravimas realiu laiku
 Senos funkcijos turi gražinti senus duomenis
 Naujos funkcijos turi gražinti naujus duomenis

36. Serviso migravimo pavyzdys

37. 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.

38. Prototipas – JSF forma, V2

39. Prototipas – Backing bean’sas, V2

40. Prototipas – MessageService, V2

41. WEB migravimo pavyzdys

42. 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

43. Prototipas – JSF forma, V3

44. Prototipas – JSF backing bean’as, V3

45. Prototipas – MessageService, V3

46. Prototipas – ZddDAO, V3

47. Išvalyto kodo diegimo pavyzdys

48. Architektūros

49. BlueGreen deployment
*Martin Fowler [https://martinfowler.com/bliki/BlueGreenDeployment.html]

50. Node swap

51. Canary deployment

52. Tomcat parallel deployment

53. 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

54. 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

55. 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.

56. Naudingos smulkmenos

57. 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ą.

58. 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į.

59. 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

60. Klausimai