Cloud computing azalpena: jakin beharreko 11 arkitektura-kontzeptuak (4K Masterclass).

Bideo honek zer jorratzen duen

• - Arkitekturaren Harresia eta Plano Nagusia
• - 01. Eskalatze Bertikala vs. Horizontala
• - 02. Karga-balantzearen Arkitektura (L4 vs. L7 eta Osasun Egiaztapenak)
• - 03. Autoskalatzea eta Elastikotasuna
• - 04. Serverless (FaaS eta Firecracker MicroVM-ak)

Itzulitako transkripzioa

Jatorrizko ingelesezko narraziotik itzulia. Eskuragarri dauden audioa eta azpitituluak YouTube-k kontrolatzen ditu.

- Arkitekturaren Harresia eta Plano Nagusia

0:00 Software-ingeniari orok, azkenean, hodeiko arkitekturaren hormari aurre egiten dio. Aplikazio bat eraikitzen duzu zure ordenagailu eramangarrian, produkziora igotzen duzu, eta benetako erabiltzaileak iristen diren unean, zerbitzariak erori egiten dira, datu-basearen konexioak agortzen dira, eta zure AWS faktura telefono-zenbaki bat dirudi. Garatzaile gehienak hodeiko ingeniaritza konpontzen saiatzen dira hirurehun AWS produktu-akronimo desberdin memorizatuz. Baina benetako hodeiko konputazioa ez da saltzaile-katalogoak memorizatzea: hamaika primitibo arkitektoniko funtsezkoetan eraikita dago.

0:34 Masterclass honetan, enpresaren plano osoa aztertuko dugu: eskalatzetik eta karga-balantzetik hasi eta serverless-era, gertaeren araberako deskonexiora, biltegiratze-hierarkietara eta hodeiko sareetara. Hamaika kontzeptu hauek menperatuta, edozein backend diseinatu dezakezu AWSn, GCPn edo Azuren. Hau The Daily Diff da, azpian.

- 01. Eskalatze Bertikala vs. Horizontala

0:57 Lehenengo kontzeptua: Eskalatzea. Zure aplikazioak trafiko hazkundea jasaten duenean, karga kudeatzeko bi modu guztiz desberdin dituzu: eskalatze bertikala edo eskalatze horizontala. Eskalatze bertikalak, edo gorantz eskalatzeak, zure lehendik dagoen makina hartu eta baliabide gehiago gehitzea esan nahi du: lau CPU koretik hogeita hamabi koretara igotzea, edo hogeita hamabi gigabyte RAM ehun eta hogeita zortzirengatik trukatzea. Eskalatze bertikalak zero arkitektura-aldaketa behar ditu: zure kodea

1:28 eta datu-basea berdin-berdin geratzen dira. Baina hardware sabai gogor bat topatzen du. Munduko makina bakar batek ere ez ditu hamar mila CPU-korerik, eta goi-mailako instantziek prezio gehigarri esponentziala dute. Eskalatze horizontalak, edo kanporantz eskalatzeak, zure zerbitzariak txiki eta merke mantentzea esan nahi du, baina instantzia anitz paraleloan exekutatzea bideratzaile baten atzean. Instantzia bat erortzen bada, gainerako nodoek trafikoa xurgatzen dute, geldialdirik gabe. Eskalatze horizontalaren urrezko araua

2:01 egoerarik gabekoa izatea da: zure aplikazio-zerbitzariek ezin dituzte erabiltzaile-saioak, igotako fitxategiak edo egoera disko lokaletan gorde. Egoerak kanpoko datu-base batean edo cache batean bizi behar du, nodo orok edozein erabiltzaile-eskaera kudeatu ahal izateko.

- 02. Karga-balantzearen Arkitektura (L4 vs. L7 eta Osasun Egiaztapenak)

2:17 Bigarren kontzeptua: Karga-balantzea. Eskalatze horizontala paper gainean oso ondo dirudi, baina berehala arazo bat sortzen du: hamar mila erabiltzailek zure domeinu-izena jotzen dutenean, zein zerbitzarik jasotzen du bere trafikoa? Karga-balantzeak alderantzizko proxy gisa jokatzen du, internet publikoaren eta zure backend pribatuko klusterraren artean kokatuta. Sarrerako TCP edo HTTP konexioak onartzen ditu eta eskaerak banatzen ditu zure instantzia osasuntsuen artean.

2:47 Karga-balantzeak bi sare-geruza nagusitan funtzionatzen dute. Layer 4 Network Load Balancers garraio-geruzan funtzionatzen dute, TCP eta UDP pakete gordinak bideratuz IP helbidearen eta portuaren arabera mikrosegundo atzerapenarekin eta milioika eskaerekin segundoko. Layer 7 Application Load Balancers HTTP protokoloa berriz ikuskatzen dute: URL bideak, eskaera-goiburuak, cookieak eta HTTP metodoak irakurriz. Honek bidearen araberako bideraketa ahalbidetzen du: slash-api eskaerak zure backend klusterrera bidaliz eta slash-static eskaerak

3:25 objektu-biltegi batera. Funtsean, karga-balantzeek osasun-egiaztapen aktiboak egiten dituzte. Zenbait segundoro, balantzeak osasun-puntu bat pingatzen du instantzia bakoitzean. Instantzia batek hiru bostehun errore jarraian ematen baditu edo ez badu erantzuten, automatikoki kendu egiten da multzotik, zero eskaera galduz.

- 03. Autoskalatzea eta Elastikotasuna

3:45 Hirugarren kontzeptua: Autoskalatzea. Zure web-aplikazioak goizeko hiruretan bi zerbitzari behar baditu, baina eguerdiko abian hogei zerbitzari, botoiak eskuz klikatzea hodeiko kontsolan geldialdia eta porrotaren bide ziurra da. Autoskalatzeak elastikotasun dinamikoa ematen die zerbitzari-multzo horizontalari. Auto Scaling Group batek errendimendu-metrikak monitorizatzen ditu, hala nola batez besteko CPU erabilera, sareko I/O edo ilara atzerapenaren sakonera. Batez besteko CPUk definitutako atalase bat gainditzen duenean —esaterako,

4:19 ehuneko hirurogeita hamar hiru minutu jarraian—, autoskalatzaileak automatikoki makina birtual berriak abiarazten ditu, zure karga-balantzailean erregistratzen ditu, eta trafikoa bideratzen hasten da. Berpiztea bezain garrantzitsua da: trafiko-uhina atzera egiten duenean, autoskalatzaileak gehiegizko instantziak amaitzen ditu, beraz, ez duzu gehiago ordaintzen konputazio geldiarengatik. "Flapping"a saihesteko —zerbitzariak azkar sortu eta suntsitzen diren thrashing begizta amaigabe batean—, hodeiko arkitektoek hoztze-aldiak konfiguratzen dituzte. Laugarren kontzeptua: Serverless.

- 04. Serverless (FaaS eta Firecracker MicroVM-ak)

4:53 Urte luzez, marketin-taldeek serverless "magia-kode" gisa saldu zuten, zeruan exekutatzen dena. Errealitatean, serverless-ek zerbitzariak erabiltzen ditu oraindik —baina ez dituzu zureak, ez dituzu adabakitzen, ezta ordaintzen ere koderik exekutatzen ez denean. Function-as-a-Service zerbitzuekin, AWS Lambda edo Google Cloud Functions bezalakoekin, handler funtzio autonomo bat idazten duzu. HTTP eskaera bat, S3 fitxategi kargatze bat edo datu-base aldaketa bat gertatzen denean, hodeiko exekuzio-inguruneak iragankor bat abiarazten du,

5:23 Firecracker bezalako mikro-makina birtual bat bost milisegundo baino gutxiagotan. Zure kodea exekutatzen da, erantzun bat itzultzen du eta itzali egiten da. Hiru hilabetez inork ez badu zure webgunea bisitatzen, zure konputazio-faktura zehazki zero dolar eta zero zentimo izango da. Milioi bat erabiltzailek aldi berean jotzen badute, hornitzaileak milioi bat mikroVM batera exekutatzen ditu. Ingeniaritza-trukeak errealak dira: hotz-hasierako latentzia exekuzio-ingurune freskoak abiaraztean, hamabost minutuko exekuzio-muga gogor bat Lambdan, eta egoerarik gabekotasun zorrotza.

5:55 Serverless gaindiezina da gertaera-hodi eta API bakanetarako, baina eskasa WebSockets iraunkorretarako edo ordu anitzeko entrenamendu-exekuzioetarako.

- 05. Gertaeren Araberako Arkitektura (EDA eta Deskonexioa)

6:05 Bosgarren kontzeptua: Gertaeren Araberako Arkitektura, edo EDA. Arkitektura tradizionaletan, zerbitzuek sinkronoki komunikatzen dira. Zure checkout-zerbitzuak ordainketa deitzen du, ordainketak inbentarioari, inbentarioak iruzurrari, eta iruzurrak posta elektronikoari. Honek kondenaren kaskada sinkronoa sortzen du. Hirugarrenen posta-zerbitzuak sare-etenaldi bat jasaten badu eta hamar segundo behar baditu erantzuteko, zure bezeroaren checkout eskaera osoa denbora-mugaz gainditzen da errore batekin. Gertaeren araberako arkitektura batean, zerbitzuak erabat deskonektatuta daude.

6:37 Bezero batek erosteko botoian klik egiten duenean, checkout-zerbitzuak ez ditu beherako zerbitzuak deitzen. Besterik gabe, OrderPlaced izeneko gertaera bat argitaratzen du zentral batera, Event Bus bat, Amazon EventBridge edo SNS gai bat bezalakoa. Checkout-a berrogeita hamar milisegundotan amaitzen da. Ordainketa, inbentario-kenketa eta posta elektronikoko ordainagirietarako beherako lanek mezuak modu independentean jasotzen dituzte beren SQS ilara dedikatuetatik. Posta elektronikoko zerbitzua ordu batez erori egiten bada, mezuak segurtasunez zain egongo dira ilaran buferrean, eskaera bakar bat ere galdu gabe.

- 06. Edukiontzien Orkestrazioa (Docker eta Kubernetes)

7:13 Seigarren kontzeptua: Edukiontzien Orkestrazioa. Docker-ek ontziratzea ebatzi zuen: zure aplikazio-kodea, sistemako liburutegiak, konfigurazioa eta exekuzio-ingurunea irudi aldaezin batean biltzen ditu, zure MacBook-en eta hodeian berdin exekutatzen dena. Baina edukiontzi bat ontziratzea erraza da. Bostehun edukiontzi berrogeita hamar makina birtual fisikoetan exekutatzea da ingeniaritza hautsi egiten den lekua. Horregatik existitzen dira Kubernetes eta AWS ECS bezalako edukiontzien orkestratzaileak.

7:41 Orkestratzaile batek kontrol-panel bat eskaintzen du: API zerbitzari bat, etcd egoera-biltegi bat eta planifikatzaile adimendun bat. Nahi duzun egoera deklaratzen duzu: nire auth zerbitzuaren hamar kopia nahi ditut bi gigabyte RAM bakoitzeko. Planifikatzaileak klusterra ikuskatzen du, podak memoria libreko nodoetan kokatzen ditu, barneko sarea konfiguratzen du eta errealitatea etengabe bateratzen du. Nodo batek hardware-matxura bat jasaten badu, Kubernetesek galera detektatzen du eta berehala birprogramatzen ditu lekualdatutako pod guztiak

- 07. Hodeiko Biltegiratzearen 4 Zutabeak (S3, EBS, DBak eta Redis)

8:16 nodo osasuntsuetara. Zazpigarren kontzeptua: Hodeiko Biltegiratze Hierarkia. Hasiberriek sarri hodeiko biltegiratzea fitxategiak botatzeko ontzi bakar gisa tratatzen dute. Produkzio-arkitekturan, biltegiratzea lau zutabe desberdinetan banatzen da sarbide-ereduen eta latentziaren arabera. Lehenengoa Objektuen Biltegiratzea da, Amazon S3 edo Google Cloud Storage bezalakoa. Fitxategiak HTTP REST APIen bidez sartzen dituzu PUT eta GET dei sinpleak erabiliz. Edukiera horizontal infinitua eskaintzen du, bi zentimo gigabyte bakoitzeko hilero,

8:49 bideoak, erabiltzaile-kargak, logak eta babeskopiak egiteko aproposa bihurtuz. Bigarrena Bloke Biltegiratzea da, Amazon EBS bezalakoa. Hauek disko gogor birtualak dira, zuzenean makina birtual zehatz bati muntatuta abiadura handiko interkonexioen bidez. ext4 bezalako fitxategi-sistema estandarretan formateatzen dira, datu-base-motorrek eskatzen duten irakurketa eta idazketa sarbide azkarra onartuz. Hirugarrenak Datu-base Kudeatuak dira: PostgreSQL bezalako motor erlazionalak RDSn, ACID transakzioak eta lotura konplexuak eskaintzen dituztenak,

9:21 eta DynamoDB bezalako NoSQL motorrak, zifra bakarreko milisegundoko latentzia eskaintzen dutenak eskala masiboan. Eta laugarrenak In-Memory Cacheak dira, Redis bezalakoak. RAMetik datuak irakurtzeak mikrosegundoak behar ditu milisegundoen ordez. Cacheak zure datu-basearen aurrean kokatzen dira, errepikatutako irakurketa-trafikotik babestuz eta erabiltzaile-saio-token hegazkorrak kudeatuz.

- 08. Erabilgarritasun Handia eta Bederatzi Maila (Multi-AZ Failover)

9:44 Zortzigarren kontzeptua: Erabilgarritasun handia, edo HA. Erabilgarritasunak galdera bakar bati erantzuten dio: zein ehunekotan dago zure aplikazioa operatibo eta erabiltzaileen eskura? Enpresa-kontratuetan, erabilgarritasuna "nines"-etan neurtzen da. Bi "nines", edo ehuneko laurogeita hemeretzi erabilgarritasuna, hiru eta erdi egun baino gehiago geldialdi onartzen ditu urtean. Lau "nines"-ek onartutako geldialdia berrogeita hamabi minutura jaisten du, eta bost "nines"-ek bost minutu eskas geldialdi osoa onartzen du

10:15 urtean. Erabilgarritasun handia lortzeko, hutsegite-puntu bakarrak ezabatu behar dituzu matxura-domeinuetan zehar. Hodeian, horrek esan nahi du erabilgarritasun-zona anitzetan zabaltzea. Erabilgarritasun-zona ez da rack bakar bat: bat edo gehiago daude, diferenteak, milia batzuk banatuta, energia eta hozte independenteekin. A eta B zonetan instantzia aktiboak exekutatuz datu-basearen erreplikazio sinkronoarekin, instalazio fisiko oso bat erortzen duen tximista edo zuntz-ebaki batek failover automatikoa eragiten du.

10:50 hogeita hamar segundotan giza esku-hartzerik gabe.

- 09. Iraunkortasuna vs. Erabilgarritasuna (Zergatik 11 Bederatzi Ez den Funtzionamendu Denbora)

10:53 Bederatzigarren kontzeptua: Iraunkortasuna versus erabilgarritasuna. Hau da hodeiko arkitekturako tranpa kontzeptual ohikoena elkarrizketetan. Ingeniariek maiz erabiltzen dituzte hitzak trukagarri, baina propietate guztiz desberdinak neurtzen dituzte. Erabilgarritasunak funtzionamendu-denbora neurtzen du: API dei bat egin dezaket nire datuak irakurtzeko edo idazteko une honetan bertan? Iraunkortasunak kontserbazioa neurtzen du: nire datuek bizirik iraungo al dute hamar urtetan zehar, bit rot, ustelkeria edo suntsipen iraunkorrik gabe? bit usteldura, ustelkeria edo suntsipen iraunkorrik gabe hamar urtean?

11:24 Begira Amazon S3 Standard-era. Bere Zerbitzu Mailako Akordioak ehuneko laurogeita hemeretzi puntu bederatzi erabilgarritasuna eskaintzen du, eta horrek hilean berrogeita hiru minutu inguruko etenaldiak ahalbidetzen ditu non API eskaera batek bostehun errore bat itzul dezakeen. Baina S3-k hamaika bederatziko iraunkortasuna agintzen du: laurogeita hemeretzi puntu bederatzi bederatzi bederatzi bederatzi bederatzi bederatzi bederatzi bederatzi bederatzi ehuneko. Hamar milioi fitxategi S3-n gordetzen badituzu, estatistikoki espero dezakezu fitxategi bat galtzea

11:56 batez beste hamar mila urtean behin. S3-k hau lortzen du objektuak ezabaketa-kodeatuz eta zatiak hedatuz, gutxienez hiru datu-instalazio geografikoki bereizitan. gutxienez hiru datu-instalazio geografikoki banatutan. Eskualdeko sare-etenaldi garrantzitsu batean, S3 aldi baterako ezin erabilgarri egon liteke, baina zure datuak ez dira inoiz suntsitzen.

- 10. Azpiegitura Kode Gisa (Terraform vs. Kontsola Aldaketa)

12:14 Hamarren kontzeptua: Azpiegitura Kode gisa, edo IaC. Hodeiko informatika-garaiaren hasieran, ingeniariek AWS-ko saioa hasi zuten web kudeaketa kontsolan eta eskuz klik egin zuten makina birtualak sortzeko, azpisareak konfiguratzeko eta segurtasun-taldeak eransteko. Industrian ClickOps deitzen diote, eta produkzioan erabateko hondamendia da. Eskuzko kontsola-aldaketek ez dute auditoretza-arrastorik, ez dute atzera egiteko mekanismorik, eta ezinbestean konfigurazio-desoreka eragiten dute proba- eta produkzio-inguruneen artean. Azpiegitura

12:48 Kode gisa tresnekin, Terraform bezalakoekin, OpenTofu, Pulumi edo AWS CDK-rekin, zure hodeiko arkitektura osoa fitxategi konfigurazio deklaratiboetan definitzen duzu Git-en gordeta. hodeiko arkitektura osoa Git-en gordetako konfigurazio-fitxategi deklaratiboetan definitzen duzu. Ataka ireki baten edo datu-basearen erreplika baten aldaketa guztiak pull request baten eta parekoen berrikuspen baten bidez pasatzen da. Terraform plan exekutatzeak APIaren diff zehatza aurreikusten du ezer ukitu baino lehen, eta zure produkzio-pila baten erreplika berdin bat abiarazteak lau minutu hartzen ditu lau aste ordez.

- 11. Hodeiko Sarea (VPC, Azpisareak, NAT eta Segurtasun Taldeak)

13:20 Hamaikagarren kontzeptua: Hodeiko Sareak eta Hodei Pribatu Birtualak. Zerbitzariak hodeian zabaltzen dituzunean, ez dira Internet publiko gordinaren aurrean agertzen. VPC izeneko software bidez definitutako muga isolatu baten barruan bizi dira. VPC izeneko muga isolatu baten barruan bizi dira. Zure VPC barruan, IP helbide pribatuen espazio bat esleitzen duzu, hala nola hamar-puntu-zero-puntu-zero-puntu-zero barra hamasei, eta azpisare publiko eta pribatuetan banatzen duzu. Azpisare publiko batek Internet Gateway-rako zuzeneko bide bat du.

13:51 Jendaurreko aktiboak ditu, hala nola zure Aplikazio Karga Banatzaileak eta NAT Gateway-ak. Zure sareko atal bakarra da IP publikoak dituenak. Zure aplikazio-zerbitzariak eta produkzio-datu-baseak azpisare pribatuetan bizi dira, IP publikorik gabe eta Internetetik zero sarrerako biderik gabe. internetetik zero sarrerako biderik gabe. Zure backend zerbitzariek segurtasun eguneraketak deskargatu behar dituztenean, internetetik zero sarrerako biderik gabe. Zure backend zerbitzariek segurtasun-eguneraketak deskargatu behar dituztenean, beren irteerako trafikoa NAT Gateway bidez bideratzen da azpisare publikoan. azpisare publikoan. Instantzia bakoitzaren inguruan Segurtasun Taldeak daude: egoerazko suhesi birtualak, pribilegio minimoaren printzipioa betearazten dutenak.

- 12. Enpresaren Plano Osoa eta Epaia

14:28 Zure datu-basearen segurtasun-taldeak 5432 portuko konexioak bakarrik onartzen ditu 5432 portuan, soilik zure aplikazio-zerbitzarien segurtasun-taldekoak, kanpoko sarrera matematikoki ezinezko bihurtuz. Urrunduz gero, hamaika primitibo hauek sistema koherente batean lotzen dira. Zure DNS-ak karga-banatzaile batera bideratzen du azpisare publiko batean, eskala automatikoko taldeek trafiko-goraketak kudeatzen dituzte Erabilgarritasun-Gune anitzetan zehar, gertaeren bus-ek backend-eko langileak desakoplatzen dituzte, eta zure pila osoa Git-etik zabaltzen da Azpiegitura Kode gisa erabiliz.

15:02 Gaurko masterclass-aren epaia: SHIP IT. Utzi hodeiko marketin-akronimo ehunka buruz ikasteari. Menderatu hamaika arkitektura-eredu hauek, desakoplatu zure egoera, eta eraiki huts egin ezin duten sistemak. Esadazu zein hodeiko kontzeptuk eman zizun buruko minik handiena lehen aldiz hasten zinenean iruzkinetan eraikitzen. Eta arkitektura-tranpa-orri osoa lortzeko, harpidetu The Daily Diff.dev-eko buletinera,

15:28 esteka behean. Eta hori da gaurko diff-a. Niko naiz, Axrisi-koa. Batu arduraz.

Iturriak

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