Pilvandmetöötlus selgitatud: 11 arhitektuurikontseptsiooni, mida peate teadma (4K meisterklass).

Mida see video hõlmab

• - Arhitektuurisein ja põhiline plaan
• - 01. Vertikaalne vs. horisontaalne skaleerimine
• - 02. Koormuse jaotamise arhitektuur (L4 vs. L7 ja seisundi kontrollid)
• - 03. Automaatne skaleerimine ja elastsus
• - 04. Serverita (FaaS ja Firecracker MicroVM-id)

Tõlgitud transkriptsioon

Tõlgitud ingliskeelsest originaaljutustusest. Saadaolevat heli ja subtiitreid kontrollib YouTube.

- Arhitektuurisein ja põhiline plaan

0:00 Iga tarkvarainsener seisab lõpuks silmitsi pilvearhitektuuri seinaga. Sa ehitad rakenduse oma sülearvutisse, lükkad selle tootmisse, ja hetkel, kui reaalsed kasutajad saabuvad, serverid kukuvad kokku, andmebaasiühendused jooksevad tühjaks ja sinu AWS-i arve näeb välja nagu telefoninumber. Enamik arendajaid proovib pilvetehnikat lahendada meelde jättes kolmsada erinevat AWS-i toote akronüümi. kolmsada erinevat AWS-i toote akronüümi. Kuid tõeline pilvandmetöötlus ei seisne müüjate kataloogide meeldejätmises: see on ehitatud üheteistkümnele fundamentaalsele arhitektuuriprimitiivile.

0:34 Selles meisterklassis käsitleme kogu ettevõtte plaani: alates skaleerimisest ja koormuse tasakaalustamisest kuni serverivaba, sündmustepõhise lahtiühendamise, salvestushierarhiate ja pilvevõrgustikuni. Omandage need üksteist kontseptsiooni ja saate disainida mis tahes taustsüsteemi AWS-is, GCP-s või Azure'is. See on The Daily Diff, sügavamalt.

- 01. Vertikaalne vs. horisontaalne skaleerimine

0:57 Kontseptsioon number üks: Skaleerimine. Kui teie rakenduse liiklus kasvab, on teil koormuse haldamiseks kaks põhimõtteliselt erinevat viisi: vertikaalne skaleerimine või horisontaalne skaleerimine. Vertikaalne skaleerimine ehk üles skaleerimine tähendab teie olemasoleva masina ja ressursside lisamist: uuendamist neljalt CPU tuumalt kolmekümne kahele, või kolmekümne kahe gigabaidi RAM-i asendamist saja kahekümne kaheksa gigabaidiga. kahekümne kaheksaga. Vertikaalne skaleerimine ei nõua arhitektuurilisi muudatusi: teie kood

1:28 ja andmebaas jäävad täpselt samaks. Kuid see jõuab karmi riistvaralise piirini. Ühelgi maailmas oleval masinal pole kümme tuhat CPU tuuma, ja tippklassi eksemplarid kaasnevad eksponentsiaalse hinnapreemiaga. Horisontaalne skaleerimine ehk väljapoole skaleerimine tähendab teie serverite väikeste ja kaubatoodete hinnaga hoidmist, kuid mitme eksemplari paralleelset käitamist ruuteri taga. Kui üks eksemplar kukub kokku, neelavad ülejäänud sõlmed liikluse endasse nullseisakuga. Horisontaalse skaleerimise kuldreegel on olekutus:

2:01 teie rakendusserverid ei saa salvestada kasutajaseansse, üleslaaditud faile ega olekut oma kohalikele ketastele. Olek peab asuma välises andmebaasis või vahemälus, mis võimaldab mis tahes sõlmel käsitleda mis tahes kasutaja päringut.

- 02. Koormuse jaotamise arhitektuur (L4 vs. L7 ja seisundi kontrollid)

2:17 Kontseptsioon number kaks: Koormuse tasakaalustamine. Horisontaalne skaleerimine kõlab paberil suurepäraselt, kuid see tekitab kohese probleemi: kui kümme tuhat kasutajat teie domeeninimele sisenevad, milline konkreetne server saab nende liikluse? Koormuse tasakaalustaja toimib pöördproksina, mis asub avaliku interneti ja teie privaatse taustasüsteemi klastri vahel. See võtab vastu sissetulevad TCP või HTTP ühendused ja jaotab päringud teie tervete eksemplaride vahel.

2:47 Koormuse tasakaalustajad töötavad kahel peamisel võrgukihil. 4. kihi võrgukoormuse tasakaalustajad töötavad transpordikihil, suunates tooreid TCP ja UDP pakette IP-aadressi ja pordi alusel mikrosekundilise latentsuse ja miljonite päringutega sekundis. 7. kihi rakenduskoormuse tasakaalustajad kontrollivad HTTP protokolli ennast: lugedes URL-i teekondi, päringu päiseid, küpsiseid ja HTTP meetodeid. See võimaldab teekonnapõhist marsruutimist: saates /api päringuid teie taustasüsteemi klastrisse ja /static päringuid objekti salvestusse.

3:25 Oluline on, et koormuse tasakaalustajad teostavad aktiivseid seisundi kontrolli. Iga paari sekundi järel pingib tasakaalustaja iga eksemplari seisundi lõpp-punkti. Kui eksemplar viskab kolm järjestikust viiesajast viga või ei reageeri, eemaldatakse see automaatselt basseinist nulliga katkestatud päringutega.

- 03. Automaatne skaleerimine ja elastsus

3:45 Kontseptsioon number kolm: Automaatne skaleerimine. Kui teie veebirakendus vajab kell kolm hommikul kahte serverit, kuid keskpäevase käivitamise ajal kakskümmend serverit, on nuppude käsitsi klõpsamine pilvekonsoolis garanteeritud tee seisakuni ja pankrotini. Automaatne skaleerimine toob dünaamilise elastsuse horisontaalsetesse serveribasseinidesse. Automaatse skaleerimise grupp jälgib jõudlusmõõdikuid nagu keskmine CPU kasutus, võrgu I/O või järjekorra pikkus. Kui keskmine CPU ületab määratletud läve – näiteks seitsekümmend protsenti

4:19 kolm järjestikust minutit – käivitab automaatse skaleerimise mehhanism automaatselt uued virtuaalmasinad, registreerib need teie koormuse tasakaalustajaga ja hakkab liiklust suunama. Sama oluline on sissepoole skaleerimine: kui liikluslaine taandub, lõpetab automaatse skaleerimise mehhanism üleliigsed eksemplarid, nii et te ei maksa enam tühikäigul oleva arvutusvõimsuse eest. Vältimaks võnkumist – kus servereid luuakse ja hävitatakse pidevas tühikäiguringluses – konfigureerivad pilvearhitektid jahtumisperioodid. Kontseptsioon number neli: Serverita.

- 04. Serverita (FaaS ja Firecracker MicroVM-id)

4:53 Aastaid reklaamisid turundusmeeskonnad serverivaba kui maagilist koodi, mis töötab taevas. Tegelikult kasutab serverivaba ikka veel servereid – aga te ei oma neid, ei paika neid ega maksa nende eest, kui koodi ei tööta. Funktsioon-kui-teenus (FaaS) abil, nagu AWS Lambda või Google Cloud Functions, kirjutate iseseisva käitleja funktsiooni. Kui ilmneb HTTP päring, S3 faili üleslaadimine või andmebaasi muutus, käivitab pilveruntime efemeerse mikro-virtuaalmasina

5:23 nagu Firecracker vähem kui viie millisekundi jooksul. Teie kood täidetakse, tagastab vastuse ja lülitub välja. Kui keegi ei külasta teie veebisaiti kolm kuud, on teie arvutusarve täpselt null dollarit ja null senti. Kui miljon kasutajat tabab seda samaaegselt, käivitab pakkuja miljon samaaegset mikro-VM-i. Inseneri kompromissid on reaalsed: külma käivituse latentsus uute käitusaegade käivitamisel, Lambda puhul range viieteistkümne minuti täitmispiirang ja range olekutus. Lambda, ja range olekutus.

5:55 Serverivaba on võitmatu sündmuste torujuhtmete ja sporadiliste API-de jaoks, kuid halb püsivate WebSocketsi või mitmetunniste treeningjooksude jaoks.

- 05. Sündmustepõhine arhitektuur (EDA ja lahtiühendamine)

6:05 Kontseptsioon number viis: Sündmustepõhine arhitektuur ehk EDA. Traditsioonilistes arhitektuurides suhtlevad teenused sünkroonselt. Teie väljaregistreerimisteenus kutsub makset, makse kutsub laoseisu, laoseis kutsub pettust ja pettus kutsub e-posti. See loob sünkroonse hukutava kaskaadi. Kui kolmanda osapoole e-posti teenusepakkuja kogeb võrguhäiret ja vastab kümne sekundiga, siis teie kliendi kogu väljaregistreerimispäring aegub veaga. Sündmustepõhises arhitektuuris on teenused täielikult lahti ühendatud.

6:37 Kui klient klõpsab osta, ei kutsu väljaregistreerimisteenus allavoolu teenuseid. See lihtsalt avaldab sündmuse nimega TellimusEsitatud kesksesse sündmuste bussi, näiteks Amazon EventBridge või SNS teema. Väljaregistreerimine lõpeb viiekümne millisekundi jooksul. Allavoolu töötajad maksete, laoseisu vähendamise ja e-posti kviitungite jaoks tõmbavad sõnumeid iseseisvalt oma spetsiaalsetest SQS-järjekordadest. Kui e-posti teenus läheb tunniks ajaks rikki, ootavad sõnumid turvaliselt puhverdatud järjekorras ilma ühegi kaduma läinud tellimuseta.

- 06. Konteinerite orkestreerimine (Docker ja Kubernetes)

7:13 Kontseptsioon number kuus: Konteinerite orkestreerimine. Docker lahendas pakendamise: see pakendab teie rakenduskoodi, süsteemiteegid, konfiguratsiooni ja käituskeskkonna muutumatuks kujutiseks, mis töötab identselt teie MacBookis ja pilves. Kuid konteineri pakendamine on lihtne. Viiesaja konteineri käitamine viiekümne füüsilise virtuaalmasina vahel on koht, kus inseneritöö katkeb. Seepärast eksisteerivad konteinerite orkestraatorid nagu Kubernetes ja AWS ECS.

7:41 Orkestraator pakub juhtpaneeli: API serverit, etcd olekuhoidlat ja intelligentset planeerijat. etcd olekuhoidlat ja intelligentset planeerijat. Te deklareerite oma soovitud oleku: ma tahan kümme repliiki oma autentimisteenusest igaühele kaks gigabaiti RAM-i. Planeerija inspekteerib klastrit, paigutab podid vabale mälule sõlmedesse, konfigureerib sisemise võrgu ja lepitab pidevalt reaalsust. Kui sõlm kannatab riistvararikkest, tuvastab Kubernetes kaotuse ja paigutab kõik ümberpaigutatud podid koheselt tervetele sõlmedele.

- 07. Neli pilve salvestusala (S3, EBS, DB-d ja Redis)

8:16 Kontseptsioon number seitse: Pilvesalvestuse hierarhia. Algajad käsitlevad pilvesalvestust sageli kui ühte ämbrit, kuhu faile visata. Tootmisarhitektuuris jaguneb salvestus neljaks erinevaks sambaks, mis põhinevad juurdepääsumustritel ja latentsusel. Esimene on objektihoidla, nagu Amazon S3 või Google Cloud Storage. Failidele pääsete juurde HTTP REST API-de kaudu, kasutades lihtsaid PUT- ja GET-kõnesid. See pakub piiramatut horisontaalset mahtu kahe sendi eest gigabaidi kohta kuus,

8:49 muutes selle ideaalseks videote, kasutajate üleslaadimiste, logide ja varukoopiate jaoks. Teine on plokksalvestus, nagu Amazon EBS. Need on virtuaalsed kõvakettad, mis on paigaldatud otse konkreetsele virtuaalmasinale kiirete ühenduste kaudu. Need vorminduvad standardseteks failisüsteemideks nagu ext4, toetades kiiret juhuslikku lugemis- ja kirjutamisjuurdepääsu, mida andmebaasimootorid vajavad. Kolmas on hallatavad andmebaasid: relatsioonimootorid nagu PostgreSQL RDS-is, mis pakuvad ACID-tehinguid ja keerukaid liitumisi, ning NoSQL-mootorid nagu DynamoDB,

9:21 mis pakuvad ühekohalise millisekundi latentsusega massiivses skaalas. milisekundilise latentsusega massiivses skaalas. Ja neljas on mälusisesed vahemälud nagu Redis. Andmete lugemine RAM-ist võtab mikrosekundeid, mitte millisekundeid. Vahemälud asuvad teie andmebaasi ees, kaitstes seda korduvast lugemisliiklusest ja hallates muutlikke kasutajaseansitokene.

- 08. Kõrge kättesaadavus ja ühikud (mitme AZ-i ümberlülitamine)

9:44 Kontseptsioon number kaheksa: Kõrge kättesaadavus ehk HA. Kättesaadavus vastab ühele küsimusele: mitu protsenti ajast on teie rakendus töökorras ja kasutajatele kättesaadav? Ettevõtluslepingutes mõõdetakse kättesaadavust "üheksates". Kaks üheksat ehk üheksakümmend üheksa protsenti kättesaadavust, lubab üle kolme ja poole päeva seisakuid igal aastal. Neli üheksat vähendab lubatud seisakuid viiekümne kahele minutile, ja viis üheksat lubab aastas vaid viis minutit seisakuid.

10:15 Kõrge kättesaadavuse saavutamiseks peate kõrvaldama ühekordsed veapunktid rikkekuvandite vahel. Pilves tähendab see juurutamist mitmesse kättesaadavuse tsooni. Kättesaadavuse tsoon ei ole üks riiul: see on üks või mitu erinevat füüsilist andmekeskust miilide kaugusel, millel on sõltumatu toide ja jahutus. Käivitades aktiivseid eksemplare tsoonis A ja tsoonis B sünkroonse andmebaasi replikatsiooniga, põhjustab välgulöök või kiudoptilise kaabli katkestus, mis viib alla terve füüsilise seadme, automatiseeritud ümberlülituse.

10:50 kolmekümne sekundiga, ilma inimliku sekkumiseta.

- 09. Kestvus vs. kättesaadavus (miks 11 ühikut ei ole tööaeg)

10:53 Kontseptsioon number üheksa: Vastupidavus versus Kättesaadavus. See on pilvearhitektuuri intervjuudes kõige levinum kontseptuaalne lõks. Insenerid kasutavad neid sõnu sageli vaheldumisi, kuid need mõõdavad täiesti erinevaid omadusi. Kättesaadavus mõõdab tööaega: kas ma saan praegu teha API-kutse oma andmete lugemiseks või kirjutamiseks? andmeid just praegu? Vastupidavus mõõdab säilimist: kas minu andmed püsivad kümne aasta jooksul ilma püsiva bittide mädanemise, riknemise või hävitamiseta? bittide mädanemise, riknemise või hävitamiseta kümne aasta jooksul?

11:24 Vaatame Amazon S3 Standardit. Selle teenustaseme kokkulepe pakub üheksakümmend üheksa koma üheksa protsenti kättesaadavust, mis lubab umbes nelikümmend kolm minutit seisakuid iga kuu kus API-päring võib tagastada viiesajase veateate. Kuid S3 lubab üheteistkümne üheksa vastupidavust: üheksakümmend üheksa punkt üheksa üheksa üheksa üheksa üheksa üheksa üheksa üheksa üheksa üheksa protsenti. Kui salvestate S3-sse kümme miljonit faili, võite statistiliselt eeldada, et kaotate keskmiselt ühe faili iga kümne tuhande aasta tagant.

11:56 keskmiselt üks fail iga kümne tuhande aasta kohta. S3 saavutab selle objektide kustutuskodeerimise ja tükkide replikeerimisega vähemalt kolme geograafiliselt eraldatud andmekeskuse vahel. vähemalt kolme geograafiliselt eraldatud andmekeskuse vahel. Suure piirkondliku võrgu katkemise ajal võib S3 ajutiselt mitte olla kättesaadav, kuid teie andmeid ei hävitata kunagi.

- 10. Taristu koodina (Terraform vs. konsooli triiv)

12:14 Kontseptsioon number kümme: Infrastruktuur koodina ehk IaC. Pilvandmetöötluse algusaegadel logisid insenerid AWS-i sisse veebihalduskonsooli ja klõpsisid käsitsi ringi, et luua virtuaalseid masinaid, masinaid, konfigureerida alamvõrke ja lisada turvagruppe. Tööstuses nimetatakse seda ClickOpsiks ja tootmises on see absoluutne katastroof. Käsitsi konsoolimuudatustel puudub auditi jälg, tagasipööramismehhanism mehhanism ja põhjustavad vältimatult konfiguratsiooni lahknevust testimis- ja tootmiskeskkondade vahel. tootmiskeskkondade vahel. Infrastruktuuriga

12:48 koodina tööriistad nagu Terraform, OpenTofu, Pulumi või AWS CDK abil määrate oma kogu pilvearhitektuuri deklaratiivsetes konfiguratsioonifailides, mis on salvestatud Git-i. kogu pilvearhitektuuri deklaratiivsetes konfiguratsioonifailides, mis on salvestatud Git-i. Iga muudatus avatud pordis või andmebaasi replikas käib läbi pull request'i ja vastastikuse hindamise. Käivitades terraform plan'i, näeb täpselt API diff'i enne, midagi ei puudutata ja tootmisandmete identse koopia käivitamine virna loomine võtab neli minutit nelja nädala asemel.

- 11. Pilvevõrgustik (VPC, alamvõrgud, NAT ja turvagrupid)

13:20 Kontseptsioon number üksteist: Pilvevõrgustik ja Virtuaalsed Privaatvõrgud. Kui paigutate serverid pilve, ei asu need otse avalikul internetis, nad elavad tarkvaraliselt määratletud isoleeritud piirides mida nimetatakse VPC-ks. Teie VPC-s eraldate privaatse IP-aadressiruumi, näiteks kümme-punkt-null-punkt-null-punkt-null kaldkriips kuusteist ja jagate selle avalikeks ja privaatseteks alamvõrkudeks. Avalikul alamvõrgul on otsene marsruut Interneti-lüüsi juurde.

13:51 See sisaldab avalikke varasid, nagu teie rakenduse koormuse jaoturid ja NAT-lüüdid. Lüüsid. See on teie võrgu ainus osa, millel on avalikud IP-aadressid. Teie rakendusserverid ja tootmisandmebaasid asuvad rangelt privaatsetes alamvõrkudes, kus puuduvad avalikud IP-d ja null sissetulevat marsruuti internetist. internetiühendusest. Kui teie taustaerveritel on vaja turvauuendusi alla laadida, turvauuendusi alla laadida, nende väljuv liiklus marsruutitakse läbi NAT-lüüsi avalikus alamvõrgus. alamvõrk. Iga eksemplari ümbritsevad turvagrupid: olekutundlikud virtuaalsed tulemüürid, mis jõustavad minimaalse privileegi põhimõtet.

- 12. Täielik ettevõtte plaan ja otsus

14:28 Teie andmebaasi turvagrupp aktsepteerib ühendusi ainult pordil 5432 rangelt teie rakendusserverite turvagrupist, muutes välise sissetungi matemaatiliselt võimatuks. Kui vaadata laiemalt, ühenduvad need üksteist algpõhimõtet ühtseks süsteemiks. Teie DNS marsruutib koormuse jaoturisse avalikus alamvõrgus, automaatskaala rühmad haldavad liiklusvooge mitmetes kättesaadavuse tsoonides, sündmuste siinid eraldavad taustatöötajaid ja teie kogu süsteem on juurutatud Gitist, kasutades infrastruktuuri kui koodi.

15:02 Tänase meistriklassi otsus: SHIP IT. Lõpetage sadade pilve turundusakronüümide meeldejätmine. Omandage need üksteist arhitektuurimustrit, eraldage oma olek, ja ehitage süsteeme, mis ei saa ebaõnnestuda. Öelge mulle kommentaarides, milline pilvekontseptsioon valmistas teile alguses kõige rohkem peavalu. ehitades kommentaarides. Ja et haarata täielik arhitektuuri spikker, tellige uudiskiri aadressil the daily diff dot dev,

15:28 link allpool. Ja see on tänase päeva erinevus. Mina olen Niko Axrisist. Ühendage vastutustundlikult.

Allikad

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