Debesų kompiuterija paaiškinta: 11 architektūros koncepcijų, kurias privalote žinoti (4K Masterclass).

Kas aptariama šiame vaizdo įraše

• - Architektūros siena ir pagrindinis planas
• - 01. Vertikalus vs. horizontalus mastelio keitimas
• - 02. Apkrovos balansavimo architektūra (L4 vs. L7 ir būsenos patikros)
• - 03. Automatinis mastelio keitimas ir elastingumas
• - 04. Serverless (FaaS ir Firecracker MicroVMs)

Išverstas transkriptas

Išversta iš originalo anglų kalbos. Galimas garso ir subtitrų valdymas per YouTube.

- Architektūros siena ir pagrindinis planas

0:00 Kiekvienas programinės įrangos inžinierius galiausiai susiduria su debesų architektūros siena. Jūs sukuriate programą savo nešiojamajame kompiuteryje, perkeliate ją į gamybą, ir tą akimirką, kai ateina tikri vartotojai, serveriai sugenda, duomenų bazės jungtys išsisklaido, o jūsų AWS sąskaita atrodo kaip telefono numeris. Dauguma kūrėjų bando išspręsti debesų inžinerijos problemas įsimindami tris šimtus skirtingų AWS produktų akronimų. Tačiau tikroji debesų kompiuterija nėra apie tiekėjų katalogų įsiminimą: ji yra pastatyta ant vienuolikos fundamentalių architektūrinių primityvų.

0:34 Šioje meistriškumo klasėje išsamiai aptarsime visą įmonės planą: nuo mastelio keitimo ir apkrovos balansavimo iki serverless, įvykiais pagrįsto atsiejimo, saugojimo hierarchijų ir debesų tinklo. Įvaldykite šias vienuolika koncepcijų ir galėsite suprojektuoti bet kokią sistemą AWS, GCP ar Azure. Tai yra „The Daily Diff“ iš vidaus.

- 01. Vertikalus vs. horizontalus mastelio keitimas

0:57 Pirma koncepcija: mastelio keitimas. Kai jūsų programa patiria srauto augimą, turite du iš esmės skirtingus būdus apkrovai valdyti: vertikalus mastelio keitimas arba horizontalus mastelio keitimas. Vertikalus mastelio keitimas, arba didinimas, reiškia jūsų esamą mašiną ir pridėti daugiau išteklių: atnaujinimas nuo keturių CPU branduolių iki trisdešimt dviejų, arba trisdešimt dviejų gigabaitų RAM keitimas į šimtą dvidešimt aštuonis. Vertikalus mastelio keitimas nereikalauja jokių architektūrinių pakeitimų: jūsų kodas

1:28 ir duomenų bazė lieka lygiai tokie patys. Tačiau jis pasiekia žiaurią techninės įrangos ribą. Nėra nė vienos mašinos pasaulyje, turinčios dešimt tūkstančių CPU branduolių, o aukščiausios klasės egzemplioriai turi eksponentinį kainų priemoką. Horizontalus mastelio keitimas, arba plėtimas, reiškia, kad jūsų serveriai yra maži ir pigūs, tačiau paleidžiama daug egzempliorių lygiagrečiai už maršrutizatoriaus. Jei vienas egzempliorius sugenda, likę mazgai sugeria srautą be prastovų. Auksinė horizontalaus mastelio keitimo taisyklė yra

2:01 būsenos nebuvimas: jūsų programų serveriai negali saugoti vartotojų sesijų, įkeltų failų ar būsenos savo vietiniuose diskuose. Būsena turi būti išorinėje duomenų bazėje arba talpykloje, leidžianti bet kuriam mazgui apdoroti bet kokią vartotojo užklausą.

- 02. Apkrovos balansavimo architektūra (L4 vs. L7 ir būsenos patikros)

2:17 Antra koncepcija: apkrovos balansavimas. Horizontalus mastelio keitimas popieriuje skamba puikiai, tačiau iš karto atsiranda problema: kai dešimt tūkstančių vartotojų pasiekia jūsų domeno vardą, kuris konkretus serveris gauna jų srautą? Apkrovos balansuoklis veikia kaip atvirkštinis tarpinis serveris, esantis tarp viešojo interneto ir jūsų privataus backend klasterio. Jis priima gaunamus TCP arba HTTP jungtis ir paskirsto užklausas jūsų veikiantiems egzemplioriams.

2:47 Apkrovos balansuokliai veikia dviejuose pagrindiniuose tinklo sluoksniuose. 4 sluoksnio tinklo apkrovos balansuokliai veikia transportavimo sluoksnyje, maršrutizuodami neapdorotus TCP ir UDP paketus pagal IP adresą ir prievadą su mikrosekundžių vėlavimu ir milijonais užklausų per sekundę. 7 sluoksnio programų apkrovos balansuokliai tikrina HTTP protokolą patį: skaito URL kelius, užklausos antraštes, slapukus ir HTTP metodus. Tai leidžia maršrutizuoti pagal kelią: siųsti slash-api užklausas į jūsų backend klasterį ir slash-static užklausas į

3:25 objektų saugyklą. Svarbiausia, apkrovos balansuokliai atlieka aktyvias būsenos patikras. Kas kelias sekundes balansuoklis tikrina būsenos galinį tašką kiekviename egzemplioriuje. Jei egzempliorius tris kartus iš eilės išmeta penkis šimtus klaidų arba nesugeba atsakyti, jis automatiškai pašalinamas iš telkinio be jokios prarastos užklausos.

- 03. Automatinis mastelio keitimas ir elastingumas

3:45 Trečia koncepcija: automatinis mastelio keitimas. Jei jūsų žiniatinklio programai reikia dviejų serverių trečią valandą ryto, bet dvidešimt serverių vidury dienos, mygtukų rankinis paspaudimas debesų konsolėje yra garantuotas kelias į prastovas ir bankrotą. Automatinis mastelio keitimas suteikia dinamišką elastingumą horizontaliems serverių telkiniams. Automatinio mastelio keitimo grupė stebi našumo metrikas, tokias kaip vidutinis CPU panaudojimas, tinklo I/O arba eilės atsilikimo gylis. Kai vidutinis CPU peržengia nustatytą ribą – tarkim,

4:19 septyniasdešimt procentų tris minutes iš eilės – automatinis mastelio keitimo įrenginys automatiškai paleidžia naujas virtualias mašinas, registruoja jas jūsų apkrovos balansuoklyje, ir pradeda maršrutizuoti srautą. Lygiai taip pat svarbu yra mastelio mažinimas: kai srauto banga atslūgsta, automatinis mastelio keitimo įrenginys nutraukia nereikalingus egzempliorius, kad nustotumėte mokėti už tuščiaja veiksena esančius skaičiavimus. Kad būtų išvengta svyravimų – kai serveriai greitai sukuriami ir naikinami begaliniame trūkčiojančiame cikle – debesų architektai konfigūruoja atvėsimo laikotarpius. Ketvirta koncepcija: Serverless.

- 04. Serverless (FaaS ir Firecracker MicroVMs)

4:53 Daugelį metų rinkodaros komandos pristatė serverless kaip stebuklingą kodą, veikiantį danguje. Iš tikrųjų, serverless vis dar naudoja serverius – bet jūs jų neturite, nelabote ir nemokate už juos, kai kodas neveikia. Naudojant Function-as-a-Service, pvz., AWS Lambda arba Google Cloud Functions, jūs parašote atskirą tvarkyklės funkciją. Kai įvyksta HTTP užklausa, S3 failo įkėlimas arba duomenų bazės pakeitimas, debesų vykdymo aplinka paleidžia efemerišką

5:23 mikrovirtualią mašiną, pvz., Firecracker, per mažiau nei penkias milisekundes. Jūsų kodas vykdomas, grąžina atsakymą ir išsijungia. Jei niekas neaplankys jūsų svetainės tris mėnesius, jūsų skaičiavimo sąskaita bus lygiai nulis dolerių ir nulis centų. Jei milijonas vartotojų vienu metu ją pasieks, tiekėjas paleis milijoną vienu metu veikiančių mikrovirtualių mašinų. Inžineriniai kompromisai yra realūs: šalto paleidimo vėlavimas paleidžiant naujas vykdymo aplinkas, griežtas penkiolikos minučių vykdymo limitas naudojant Lambda ir griežtas būsenos nebuvimas.

5:55 Serverless yra nepralenkiamas įvykių srautams ir sporadiniams API, bet prastas nuolatiniams WebSockets arba kelių valandų mokymosi vykdymams.

- 05. Įvykiais pagrįsta architektūra (EDA ir atsiejimas)

6:05 Penkta koncepcija: įvykiais pagrįsta architektūra, arba EDA. Tradicinėse architektūrose paslaugos bendrauja sinchroniškai. Jūsų kasos paslauga kreipiasi į mokėjimų, mokėjimų paslauga – į atsargų, atsargų paslauga – į sukčiavimo, o sukčiavimo paslauga – į el. pašto paslaugą. Tai sukuria sinchroninę pražūties kaskadą. Jei trečiosios šalies el. pašto paslauga patiria tinklo sutrikimą ir atsakymui prireikia dešimt sekundžių, visas jūsų kliento kasos užklausa baigiasi klaida. Įvykiais pagrįstoje architektūroje paslaugos yra visiškai atsietos.

6:37 Kai klientas paspaudžia „pirkti“, kasos paslauga nekviečia paslaugų, esančių žemiau srauto. Ji tiesiog paskelbia įvykį pavadinimu „Užsakymas_įvykdytas“ į centrinį įvykių autobusą, pvz., Amazon EventBridge arba SNS temą. Atsiskaitymas baigiamas per penkiasdešimt milisekundžių. Tolesni apmokėjimo, atsargų atėmimo ir el. pašto kvitų darbuotojai nepriklausomai išsitraukia pranešimus iš savo dedikuotų SQS eilių. Jei el. pašto paslauga neveikia valandą, pranešimai saugiai laukia buferizuoti eilėje be jokio prarasto užsakymo.

- 06. Konteinerių orkestravimas (Docker ir Kubernetes)

7:13 Šešta koncepcija: konteinerių orkestravimas. Docker išsprendė pakavimo problemą: jis apgaubia jūsų programos kodą, sistemos bibliotekas, konfigūraciją ir vykdymo aplinką į nekintamą atvaizdą, kuris identiškai veikia jūsų „MacBook“ ir debesyje. Tačiau supakuoti konteinerį yra lengva. Vykdyti penkis šimtus konteinerių penkiasdešimtyje fizinių virtualių mašinų yra vieta, kur inžinerija sustoja. Štai kodėl egzistuoja konteinerių orkestratoriai, tokie kaip Kubernetes ir AWS ECS.

7:41 Orkestratorius suteikia valdymo plokštumą: API serverį, etcd būsenos saugyklą ir išmanųjį planuotoją. Jūs deklaruojate norimą būseną: aš noriu dešimt savo autentifikavimo paslaugos kopijų su dviem gigabaitais RAM kiekvienai. Planuotojas tikrina klasterį, padeda mazgus su laisva atmintimi, konfigūruoja vidinį tinklą ir nuolat derina realybę. Jei mazgas patiria techninės įrangos gedimą, Kubernetes aptinka praradimą ir iš karto perskelia visus išstumtus modulius į

- 07. 4 debesų saugojimo ramsčiai (S3, EBS, DBs ir Redis)

8:16 sveikus mazgus. Septinta koncepcija: debesų saugyklos hierarchija. Pradedantieji dažnai debesų saugyklą traktuoja kaip vieną kibirą, į kurį iškraunami failai. Gamybos architektūroje saugykla yra padalinta į keturis skirtingus stulpus, pagrįstus prieigos modeliais ir vėlavimu. Pirma yra objektų saugykla, pvz., Amazon S3 arba Google Cloud Storage. Prie failų prisijungiate per HTTP REST API, naudodami paprastus PUT ir GET iškvietimus. Ji siūlo begalinę horizontalią talpą už du centus už gigabaitą per mėnesį,

8:49 todėl ji idealiai tinka vaizdo įrašams, vartotojų įkėlimams, žurnalams ir atsarginėms kopijoms. Antra yra blokų saugykla, pvz., Amazon EBS. Tai yra virtualūs standieji diskai, tiesiogiai prijungti prie konkrečios virtualios mašinos per didelio greičio jungtis. Jie formatuojami į standartines failų sistemas, pvz., ext4, palaikančios greitą atsitiktinę skaitymo ir rašymo prieigą, reikalingą duomenų bazių varikliams. Trečia – valdomos duomenų bazės: reliacinės varikliai, tokie kaip PostgreSQL RDS, teikiantys ACID operacijas ir sudėtingas jungtis,

9:21 ir NoSQL varikliai, tokie kaip DynamoDB, užtikrinantys vienženklį milisekundžių vėlavimą dideliu mastu. Ir ketvirta – atminties talpyklos, tokios kaip Redis. Duomenų skaitymas iš RAM trunka mikrosekundes, o ne milisekundes. Talpyklos yra priešais jūsų duomenų bazę, apsaugodamos ją nuo pasikartojančio skaitymo srauto ir valdančios nepastovius vartotojų sesijų žetonus.

- 08. Didelis pasiekiamumas ir devynetai (daugiAZ gedimų perėmimas)

9:44 Aštunta koncepcija: didelis pasiekiamumas, arba HA. Pasiekiamumas atsako į vieną klausimą: kiek procentų laiko jūsų programa yra veikianti ir prieinama vartotojams? Įmonės sutartyse pasiekiamumas matuojamas devynetais. Du devynetai, arba devyniasdešimt devyni procentai pasiekiamumo, leidžia daugiau nei tris su puse dienos prastovos kiekvienais metais. Keturi devynetai sumažina leistiną prastovą iki penkiasdešimt dviejų minučių, o penki devynetai leidžia vos penkias minutes bendros prastovos per

10:15 metus. Norėdami pasiekti didelį pasiekiamumą, turite pašalinti vienkartinius gedimo taškus per gedimo domenus. Debesyje tai reiškia diegimą keliose pasiekiamumo zonose. Pasiekiamumo zona nėra vienas stovas: tai yra vienas ar daugiau skirtingų fizinių duomenų centrų, nutolusių mylias, su nepriklausomu maitinimu ir aušinimu. Vykdant aktyvius egzempliorius A ir B zonose su sinchroniniu duomenų bazės replikavimu, žaibo smūgis ar pluošto nutrūkimas, dėl kurio sugenda visa fizinė įranga, lemia automatinį persijungimą

10:50 per trisdešimt sekundžių be jokio žmogaus įsikišimo.

- 09. Patvarumas vs. pasiekiamumas (kodėl 11 devynetų nėra veikimo laikas)

10:53 Devinta koncepcija: Patvarumas prieš Prieinamumą. Tai yra pati dažniausia konceptuali spąstų vieta debesų architektūros interviu metu. Inžinieriai dažnai vartoja šiuos žodžius pakaitomis, tačiau jie matuoja visiškai skirtingas savybes. Prieinamumas matuoja veikimo laiką: ar galiu dabar atlikti API užklausą, kad skaityčiau ar rašyčiau savo duomenis? Patvarumas matuoja išsaugojimą: ar mano duomenys išliks be nuolatinio bitų irimo, sugadinimo ar sunaikinimo per dešimt metų?

11:24 Pažvelkite į Amazon S3 Standard. Jo paslaugų lygio sutartis siūlo devyniasdešimt devynių kablelio devynių procentų prieinamumą, kuris leidžia maždaug keturiasdešimt tris minutes prastovos kiekvieną mėnesį, kai API užklausa gali grąžinti penkių šimtų klaidą. Tačiau S3 žada vienuolika devynetų patvarumo: devyniasdešimt devynis kablelis devyni devyni devyni devyni devyni devyni devyni devyni devyni procentai. Jei S3 saugote dešimt milijonų failų, statistiškai galite tikėtis prarasti vidutiniškai

11:56 vieną failą kas dešimt tūkstančių metų. S3 tai pasiekia koduodamas objektus ir replikuodamas fragmentus mažiausiai trijuose geografiškai atskirtuose duomenų centruose. Didelio regioninio tinklo gedimo metu S3 gali laikinai būti nepasiekiamas, bet jūsų duomenys niekada nėra sunaikinami.

- 10. Infrastruktūra kaip kodas (Terraform vs. konsolės poslinkis)

12:14 Dešimta koncepcija: Infrastruktūra kaip kodas, arba IaC. Ankstyvosiomis debesų kompiuterijos dienomis inžinieriai prisijungdavo prie AWS žiniatinklio valdymo konsolės ir rankiniu būdu spaudžiodami kūrė virtualias mašinas, konfigūravo potinklius ir prijungdavo saugumo grupes. Pramonėje tai vadinama ClickOps, ir gamyboje tai yra absoliuti nelaimė. Rankiniai konsolės pakeitimai neturi audito žurnalo, atšaukimo mechanizmo ir neišvengiamai sukelia konfigūracijos skirtumus tarp testavimo ir gamybos aplinkų. Su Infrastruktūros kaip kodo įrankiais, tokiais kaip Terraform,

12:48 OpenTofu, Pulumi ar AWS CDK, jūs apibrėžiate savo visą debesų architektūrą deklaratyviuose konfigūracijos failuose, saugomuose Git. Kiekvienas pakeitimas atvirame porte ar duomenų bazės replikoje vyksta per ištraukimo užklausą ir peržiūrą. Paleidus terraform plan peržiūrimas tikslus API skirtumas prieš bet kas liečiasi, o identiško jūsų gamybos sukūrimas užtrunka keturias minutes, o ne keturias savaites. Vienuolikta koncepcija: Debesų tinklai ir virtualūs privatūs debesys (VPC).

- 11. Debesų tinklas (VPC, potinkliai, NAT ir saugos grupės)

13:20 Kai diegiate serverius į debesį, jie nėra tiesiogiai atviri viešajam internetui. Jie gyvena programine įranga apibrėžtoje izoliuotoje aplinkoje, vadinamoje VPC. Savo VPC viduje, jūs skiriate privatų IP adresų erdvę, pvz., dešimt kablelis nulis kablelis nulis kablelis nulis pasvirasis brūkšnys šešiolika, ir padalijate ją į viešus ir privačius potinklius. Viešasis potinklis turi tiesioginį maršrutą į interneto vartus (Internet Gateway). Jame yra viešai prieinami objektai, pvz., jūsų programų apkrovos balansatoriai (Application Load Balancers) ir NAT

13:51 vartai (NAT Gateways). Tai yra vienintelė jūsų tinklo dalis, turinti viešus IP adresus. Jūsų programų serveriai ir gamybos duomenų bazės gyvena griežtai privačiuose potinkliuose be viešųjų IP ir be jokių įeinančių maršrutų iš interneto. Kai jūsų pagrindiniams serveriams reikia atsisiųsti saugos naujinimus, jų išeinantis srautas nukreipiamas per NAT vartus viešajame potinklyje. Kiekvieną egzempliorių supa saugos grupės (Security Groups): būseną išlaikančios virtualios ugniasienės, kurios užtikrina minimalių privilegijų principą. Jūsų duomenų bazės saugos grupė priima prisijungimus tik per 5432

- 12. Visas įmonės planas ir verdiktas

14:28 prievadą griežtai iš jūsų programų serverių saugos grupės, padarydama išorinį įsilaužimą matematiškai neįmanomu. Kai nutolstate, šie vienuolika primityvų susijungia į vieną darnią sistemą. Jūsų DNS nukreipiamas į apkrovos balansatorių viešame potinklyje, automatinio mastelio keitimo grupės tvarko srauto padidėjimus keliose prieinamumo zonose, įvykių magistralės atsiskiria pagrindinius darbuotojus, o visa jūsų sistema diegiama iš Git naudojant infrastruktūrą kaip kodą. Šiandienos meistriškumo pamokos verdiktas: SHIP IT.

15:02 Nustokite įsiminti šimtus debesų rinkodaros akronimų. Įvaldykite šiuos vienuolika architektūros modelių, atskirkite savo būseną ir kurkite sistemas, kurios negali sugesti. Komentaruose parašykite, kuri debesų koncepcija sukėlė jums didžiausią galvos skausmą, kai pirmą kartą pradėjote kurti. O kad gautumėte visą architektūros atmintinę, užsiprenumeruokite naujienlaiškį adresu the daily diff dot dev, nuoroda žemiau. Ir tai yra šiandienos skirtumas.

15:28 Aš esu Niko iš Axrisi. Jungti atsakingai. Susilieti atsakingai.

Šaltiniai

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