Amazon S3 tukee monia AWS-palveluita, mukaan lukien AWS Lambda, Elastic BeanStalk ja Amazonin oma Service Health Dashboard. Se toimii myös esine- ja mediakaupana monille muille Internet-palveluille, jotka luottavat siihen joka päivä.
28. helmikuuta 2017 AWS koki useita tunteja pitkän seisokin Amazon S3 -palvelusta Yhdysvaltain itäosissa. Se loi keskeytyksekkään vaikutuksen seisokkeihin hyvässä Internet-osassa, mukaan lukien Dockerhubin kaltaiset palvelut.
Inhimillinen virhe osoittautui syy:
Klo 9.37 PST valtuutettu S3-tiimin jäsen, joka käytti vakiintunutta soittokirjaa, suoritti komennon, jonka oli tarkoitus poistaa pieni määrä palvelimia yhdelle S3-alijärjestelmistä, joita S3-laskutusprosessi käyttää. Valitettavasti yksi komennon syötteistä syötettiin väärin, ja suurempi joukko palvelimia poistettiin kuin oli tarkoitettu.
Kuten käy ilmi, kestävyyden ja saatavuuden erosta on yleinen väärinkäsitys. Kestävyys mittaa tallennuksen luotettavuutta ja vastaa kysymykseen "Menetänkö hukkaan tietoni?" Saatavuus puolestaan mittaa tietojen saatavuutta, ts. "Pystynkö hakemaan tietoni?"
AWS S3 tarjoaa 99,999999999% kestävyyden yhdellä alueella. Jos tarkastelemme Amazonin esimerkkiä, se tarkoittaa, että jos tallennat 10000 objektia S3: een, keskimäärin yksi esine voi kadota 10 miljoonan vuoden välein. Amazon S3 saavuttaa tämän toistamalla tiedot useista alueen eri laitoksista.
Sitä vastoin S3: n tavanomainen objektien saatavuus alueella on 99,99% vuodessa. Tämä tarkoittaa sitä, että tietyllä 12 kuukauden jaksolla sinun pitäisi odottaa, että 52 minuuttia ja 33 sekuntia et voi käyttää tietojasi.
AWS tarjoaa sekä IaaS- että PaaS-palveluja. IaaS-tasolla AWS-asiakkailla on täysi hallinta virtuaalipalvelimista ja -verkoista. He voivat määrittää minkä tahansa haluamansa ohjelmiston ja palvelun ja hallita sitä itse. Kaikki seisokit ovat asiakkaan vastuulla.
PaaS-tasolla AWS tarjoaa täysin hallittuja alustapalveluja, kuten esineiden tallennus, tietokannat, jonot ja niin edelleen. Asiakas delegoi vastuun näiden palvelujen saatavuudesta ja kestävyydestä hallitulle palveluntarjoajalle - tässä tapauksessa AWS: lle. AWS-alustapalvelut, joita käytetään niiden omien sovellusliittymien kautta, ovat erityisen alttiita alueelliselle häiriölle AWS: n inhimillisen virheen vuoksi.
Inhimillinen virhe voi aiheuttaa katkoksen missä tahansa - paikan päällä, pilvessä, hallitusti tai itse isännöimänä. Tarkastellaan äskettäistä Delta-tietokoneen seisokkia esimerkkinä koko itse ylläpidetystä järjestelmästä. Alustapalvelun hallinnointivastuun siirtäminen pilvipalveluntarjoajalle ei muuta sitä tosiasiaa, että inhimilliset virheet voivat tuoda sen alas - mutta se vahvistaa vaikutusta. Delta-seisokki vaikutti vain Deltaan, kun taas AWS S3 -katkos vaikutti hyvään Internet-osaan.
Onneksi AWS S3 tarjoaa runsaasti työkaluja seisokkien vaikutusten vähentämiseksi. Tarkastellaan vain muutamia.
S3-alueen poikkileikkaus
Tietylle S3-alueelle tallennettu data toistetaan kaikilla käytettävyysvyöhykkeillä, ja se voi ylläpitää seisokkia missä tahansa vyöhykkeessä. Se ei kuitenkaan voi selviytyä katkoksesta koko alueella, kuten joka tapahtui 28. helmikuuta. S3-objektien toistaminen maantieteellisillä alueilla auttaa täyttämään lisääntyneet redundanssivaatimukset.
Varmuuskopiot
Alueiden välinen replikointi voi lisätä saatavuutta. Varmuuskopiot AWS-jäätikölle voivat lisätä kestävyyttä. AWS tarjoaa kätevästi automaattisen mekanismin S3: n objektien varmuuskopioimiseksi jäätikölle.
Harkitse sisällön jakelua CloudFrontin avulla
Jos S3-objektejasi käytetään usein, voi olla järkevää määrittää AWS CloudFront palvelemaan objekteja S3: sta. CloudFront kopioi tiedot siellä, missä käyttäjät sitä eniten tarvitsevat, ja se voi auttaa lievittämään S3-seisokin vaikutuksia joissakin käyttötapauksissa.
Lopulliset ajatukset
Hallinnoidut alustapalvelut ovat pilvipalvelujen kulmakivi. S3: n kaltaisen käyttäminen voi vähentää DevOps-kustannuksia ja auttaa tuomaan sovellukset markkinoille nopeammin. Vaikka AWS on ollut erittäin luotettava vuosien varrella, Amazon on aiemmin kokenut itsensä aiheuttamia katkoksia. Äskettäinen S3-seisokki ei ole poikkeus. Joitakin alueiden välisten replikointien, varmuuskopioiden ja sisällön jakelun yhdistelmien pitäisi vähentää tällaisten seisokkien vaikutuksia.
