Objašnjen cloud computing: 11 arhitektonskih koncepata koje morate znati (4K Masterclass).

Šta ovaj video pokriva

• - Zid arhitekture i glavni nacrt
• - 01. Vertikalno vs. horizontalno skaliranje
• - 02. Arhitektura balansiranja opterećenja (L4 vs. L7 i provjere ispravnosti)
• - 03. Autoskaliranje i elastičnost
• - 04. Serverless (FaaS i Firecracker MicroVMs)

Prevedeni transkript

Prevedeno iz originalne engleske naracije. Dostupan zvuk i titlovi kontroliše YouTube.

- Zid arhitekture i glavni nacrt

0:00 Svaki softverski inženjer na kraju se suoči sa zidom cloud arhitekture. Izgradite aplikaciju na svom laptopu, gurnete je u produkciju, i u trenutku kada stignu pravi korisnici, serveri padaju, baze podataka se pune, a vaš AWS račun izgleda kao telefonski broj. Većina programera pokušava riješiti cloud inženjerstvo pamćenjem tristo različitih akronima AWS proizvoda. Ali pravo računalstvo u oblaku nije pamćenje kataloga dobavljača: ono je izgrađeno na jedanaest fundamentalnih arhitektonskih primitiva.

0:34 U ovom masterclassu, proći ćemo kroz cijeli korporativni nacrt: od skaliranja i balansiranja opterećenja do serverless, razdvajanja vođenog događajima, hijerarhija pohrane i umrežavanja u oblaku. Savladajte ovih jedanaest koncepata i možete dizajnirati bilo koji backend na AWS-u, GCP-u ili Azureu. Ovo je The Daily Diff, ispod haube.

- 01. Vertikalno vs. horizontalno skaliranje

0:57 Koncept broj jedan: Skaliranje. Kada vaša aplikacija doživi rast prometa, imate dva fundamentalno različita načina za rješavanje opterećenja: 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 i dvije, ili zamjena trideset i dva gigabajta RAM-a za sto dvadeset i osam. Vertikalno skaliranje ne zahtijeva nikakve arhitektonske promjene: vaš kod

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

2:01 bezstanja: vaši aplikacijski serveri ne mogu pohranjivati korisničke sesije, učitate datoteke ili stanje na svojim lokalnim diskovima. Stanje mora živjeti u vanjskoj bazi podataka ili kešu, omogućavajući bilo kojem čvoru da obrađuje bilo koji korisnički zahtjev.

- 02. Arhitektura balansiranja opterećenja (L4 vs. L7 i provjere ispravnosti)

2:17 Koncept broj dva: Balansiranje opterećenja. Horizontalno skaliranje zvuči sjajno na papiru, ali uvodi neposredan problem: kada deset hiljada korisnika pogodi vaše ime domene, koji specifični server prima njihov promet? Balanser opterećenja djeluje kao obrnuti proxy koji sjedi između javnog interneta i vašeg privatnog backend klastera. Prihvaća dolazne TCP ili HTTP veze i distribuira zahtjeve preko vaših zdravih instanci.

2:47 Balanseri opterećenja djeluju na dva primarna mrežna sloja. Layer 4 Network Load Balancers djeluju na transportnom sloju, usmjeravajući sirove TCP i UDP pakete na temelju IP adrese i porta s latencijom od mikrosekunde i milionima zahtjeva u sekundi. Layer 7 Application Load Balancers provjeravaju sam HTTP protokol: čitaju URL putanje, zaglavlja zahtjeva, kolačiće i HTTP metode. To omogućuje usmjeravanje na temelju putanje: slanje /api zahtjeva vašem backend klasteru i /static zahtjeva u

3:25 skladište objekata. Ključno, balanser opterećenja provodi aktivne zdravstvene provjere. Svakih nekoliko sekundi, balanser pinga krajnju točku zdravlja na svakoj instanci. Ako instanca baci tri uzastopne pogreške 500 ili ne uspije odgovoriti, automatski se izbacuje iz bazena s nula ispuštenih zahtjeva.

- 03. Autoskaliranje i elastičnost

3:45 Koncept broj tri: Autoskaliranje. Ako vaša web aplikacija treba dva servera u tri ujutro, ali dvadeset servera tijekom podnevnog pokretanja, ručno klikanje gumba u cloud konzoli je zajamčeni put do zastoja i bankrota. Autoskaliranje donosi dinamičku elastičnost horizontalnim serverskim bazenima. Grupa za automatsko skaliranje prati metrike performansi poput prosječne iskorištenosti CPU-a, mrežnog I/O-a ili dubine zaostalog reda. Kada prosječni CPU prijeđe definiranu granicu — recimo,

4:19 sedamdeset posto tri uzastopne minute — autoskaler automatski pokreće nove virtualne mašine, registrira ih kod vašeg balansera opterećenja, i počinje usmjeravati promet. Jednako važno je skaliranje prema unutra: kada se val prometa povuče, autoskaler ukida višak instanci tako da prestajete plaćati za neaktivno računanje. Da bi se spriječilo treptanje — gdje se serveri brzo stvaraju i uništavaju u beskrajnoj petlji gašenja — cloud arhitekti konfiguriraju periode mirovanja. Koncept broj četiri: Serverless.

- 04. Serverless (FaaS i Firecracker MicroVMs)

4:53 Godinama su marketinški timovi predstavljali serverless kao čarobni kod koji radi u oblaku. U stvarnosti, serverless još uvijek koristi servere — ali ih ne posjedujete, ne zakrpite ih niti plaćate kada ne radi nikakav kod. S funkcijom kao uslugom poput AWS Lambda ili Google Cloud Functions, pišete samostalnu funkciju rukovatelja. Kada se dogodi HTTP zahtjev, S3 učitavanje datoteke ili promjena baze podataka, cloud runtime pokreće efemernu

5:23 mikro-virtualnu mašinu poput Firecrackera za manje od pet milisekundi. Vaš kod se izvršava, vraća odgovor i gasi se. Ako niko ne posjeti vašu web stranicu tri mjeseca, vaš račun za računanje je tačno nula dolara i nula centi. Ako milion korisnika istovremeno posjeti, pružatelj pokreće milion istovremenih mikroVM-a. Inženjerski kompromisi su stvarni: latencija hladnog starta pri pokretanju svježih runtimea, tvrda granica izvršavanja od petnaest minuta na Lambdi i stroga besprijekornost.

5:55 Serverless je nenadmašan za event pipelinese i sporadične API-je, ali loš za trajne WebSockets ili višesatne treninge.

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

6:05 Koncept broj pet: Arhitektura vođena događajima, ili EDA. U tradicionalnim arhitekturama, servisi komuniciraju sinhrono. Vaš servis za naplatu poziva plaćanje, plaćanje poziva inventar, inventar poziva prevaru, a prevara poziva email. Ovo stvara sinhronu kaskadu propasti. Ako vanjski davatelj emaila doživi mrežni zastoj i treba mu deset sekundi da odgovori, cijeli zahtjev za naplatu vašeg kupca ističe s greškom. U arhitekturi vođenoj događajima, servisi su potpuno razdvojeni.

6:37 Kada kupac klikne kupi, servis za naplatu ne poziva podređene servise. On jednostavno objavljuje događaj pod nazivom Narudžba postavljena na centralnu Event Bus poput Amazon EventBridgea ili SNS teme. Naplata se završava za pedeset milisekundi. Podređeni radnici za plaćanje, oduzimanje inventara i potvrde o emailu nezavisno povlače poruke iz vlastitih namjenskih SQS redova. Ako email servis padne na sat vremena, poruke čekaju sigurno baferirane 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: omotava vaš aplikacijski kod, sistemske biblioteke, konfiguraciju i runtime u nepromjenjivu sliku koja identično radi na vašem MacBooku i u oblaku. Ali pakiranje kontejnera je jednostavno. Pokretanje pet stotina kontejnera na pedeset fizičkih virtualnih mašina je mjesto gdje inženjering propada. Zato postoje orkestratori kontejnera poput Kubernetesa i AWS ECS-a.

7:41 Orkestrator pruža kontrolnu ravan: API server, etcd spremište stanja i inteligentni raspoređivač. Deklarirate željeno stanje: želim deset replika mog auth servisa s dva gigabajta RAM-a svaka. Raspoređivač provjerava klaster, postavlja podove na čvorove sa slobodnom memorijom, konfigurira unutarnje umrežavanje i kontinuirano usklađuje stvarnost. Ako čvor pretrpi hardverski kvar, Kubernetes detektira gubitak i odmah prebacuje sve raseljene podove na

- 07. 4 stuba pohrane u oblaku (S3, EBS, DBs i Redis)

8:16 zdrave čvorove. Koncept broj sedam: Hijerarhija pohrane u oblaku. Početnici često tretiraju pohranu u oblaku kao jednu kantu u koju bacaju datoteke. U produkcijskoj arhitekturi, pohrana je podijeljena u četiri različita stuba na temelju obrazaca pristupa i latencije. Prvo je Objektna Pohrana, poput Amazon S3 ili Google Cloud Storage. Datotekama pristupate 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 učitavanja, logove i sigurnosne kopije. Drugo je Blok Pohrana, poput Amazon EBS-a. To su virtualni tvrdi diskovi montirani direktno na specifičnu virtualnu mašinu preko brzih međusobnih veza. Formatiraju se u standardne datotečne sisteme poput ext4, podržavajući brzi nasumični pristup čitanju i pisanju koji zahtijevaju baze podataka. Treće su Upravljane Baze Podataka: relacijski mehanizmi poput PostgreSQL-a na RDS-u koji pružaju ACID transakcije i složene spojeve,

9:21 i NoSQL mehanizmi poput DynamoDB-a koji isporučuju jednoznamenkastu milisekundu latencije na masivnoj skali. I četvrto su In-Memory Keševi poput Redis-a. Čitanje podataka iz RAM-a traje mikrosekunde, a ne milisekunde. Keševi sjede ispred vaše baze podataka, štiteći je od ponovljenog prometa čitanja i upravljajući nestabilnim tokenima korisničkih sesija.

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

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

10:15 Za postizanje visoke dostupnosti, morate eliminirati pojedine točke kvara preko domena kvara. U oblaku, to znači implementaciju preko više Zona dostupnosti. Zona dostupnosti nije jedan stalak: to je jedan ili više različitih fizičkih podatkovnih centara udaljenih kilometrima s neovisnim napajanjem i hlađenjem. Pokretanjem aktivnih instanci u Zoni A i Zoni B sa sinkronom replikacijom baze podataka, udar groma ili prekid optičkog kabela koji sruši cijeli fizički objekt rezultira automatskim prebacivanjem na rezervni sustav

10:50 za trideset sekundi bez ikakve ljudske intervencije.

- 09. Trajnost vs. dostupnost (Zašto 11 devetki nije vrijeme rada)

10:53 Deveti koncept: Trajnost naspram dostupnosti. Ovo je najčešća konceptualna zamka u intervjuima za cloud arhitekturu. 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 tokom deset godina?

11:24 Pogledajte Amazon S3 Standard. Njegov Ugovor o nivou usluge nudi devedeset devet tačka devet posto dostupnosti, što dozvoljava otprilike četrdeset tri minute prekida rada svakog mjeseca gdje API zahtjev može vratiti grešku petsto. Ali S3 obećava jedanaest devetki trajnosti: devedeset devet tačka devet devet devet devet devet devet devet devet devet posto. Ako pohranite deset miliona datoteka u S3, statistički možete očekivati da ćete izgubiti u

11:56 prosjeku jednu datoteku svakih deset hiljada godina. S3 to postiže kodiranjem objekata i repliciranjem dijelova kroz najmanje tri geografski odvojene podatkovne lokacije. Tokom velikog regionalnog prekida mreže, S3 možda privremeno bude nedostupan, ali vaši podaci nikada nisu uništeni.

- 10. Infrastruktura kao kod (Terraform vs. Console Drift)

12:14 Koncept broj deset: Infrastruktura kao kod, ili IaC. U ranim danima cloud computinga, inženjeri su se prijavljivali u AWS web konzolu za upravljanje i ručno kliktali kako bi kreirali virtualne mašine, konfigurisali podmreže i dodijelili sigurnosne grupe. Industrija to naziva ClickOps, i u produkciji je to apsolutna katastrofa. Ručne promjene u konzoli nemaju trag revizije, nemaju mehanizam za povratak na prethodno stanje i neizbježno uzrokuju odstupanje konfiguracije između razvojnog i produkcijskog okruženja. S alatima za infrastrukturu

12:48 kao kod, kao što su Terraform, OpenTofu, Pulumi ili AWS CDK, cijelu svoju cloud arhitekturu definišete u deklarativnim konfiguracijskim datotekama pohranjenim u Gitu. Svaka promjena otvorenog porta ili replike baze podataka prolazi kroz zahtjev za povlačenje i pregled kolega. Pokretanje terraform plana pregledava tačan API diff prije nego što se išta dodirne, a pokretanje identične replike vašeg produkcijskog steka traje četiri minute umjesto četiri sedmice.

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

13:20 Koncept broj jedanaest: Cloud mreže i virtualni privatni oblaci. Kada servere implementirate u oblak, oni ne stoje izloženi na sirovom javnom internetu. Oni žive unutar softverski definisane izolirane granice koja se zove VPC. Unutar vašeg VPC-a, dodjeljujete privatni IP adresni prostor kao deset-tačka-nula-tačka-nula-tačka-nula kosa crta šesnaest, i dijelite ga na javne i privatne podmreže. Javna podmreža ima direktnu rutu do Internet Gatewaya.

13:51 Ona sadrži javno dostupne resurse kao što su vaši Application Load Balanceri i NAT Gatewayi. To je jedini dio vaše mreže koji posjeduje javne IP adrese. Vaši aplikacijski serveri i produkcijske baze podataka striktno žive u privatnim podmrežama bez javnih IP-ova i bez dolaznih ruta s interneta. Kada vaši backend serveri trebaju preuzeti sigurnosne nadogradnje, njihov odlazni promet ide kroz NAT Gateway u javnoj podmreži. Svaku instancu okružuju sigurnosne grupe: stateful virtualni firewalli koji primjenjuju princip najmanje privilegije.

- 12. Potpuni korporativni nacrt i presuda

14:28 Vaša sigurnosna grupa baze podataka prihvaća veze samo na portu 5432 striktno od sigurnosne grupe vaših aplikacijskih servera, čineći vanjsko prodiranje matematički nemogućim. Kada se odmaknete, ovih jedanaest primitiva povezuju se u jedan koherentan sistem. Vaš DNS rutira na Load Balancer u javnoj podmreži, grupe za automatsko skaliranje rješavaju nagle poraste prometa kroz više zona dostupnosti, sabirnice događaja razdvajaju pozadinske radnike, a cijeli vaš stog je implementiran iz Gita pomoću Infrastrukture kao koda.

15:02 Današnja presuda masterclassa: SHIP IT. Prestanite pamtiti stotine akronima cloud marketinga. Savladajte ovih jedanaest arhitektonskih obrazaca, odvojite svoje stanje, i gradite sisteme koji ne mogu propasti. Recite mi koji vam je cloud koncept zadavao najveću glavobolju kada ste tek počeli graditi u komentarima. A da biste preuzeli kompletnu varalicu za arhitekturu, pretplatite se na newsletter na the daily diff dot dev,

15:28 link ispod. I to je diff 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