Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Diegimas nestabdant sistemos
Technikos 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...
Įvadas
Įvadas
 Kam to reikia:
A. Kūrimo ar priežiūros (SLA) sutartyse reikalaujama > 99% up time’o.
B. Norime turėti pilnavertį ...
Įvadas
 Reikalavimai:
A. Labai pageidaujamas automatizuotas “Continuos deployment” procesas
B. Diegimas mažais funkcional...
Veikimo pagrindai
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistu...
Veikimo pagrindai – keli procesai
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistu...
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 egzistu...
Veikimo pagrindai – karštas suderinamumas
Veikimo pagrindai
 Kas trukdo realiu laiku pakeisti esamą programą į naują:
A. Veikiantis procesas (kodas)
B. Jau egzistu...
Prototipas
Prototipas
 Tarnybinė stotis:
 Intel Atom x5-Z8300 – 1.84 GHz 4 branduoliai
 2 GB RAM
 32 GB SSD
 Windows 10 Home
 P...
Prototipas - architektūra
Prototipas
 Naudojama programinė įranga ir biblioketos:
 Java 8
 RedHat Jboss EAP 6.4
 Pound 2.7 reverse proxy
 MySql...
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ės...
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 pro...
Būsena – duomenų bazė
 Stulpelio pakeitimas (pavadinimas, duomenų tipas ar kita):
 Pridedate naują stulpelį pagal anksči...
Būsena – duomenų bazė
 Didelių lentelių keitimas:
 Pridedant ar šalinant stulpelį yra rakinama lentelė
 Lentelės rakini...
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 ...
Būsena – serviso sąsajos pasikeitimas
 Duomenų migravimas realiu laiku
 Senos funkcijos turi gražinti senus duomenis
 N...
Serviso migravimo pavyzdys
Būsena – web serveris
 Sesijos valdymas:
 Iškelti sesiją iš WEB konteinerio atminties – laikyti db išorinimiame, kešo se...
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...
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...
Architektūrų privalumai ir trūkumai
 NodeSwap
 Privalumai:
 Perdiegimui reikia tik vienos mašinos
 Naudojama ta pati d...
Architektūrų privalumai ir trūkumai
 Canary deployment
 Tai tarpinis variantas tarp BlueGreen ir NodeSwap architektūrų –...
Naudingos smulkmenos
Naudingos smulkmenos
 Didelių pakeitimų darymas:
 Suskaidykite į mažus nepriklausomus pakeitimus
 Darykite didelį pakei...
Naudingos smulkmenos
 Web tarnybinės stoties išėmimas iš “reverse proxy”:
 Keičiant “reverse proxy” konfigūraciją
 Dažn...
Pakeitimai kuriems būtinas stabdymas
 Duomenų bazės serverio versijos keitimas
 Dideli aplikacijos arba duomenų bazės sc...
Klausimai
Upcoming SlideShare
Loading in …5
×

Zero downtime deployment

226 views

Published on

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

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Zero downtime deployment

  1. 1. Diegimas nestabdant sistemos Technikos ir architektūros Rolandas Jaskovikas Kaunas JUG 2017-01-18
  2. 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. 3. Įvadas
  4. 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. 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. 6. Veikimo pagrindai
  7. 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. 8. Veikimo pagrindai – keli procesai
  9. 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. 10. Veikimo pagrindai – atskirta būsena
  11. 11. Veikimo pagrindai – būsenos nesuderinamos
  12. 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. 13. Veikimo pagrindai – karštas suderinamumas
  14. 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. 15. Prototipas
  16. 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. 17. Prototipas - architektūra
  18. 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. 19. Prototipas – vartotojo sąsaja
  20. 20. Prototipas – JSF forma, V1
  21. 21. Prototipas – JSF backing bean’as, V1
  22. 22. Prototipas – MessageService, V1
  23. 23. Prototipas – ZddDAO, V1
  24. 24. Versijos keitimo technikos
  25. 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. 26. Būsena – navigacijos būsena
  27. 27. Būsena – navigacijos būsena
  28. 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. 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. 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. 31. Būsena – prototipo DB migravimas V1 -> V2 -> V1.5 ->
  32. 32. DB migravimo pavyzdys
  33. 33. Prototipas – ZddDAO, V2
  34. 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. 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. 36. Serviso migravimo pavyzdys
  37. 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. 38. Prototipas – JSF forma, V2
  39. 39. Prototipas – Backing bean’sas, V2
  40. 40. Prototipas – MessageService, V2
  41. 41. WEB migravimo pavyzdys
  42. 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. 43. Prototipas – JSF forma, V3
  44. 44. Prototipas – JSF backing bean’as, V3
  45. 45. Prototipas – MessageService, V3
  46. 46. Prototipas – ZddDAO, V3
  47. 47. Išvalyto kodo diegimo pavyzdys
  48. 48. Architektūros
  49. 49. BlueGreen deployment *Martin Fowler [https://martinfowler.com/bliki/BlueGreenDeployment.html]
  50. 50. Node swap
  51. 51. Canary deployment
  52. 52. Tomcat parallel deployment
  53. 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. 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. 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. 56. Naudingos smulkmenos
  57. 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. 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. 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. 60. Klausimai

×