Successfully reported this slideshow.

Zero downtime deployment

0

Share

Loading in …3
×
1 of 60
1 of 60

Zero downtime deployment

0

Share

Download to read offline

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

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

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all

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

×