Cloud computing forklart: de 11 arkitekturkonseptene du må kjenne til (4K Masterclass).

Hva denne videoen dekker

• - Arkitekturveggen og Hovedplanen
• - 01. Vertikal vs. Horisontal Skalering
• - 02. Lastbalanseringsarkitektur (L4 vs. L7 & Tilstandssjekker)
• - 03. Autoskalering og Elastisitet
• - 04. Serverløs (FaaS og Firecracker Mikro-VMs)

Oversatt transkripsjon

Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.

- Arkitekturveggen og Hovedplanen

0:00 Hver programvareingeniør står til slutt overfor skyarkitekturveggen. Du bygger en applikasjon på laptopen din, skyver den til produksjon, og i det øyeblikket ekte brukere ankommer, krasjer servere, databaseforbindelser går tomme, og AWS-regningen din ser ut som et telefonnummer. De fleste utviklere prøver å løse skyteknikk ved å memorere tre hundre forskjellige AWS-produktakronymer. Men ekte skytjenester handler ikke om å memorere leverandørkataloger: det er bygget på elleve grunnleggende arkitektoniske primitiver.

0:34 I denne masterclassen vil vi gå gjennom hele bedriftsplanen: fra skalering og lastbalansering til serverløs, hendelsesdrevet frikobling, lagringshierarkier og skynettverk. Mestr disse elleve konseptene, og du kan designe enhver backend på AWS, GCP eller Azure. Dette er The Daily Diff, under panseret.

- 01. Vertikal vs. Horisontal Skalering

0:57 Konsept nummer én: Skalering. Når applikasjonen din opplever trafikkvekst, har du to fundamentalt forskjellige måter å håndtere belastningen på: vertikal skalering, eller horisontal skalering. Vertikal skalering, eller oppskalering, betyr å ta din eksisterende maskin og legge til flere ressurser: oppgradere fra fire CPU-kjerner til trettito, eller bytte ut trettito gigabyte RAM med et hundre og tjueåtte. Vertikal skalering krever null arkitektoniske endringer: koden din

1:28 og databasen forblir nøyaktig den samme. Men det treffer et brutalt maskinvaretak. Ingen enkelt maskin i verden har ti tusen CPU-kjerner, og topp-tier-instanser har en eksponentiell prispremie. Horisontal skalering, eller utskalering, betyr å holde serverne dine små og rimelige, men kjøre flere instanser parallelt bak en ruter. Hvis en instans krasjer, absorberer de resterende nodene trafikken med null nedetid. Den gyldne regelen for horisontal skalering er

2:01 tilstandsløshet: applikasjonsserverne dine kan ikke lagre brukersesjoner, opplastede filer, eller tilstand på deres lokale disker. Tilstand må ligge i en ekstern database eller cache, noe som tillater enhver node å håndtere enhver brukerforespørsel.

- 02. Lastbalanseringsarkitektur (L4 vs. L7 & Tilstandssjekker)

2:17 Konsept nummer to: Lastbalansering. Horisontal skalering høres flott ut på papiret, men det introduserer et umiddelbart problem: når ti tusen brukere treffer domenenavnet ditt, hvilken spesifikk server mottar trafikken deres? En lastbalanser fungerer som en omvendt proxy som sitter mellom det offentlige internett og ditt private bakendkluster. Den aksepterer innkommende TCP- eller HTTP-forbindelser og fordeler forespørsler på tvers av dine sunne instanser.

2:47 Lastbalansere opererer på to primære nettverkslag. Layer 4 Nettverkslastbalansere opererer på transportlaget, ruter rå TCP- og UDP-pakker basert på IP-adresse og port med mikrosekunds forsinkelse og millioner av forespørsler per sekund. Layer 7 Applikasjonslastbalansere inspiserer HTTP-protokollen selv: leser URL-stier, forespørselsoverskrifter, informasjonskapsler og HTTP metoder. Dette muliggjør sti-basert ruting: sender skråstrek-api forespørsler til bakendklusteret ditt og skråstrek-statisk forespørsler til et

3:25 objektlager. Avgjørende er at lastbalansere utfører aktive tilstandssjekker. Hvert par sekunder pinger balansereren et tilstandsendepunkt på hver instans. Hvis en instans kaster tre påfølgende femhundre-feil eller ikke svarer, blir den automatisk fjernet fra puljen med null tapte forespørsler.

- 03. Autoskalering og Elastisitet

3:45 Konsept nummer tre: Autoskalering. Hvis nettapplikasjonen din trenger to servere klokka tre om morgenen, men tjue servere under en middags lansering, er manuelt å klikke på knapper i skykonsollen en garantert vei til nedetid og konkurs. Autoskalering gir dynamisk elastisitet til horisontale serverpuljer. En Autoskaleringsgruppe overvåker ytelsesmetrikker som gjennomsnittlig CPU-utnyttelse, nettverks-I/O eller køetterslepdybde. Når gjennomsnittlig CPU overskrider en definert terskel – si,

4:19 sytti prosent i tre sammenhengende minutter – starter autoskaleren automatisk nye virtuelle maskiner, registrerer dem med lastbalanseren din, og begynner å rute trafikk. Like viktig er nedskalering: når trafikkbølgen avtar, autoskaleren avslutter overflødige instanser slik at du slutter å betale for ubrukt datakraft. For å forhindre flappering – der servere raskt opprettes og ødelegges i en endeløs sirkel – konfigurerer skyarkitekter nedkjølingsperioder. Konsept nummer fire: Serverløs.

- 04. Serverløs (FaaS og Firecracker Mikro-VMs)

4:53 I årevis har markedsføringsteam fremstilt serverløs som magisk kode som kjører i skyen. I virkeligheten bruker serverløs fortsatt servere – men du eier ikke, oppdaterer, eller betaler for dem når ingen kode kjører. Med Funksjon-som-en-Tjeneste som AWS Lambda eller Google Cloud Functions, skriver du en frittstående håndteringsfunksjon. Når en HTTP-forespørsel, S3-filopplasting eller databaseendring inntreffer, starter skykjøretiden en flyktig

5:23 mikro-virtuell-maskin som Firecracker på under fem millisekunder. Koden din utføres, returnerer et svar og slås av. Hvis ingen besøker nettstedet ditt på tre måneder, er dataregningen din nøyaktig null dollar og null cent. Hvis en million brukere treffer det samtidig, spinner leverandøren opp en million samtidige mikro-VM-er. Kompromissene i ingeniørkunsten er reelle: kaldstart- forsinkelse ved oppstart av nye kjøretider, en hard femten minutters utførelsesgrense på Lambda, og streng tilstandsløshet.

5:55 Serverløs er uslåelig for hendelsespipelines og sporadiske API-er, men dårlig for vedvarende WebSockets eller flertimers treningskjøringer.

- 05. Hendelsesdrevet Arkitektur (EDA og Frikobling)

6:05 Konsept nummer fem: Hendelsesdrevet arkitektur, eller EDA. I tradisjonelle arkitekturer kommuniserer tjenester synkront. Din kasse-tjeneste kaller betaling, betaling kaller lager, lager kaller svindel, og svindel kaller e-post. Dette skaper den synkrone kaskaden av undergang. Hvis tredjeparts e-postleverandøren opplever et nettverksproblem og bruker ti sekunder på å svare, vil kundens hele kasseforespørsel tidsavbrytes med en feil. I en hendelsesdrevet arkitektur er tjenestene fullstendig frikoblet.

6:37 Når en kunde klikker kjøp, kaller kasse-tjenesten ikke nedstrøms tjenester. Den publiserer ganske enkelt en hendelse kalt OrderPlaced til en sentral Hendelsesbuss som Amazon EventBridge eller et SNS-emne. Kasseprosessen fullføres på femti millisekunder. Nedstrømsarbeidere for betaling, lagerfradrag og e-postkvitteringer trekker meldinger uavhengig fra sine egne dedikerte SQS-køer. Hvis e-posttjenesten går ned i en time, venter meldinger trygt bufret i køen uten en eneste tapt ordre.

- 06. Containerorkestrering (Docker og Kubernetes)

7:13 Konsept nummer seks: Containerorkestrering. Docker løste pakking: den pakker inn applikasjonskoden din, systembiblioteker, konfigurasjon og kjøretid i et uforanderlig bilde som kjører identisk på din MacBook og i skyen. Men å pakke en container er enkelt. Å kjøre fem hundre containere på tvers av femti fysiske virtuelle maskiner er der ingeniørarbeidet bryter sammen. Det er derfor containerorkestratorer som Kubernetes og AWS ECS

7:41 eksisterer. En orkestrator tilbyr et kontrollplan: en API-server, et etcd-tilstandslager og en intelligent planlegger. Du erklærer ønsket tilstand: Jeg vil ha ti replikaer av min auth- tjeneste med to gigabyte RAM hver. Planleggeren inspiserer klyngen, plasserer pods på noder med ledig minne, konfigurerer internt nettverk, og forsoner kontinuerlig virkeligheten. Hvis en node lider av en maskinvarefeil, oppdager Kubernetes tapet og omplanlegger umiddelbart alle fortrengte pods til

- 07. De 4 Skylagringspilarene (S3, EBS, DBs og Redis)

8:16 friske noder. Konsept nummer syv: Skylagringshierarkiet. Nybegynnere behandler ofte skylagring som en enkelt bøtte der du dumper filer. I produksjonsarkitektur er lagring delt inn i fire distinkte pilarer basert på tilgangsmønstre og ventetid. Først er objektlagring, som Amazon S3 eller Google Cloud Storage. Du får tilgang til filer over HTTP REST APIer ved hjelp av enkle PUT- og GET-kall. Det tilbyr uendelig horisontal kapasitet til to cent per gigabyte per måned,

8:49 noe som gjør det ideelt for video, brukeropplastinger, logger og sikkerhetskopier. For det andre er blokklagring, som Amazon EBS. Dette er virtuelle harddisker montert direkte til en spesifikk virtuell maskin over høyhastighetsforbindelser. De formateres til standard filsystemer som ext4, som støtter rask tilfeldig lese- og skrivetilgang som kreves av database- motorer. For det tredje er administrerte databaser: relasjonelle motorer som PostgreSQL på RDS som gir ACID-transaksjoner og komplekse sammenføyninger,

9:21 og NoSQL-motorer som DynamoDB som leverer ensifret millisekunds latenstid i massiv skala. Og for det fjerde er In-Memory Cacher som Redis. Å lese data fra RAM tar mikrosekunder snarere enn millisekunder. Cacher sitter foran databasen din, og beskytter den mot gjentatt lesetrafikk og administrerer flyktige brukersesjonstokener.

- 08. Høy Tilgjengelighet og Nierene (Multi-AZ Failover)

9:44 Konsept nummer åtte: Høy Tilgjengelighet, eller HA. Tilgjengelighet svarer på ett spørsmål: hvor stor prosentandel av tiden er din applikasjon operativ og tilgjengelig for brukere? I bedriftskontrakter måles tilgjengelighet i niere. To niere, eller nittini prosent tilgjengelighet, tillater over tre og en halv dager med nedetid hvert år. Fire niere reduserer tillatt nedetid til femtito minutter, og fem niere tillater knapt fem minutter total nedetid per

10:15 år. For å oppnå høy tilgjengelighet må du eliminere enkeltpunkter for feil på tvers av feildomener. I skyen betyr det å distribuere over flere tilgjengelighetssoner. En tilgjengelighetssone er ikke et enkelt rack: det er ett eller flere distinkte fysiske datasentre miles fra hverandre med uavhengig strøm og kjøling. Ved å kjøre aktive instanser i sone A og sone B med synkron databasereplikering, resulterer et lynnedslag eller fiberbrudd som tar ned et helt fysisk anlegg i en automatisert failover

10:50 på tretti sekunder med null menneskelig innblanding.

- 09. Holdbarhet vs. Tilgjengelighet (Hvorfor 11 Niere Ikke Er Oppetid)

10:53 Konsept nummer ni: Holdbarhet kontra Tilgjengelighet. Dette er den vanligste konseptuelle fellen i skyarkitektur intervjuer. Ingeniører bruker ofte ordene om hverandre, men de måler helt forskjellige egenskaper. Tilgjengelighet måler oppetid: kan jeg foreta et API-kall for å lese eller skrive mine data akkurat nå? Holdbarhet måler bevaring: vil dataene mine overleve uten permanent bitrot, korrupsjon eller ødeleggelse over ti år?

11:24 Se på Amazon S3 Standard. Dets Service Level Agreement tilbyr nitti-ni komma ni prosent tilgjengelighet, noe som tillater omtrent førtitre minutter med nedetid hver måned hvor en API-forespørsel kan returnere en femhundre-feil. Men S3 lover elleve niere med holdbarhet: nitti-ni komma ni ni ni ni ni ni ni ni ni prosent. Hvis du lagrer ti millioner filer i S3, kan du statistisk forvente å miste en

11:56 gjennomsnittlig én fil hvert ti tusen år. S3 oppnår dette ved å feilkode objekter og replikere biter på tvers av minst tre geografisk adskilte datasentre. Under et stort regionalt nettverksbrudd kan S3 midlertidig være utilgjengelig, men dataene dine blir aldri ødelagt.

- 10. Infrastruktur som Kode (Terraform vs. Konsolldrift)

12:14 Konsept nummer ti: Infrastruktur som Kode, eller IaC. I skykomputeringens tidlige dager logget ingeniører seg på AWS webadministrasjonskonsollen og klikket manuelt rundt for å opprette virtuelle maskiner, konfigurere subnett og legge til sikkerhetsgrupper. Bransjen kaller dette ClickOps, og i produksjon er det en absolutt katastrofe. Manuelle konsollendringer har ingen revisjonsspor, ingen tilbakeførings- mekanisme, og forårsaker uunngåelig konfigurasjonsdrift mellom staging og produksjonsmiljøer. Med Infrastructure

12:48 as Code-verktøy som Terraform, OpenTofu, Pulumi eller AWS CDK, definerer du din komplette skyarkitektur i deklarative konfigurasjonsfiler lagret i Git. Hver endring av en åpen port eller databasereplika går gjennom en pull-forespørsel og fagfellevurdering. Kjøring av terraform plan forhåndsviser den nøyaktige API-diffen før noe blir rørt, og å spinne opp en identisk replika av din produksjons- stack tar fire minutter i stedet for fire uker.

- 11. Skynettverk (VPC, Subnets, NAT og Sikkerhetsgrupper)

13:20 Konsept nummer elleve: Skynettverk og Virtuelle Private Skyer. Når du distribuerer servere til skyen, ligger de ikke eksponert på det rå offentlige internett. De lever innenfor en programvaredefinert isolert grense kalt en VPC. Inne i din VPC tildeler du et privat IP-adresseområde som ti-punkt-null-punkt-null-punkt-null skråstrek seksten, og deler det inn i offentlige og private subnett. Et offentlig subnett har en direkte rute til en Internett-gateway.

13:51 Den inneholder offentlige ressurser som dine Application Load Balancers og NAT Gateways. Det er den eneste delen av nettverket ditt som har offentlige IP- adresser. Dine applikasjonsservere og produksjonsdatabaser lever strengt i private subnett uten offentlige IP-er og null innkommende ruter fra internett. Når backend-serverne dine trenger å laste ned sikkerhetsoppdateringer, rutes deres utgående trafikk via NAT Gateway i det offentlige subnettet. Rundt hver instans er det Sikkerhetsgrupper: tilstandsbaserte virtuelle brannmurer som håndhever prinsippet om minst privilegium.

- 12. Den Komplette Bedriftsplanen og Dommen

14:28 Din databasesikkerhetsgruppe aksepterer kun tilkoblinger på port 5432 strengt fra sikkerhetsgruppen til dine applikasjonsservere, noe som gjør utenforstående penetrering matematisk umulig. Når du zoomer ut, kobles disse elleve primitivene sammen til ett sammenhengende system. Din DNS ruter til en Load Balancer i et offentlig subnett, autoskaleringsgrupper håndterer trafikktopper på tvers av flere tilgjengelighetssoner, hendelsesbusser frakobler backend-arbeidere, og hele stakken din er distribuert fra Git ved hjelp av Infrastructure as Code.

15:02 Dagens masterclass-dom: SHIP IT. Slutt å pugge hundrevis av sky-markedsføringsakronymer. Mestre disse elleve arkitekturmønstrene, koble fra tilstanden din, og bygg systemer som ikke kan feile. Fortell meg hvilket skykonsept som ga deg størst hodebry da du først begynte å bygge i kommentarfeltet. Og for å hente det komplette arkitektur-juksearket, abonner på nyhetsbrevet på the daily diff dot dev,

15:28 lenke nedenfor. Og det er diffen for i dag. Jeg er Niko fra Axrisi. Merge ansvarlig.

Kilder

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