Objašnjeno računalstvo u oblaku: 11 arhitektonskih koncepata koje morate znati (4K Masterclass).

Što ovaj video pokriva

• - Zid arhitekture i glavni nacrt
• - 01. Vertikalno naspram horizontalnog skaliranja
• - 02. Arhitektura uravnoteženja opterećenja (L4 naspram L7 i provjere ispravnosti)
• - 03. Automatsko skaliranje i elastičnost
• - 04. Bez poslužitelja (FaaS i Firecracker MicroVM-ovi)

Prevedeni transkript

Prevedeno iz izvornog engleskog pripovijedanja. Dostupni zvuk i titlovi kontroliraju se putem YouTubea.

- Zid arhitekture i glavni nacrt

0:00 Svaki softverski inženjer na kraju se suoči sa zidom arhitekture oblaka. Izgradite aplikaciju na svom laptopu, gurnete je u produkciju, i u trenutku kada stignu stvarni korisnici, poslužitelji se ruše, veze s bazom podataka se iscrpe, a vaš AWS račun izgleda kao telefonski broj. Većina developera pokušava riješiti inženjering oblaka memoriranjem tristo različitih akronima AWS proizvoda. Ali stvarno računalstvo u oblaku ne odnosi se na memoriranje kataloga dobavljača: ono je izgrađeno na jedanaest temeljnih arhitektonskih primitiva.

0:34 U ovoj majstorskoj klasi proći ćemo kroz cijeli poduzećni nacrt: od skaliranja i uravnoteženja opterećenja do serverless, razdvajanja pogonjenog događajima, hijerarhija pohrane i umrežavanja u oblaku. Ovladajte ovim jedanaest koncepata i moći ćete dizajnirati bilo koji backend na AWS-u, GCP-u ili Azureu. Ovo je The Daily Diff, ispod haube.

- 01. Vertikalno naspram horizontalnog skaliranja

0:57 Koncept broj jedan: Skaliranje. Kada vaša aplikacija doživi rast prometa, imate dva temeljno različita načina za rukovanje opterećenjem: vertikalno skaliranje ili horizontalno skaliranje. Vertikalno skaliranje, ili skaliranje prema gore, znači uzimanje vaše postojeće mašine i dodavanje više resursa: nadogradnja sa četiri CPU jezgre na trideset dvije, ili zamjena trideset dva gigabajta RAM-a za sto dvadeset osam. Vertikalno skaliranje ne zahtijeva nikakve arhitektonske promjene: vaš kod

1:28 i baza podataka ostaju potpuno isti. Ali nailazi na brutalni hardverski plafon. Nijedna jedina mašina na svijetu nema deset tisuća CPU jezgri, a vrhunske instance nose eksponencijalnu cijenu. Horizontalno skaliranje, ili skaliranje van, znači držanje vaših poslužitelja malih i cjenovno prihvatljivih, ali pokretanje više instanci paralelno iza rutera. Ako jedna instanca padne, preostali čvorovi apsorbiraju promet s nula vremena zastoja. Zlatno pravilo horizontalnog skaliranja je

2:01 bezstanovnost: vaši aplikacijski poslužitelji ne mogu pohranjivati korisničke sesije, učitane datoteke ili stanje na svojim lokalnim diskovima. Stanje mora živjeti u vanjskoj bazi podataka ili predmemoriji, omogućujući bilo kojem čvoru da rukuje bilo kojim korisničkim zahtjevom.

- 02. Arhitektura uravnoteženja opterećenja (L4 naspram L7 i provjere ispravnosti)

2:17 Koncept broj dva: Uravnoteženje opterećenja. Horizontalno skaliranje zvuči sjajno na papiru, ali uvodi neposredan problem: kada deset tisuća korisnika pogodi vašu domenu, koji specifični poslužitelj prima njihov promet? Uravnoteženje opterećenja djeluje kao obrnuti proxy koji se nalazi između javnog interneta i vašeg privatnog pozadinskog klastera. Prihvaća dolazne TCP ili HTTP veze i distribuira zahtjeve među vašim ispravnim instancama.

2:47 Uravnoteživači opterećenja rade na dva primarna mrežna sloja. Mrežni uravnoteživači opterećenja sloja 4 rade na transportnom sloju, usmjeravajući sirove TCP i UDP pakete na temelju IP adrese i porta s mikrosekundnom latencijom i milijunima zahtjeva u sekundi. Aplikacijski uravnoteživači opterećenja sloja 7 pregledavaju HTTP protokol sam: čitaju URL putanje, zaglavlja zahtjeva, kolačiće i HTTP metode. To omogućuje usmjeravanje na temelju putanje: slanje zahtjeva za slash-api vašem pozadinskom klasteru i zahtjeva za slash-static na

3:25 skladište objekata. Ključno, uravnoteživači opterećenja obavljaju aktivne provjere ispravnosti. Svakih nekoliko sekundi, uravnoteživač pinga zdravstvenu točku na svakoj instanci. Ako instanca baci tri uzastopne petsto pogreške ili ne uspije odgovoriti, automatski se izbacuje iz skupa s nula ispuštenih zahtjeva.

- 03. Automatsko skaliranje i elastičnost

3:45 Koncept broj tri: Automatsko skaliranje. Ako vaša web aplikacija treba dva poslužitelja u tri ujutro, ali dvadeset poslužitelja tijekom podneva, ručno klikanje gumba u konzoli oblaka zajamčeni je put do zastoja i bankrota. Automatsko skaliranje donosi dinamičku elastičnost horizontalnim skupovima poslužitelja. Grupa za automatsko skaliranje prati metrike performansi kao što su prosječna iskorištenost CPU-a, mrežno I-O ili dubina zaostatka u redu čekanja. Kada prosječna upotreba CPU-a prijeđe definirani prag — recimo,

4:19 sedamdeset posto tijekom tri uzastopne minute — automatski pokretač automatski pokreće nove virtualne strojeve, registrira ih s vašim uravnoteživačem opterećenja, i počinje usmjeravati promet. Jednako važno je skaliranje prema unutra: kada se val prometa povuče, automatski pokretač terminira višak instanci tako da prestanete plaćati za neaktivno računalstvo. Da bi se spriječilo treptanje — gdje se poslužitelji brzo kreiraju i uništavaju u beskonačnoj petlji trzanja — arhitekti oblaka konfiguriraju razdoblja hlađenja. Koncept broj četiri: Bez poslužitelja.

- 04. Bez poslužitelja (FaaS i Firecracker MicroVM-ovi)

4:53 Godinama su marketinški timovi prodavali bez poslužitelja kao čarobni kod koji radi na nebu. U stvarnosti, bez poslužitelja i dalje koristi poslužitelje — ali ih ne posjedujete, ne patchirate niti plaćate kada kod ne radi. S funkcijama kao uslugom (FaaS) poput AWS Lambda ili Google Cloud Functions, pišete samostalnu funkciju rukovatelja. Kada se dogodi HTTP zahtjev, S3 prijenos datoteke ili promjena baze podataka, runtime u oblaku pokreće efemerni

5:23 mikrovirtualni stroj poput Firecrackera za manje od pet milisekundi. Vaš se kod izvršava, vraća odgovor i gasi se. Ako nitko ne posjeti vašu web stranicu tri mjeseca, vaš račun za računalstvo je točno nula dolara i nula centi. Ako ga milijun korisnika pogodi istovremeno, pružatelj pokreće milijun istodobnih mikroVM-ova. Inženjerski kompromisi su stvarni: latencija hladnog starta pri pokretanju svježih runtimea, tvrdo petnaestominutno ograničenje izvršavanja na Lambdi i stroga bezstanovnost.

5:55 Bez poslužitelja je nenadmašan za događajne cjevovode i sporadične API-je, ali loš za trajne WebSockets ili više-satne obuke.

- 05. Arhitektura vođena događajima (EDA i razdvajanje)

6:05 Koncept broj pet: Arhitektura vođena događajima, ili EDA. U tradicionalnim arhitekturama, usluge komuniciraju sinkrono. Vaša usluga naplate poziva plaćanje, plaćanje poziva inventar, inventar poziva prijevaru, a prijevara poziva e-poštu. Ovo stvara sinkronu kaskadu propasti. Ako pružatelj e-pošte treće strane doživi mrežni zastoj i treba mu deset sekundi da odgovori, cijeli zahtjev za naplatu vašeg klijenta istekne s greškom. U arhitekturi vođenoj događajima, usluge su potpuno odvojene.

6:37 Kada kupac klikne kupi, usluga naplate ne poziva nizvodne usluge. Ona jednostavno objavljuje događaj pod nazivom NarudžbaPostavljena na središnji Event Bus poput Amazon EventBridge ili SNS temu. Naplata se dovršava za pedeset milisekundi. Nizvodni radnici za plaćanje, oduzimanje inventara i račune e-pošte povlače poruke neovisno iz svojih posvećenih SQS redova. Ako usluga e-pošte padne sat vremena, poruke sigurno čekaju u redu bez ijedne ispuštene narudžbe.

- 06. Orkestracija kontejnera (Docker i Kubernetes)

7:13 Koncept broj šest: Orkestracija kontejnera. Docker je riješio pakiranje: on omotava vaš aplikacijski kod, sistemske biblioteke, konfiguraciju i runtime u nepromjenjivu sliku koja radi identično na vašem MacBooku i u oblaku. Ali pakiranje kontejnera je jednostavno. Pokretanje pet stotina kontejnera na pedeset fizičkih virtualnih strojeva je mjesto gdje inženjering puca. Zato postoje orkestratori kontejnera poput Kubernetes i AWS ECS.

7:41 Orkestrator pruža kontrolnu ravan: API poslužitelj, etcd skladište stanja i inteligentni raspoređivač. Vi deklarirate svoje željeno stanje: Želim deset replika svoje auth usluge s po dva gigabajta RAM-a. Raspoređivač pregledava klaster, postavlja podove na čvorove sa slobodnom memorijom, konfigurira interno umrežavanje i kontinuirano usklađuje stvarnost. Ako čvor doživi hardverski kvar, Kubernetes otkriva gubitak i odmah prebacuje sve raseljene podove na

- 07. 4 stupa pohrane u oblaku (S3, EBS, DB-ovi i Redis)

8:16 zdrave čvorove. Koncept broj sedam: Hijerarhija pohrane u oblaku. Početnici često tretiraju pohranu u oblaku kao jednu kantu gdje bacate datoteke. U produkcijskoj arhitekturi, pohrana je podijeljena u četiri različita stupa na temelju obrazaca pristupa i latencije. Prvo je Objektna pohrana, poput Amazon S3 ili Google Cloud Storage. Pristupate datotekama putem HTTP REST API-ja koristeći jednostavne PUT i GET pozive. Nudi beskonačan horizontalni kapacitet po dva centa po gigabajtu mjesečno,

8:49 čineći ga idealnim za video, korisničke prijenose, dnevnike i sigurnosne kopije. Drugo je Blokovna pohrana, poput Amazon EBS. To su virtualni tvrdi diskovi montirani izravno na specifični virtualni stroj putem brzih međusobnih veza. Formatiraju se u standardne datotečne sustave poput ext4, podržavajući brzi nasumični pristup čitanju i pisanju koji zahtijevaju baze podataka motori. Treće su Upravljane baze podataka: relacijski motori poput PostgreSQL-a na RDS-u koji pružaju ACID transakcije i složena spajanja,

9:21 i NoSQL motori poput DynamoDB-a koji isporučuju jednoznamenkastu milisekundnu latenciju pri masivnoj skali. I četvrto su predmemorije u memoriji poput Redisa. Čitanje podataka iz RAM-a traje mikrosekunde, a ne milisekunde. Predmemorije se nalaze ispred vaše baze podataka, štiteći je od ponovljenog prometa čitanja i upravljajući volatilnim tokenima korisničke sesije.

- 08. Visoka dostupnost i devetke (Multi-AZ Failover)

9:44 Koncept broj osam: Visoka dostupnost, ili HA. Dostupnost odgovara na jedno pitanje: koliki postotak vremena je vaša aplikacija operativna i dostupna korisnicima? U korporativnim ugovorima, dostupnost se mjeri u devetkama. Dvije devetke, ili devedeset devet posto dostupnosti, dopušta više od tri i pol dana zastoja svake godine. Četiri devetke smanjuju dopušteno vrijeme zastoja na pedeset dvije minute, a pet devetki dopušta jedva pet minuta ukupnog zastoja godišnje.

10:15 Da bi se postigla visoka dostupnost, morate eliminirati pojedine točke kvara preko domena greške. U oblaku, to znači implementaciju preko više Zona dostupnosti. Zona dostupnosti nije samo jedan stalak: to je jedan ili više različitih fizičkih podatkovnih centara udaljenih miljama s neovisnim napajanjem i hlađenjem. Pokretanjem aktivnih instanci u Zoni A i Zoni B sa sinkronom replikacijom baze podataka, udar groma ili prekid vlakana koji sruši cijelo fizičko postrojenje rezultira automatskim prebacivanjem na rezervu.

10:50 za trideset sekundi bez ikakve ljudske intervencije.

- 09. Trajnost naspram dostupnosti (Zašto 11 devetki nije vrijeme rada)

10:53 Koncept broj devet: Trajnost naspram Dostupnosti. Ovo je najčešća konceptualna zamka u intervjuima za arhitekturu oblaka. Inženjeri često koriste ove riječi naizmjenično, ali one mjere potpuno različite osobine. Dostupnost mjeri vrijeme rada: mogu li uputiti API poziv za čitanje ili pisanje mojih podataka upravo sada? Trajnost mjeri očuvanje: hoće li moji podaci preživjeti bez trajnog kvarenja bitova, korupcije ili uništenja tijekom deset godina?

11:24 Pogledajte Amazon S3 Standard. Njegov Ugovor o razini usluge nudi devedeset devet zarez devet posto dostupnosti, što dopušta otprilike četrdeset tri minute prekida rada svaki mjesec gdje API zahtjev može vratiti pogrešku petstotinjak. Ali S3 obećava jedanaest devetki trajnosti: devedeset devet zarez devet devet devet devet devet devet devet devet devet posto. Ako pohranite deset milijuna datoteka u S3, statistički možete očekivati da ćete izgubiti

11:56 prosječno jednu datoteku svakih deset tisuća godina. S3 to postiže kodiranjem objekata s ispravljanjem pogrešaka i repliciranjem dijelova preko najmanje tri geografski odvojena podatkovna centra. Tijekom velikog regionalnog mrežnog prekida, S3 bi privremeno mogao biti nedostupan, ali vaši podaci nikada nisu uništeni.

- 10. Infrastruktura kao kod (Terraform naspram konzolnog pomaka)

12:14 Koncept broj deset: Infrastruktura kao kod, ili IaC. U ranim danima računalstva u oblaku, inženjeri su se prijavljivali u AWS web konzolu za upravljanje i ručno klikali kako bi stvorili virtualne strojeve, konfigurirali podmreže i priključili sigurnosne grupe. Industrija to naziva ClickOps, a u proizvodnji je to apsolutna katastrofa. Ručne promjene u konzoli nemaju revizorski trag, nemaju mehanizam povratka na prethodno stanje i neizbježno uzrokuju odstupanje konfiguracije između razvojnih i produkcijskih okruženja. S alatima za Infrastrukturu

12:48 kao kod, poput Terraform, OpenTofu, Pulumi ili AWS CDK, cijelu svoju arhitekturu oblaka definirate u deklarativnim konfiguracijskim datotekama pohranjenim u Gitu. Svaka promjena otvorenog porta ili replike baze podataka prolazi kroz zahtjev za povlačenje i recenziju kolega. Pokretanje terraform plan-a pregledava točnu API razliku prije nego što se išta dodirne, a pokretanje identične replike vašeg produkcijskog sustava traje četiri minute umjesto četiri tjedna.

- 11. Umrežavanje u oblaku (VPC, podmreže, NAT i sigurnosne grupe)

13:20 Koncept broj jedanaest: Mreža u oblaku i Virtualne privatne mreže (VPC). Kada poslužitelje postavljate u oblak, oni nisu izloženi na sirovom javnom internetu. Žive unutar softverski definirane izolirane granice nazvane VPC. Unutar svog VPC-a dodjeljujete privatni IP adresni prostor poput deset-točka-nula-točka-nula-točka-nula kosa crta šesnaest, i dijelite ga na javne i privatne podmreže. Javna podmreža ima izravan put do internetskog prolaza.

13:51 Sadrži javne resurse poput vaših balansa opterećenja aplikacije i NAT prolaza. To je jedini dio vaše mreže koji posjeduje javne IP adrese. Vaši aplikacijski poslužitelji i produkcijske baze podataka žive isključivo u privatnim podmrežama bez javnih IP-ova i nula ulaznih ruta s interneta. Kada vaši pozadinski poslužitelji trebaju preuzeti sigurnosna ažuriranja, njihov izlazni promet prolazi kroz NAT Gateway u javnoj podmreži. Oko svake instance nalaze se Sigurnosne grupe: stateful virtualni vatrozidi koji provode princip najmanje privilegije.

- 12. Kompletan poduzećni nacrt i presuda

14:28 Vaša sigurnosna grupa baze podataka prihvaća veze samo na portu 5432 isključivo iz sigurnosne grupe vaših aplikacijskih poslužitelja, čineći vanjsko prodiranje matematički nemogućim. Kada se odmaknete, ovih jedanaest primitiva povezuje se u jedan kohezivni sustav. Vaš DNS usmjerava se na balanser opterećenja u javnoj podmreži, grupe za automatsko skaliranje rješavaju prometne vrhunce u više zona dostupnosti, sabirnice događaja razdvajaju pozadinske radnike, a cijeli vaš sustav se postavlja iz GITA koristeći Infrastrukturu kao kod.

15:02 Presuda današnje majstorske klase: SHIP IT. Prestanite pamtiti stotine akronima oblačnog marketinga. Ovladajte ovih jedanaest arhitektonskih obrazaca, razdvojite svoje stanje, i izgradite sustave koji ne mogu propasti. Recite mi koji vam je koncept oblaka zadao najveću glavobolju kada ste tek počeli graditi u komentarima. A da biste preuzeli kompletnu arhitektonsku "cheat sheet", pretplatite se na newsletter na the daily diff dot dev,

15:28 link ispod. I to je razlika za danas. Ja sam Niko iz Axrisija. Spajajte odgovorno.

Izvori

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