Pojasnilo o računalništvu v oblaku: 11 arhitekturnih konceptov, ki jih morate poznati (4K Masterclass).

Kaj zajema ta videoposnetek

• - Arhitekturni zid in glavni načrt
• - 01. Vertikalno v primerjavi s horizontalnim skaliranjem
• - 02. Arhitektura uravnoteženja obremenitve (L4 v primerjavi z L7 in preverjanje zdravja)
• - 03. Samodejno skaliranje in elastičnost
• - 04. Brezstrežniško (FaaS in Firecracker MicroVMs)

Preveden prepis

Prevedeno iz izvirnega angleškega pripovedovanja. Razpoložljivi zvok in podnapisi so nadzorovani s strani YouTuba.

- Arhitekturni zid in glavni načrt

0:00 Vsak programski inženir se sčasoma sreča z zidom arhitekture v oblaku. Zgradite aplikacijo na svojem prenosniku, jo objavite v produkciji, in v trenutku, ko pridejo pravi uporabniki, strežniki padejo, povezave z bazo podatkov se izčrpajo, in vaš račun za AWS izgleda kot telefonska številka. Večina razvijalcev poskuša rešiti inženiring v oblaku z zapomnitvijo tristo različnih akronimov izdelkov AWS. Toda resnično računalništvo v oblaku ne pomeni zapomnitve katalogov ponudnikov: je zgrajeno na enajstih temeljnih arhitekturnih primitivih.

0:34 V tem masterclassu bomo prešli celoten načrt podjetja: od skaliranja in uravnoteženja obremenitve do brezstrežniškega, dogodkovno vodenega razkopčanja, hierarhij shranjevanja in mreženja v oblaku. Obvladajte teh enajst konceptov in lahko zasnujete kateri koli zaledni sistem na AWS, GCP ali Azure. To je The Daily Diff, pod pokrovom.

- 01. Vertikalno v primerjavi s horizontalnim skaliranjem

0:57 Koncept številka ena: Skaliranje. Ko vaša aplikacija doživi rast prometa, imate dva bistveno različna načina za obvladovanje obremenitve: vertikalno skaliranje ali horizontalno skaliranje. Vertikalno skaliranje ali skaliranje navzgor pomeni, da vzamete svojo obstoječo napravo in dodate več virov: nadgradite s štirih CPU jeder na dvaintrideset, ali zamenjate dvaintrideset gigabajtov RAM-a za sto osemindvajset. Vertikalno skaliranje ne zahteva nobenih arhitekturnih sprememb: vaša koda

1:28 in baza podatkov ostanejo popolnoma enaki. Toda doseže brutalno strojno mejo. Noben posamezen stroj na svetu nima deset tisoč CPU jeder, in najvišji nivoji instanc imajo eksponentno višjo ceno. Horizontalno skaliranje ali skaliranje navzven pomeni, da ohranite svoje strežnike majhne in s ceno osnovnih dobrin, vendar vzporedno poganjate več instanc za usmerjevalnikom. Če ena instanca pade, preostala vozlišča absorbirajo promet z ničelno prekinitvijo delovanja. Zlato pravilo horizontalnega skaliranja je

2:01 brezstanovost: vaši aplikacijski strežniki ne smejo shranjevati uporabniških sej, naloženih datotek ali stanja na svojih lokalnih diskih. Stanje mora živeti v zunanji bazi podatkov ali predpomnilniku, kar omogoča, da katero koli vozlišče obdela katero koli uporabniško zahtevo.

- 02. Arhitektura uravnoteženja obremenitve (L4 v primerjavi z L7 in preverjanje zdravja)

2:17 Koncept številka dve: Uravnoteženje obremenitve. Horizontalno skaliranje se na papirju sliši odlično, vendar takoj uvede problem: ko deset tisoč uporabnikov obišče vaše domensko ime, kateri specifični strežnik prejme njihov promet? Uravnoteževalnik obremenitve deluje kot povratni proxy, ki se nahaja med javnim internetom in vašim zasebnim zalednim grozdom. Sprejema dohodne povezave TCP ali HTTP in razdeli zahteve med vaše zdrave instance.

2:47 Uravnoteževalniki obremenitve delujejo na dveh glavnih omrežnih slojih. Layer 4 Network Load Balancers delujejo na transportnem sloju, usmerjajo neobdelane TCP in UDP pakete na podlagi IP naslova in vrat z mikrosekundno zakasnitvijo in milijoni zahtev na sekundo. Layer 7 Application Load Balancers pregledujejo protokol HTTP sam: berejo poti URL, glave zahtev, piškotke in HTTP metode. To omogoča usmerjanje na podlagi poti: pošiljanje poševnica-api zahtev v vaš zaledni grozd in poševnica-static zahtev v

3:25 skladišče objektov. Bistveno je, da uravnoteževalniki obremenitve izvajajo aktivne preglede zdravja. Vsakih nekaj sekund uravnoteževalnik pinga končno točko zdravja na vsaki instanci. Če instanca trikrat zapored vrne petstotke napake ali ne uspe odgovoriti, se samodejno izloči iz bazena z ničelnimi izpadlimi zahtevami.

- 03. Samodejno skaliranje in elastičnost

3:45 Koncept številka tri: Samodejno skaliranje. Če vaša spletna aplikacija potrebuje dva strežnika ob treh zjutraj, vendar dvajset strežnikov med opoldanskim zagonom, je ročno klikanje gumbov v konzoli oblaka zagotovljena pot do izpadov in bankrota. Samodejno skaliranje prinaša dinamično elastičnost v horizontalne strežniške bazene. Skupina za samodejno skaliranje spremlja metrike delovanja, kot so povprečna izkoriščenost CPU, omrežni V/I ali globina čakalne vrste. Ko povprečna izkoriščenost CPU prečka določen prag – recimo,

4:19 sedemdeset odstotkov tri zaporedne minute – samodejni skalirnik samodejno zažene nove virtualne stroje, jih registrira z vašim uravnoteževalnikom obremenitve, in začne usmerjati promet. Enako pomembno je skaliranje navznoter: ko val prometa upade, samodejni skalirnik zaustavi odvečne instance, tako da nehate plačevati za neizkoriščeno računalniško moč. Da bi preprečili nihanje – kjer se strežniki hitro ustvarjajo in uničujejo v neskončni petlji trzanja – arhitekti v oblaku konfigurirajo čakalne dobe. Koncept številka štiri: Brezstrežniško.

- 04. Brezstrežniško (FaaS in Firecracker MicroVMs)

4:53 Že leta so marketinške ekipe brezstrežniško oglaševale kot čarobno kodo, ki teče v oblaku. V resnici brezstrežniško še vedno uporablja strežnike – vendar jih ne lastite, ne krpate ali plačujete, ko koda ne teče. S Function-as-a-Service, kot so AWS Lambda ali Google Cloud Functions, napišete samostojno funkcijo za obravnavo. Ko pride do zahteve HTTP, nalaganja datoteke S3 ali spremembe baze podatkov, oblakova izvedbena okolja zažene efemerni

5:23 mikro-virtualni stroj, kot je Firecracker, v manj kot petih milisekundah. Vaša koda se izvede, vrne odgovor in se izklopi. Če nihče ne obišče vaše spletne strani tri mesece, je vaš račun za računalniško moč natančno nič dolarjev in nič centov. Če ga milijon uporabnikov obišče hkrati, ponudnik zažene milijon sočasnih mikroVM-jev. Kompromisi v inženirstvu so resnični: zakasnitev hladnega zagona pri zagonu svežih izvedbenih okolij, trda petnajstminutna omejitev izvajanja na Lambdi in stroga brezstanost.

5:55 Brezstrežniško je neprekosljivo za dogodkovne cevovode in sporadične API-je, vendar slabo za trajne WebSockete ali večurne učne procese.

- 05. Dogodkovno vodena arhitektura (EDA in razkopčanje)

6:05 Koncept številka pet: Dogodkovno vodena arhitektura ali EDA. V tradicionalnih arhitekturah storitve komunicirajo sinhrono. Vaša storitev plačila kliče plačilo, plačilo kliče inventar, inventar kliče goljufijo, in goljufija kliče e-pošto. To ustvarja sinhrono kaskado pogube. Če neodvisni ponudnik e-pošte doživi omrežno napako in traja deset sekund, da odgovori, celotna zahteva za plačilo vaše stranke poteče z napako. V dogodkovno vodeni arhitekturi so storitve popolnoma razkoppčene.

6:37 Ko stranka klikne kupi, storitev plačila ne kliče podrejenih storitev. Preprosto objavi dogodek z imenom NaročiloOddano na centralni dogodkovni vmesnik, kot je Amazon EventBridge ali tema SNS. Plačilo je zaključeno v petdesetih milisekundah. Podrejeni delavci za plačilo, odštevanje inventarja in e-poštna potrdila neodvisno vlečejo sporočila iz svojih namenskih SQS čakalnih vrst. Če e-poštna storitev ne deluje eno uro, sporočila varno čakajo medpomnjena v čakalni vrsti brez ene same izgubljene naročbe.

- 06. Orkestracija vsebin (Docker in Kubernetes)

7:13 Koncept številka šest: Orkestracija vsebnika. Docker je rešil pakiranje: ovije kodo vaše aplikacije, sistemske knjižnice, konfiguracijo in izvedbeno okolje v nespremenljivo sliko, ki deluje enako na vašem MacBooku in v oblaku. Toda pakiranje vsebnika je enostavno. Zagon petsto vsebnika na petdesetih fizičnih virtualnih strojih je tisto, kjer inženiring odpove. Zato obstajajo orkestratorji vsebnikov, kot sta Kubernetes in AWS ECS.

7:41 Orkestrator zagotavlja nadzorno ravnino: API strežnik, etcd shrambo stanja in inteligentni razporejevalnik. Deklarirate želeno stanje: želim deset replik svoje avtentikacijske storitve z dvema gigabajtoma RAM-a vsaka. Razporejevalnik pregleda grozd, postavi pode na vozlišča s prostim pomnilnikom, konfigurira notranje omrežje in nenehno usklajuje realnost. Če vozlišče doživi strojno okvaro, Kubernetes zazna izgubo in takoj prerazporedi vse premaknjene pode na

- 07. 4 stebri shranjevanja v oblaku (S3, EBS, DB in Redis)

8:16 zdrava vozlišča. Koncept številka sedem: Hierarhija shranjevanja v oblaku. Začetniki pogosto obravnavajo shranjevanje v oblaku kot en sam vedro, kamor odvržejo datoteke. V produkcijski arhitekturi je shranjevanje razdeljeno na štiri različne stebre glede na vzorce dostopa in zakasnitev. Prvo je shranjevanje objektov, kot sta Amazon S3 ali Google Cloud Storage. Do datotek dostopate prek HTTP REST API-jev z uporabo enostavnih klicev PUT in GET. Ponuja neskončno horizontalno zmogljivost po dveh centih na gigabajt na mesec,

8:49 zaradi česar je idealen za video, uporabniška nalaganja, dnevnike in varnostne kopije. Drugo je shranjevanje blokov, kot je Amazon EBS. To so virtualni trdi diski, ki so neposredno nameščeni na specifičen virtualni stroj prek hitrih povezav. Oblikujejo se v standardne datotečne sisteme, kot je ext4, podpirajo hiter naključni dostop za branje in pisanje, ki ga zahtevajo podatkovni motorji. Tretje so upravljane baze podatkov: relacijski motorji, kot je PostgreSQL na RDS, ki zagotavlja transakcije ACID in kompleksne združitve,

9:21 in NoSQL motorji, kot je DynamoDB, ki zagotavljajo enomestno milisekundno zakasnitev pri masivnem obsegu. In četrto so predpomnilniki v pomnilniku, kot je Redis. Branje podatkov iz RAM-a traja mikrosekunde in ne milisekunde. Predpomnilniki sedijo pred vašo bazo podatkov, jo ščitijo pred ponavljajočim se prometom branja in upravljajo nestabilne žetone uporabniških sej.

- 08. Visoka razpoložljivost in devetke (Multi-AZ Failover)

9:44 Koncept številka osem: Visoka razpoložljivost ali HA. Razpoložljivost odgovarja na eno vprašanje: kolikšen odstotek časa je vaša aplikacija operativna in dosegljiva uporabnikom? V podjetniških pogodbah se razpoložljivost meri v devetkah. Dve devetki ali devetindevetdeset odstotna razpoložljivost, omogoča več kot tri in pol dneva izpadov vsako leto. Štiri devetke zmanjšajo dovoljen čas izpada na dvainpetdeset minut, in pet devetk dovoljuje komaj pet minut skupnega časa izpada na

10:15 leto. Za doseganje visoke razpoložljivosti morate odpraviti posamezne točke napake v domenah napak. V oblaku to pomeni uvajanje v več razpoložljivostnih conah. Razpoložljivostna cona ni en sam regal: je eno ali več različnih fizičnih podatkovnih centrov, oddaljenih kilometre, z neodvisnim napajanjem in hlajenjem. Z delovanjem aktivnih instanc v coni A in coni B s sinhrono replikacijo baze podatkov, udar strele ali prekinitev optičnih vlaken, ki povzroči izpad celotnega fizičnega objekta, povzroči avtomatiziran preklop.

10:50 v tridesetih sekundah z nič človeškega posredovanja.

- 09. Trajnost v primerjavi z razpoložljivostjo (zakaj 11 devetk ni čas delovanja)

10:53 Koncept številka devet: Trajnost proti Razpoložljivosti. To je daleč najpogostejša konceptualna past v intervjujih za oblačno arhitekturo. Inženirji pogosto uporabljajo besedi zamenljivo, vendar merita popolnoma različne lastnosti. Razpoložljivost meri čas delovanja: ali lahko trenutno izvedem klic API-ja za branje ali pisanje svojih podatkov? podatkov prav v tem trenutku? Trajnost meri ohranjanje: ali bodo moji podatki preživeli brez trajnega propadanja bitov, korupcije ali uničenja v desetih letih? bit rot, korupcije ali uničenja v desetih letih?

11:24 Poglejmo Amazon S3 Standard. Njegova pogodba o ravni storitev ponuja devetindevetdeset celih devet odstotkov razpoložljivosti, kar dopušča približno triinštirideset minut nedelovanja na mesec, kjer lahko zahteva API vrne napako petsto. Toda S3 obljublja enajst devetic trajnosti: devetindevetdeset vejica devet devet devet devet devet devet devet devet devet odstotkov. Če shranite deset milijonov datotek v S3, lahko statistično pričakujete, da boste izgubili povprečno eno datoteko vsakih deset tisoč let.

11:56 povprečno eno datoteko vsakih deset tisoč let. S3 to doseže z uporabo izbrisa-kodiranja objektov in replikacijo kosov med vsaj tremi geografsko ločenimi podatkovnimi centri. vsaj tri geografsko ločene podatkovne objekte. Med večjo regionalno omrežno izpadjo, S3 morda začasno ne bo na voljo, vendar vaši podatki nikoli niso uničeni.

- 10. Infrastruktura kot koda (Terraform v primerjavi s Console Drift)

12:14 Koncept številka deset: Infrastruktura kot koda, ali IaC. V zgodnjih dneh oblačnega računalništva so se inženirji prijavljali v AWS spletno upravljalno konzolo in ročno klikali, da bi ustvarili virtualne stroje, konfigurirali podomrežja in priključili varnostne skupine. Industrija to imenuje ClickOps, in v produkciji je to popolna katastrofa. Ročne spremembe v konzoli nimajo revizijske sledi, nimajo mehanizma za povrnitev mehanizma in neizogibno povzročajo odstopanje konfiguracije med razvojnim in produkcijskim okoljem. produkcijskih okoljih. Z orodji Infrastrukture kot kode, kot je Terraform,

12:48 kot orodja za kodo, kot je Terraform, OpenTofu, Pulumi ali AWS CDK, svojo celotno oblačno arhitekturo določite v deklarativnih konfiguracijskih datotekah, shranjenih v Gitu. celotno oblačno arhitekturo v deklarativnih konfiguracijskih datotekah, shranjenih v Gitu. Vsaka sprememba odprtih vrat ali replike baze podatkov gre skozi zahtevo za združitev in strokovni pregled. pull zahtevo in pregled s strani strokovnjakov. Zagon terraform plan predogleda točno API razliko, preden se karkoli spremeni, in zagon identične replike vašega produkcijskega sklada traja štiri minute namesto štirih tednov. karkoli se dotakne, in zagon identične replike vaše produkcije sklada traja štiri minute namesto štirih tednov.

- 11. Mreženje v oblaku (VPC, podomrežja, NAT in varnostne skupine)

13:20 Koncept številka enajst: Oblačno omrežje in navidezna zasebna oblaka. Ko namestite strežnike v oblak, niso izpostavljeni na surovem javnem internetu. Živijo znotraj programsko določene izolirane meje imenovane VPC. Znotraj vašega VPC dodelite zasebni naslovni prostor IP, kot je deset-pika-nič-pika-nič-pika-nič poševnica šestnajst, in ga razdelite na javna in zasebna podomrežja. deset-pika-nič-pika-nič-pika-nič poševnica šestnajst in ga razdelite v javna in zasebna podomrežja. Javno podomrežje ima neposredno pot do internetnega prehoda.

13:51 Vsebuje javno dostopna sredstva, kot so vaši Application Load Balancerji in NAT Prehodi. Je edini del vašega omrežja, ki ima javne IP naslove. Vaši aplikacijski strežniki in produkcijske baze podatkov živijo strogo v zasebnih podomrežjih brez javnih IP-jev in brez vhodnih poti iz interneta. interneta. Ko morajo vaši strežniki zaledja prenesti varnostne posodobitve, njihov odhodni promet poteka skozi NAT prehod v javnem podomrežju. podomrežju. Vsak primerek obdajajo varnostne skupine: stateful virtualni požarni zidovi, ki uveljavljajo načelo najmanjših privilegijev.

- 12. Celoten načrt podjetja in sodba

14:28 Vaša varnostna skupina baze podatkov sprejema povezave samo na vratih 5432 strogo iz varnostne skupine vaših aplikacijskih strežnikov, zaradi česar je zunanji vdor matematično nemogoč. Ko se oddaljimo, se teh enajst primitivov poveže v en koheziven sistem. Vaš DNS usmerja na uravnoteževalnik obremenitve v javnem podomrežju, skupine za samodejno skaliranje obvladujejo prometne konice med več območji razpoložljivosti, bus dogodkov ločuje delavce zaledja, in celoten vaš sklad je razporejen iz Gita z uporabo Infrastrukture kot kode.

15:02 Današnja sodba mojstrskega tečaja: SHIP IT. Nehajte si zapomniti na stotine marketinških okrajšav v oblaku. Obvladajte teh enajst arhitekturnih vzorcev, ločite svoje stanje, in gradite sisteme, ki ne morejo odpovedati. Povejte mi, kateri koncept oblaka vam je povzročal največ glavobolov, ko ste prvič začeli graditi v komentarjih. gradnjo v komentarjih. In da dobite celoten arhitekturni 'cheat sheet', naročite se na novice na the daily diff dot dev,

15:28 povezava spodaj. In to je razlika za danes. Sem Niko iz Axrisija. Združujte odgovorno.

Viri

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