Pilvilaskenta selitettynä: 11 arkkitehtuurikonseptia, jotka sinun täytyy tietää (4K Masterclass).

Mitä tämä video käsittelee

• - Arkkitehtuurin seinä & pääpiirustus
• - 01. Pysty- vs. vaakasuora skaalaus
• - 02. Kuormituksen tasapainotuksen arkkitehtuuri (L4 vs. L7 & terveyskäytännöt)
• - 03. Automaattinen skaalaus & joustavuus
• - 04. Palvelimeton (FaaS & Firecracker MicroVMs)

Käännetty transkriptio

Käännetty alkuperäisestä englanninkielisestä selostuksesta. Käytettävissä olevan äänen ja tekstitysten hallinta tapahtuu YouTuben kautta.

- Arkkitehtuurin seinä & pääpiirustus

0:00 Jokainen ohjelmistosuunnittelija kohtaa lopulta pilviarkkitehtuurin seinän. Rakennat sovelluksen kannettavallesi, siirrät sen tuotantoon, ja heti kun todelliset käyttäjät saapuvat, palvelimet kaatuvat, tietokantayhteydet loppuvat, ja AWS-laskusi näyttää puhelinnumerolta. Useimmat kehittäjät yrittävät ratkaista pilvitekniikan ulkoa opettelemalla kolmesataa erilaista AWS-tuoteakronyymiä. Mutta todellinen pilvilaskenta ei tarkoita myyjien luetteloiden ulkoa opettelua: se rakentuu yhdestätoista perustavanlaatuisesta arkkitehtonisesta primitiivistä.

0:34 Tällä mestarikurssilla käymme läpi koko yrityspohjapiirroksen: skaalauksesta ja kuormituksen tasapainottamisesta palvelimettomuuteen, tapahtumaohjattuun irrottamiseen, tallennushierarkioihin ja pilviverkkoihin. Hallitse nämä yksitoista käsitettä, ja voit suunnitella minkä tahansa taustajärjestelmän AWS:ssä, GCP:ssä tai Azurella. Tämä on The Daily Diff, pinnan alla.

- 01. Pysty- vs. vaakasuora skaalaus

0:57 Käsite numero yksi: Skaalaus. Kun sovelluksesi kokee liikenteen kasvua, sinulla on kaksi perustavanlaatuisesti erilaista tapaa käsitellä kuormaa: pystysuora skaalaus tai vaakasuora skaalaus. Pystysuora skaalaus, tai skaalaus ylöspäin, tarkoittaa olemassa olevan koneesi ottamista ja lisäresurssien lisäämistä: päivittämistä neljästä CPU-ytimestä kolmeenkymmeneen kahteen, tai kolmenkymmenen kahden gigatavun RAM-muistin vaihtamista sataan kahteenkymmeneen kahdeksaan. Pystysuora skaalaus ei vaadi arkkitehtonisia muutoksia: koodisi

1:28 ja tietokanta pysyvät täsmälleen samoina. Mutta se saavuttaa julman laitteistorajan. Maailmassa ei ole yhtään konetta, jossa olisi kymmenen tuhatta CPU-ydintä, ja huipputason instansseilla on eksponentiaalinen hintapreemio. Vaakasuora skaalaus, tai skaalaus ulospäin, tarkoittaa palvelimiesi pitämistä pieninä ja edullisina, mutta useiden instanssien ajamista rinnakkain reitittimen takana. Jos yksi instanssi kaatuu, jäljelle jäävät solmut imevät liikenteen nolla seisokilla. Vaakasuoran skaalauksen kultainen sääntö on

2:01 tilattomuus: sovelluspalvelimesi eivät voi tallentaa käyttäjäistuntoja, ladattuja tiedostoja tai tilaa paikallisille levyilleen. Tilan on oltava ulkoisessa tietokannassa tai välimuistissa, mahdollistaen minkä tahansa solmun käsittelemään minkä tahansa käyttäjän pyynnön.

- 02. Kuormituksen tasapainotuksen arkkitehtuuri (L4 vs. L7 & terveyskäytännöt)

2:17 Käsite numero kaksi: Kuormituksen tasapainotus. Vaakasuora skaalaus kuulostaa hyvältä paperilla, mutta se esittelee välittömän ongelman: kun kymmenen tuhatta käyttäjää saapuu verkkotunnukseesi, mikä tietty palvelin vastaanottaa heidän liikenteensä? Kuormituksen tasapainottaja toimii käänteisenä välityspalvelimena julkisen internetin ja yksityisen taustajärjestelmäklusterisi välissä. Se hyväksyy saapuvat TCP- tai HTTP-yhteydet ja jakaa pyynnöt terveiden instanssiesi kesken.

2:47 Kuormituksen tasapainottajat toimivat kahdella ensisijaisella verkkokerroksella. Layer 4 -verkon kuormituksen tasapainottajat toimivat siirtokerroksella, reitittäen raakoja TCP- ja UDP-paketteja IP-osoitteen ja portin perusteella mikrosekunnin viiveellä ja miljoonilla pyynnöillä sekunnissa. Layer 7 -sovelluksen kuormituksen tasapainottajat tarkastavat HTTP-protokollan itsensä: lukevat URL-polkuja, pyyntöotsikoita, evästeitä ja HTTP-menetelmiä. Tämä mahdollistaa polkupohjaisen reitityksen: lähettämällä kauttaviiva-api-pyynnöt taustajärjestelmäklusteriisi ja kauttaviiva-staattiset pyynnöt

3:25 objektivarastoon. Erityisesti kuormituksen tasapainottajat suorittavat aktiivisia terveyskäytäntöjä. Muutaman sekunnin välein tasapainottaja pingaa terveyspäätepistettä jokaisessa instanssissa. Jos instanssi antaa kolme peräkkäistä viisisataa virhettä tai ei vastaa, se poistetaan automaattisesti poolista nolla pudonneella pyynnöllä.

- 03. Automaattinen skaalaus & joustavuus

3:45 Käsite numero kolme: Automaattinen skaalaus. Jos verkkosovelluksesi tarvitsee kaksi palvelinta aamukolmena, mutta kaksikymmentä palvelinta keskipäivän lanseerauksen aikana, painikkeiden manuaalinen napsauttelu pilvikonsolissa johtaa varmasti seisokkeihin ja konkurssiin. Automaattinen skaalaus tuo dynaamisen joustavuuden vaakasuoriin palvelinryhmiin. Automaattisen skaalauksen ryhmä valvoo suorituskykymittareita, kuten keskimääräistä suorittimen käyttöä, verkon I/O:ta tai jonon ruuhkaa. Kun keskimääräinen suoritin ylittää määritellyn kynnyksen – esimerkiksi

4:19 seitsemänkymmentä prosenttia kolmen peräkkäisen minuutin ajan – automaattinen skaalain käynnistää automaattisesti uusia virtuaalikoneita, rekisteröi ne kuormituksen tasapainottajaasi ja alkaa ohjata liikennettä. Yhtä tärkeää on skaalaus sisäänpäin: kun liikenneaalto vetäytyy, automaattinen skaalain lopettaa ylimääräiset instanssit, jotta et enää maksa tyhjäkäynnillä olevasta laskentatehosta. Estääkseen räpiköinnin – jossa palvelimia luodaan ja tuhotaan nopeasti loputtomassa rymistelevässä silmukassa – pilviarkkitehdit määrittävät jäähdytysajat. Käsite numero neljä: Palvelimeton.

- 04. Palvelimeton (FaaS & Firecracker MicroVMs)

4:53 Vuosia markkinointitiimit mainostivat palvelimetonta taianomaisena koodina, joka juoksee taivaalla. Todellisuudessa palvelimeton käyttää edelleen palvelimia – mutta et omista, korjaa tai maksa niistä, kun koodia ei suoriteta. Function-as-a-Service -palveluissa, kuten AWS Lambdassa tai Google Cloud Functionsissa, kirjoitat itsenäisen käsittelijäfunktion. Kun HTTP-pyyntö, S3-tiedoston lataus tai tietokannan muutos tapahtuu, pilven suoritusympäristö käynnistää lyhytaikaisen

5:23 mikrovirtuaalikoneen, kuten Firecrackerin, alle viidessä millisekunnissa. Koodisi suoritetaan, palauttaa vastauksen ja sammuu. Jos kukaan ei käy verkkosivustollasi kolmeen kuukauteen, laskutus laskentatehosta on täsmälleen nolla dollaria ja nolla senttiä. Jos miljoona käyttäjää iskee siihen samanaikaisesti, palveluntarjoaja pyöräyttää miljoona samanaikaista microVM:ää. Tekniset kompromissit ovat todellisia: kylmäkäynnistyksen viive uusien suoritusympäristöjen käynnistyessä, Lambdan tiukka viidentoista minuutin suoritusraja ja tiukka tilattomuus.

5:55 Palvelimeton on lyömätön tapahtumaputkille ja satunnaisille API:ille, mutta huono pysyville WebSockets-yhteyksille tai usean tunnin koulutuskierroksille.

- 05. Tapahtumaohjattu arkkitehtuuri (EDA & irrottaminen)

6:05 Käsite numero viisi: Tapahtumaohjattu arkkitehtuuri, eli EDA. Perinteisissä arkkitehtuureissa palvelut kommunikoivat synkronisesti. Ostoskoripalvelusi kutsuu maksua, maksu kutsuu varastoa, varasto kutsuu petosta, ja petos kutsuu sähköpostia. Tämä luo synkronisen tuomion kaskadin. Jos kolmannen osapuolen sähköpostipalveluntarjoaja kokee verkon häiriön ja vastaaminen kestää kymmenen sekuntia, asiakkaasi koko kassapyyntö aikakatkaistaan virheellä. Tapahtumaohjatussa arkkitehtuurissa palvelut ovat täysin erotettuja.

6:37 Kun asiakas klikkaa osta, kassapalvelu ei kutsu alavirran palveluita. Se yksinkertaisesti julkaisee tapahtuman nimeltä OrderPlaced keskitettyyn tapahtumaväylään, kuten Amazon EventBridgeen tai SNS-aiheeseen. Kassa suoritetaan viidessäkymmenessä millisekunnissa. Alavirran työntekijät maksun, varaston vähennyksen ja sähköpostikuitin osalta hakevat viestejä itsenäisesti omista dedikoiduista SQS-jonoistaan. Jos sähköpostipalvelu kaatuu tunniksi, viestit odottavat turvallisesti puskuroituna jonossa ilman yhtään pudonnutta tilausta.

- 06. Konttien orkestrointi (Docker & Kubernetes)

7:13 Käsite numero kuusi: Konttien orkestrointi. Docker ratkaisi pakkaamisen: se käärii sovelluskoodisi, järjestelmäkirjastot, konfiguraation ja ajonaikaisen ympäristön muuttumattomaksi kuvaksi, joka toimii samalla tavalla MacBookissasi ja pilvessä. Mutta konttien pakkaaminen on helppoa. Viidensadan kontin ajaminen viidelläkymmenellä fyysisellä virtuaalikoneella on se kohta, jossa insinöörityö katkeaa. Siksi konttien orkestraattorit, kuten Kubernetes ja AWS ECS,

7:41 ovat olemassa. Orkestraattori tarjoaa ohjaustason: API-palvelimen, etcd-tilavaraston ja älykkään aikatauluttajan. Ilmoitat haluamasi tilan: haluan kymmenen kopiota todennuspalvelustani kahden gigatavun RAM-muistilla kukin. Aikatauluttaja tarkastaa klusterin, asettaa podit solmuihin, joilla on vapaata muistia, konfiguroi sisäisen verkon ja sovittaa jatkuvasti todellisuutta. Jos solmu kärsii laitteistovirheestä, Kubernetes havaitsee menetyksen ja ajoittaa välittömästi kaikki siirretyt podit

- 07. Neljä pilvitallennuspilaria (S3, EBS, DBs & Redis)

8:16 terveille solmuille. Käsite numero seitsemän: Pilvitallennuksen hierarkia. Aloittelijat kohtelevat usein pilvitallennusta yhtenä säiliönä, johon he kaatavat tiedostoja. Tuotantoarkkitehtuurissa tallennus jaetaan neljään erilliseen pilariin pääsymallien ja latenssin perusteella. Ensimmäinen on objektitallennus, kuten Amazon S3 tai Google Cloud Storage. Pääset tiedostoihin HTTP REST API:en kautta käyttämällä yksinkertaisia PUT- ja GET-kutsuja. Se tarjoaa äärettömän vaakasuoran kapasiteetin kahdella sentillä gigatavua kohti kuukaudessa,

8:49 mikä tekee siitä ihanteellisen videolle, käyttäjän latauksille, lokeille ja varmuuskopioille. Toinen on lohkotallennus, kuten Amazon EBS. Nämä ovat virtuaalisia kiintolevyjä, jotka on asennettu suoraan tiettyyn virtuaalikoneeseen nopeiden liitäntöjen kautta. Ne alustetaan tavallisiksi tiedostojärjestelmiksi, kuten ext4:ksi, tukien nopeaa satunnaista luku- ja kirjoituskäyttöä, jota tietokantamoottorit vaativat. Kolmas ovat hallitut tietokannat: relaatiomoottorit, kuten PostgreSQL RDS:ssä, jotka tarjoavat ACID-transaktiot ja monimutkaiset liitokset,

9:21 ja NoSQL-moottorit, kuten DynamoDB, jotka tarjoavat yhden numeron millisekunnin latenssin massiivisessa mittakaavassa. Ja neljäs ovat muistivälimuistit, kuten Redis. Tiedon lukeminen RAM-muistista kestää mikrosekunteja millisekuntien sijaan. Välimuistit sijaitsevat tietokantasi edessä, suojaten sitä toistuvilta lukuliikenteiltä ja halliten haihtuvia käyttäjäistuntojen tunnuksia.

- 08. Korkea saatavuus & yhdeksiköt (Multi-AZ Failover)

9:44 Käsite numero kahdeksan: Korkea saatavuus, eli HA. Saatavuus vastaa yhteen kysymykseen: kuinka monta prosenttia ajasta sovelluksesi on toiminnassa ja käyttäjien saavutettavissa? Yrityssopimuksissa saatavuus mitataan yhdeksiköinä. Kaksi yhdeksikköä, tai yhdeksänkymmentäyhdeksän prosentin saatavuus, sallii yli kolmen ja puolen päivän seisokin joka vuosi. Neljä yhdeksikköä pudottaa sallitun seisokin viiteenkymmeneen kahteen minuuttiin, ja viisi yhdeksikköä sallii tuskin viisi minuuttia kokonaisseisokkia

10:15 vuodessa. Saavuttaaksesi korkean saatavuuden sinun on poistettava yksittäiset vikakohdat vika-alueiden yli. Pilvessä se tarkoittaa käyttöönottoa useilla saatavuusvyöhykkeillä. Saatavuusvyöhyke ei ole yksi teline: se on yksi tai useampi erillinen fyysinen datakeskus mailien päässä toisistaan itsenäisellä virransyötöllä ja jäähdytyksellä. Ajamalla aktiivisia instansseja vyöhykkeellä A ja vyöhykkeellä B synkronisella tietokannan replikoinnilla, salamanniskut tai kuitukatkos, joka kaataa koko fyysisen tilan, johtaa automaattiseen vikasietoisuuteen.

10:50 kolmessakymmenessä sekunnissa ilman ihmisen väliintuloa.

- 09. Kestävyys vs. saatavuus (Miksi 11 yhdeksikköä ei ole käytettävyysaika)

10:53 Yhdeksäs käsite: Kestävyys vastaan saatavuus. Tämä on yleisin käsitteellinen ansa pilviarkkitehtuurihaastatteluissa. Insinöörit käyttävät sanoja usein vaihdellen, mutta ne mittaavat täysin eri ominaisuuksia. Saatavuus mittaa käyttöaikaa: voinko tehdä API-kutsun lukeakseni tai kirjoittaakseni dataani juuri nyt? Kestävyys mittaa säilyvyyttä: säilyykö datani ilman pysyvää bittimätää, korruptiota tai tuhoutumista kymmenen vuoden ajan?

11:24 Katsotaanpa Amazon S3 Standardia. Sen palvelutasosopimus tarjoaa yhdeksänkymmentäyhdeksän pilkku yhdeksän prosenttia saatavuutta, mikä sallii noin neljäkymmentäkolme minuuttia käyttökatkoa kuukaudessa, jolloin API-pyyntö voi palauttaa viisisataa virheen. Mutta S3 lupaa yksitoista yhdeksikköä kestävyyttä: yhdeksänkymmentäyhdeksän pilkku yhdeksän yhdeksän yhdeksän yhdeksän yhdeksän yhdeksän yhdeksän yhdeksän yhdeksän prosenttia. Jos tallennat kymmenen miljoonaa tiedostoa S3:een, voit tilastollisesti odottaa menettäväsi keskimäärin yhden tiedoston kymmenentuhannen vuoden välein.

11:56 keskimäärin yhden tiedoston kymmenentuhannen vuoden välein. S3 saavuttaa tämän poistamalla virheitä kohteista ja replikoimalla paloja vähintään kolmen maantieteellisesti erillisen datakeskuksen kesken. Suuren alueellisen verkkokatkon aikana S3 voi olla tilapäisesti käyttökelvoton, mutta tietosi eivät koskaan tuhoudu.

- 10. Infrastruktuuri koodina (Terraform vs. konsolivirhe)

12:14 Kymmenes käsite: Infrastruktuuri koodina, eli IaC. Pilvilaskennan alkuvaiheessa insinöörit kirjautuivat AWS:n web-hallintakonsoliin ja napsauttelivat manuaalisesti luodakseen virtuaalikoneita, määrittääkseen aliverkkoja ja liittääkseen turvallisuusryhmiä. Alan termi tälle on ClickOps, ja tuotantoympäristössä se on täydellinen katastrofi. Manuaalisilla konsolimuutoksilla ei ole valvontajälkeä, ei palautusmekanismia eikä ne väistämättä aiheuta konfiguraation ajautumista kehitys- ja tuotantoympäristöjen välillä. Infrastructure as Code -työkalujen, kuten Terraformin,

12:48 Infrastructure as Code -työkalujen, kuten Terraformin, OpenTofun, Pulumin tai AWS CDK:n, avulla määrität koko pilviarkkitehtuurisi deklaratiivisissa konfiguraatiotiedostoissa, jotka on tallennettu Gitiin. Jokainen avoimen portin tai tietokannan replikan muutos käy läpi pull-pyynnön ja vertaisarvioinnin. terraform plan -komennon suorittaminen esikatselee tarkan API-diffin ennen kuin mitään kosketaan, ja identtisen kopion tuotantoympäristöstäsi käynnistäminen kestää neljä minuuttia neljän viikon sijaan.

- 11. Pilviverkko (VPC, aliverkot, NAT & tietoturvaryhmät)

13:20 Yhdestoista käsite: Pilviverkot ja virtuaaliset yksityisverkot (VPC). Kun otat palvelimia käyttöön pilveen, ne eivät ole alttiina suoraan julkisessa internetissä. Ne elävät ohjelmistopohjaisessa eristetyssä rajapinnassa nimeltään VPC. VPC:si sisällä allokoit yksityisen IP-osoiteavaruuden, kuten kymmenen-piste-nolla-piste-nolla-piste-nolla kauttaviiva kuusitoista, ja jaat sen julkisiin ja yksityisiin aliverkkoihin. Julkisella aliverkolla on suora reitti Internet Gateway -yhdyskäytävään.

13:51 Se sisältää julkisesti näkyviä resursseja, kuten Application Load Balancerit ja NAT Gatewayt. Se on ainoa osa verkkoasi, jolla on julkisia IP-osoitteita. Sovelluspalvelimesi ja tuotantotietokannat sijaitsevat tiukasti yksityisissä aliverkoissa, joissa ei ole julkisia IP-osoitteita ja nolla sisääntulevaa reittiä internetistä. Kun taustapalvelimiesi täytyy ladata tietoturvapäivityksiä, niiden lähtevä liikenne reititetään julkisen aliverkon NAT Gatewayn kautta. Jokaisen instanssin ympärillä ovat Security Groups -turvallisuusryhmät: tilallisia virtuaalisia palomuureja, jotka noudattavat "vähiten etuoikeutta" -periaatetta.

- 12. Täydellinen yrityspohjapiirros & tuomio

14:28 Tietokannan turvallisuusryhmä hyväksyy yhteydet vain porttiin 5432 ja ainoastaan sovelluspalvelimien turvallisuusryhmästä, tehden ulkopuolisen tunkeutumisen matemaattisesti mahdottomaksi. Kun zoomaat ulos, nämä yksitoista perusosaa yhdistyvät yhdeksi yhtenäiseksi järjestelmäksi. DNS ohjaa kuormantasaajaan julkisessa aliverkossa, automaattiset skaalausryhmät käsittelevät liikennekuormia useilla saatavuusalueilla, tapahtumaväylät erottavat taustatyötekijät, ja koko pinosi on käyttöönotettu Gitistä käyttäen Infrastructure as Codea.

15:02 Tämän päivän mestarikurssin tuomio: SHIP IT. Lopeta satojen pilvimarkkinoinnin lyhenteiden ulkoa opettelu. Hallitse nämä yksitoista arkkitehtuurimallia, irrota tilasi, ja rakenna järjestelmiä, jotka eivät voi epäonnistua. Kerro minulle, mikä pilvikonsepti aiheutti sinulle suurimman päänsäryn, kun aloit rakentaa kommentteissa. Ja saadaksesi täydellisen arkkitehtuurin huijauslehdellä, tilaa uutiskirje daily diff dot dev -sivustolta,

15:28 linkki alla. Ja se on päivän ero. Olen Niko Axrisista. Yhdistä vastuullisesti.

Lähteet

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io