Pilviarkkitehtuurien salat

650 views
603 views

Published on

Codenton päättäjätapaaminen 1.3.2011: Pilvipalvelut ilman jarrumiehiä ja hihhuleita

Antti Rasinen, Codento Oy

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
650
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Pilviarkkitehtuurien salat

  1. 1. Case Amazon Web Services Pilviarkkitehtuurien salat Antti Rasinen 7.6.2011
  2. 2. Kun tulin huoneeseen, se oli jo rikki 21.4. Amazonin pilvessä vakava häiriötilanne Monet AWS:n päälle rakennetut palvelut köhivät Eivät kuitenkaan kaikki. Miksi näin? V: Tilanteen vaatima arkkitehtuuri yhdistettynä oikeaan kulttuuriin2
  3. 3. Sisällys Mitä Amazon Web Services tarjoaa? Mikä hajosi ja miten? Miksi toiset selvisivät ja toiset eivät? Mitä tästä voi ottaa opikseen?3
  4. 4. AWS EC2 S3 RDS ELB SQS … Import/Export RDS BeanstalkSNS SES EC2 ELB S3 VPC SQS CloudFront EBS Virtuaalikoneita Tallennuskapasiteettia4
  5. 5. AWS EC2 S3 RDS ELB SQS … Import/Export RDS BeanstalkSNS SES EC2 ELB S3 VPC SQS CloudFront EBS Virtuaalikoneita Tallennuskapasiteettia5
  6. 6. EBS-klusterin rakenne Primaariverkko Varaverkko6
  7. 7. EBS-klusterin rakenne Primaariverkko Varaverkko7
  8. 8. EBS-klusterin rakenne Varaverkko8
  9. 9. EBS-klusterin rakenne ! ! ! !9
  10. 10. Seuraukset Klusterin varalla ollut levytila loppui 13% koneista jäi jumiin odottamaan vuoroaan EBS-koneiden soidinhuudot tukkivat sisäisen EBS- rajapinnan  Regionit jakavat saman toteutuksen  Ongelma levisi yhden saatavuusalueen ulkopuolelle Harvinainen bugi pahensi tilannetta10
  11. 11. Sirpaleiden kantomatka Import/Export RDS BeanstalkSNS SES EC2 ELB S3 VPC SQS CloudFront EBS11
  12. 12. Alusta petti, mitä teen? “Lessons learned” ja “How we avoided ...” -analyysit jakautuivat kahteen kategoriaan Eräät tarjosivat ratkaisuksi tiettyjä AWS:n teknisiä ominaisuuksia tai vikasietoisia arkktehtuureja Toiset painottivat enemmän häiriökeskeistä kehitystä ja kulttuuria  Netflixin Chaos Monkey ja Chaos Gorilla kenties tunnetuimmat Valitse lähestymistapa palvelun vaatimusten mukaan12
  13. 13. Vältä EBS:n käyttöä EBS:llä jo aiemmista häiriöistä johtuen huonohko maine  Joskaan ei pyörivää ruostelättyä huonompi EBS ei aina tarpeellinen  Yksittäisen instanssin levy riittää pitkälle  Onko EBS käytössä “mukavuussyistä”?  Oletko siirtänyt vanhan rautasidonnaisen arkkitehtuurin pilveen krouvisti suuremmin miettimättä? Yleisemmin: tunne teknologia ja harkitse sen käyttöä huolellisesti13
  14. 14. Hajauta ja hallitse Palvelut voi hajauttaa eri saatavuusalueille (Availability Zone)  AZ:t eivät ole aivan niin riippumattomia kuin on annettu ymmärtää  Käsitellyssä casessa ongelma vuosi laitojen yli Maantieteellinen hajauttaminen (Multi-Region) lisää turvaa enemmän  Mutka matkassa: asiat, jotka eristävät alueet toisistaan, hidastavat myös sinua  Hajauttaminen lisää monimutkaisuutta, mikä lisää virhealttiutta  Etsi kultainen keskitie Tee oma privaattipilvi14
  15. 15. “Systems are disposable” Tee pilvipalvelu pilven ehdoilla Automatisoi palvelinten (ja palvelujen!) provisiointi Mehiläispesäarkkitehtuuri  Paljon lyhytikäisiä työläisiä, joita kuningatar tuottaa  Uuden pesän perustaminen helppoa Ideaalitilanne: Palvelut tilattomia ja toisistaan riippumattomia Kaikkea ei tarvitse eikä kannata laittaa pilveen15
  16. 16. Kulttuuritekijät “Design for failure” Tuuri Valmistautuminen Pilvi ei ole taikateknologiaa16
  17. 17. Muista virheet suunnittelussa Häiriötilanteet mukana jokapäiväisessä keskustelussa  Vikasietoisuutta hankala tuoda jälkikäteen Modularisoitu järjestelmä, jonka osien häiriötilanteet tunnetaan  Ei kuitenkaan estä kunnon katastrofia… KISS-periaate17
  18. 18. Muista virheet päivittäistyössä Chaos Monkey  Virtuaalinen Ville 5v, joka nyppii kaapeleita ja kaataa koneita  Häiriöt helpompia, kun niitä on enemmän Paloharjoitukset  Miten järjestelmä saadaan ylös?  Kuka sen voi tehdä?  Tietävätkö kaikki, mitä tehdä hälytyksen soidessa?  Onko hälytintä ollenkaan?  Kauanko datan palauttamiseen menee aikaa? Varmuuskopiot!18
  19. 19. Opi virheistä Hyvien post mortem -analyysien tekeminen on oma taitonsa Syyllisten ja alkusyiden etsiminen luonnollista, muttei tuloksellista  Syitä ja niihin tarvittavia korjauksia on jokaisella tasolla Vaatii osallistujilta luottamusta toisiinsa  Korollaari: Kaikki osallistujat samassa tilassa19
  20. 20. Mitä opittiin? Häiriötilanteista selviää vähemmällä, jos arkkitehtuuri ottaa häiriöt huomioon  Teknologiat ja niiden rajoitukset tunnetaan Kulttuuritekijät auttavat tällaisen arkkitehtuurin synnyssä ja erityisesti ylläpidossa20

×