Paskaidroti mākoņdatošanas pamatprincipi: 11 arhitektūras koncepti, kas jāzina (4K meistarklase).

Ko aptver šis video

• - Arhitektūras siena un galvenais projekts
• - 01. Vertikālā pret horizontālo mērogošanu
• - 02. Slodzes balansēšanas arhitektūra (L4 pret L7 un veselības pārbaudes)
• - 03. Automātiskā mērogošana un elastība
• - 04. Bezserveru (FaaS un Firecracker MicroVM)

Tulkotais transkripts

Tulkojums no oriģinālā angļu stāstījuma. Pieejamais audio un subtitri tiek kontrolēti no YouTube.

- Arhitektūras siena un galvenais projekts

0:00 Katrs programmatūras inženieris galu galā saskaras ar mākoņa arhitektūras sienu. Jūs veidojat lietojumprogrammu savā klēpjdatorā, ievietojat to ražošanā, un brīdī, kad parādās reāli lietotāji, serveri avarē, datu bāzes savienojumi izveidojas, un jūsu AWS rēķins izskatās pēc tālruņa numura. Lielākā daļa izstrādātāju cenšas atrisināt mākoņdatošanas inženierijas problēmu, iegaumējot trīssimt dažādus AWS produktu akronīmus. Bet reālā mākoņdatošana nav par piegādātāju katalogu iegaumēšanu: tā ir balstīta uz vienpadsmit fundamentālām arhitektūras primitīvām.

0:34 Šajā meistarklasē mēs izskatīsim visu uzņēmuma plānu: no mērogošanas un slodzes balansēšanas līdz serverless, notikumu virzītai atsaistīšanai, glabāšanas hierarhijām un mākoņa tīklošanai. Apgūstiet šos vienpadsmit konceptus, un jūs varat projektēt jebkuru aizmugures sistēmu AWS, GCP vai Azure. Šis ir The Daily Diff, aiz kulisēm.

- 01. Vertikālā pret horizontālo mērogošanu

0:57 Pirmais koncepts: Mērogošana. Kad jūsu lietojumprogramma piedzīvo trafika pieaugumu, jums ir divi fundamentāli dažādi veidi, kā apstrādāt slodzi: vertikālā mērogošana vai horizontālā mērogošana. Vertikālā mērogošana jeb mērogošana uz augšu nozīmē, ka jūs ņemat savu esošo mašīnu un pievienojat vairāk resursu: jauninot no četriem CPU kodoliem uz trīsdesmit diviem, vai mainot trīsdesmit divus gigabaitus RAM uz simts divdesmit astoņiem. Vertikālā mērogošana neprasa nekādas arhitektūras izmaiņas: jūsu kods

1:28 un datu bāze paliek tieši tādas pašas. Bet tā sasniedz brutālu aparatūras griestus. Nevienai mašīnai pasaulē nav desmit tūkstošu CPU kodolu, un augstākās klases instances nes eksponenciālu cenu piemaksu. Horizontālā mērogošana jeb mērogošana uz āru nozīmē, ka jūsu serveri paliek mazi un ar standarta cenām, bet vairākas instances darbojas paralēli aiz maršrutētāja. Ja viena instance avarē, pārējie mezgli absorbē trafiku ar nulles dīkstāvi. Horizontālās mērogošanas zelta likums ir

2:01 bezvalstiskums: jūsu lietojumprogrammu serveri nevar glabāt lietotāju sesijas, augšupielādētos failus vai stāvokli savos lokālajos diskos. Stāvoklim jāatrodas ārējā datu bāzē vai kešatmiņā, ļaujot jebkuram mezglam apstrādāt jebkuru lietotāja pieprasījumu.

- 02. Slodzes balansēšanas arhitektūra (L4 pret L7 un veselības pārbaudes)

2:17 Otrais koncepts: Slodzes balansēšana. Horizontālā mērogošana uz papīra izklausās lieliski, taču tā rada tūlītēju problēmu: kad desmit tūkstoši lietotāju piekļūst jūsu domēna vārdam, kurš konkrētais serveris saņem viņu trafiku? Slodzes balansētājs darbojas kā reversais starpniekserveris starp publisko internetu un jūsu privāto aizmugures klasteri. Tas pieņem ienākošos TCP vai HTTP savienojumus un sadala pieprasījumus starp jūsu veselīgajām instancēm.

2:47 Slodzes balansētāji darbojas divos galvenajos tīkla slāņos. Layer 4 tīkla slodzes balansētāji darbojas transporta slānī, maršrutējot neapstrādātus TCP un UDP paketes, pamatojoties uz IP adresi un portu ar mikrosekunžu latentumu un miljoniem pieprasījumu sekundē. Layer 7 lietojumprogrammu slodzes balansētāji pārbauda pašu HTTP protokolu: lasot URL ceļus, pieprasījumu galvenes, sīkdatnes un HTTP metodes. Tas nodrošina maršrutēšanu, pamatojoties uz ceļu: sūtot slīpsvītra-api pieprasījumus uz jūsu aizmugures klasteri un slīpsvītra-static pieprasījumus uz

3:25 objektu krātuvi. Svarīgi, ka slodzes balansētāji veic aktīvās veselības pārbaudes. Ik pēc dažām sekundēm balansētājs pingā veselības galapunktu katrā instancē. Ja instance trīs reizes pēc kārtas izmet piecsimtās kļūdas vai nespēj atbildēt, tā tiek automātiski izņemta no pūla ar nulli nokritušu pieprasījumu.

- 03. Automātiskā mērogošana un elastība

3:45 Trešais koncepts: Automātiskā mērogošana. Ja jūsu tīmekļa lietojumprogrammai plkst. trīs no rīta ir nepieciešami divi serveri, bet divdesmit serveri dienas vidus palaišanas laikā, manuāla pogu klikšķināšana mākoņa konsolē garantē dīkstāvi un bankrotu. Automātiskā mērogošana nodrošina dinamisku elastību horizontālajiem serveru pulkiem. Automātiskās mērogošanas grupa uzrauga veiktspējas rādītājus, piemēram, vidējo CPU izmantošanu, tīkla I/O vai rindas atpalicības dziļumu. Kad vidējā CPU izmantošana pārsniedz noteiktu slieksni — teiksim,

4:19 septiņdesmit procentus trīs minūtes pēc kārtas — automātiskais mērogotājs automātiski palaiž jaunas virtuālās mašīnas, reģistrē tās jūsu slodzes balansētājā, un sāk maršrutēt trafiku. Tikpat svarīga ir mērogošana: kad trafika vilnis atkāpjas, automātiskais mērogotājs izbeidz liekās instances, lai jūs pārtrauktu maksāt par tukšgaitas resursiem. Lai novērstu flaping (kur serveri tiek ātri izveidoti un iznīcināti bezgalīgā cīņas cilpā), mākoņa arhitekti konfigurē atdzišanas periodus. Ceturtais koncepts: Serverless.

- 04. Bezserveru (FaaS un Firecracker MicroVM)

4:53 Gadiem ilgi mārketinga komandas reklamēja serverless kā burvju kodu, kas darbojas debesīs. Realitātē serverless joprojām izmanto serverus — bet jūs tos nepiederat, nepaielāpojat vai nemaksājat par tiem, kad kods nedarbojas. Ar Funkciju kā pakalpojumu (FaaS), piemēram, AWS Lambda vai Google Cloud Functions, jūs rakstāt atsevišķu apstrādātāja funkciju. Kad notiek HTTP pieprasījums, S3 failu augšupielāde vai datu bāzes izmaiņas, mākoņa izpildlaiks palaiž īslaicīgu

5:23 mikro-virtuālo mašīnu, piemēram, Firecracker, mazāk nekā piecās milisekundēs. Jūsu kods izpildās, atgriež atbildi un izslēdzas. Ja neviens neapmeklē jūsu vietni trīs mēnešus, jūsu skaitļošanas rēķins ir tieši nulle dolāru un nulle centu. Ja miljons lietotāju to apmeklē vienlaicīgi, pakalpojumu sniedzējs palaiž miljonu vienlaicīgu mikroVM. Inženiertehniskie kompromisi ir reāli: aukstās palaišanas latentums, palaižot svaigus izpildlaikus, stingrs piecpadsmit minūšu izpildes ierobežojums Lambda un stingra bezvalstiskums.

5:55 Serverless ir nepārspējams notikumu cauruļvadiem un sporādiskiem API, bet slikts ilgstošām WebSockets vai vairāku stundu apmācību sesijām.

- 05. Notikumu vadīta arhitektūra (EDA un atsaiste)

6:05 Piektais koncepts: Notikumu virzīta arhitektūra jeb EDA. Tradicionālajās arhitektūrās pakalpojumi sazinās sinhroni. Jūsu norēķinu pakalpojums izsauc maksājumu, maksājums izsauc inventāru, inventārs izsauc krāpšanu, un krāpšana izsauc e-pastu. Tas rada sinhronu liktenīgo kaskādi. Ja trešās puses e-pasta pakalpojumu sniedzējs piedzīvo tīkla kļūmi un atbild desmit sekundes, jūsu klienta viss norēķinu pieprasījums beidzas ar laika limitu un kļūdu. Notikumu virzītā arhitektūrā pakalpojumi ir pilnībā atsaistīti.

6:37 Kad klients noklikšķina uz pirkt, norēķinu pakalpojums neizsauc pakalpojumus tālāk. Tas vienkārši publicē notikumu ar nosaukumu OrderPlaced uz centrālo Notikumu kopni, piemēram, Amazon EventBridge vai SNS tēmu. Norēķini tiek pabeigti piecdesmit milisekundēs. Pakalpojumi maksājumiem, krājumu samazināšanai un e-pasta kvītīm neatkarīgi izgūst ziņojumus no savām īpašajām SQS rindām. Ja e-pasta pakalpojums nedarbojas stundu, ziņojumi droši gaida buferēti rindā bez neviena pazaudēta pasūtījuma.

- 06. Konteineru orķestrēšana (Docker un Kubernetes)

7:13 Sestais koncepts: Konteineru orķestrēšana. Docker atrisināja iepakojumu: tas aptver jūsu lietojumprogrammas kodu, sistēmas bibliotēkas, konfigurāciju un izpildlaiku nemainīgā attēlā, kas identiski darbojas jūsu MacBook un mākonī. Bet konteinera iepakošana ir viegla. Piecsimt konteineru darbība piecdesmit fiziskās virtuālajās mašīnās ir tas, kur inženierija sabrūk. Tāpēc pastāv konteineru orķestratori, piemēram, Kubernetes un AWS ECS.

7:41 Orķestrators nodrošina vadības plakni: API serveri, etcd stāvokļa krātuvi un inteliģentu plānotāju. Jūs deklarējat vēlamo stāvokli: es vēlos desmit sava autentifikācijas pakalpojuma replikas ar diviem gigabaitiem RAM katrai. Plānotājs pārbauda klasteri, novieto podus uz mezgliem ar brīvu atmiņu, konfigurē iekšējo tīklošanu un nepārtraukti saskaņo realitāti. Ja mezgls cieš aparatūras kļūmi, Kubernetes atklāj zudumu un nekavējoties pārsūta visus pārvietotos podus uz

- 07. 4 mākoņa krātuves pīlāri (S3, EBS, DBs un Redis)

8:16 veselīgiem mezgliem. Septītais koncepts: Mākoņa krātuves hierarhija. Iesācēji bieži uztver mākoņa krātuvi kā vienu spaini, kurā izmet failus. Ražošanas arhitektūrā krātuve ir sadalīta četros atšķirīgos pīlāros, pamatojoties uz piekļuves modeļiem un latentumu. Pirmā ir Objekta krātuve, piemēram, Amazon S3 vai Google Cloud Storage. Failiem piekļūstat, izmantojot HTTP REST API, izmantojot vienkāršus PUT un GET izsaukumus. Tā piedāvā bezgalīgu horizontālo ietilpību par diviem centiem par gigabaitu mēnesī,

8:49 padarot to ideāli piemērotu video, lietotāju augšupielādēm, žurnāliem un dublējumkopijām. Otrā ir Bloķētā krātuve, piemēram, Amazon EBS. Tie ir virtuālie cietie diski, kas tieši pieslēgti konkrētai virtuālajai mašīnai ar ātrgaitas savienojumiem. Tie formatējas standarta failu sistēmās, piemēram, ext4, atbalstot ātru nejaušu lasīšanas un rakstīšanas piekļuvi, ko pieprasa datu bāzes dzinēji. Trešās ir Pārvaldītās datu bāzes: relāciju dzinēji, piemēram, PostgreSQL RDS, kas nodrošina ACID transakcijas un sarežģītus savienojumus,

9:21 un NoSQL dzinēji, piemēram, DynamoDB, kas nodrošina viena cipara milisekundes latentumu masīvā mērogā. Un ceturtās ir Atmiņas kešatmiņas, piemēram, Redis. Datu lasīšana no RAM aizņem mikrosekundes, nevis milisekundes. Kešatmiņas atrodas jūsu datu bāzes priekšā, pasargājot to no atkārtotas lasīšanas trafika un pārvaldot gaistošus lietotāju sesiju žetonus.

- 08. Augsta pieejamība un deviņas (Multi-AZ pārslēgšanās)

9:44 Astotais koncepts: Augsta pieejamība jeb HA. Pieejamība atbild uz vienu jautājumu: kāds procents laika jūsu lietojumprogramma ir funkcionāla un pieejama lietotājiem? Uzņēmumu līgumos pieejamība tiek mērīta deviņos. Divi deviņi jeb deviņdesmit deviņu procentu pieejamība pieļauj vairāk nekā trīs ar pusi dienas dīkstāves katru gadu. Četri deviņi samazina pieļaujamo dīkstāvi līdz piecdesmit divām minūtēm, un pieci deviņi pieļauj knapi piecas minūtes kopējās dīkstāves gadā.

10:15 Lai panāktu augstu pieejamību, jums jānovērš vieni kļūmes punkti pār bojājumu domēniem. Mākonī tas nozīmē izvietošanu vairākās pieejamības zonās. Pieejamības zona nav viens plaukts: tā ir viens vai vairāki atšķirīgi fiziskie datu centri, kas atrodas jūdzes attālumā, ar neatkarīgu jaudu un dzesēšanu. Darbinot aktīvas instances A zonā un B zonā ar sinhronu datu bāzes replikāciju, zibens spēriens vai optiskā kabeļa pārrāvums, kas izraisa visa fiziskā objekta sabrukumu, rezultātā notiek automātiska pārslēgšanās

10:50 trīsdesmit sekundēs bez cilvēka iejaukšanās.

- 09. Izturība pret pieejamību (kāpēc 11 deviņi nav darbspējas laiks)

10:53 Devītais koncepts: Noturība pret pieejamību. Šīs ir visbiežāk sastopamās konceptuālās lamatas mākoņarhitektūras intervijās. Inženieri bieži lieto vārdus savstarpēji aizstājami, bet tie mēra pilnīgi atšķirīgas īpašības. Pieejamība mēra darbības laiku: vai es varu veikt API izsaukumu, lai lasītu vai rakstītu savus datus tieši šajā sekundē? Noturība mēra saglabāšanu: vai mani dati izdzīvos bez pastāvīgas bitu bojāšanās, korupcijas vai iznīcināšanas desmit gadu laikā?

11:24 Apskatiet Amazon S3 Standard. Tās pakalpojumu līmeņa līgums piedāvā deviņdesmit deviņus komats deviņus procentus pieejamības, kas pieļauj aptuveni četrdesmit trīs minūtes dīkstāves katru mēnesi kur API pieprasījums var atgriezt piecsimt kļūdu. Bet S3 sola vienpadsmit deviņniekus noturības: deviņdesmit deviņi komats deviņi deviņi deviņi deviņi deviņi deviņi deviņi deviņi deviņi procenti. Ja jūs S3 glabājat desmit miljonus failu, statistiski varat sagaidīt, ka zaudēsiet vidēji

11:56 vienu failu ik pēc desmit tūkstošiem gadu. S3 to panāk, izmantojot dzēšanas kodēšanas objektus un replicējot segmentus vismaz trīs ģeogrāfiski atdalītās datu iekārtās. Liela reģionāla tīkla pārtraukuma laikā S3 var īslaicīgi nebūt pieejams, bet jūsu dati nekad netiek iznīcināti.

- 10. Infrastruktūra kā kods (Terraform pret konsoles nobīdi)

12:14 Desmitais koncepts: Infrastruktūra kā kods, jeb IaC. Mākoņdatošanas pirmsākumos inženieri pieslēdzās AWS tīmekļa pārvaldības konsolei un manuāli klikšķināja, lai izveidotu virtuālās mašīnas, konfigurētu apakštīklus un pievienotu drošības grupas. Nozare to sauc par ClickOps, un ražošanā tas ir absolūta katastrofa. Manuālām konsoles izmaiņām nav audita pierakstu, nav atgriešanas mehānisma un tās neizbēgami izraisa konfigurācijas novirzes starp testēšanas un ražošanas vidēm. Izmantojot Infrastruktūru

12:48 kā koda rīkus, piemēram, Terraform, OpenTofu, Pulumi vai AWS CDK, jūs definējat savu pilnīgo mākoņarhitektūru deklaratīvos konfigurācijas failos, kas glabājas Git. Katra atvērta porta vai datu bāzes replikas izmaiņa notiek, izmantojot pull pieprasījumu un kolēģu pārbaudi. Veicot terraform plan, tiek parādīts precīzs API diff pirms jebkas tiek mainīts, un identiskas jūsu ražošanas sistēmas replikas izveide aizņem četras minūtes, nevis četras nedēļas.

- 11. Mākoņa tīklošana (VPC, apakštīkli, NAT un drošības grupas)

13:20 Vienpadsmitais koncepts: Mākoņu tīklošana un virtuālie privātie mākoņi. Kad jūs izvietojat serverus mākonī, tie nav pakļauti neapstrādātam publiskajam internetam. Tie atrodas programmatūriski definētā izolētā robežā ko sauc par VPC. Jūsu VPC ietvaros jūs piešķirat privātu IP adrešu telpu, piemēram, desmit-punkts-nulle-punkts-nulle-punkts-nulle slīpsvītra sešpadsmit, un sadalāt to publiskos un privātos apakštīklos. Publiskajam apakštīklam ir tiešs maršruts uz interneta vārteju.

13:51 Tas satur publiskos aktīvus, piemēram, jūsu lietojumprogrammu slodzes balansētājus un NAT vārtejas. Tā ir vienīgā jūsu tīkla daļa, kurai ir publiskas IP adreses. Jūsu lietojumprogrammu serveri un ražošanas datu bāzes atrodas stingri privātos apakštīklos bez publiskām IP adresēm un bez ienākošiem maršrutiem no interneta. Kad jūsu aizmugures serveriem ir jālejupielādē drošības atjauninājumi, to izejošā trafika tiek maršrutēta caur NAT vārteju publiskajā apakštīklā. Ap katru instanci ir drošības grupas: stāvoklī uzturoši virtuālie ugunsmūri, kas nodrošina vismazāko privilēģiju principu.

- 12. Pilnīgs uzņēmuma plāns un spriedums

14:28 Jūsu datu bāzes drošības grupa pieņem savienojumus tikai portā 5432 tikai no jūsu lietojumprogrammu serveru drošības grupas, padarot ārēju iekļūšanu matemātiski neiespējamu. Kad jūs palielināt, šie vienpadsmit primitīvi savienojas vienā saskaņotā sistēmā. Jūsu DNS maršruti uz slodzes balansētāju publiskā apakštīklā, automātiskās mērogošanas grupas apstrādā trafika pieaugumus vairākās pieejamības zonās, notikumu kopnes atdala aizmugures procesus, un visa jūsu sistēma ir izvietota no Git, izmantojot Infrastruktūru kā kodu.

15:02 Šodienas meistarklases verdikts: SHIP IT. Pārtrauciet iegaumēt simtiem mākoņdatošanas mārketinga akronīmu. Apgūstiet šos vienpadsmit arhitektūras modeļus, atdaliet savu stāvokli, un veidojiet sistēmas, kas nevar sabojāties. Pastāstiet man, kurš mākoņdatošanas koncepts jums sagādāja vislielākās galvassāpes, kad jūs pirmo reizi sākāt veidot komentāros. Un, lai iegūtu pilnīgu arhitektūras "špikeru", abonējiet biļetenu the daily diff dot dev,

15:28 saite zemāk. Un tas ir viss par šodienu. Esmu Niko no Axrisi. Apvienojiet atbildīgi.

Avoti

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