Vysvětlení cloud computingu: 11 architektonických konceptů, které musíte znát (4K Masterclass).

Co toto video pokrývá

• - Architektonická stěna a hlavní plán
• - 01. Vertikální vs. horizontální škálování
• - 02. Architektura vyrovnávání zátěže (L4 vs. L7 & kontroly stavu)
• - 03. Automatické škálování a elasticita
• - 04. Bezserverové (FaaS a Firecracker MicroVMs)

Přeložený přepis

Přeloženo z původního anglického vyprávění. Dostupné audio a titulky jsou řízeny YouTube.

- Architektonická stěna a hlavní plán

0:00 Každý softwarový inženýr se nakonec střetne se stěnou cloudové architektury. Sestavíte aplikaci na svém notebooku, nasadíte ji do produkce, a v okamžiku, kdy dorazí skuteční uživatelé, servery padají, databázová připojení se vyčerpají a váš účet za AWS vypadá jako telefonní číslo. Většina vývojářů se snaží řešit cloudové inženýrství zapamatováním si tří set různých akronymů produktů AWS. Ale skutečné cloud computing není o memorování katalogů prodejců: je postaveno na jedenácti základních architektonických primitivech.

0:34 V této masterclass projdeme celý podnikový plán: od škálování a vyrovnávání zátěže po bezserverové, událostmi řízené oddělení, hierarchie úložišť a cloudové sítě. Ovládněte těchto jedenáct konceptů a můžete navrhnout jakýkoli backend na AWS, GCP nebo Azure. Toto je The Daily Diff, pod kapotou.

- 01. Vertikální vs. Horizontální škálování

0:57 Koncept číslo jedna: Škálování. Když vaše aplikace zažívá nárůst provozu, máte dvě zásadně odlišné způsoby, jak zvládnout zátěž: vertikální škálování nebo horizontální škálování. Vertikální škálování, neboli škálování nahoru, znamená vzít váš stávající stroj a přidat více zdrojů: upgrade ze čtyř CPU jader na třicet dva, nebo výměnu třiceti dvou gigabajtů RAM za sto dvacet osm. Vertikální škálování nevyžaduje žádné architektonické změny: váš kód

1:28 a databáze zůstávají přesně stejné. Ale naráží na brutální hardwarový strop. Žádný jednotlivý stroj na světě nemá deset tisíc CPU jader, a špičkové instance nesou exponenciální cenovou prémii. Horizontální škálování, neboli škálování ven, znamená udržovat vaše servery malé a s komoditní cenou, ale spouštět více instancí paralelně za routerem. Pokud jedna instance spadne, zbývající uzly absorbují provoz s nulovou dobou výpadku. Zlaté pravidlo horizontálního škálování je

2:01 bezstavovost: vaše aplikační servery nemohou ukládat uživatelské relace, nahrané soubory nebo stav na své lokální disky. Stav musí žít v externí databázi nebo cache, což umožňuje jakémukoli uzlu zpracovat jakýkoli uživatelský požadavek.

- 02. Architektura vyrovnávání zátěže (L4 vs. L7 & kontroly stavu)

2:17 Koncept číslo dvě: Vyrovnávání zátěže. Horizontální škálování zní na papíře skvěle, ale zavádí okamžitý problém: když deset tisíc uživatelů navštíví vaše doménové jméno, který konkrétní server obdrží jejich provoz? Vyrovnávač zátěže funguje jako reverzní proxy sedící mezi veřejným internetem a vaším soukromým backendovým klastrem. Přijímá příchozí TCP nebo HTTP připojení a distribuuje požadavky napříč vašimi zdravými instancemi.

2:47 Vyrovnávače zátěže fungují na dvou primárních síťových vrstvách. Vyrovnávače síťové zátěže vrstvy 4 fungují na transportní vrstvě, směrují syrové TCP a UDP pakety na základě IP adresy a portu s mikrosekundovou latencí a miliony požadavků za sekundu. Vyrovnávače aplikační zátěže vrstvy 7 kontrolují samotný protokol HTTP: čtou cesty URL, hlavičky požadavků, soubory cookie a HTTP metody. To umožňuje směrování založené na cestě: odesílání požadavků na /api do vašeho backendového klastru a požadavků na /static do

3:25 objektového úložiště. Klíčové je, že vyrovnávače zátěže provádějí aktivní kontroly stavu. Každých několik sekund vyrovnávač pingne koncový bod stavu na každé instanci. Pokud instance vyhodí tři po sobě jdoucí chyby 500 nebo nereaguje, je automaticky odstraněna z fondu s nulovými zrušenými požadavky.

- 03. Automatické škálování a elasticita

3:45 Koncept číslo tři: Automatické škálování. Pokud vaše webová aplikace potřebuje dva servery ve tři ráno, ale dvacet serverů během poledního spuštění, ruční klikání na tlačítka v cloudové konzoli je zaručená cesta k výpadkům a bankrotu. Automatické škálování přináší dynamickou elasticitu do horizontálních serverových fondů. Skupina automatického škálování monitoruje výkonnostní metriky jako průměrné využití CPU, síťové I/O nebo hloubku fronty zálohy. Když průměrné CPU překročí definovanou prahovou hodnotu – řekněme,

4:19 sedmdesát procent po dobu tří po sobě jdoucích minut – automatický škálovatel automaticky spouští nové virtuální stroje, registruje je u vašeho vyrovnávače zátěže, a začíná směrovat provoz. Stejně důležité je škálování dolů: když vlna provozu ustoupí, automatický škálovatel ukončuje nadbytečné instance, takže přestanete platit za nečinný výpočet. Aby se zabránilo "flappingu" – kdy jsou servery rychle vytvářeny a ničeny v nekonečné smyčce přetížení – cloudoví architekti konfigurují období ochlazení. Koncept číslo čtyři: Bezserverové.

- 04. Bezserverové (FaaS a Firecracker MicroVMs)

4:53 Po léta marketingové týmy propagovaly bezserverové jako magický kód běžící v oblacích. Ve skutečnosti bezserverové stále používá servery – ale vy je nevlastníte, nepatchujete ani za ně neplatíte, když neběží žádný kód. S funkcí jako službou (Function-as-a-Service) jako AWS Lambda nebo Google Cloud Functions, napíšete samostatnou obslužnou funkci. Když dojde k HTTP požadavku, nahrání souboru S3 nebo změně v databázi, cloudové běhové prostředí spustí efemérní

5:23 mikro-virtuální stroj jako Firecracker za méně než pět milisekund. Váš kód se provede, vrátí odpověď a vypne se. Pokud nikdo nenavštíví váš web po dobu tří měsíců, váš účet za výpočet je přesně nula dolarů a nula centů. Pokud ho současně navštíví milion uživatelů, poskytovatel spustí milion současných mikro-VM. Inženýrské kompromisy jsou reálné: latence "studeného startu" při spouštění nových běhových prostředí, tvrdý patnáctiminutový limit provádění na Lambda a přísná bezstavovost.

5:55 Bezserverové je nepřekonatelné pro událostní potrubí a sporadické API, ale nevhodné pro perzistentní WebSockety nebo vícehodinové tréninkové běhy.

- 05. Architektura řízená událostmi (EDA & oddělení)

6:05 Koncept číslo pět: Architektura řízená událostmi, neboli EDA. V tradičních architekturách služby komunikují synchronně. Vaše platební služba volá platbu, platba volá inventář, inventář volá podvody a podvody volají e-mail. To vytváří synchronní kaskádu zkázy. Pokud třetí strana poskytovatele e-mailu zažije síťový zádrhel a trvá jí deset sekund, než odpoví, celý požadavek zákazníka na nákup vyprší s chybou. V architektuře řízené událostmi jsou služby zcela oddělené.

6:37 Když zákazník klikne na koupit, platební služba nevolá navazující služby. Jednoduše publikuje událost nazvanou OrderPlaced na centrální Event Bus jako Amazon EventBridge nebo téma SNS. Nákup se dokončí za padesát milisekund. Navazující pracovníci pro platby, odečty zásob a e-mailové účtenky stahují zprávy nezávisle ze svých vlastních vyhrazených front SQS. Pokud e-mailová služba spadne na hodinu, zprávy bezpečně čekají uložené ve frontě bez jediného zrušeného objednávky.

- 06. Orchestrace kontejnerů (Docker a Kubernetes)

7:13 Koncept číslo šest: Orchestrace kontejnerů. Docker vyřešil balení: zabalí váš aplikační kód, systémové knihovny, konfiguraci a běhové prostředí do neměnného obrazu, který běží identicky na vašem MacBooku i v cloudu. Ale zabalení kontejneru je snadné. Spuštění pěti set kontejnerů napříč padesáti fyzickými virtuálními stroji je tam, kde se inženýrství zhroutí. Proto existují orchestrátory kontejnerů jako Kubernetes a AWS ECS.

7:41 Orchestrátor poskytuje řídící rovinu: API server, úložiště stavu etcd a inteligentní plánovač. Deklarujete svůj požadovaný stav: Chci deset replik mé autentizační služby s dvěma gigabajty RAM každá. Plánovač kontroluje klastr, umisťuje pody na uzly s volnou pamětí, konfiguruje interní síť a neustále slaďuje realitu. Pokud uzel utrpí hardwarovou chybu, Kubernetes detekuje ztrátu a okamžitě přeplánuje všechny přemístěné pody na

- 07. 4 pilíře cloudového úložiště (S3, EBS, DBs & Redis)

8:16 zdravé uzly. Koncept číslo sedm: Hierarchie cloudového úložiště. Začátečníci často považují cloudové úložiště za jeden kbelík, kam "dumpujete" soubory. V produkční architektuře je úložiště rozděleno do čtyř odlišných pilířů na základě přístupových vzorů a latence. První je Object Storage, jako Amazon S3 nebo Google Cloud Storage. K souborům přistupujete přes HTTP REST API pomocí jednoduchých volání PUT a GET. Nabízí nekonečnou horizontální kapacitu za dva centy za gigabajt měsíčně,

8:49 což je ideální pro video, uživatelské nahrávky, logy a zálohy. Druhé je Block Storage, jako Amazon EBS. Jsou to virtuální pevné disky připojené přímo k specifickému virtuálnímu stroji přes vysokorychlostní propojení. Formátují se do standardních souborových systémů jako ext4, podporují rychlý náhodný přístup pro čtení a zápis, který vyžadují databázové enginy. Třetí jsou Managed Databases: relační enginy jako PostgreSQL na RDS poskytující ACID transakce a složité joiny,

9:21 a NoSQL enginy jako DynamoDB dodávající jednocifernou milisekundovou latenci v masivním měřítku. A čtvrté jsou In-Memory Caches jako Redis. Čtení dat z RAM trvá mikrosekundy namísto milisekund. Caches sedí před vaší databází, chrání ji před opakovaným čtecím provozem a spravují těkavé uživatelské session tokeny.

- 08. Vysoká dostupnost a devítky (Multi-AZ Failover)

9:44 Koncept číslo osm: Vysoká dostupnost, neboli HA. Dostupnost odpovídá na jednu otázku: jaké procento času je vaše aplikace funkční a dostupná pro uživatele? V podnikových smlouvách se dostupnost měří v devítkách. Dvě devítky, neboli devadesát devět procent dostupnosti, umožňuje přes tři a půl dne výpadků každý rok. Čtyři devítky snižují povolenou dobu výpadku na padesát dvě minuty, a pět devítek povoluje sotva pět minut celkové doby výpadku ročně.

10:15 K dosažení vysoké dostupnosti musíte eliminovat jednotlivé body selhání napříč doménami selhání. V cloudu to znamená nasazení napříč více zónami dostupnosti. Zóna dostupnosti není jediný rack: je to jedno nebo více odlišných fyzických datových center vzdálených míle od sebe s nezávislým napájením a chlazením. Spuštěním aktivních instancí v zóně A a zóně B se synchronní replikací databáze, úder blesku nebo přerušení vlákna, které vyřadí celé fyzické zařízení, vede k automatickému přepnutí na záložní systém.

10:50 za třicet sekund s nulovou lidskou intervencí.

- 09. Trvanlivost vs. Dostupnost (Proč 11 devítek není provozuschopnost)

10:53 Devátý koncept: Odolnost versus dostupnost. Toto je nejčastější koncepční past v rozhovorech o cloudové architektuře. Inženýři tato slova často používají zaměnitelně, ale měří zcela odlišné vlastnosti. Dostupnost měří dobu provozuschopnosti: mohu v tuto chvíli provést volání API pro čtení nebo zápis mých dat? Odolnost měří uchování: přežijí moje data bez trvalého poškození bitů, znehodnocení nebo zničení po dobu deseti let?

11:24 Podívejme se na Amazon S3 Standard. Jeho smlouva o úrovni služeb nabízí devadesát devět celých devět procent dostupnosti, což umožňuje zhruba čtyřicet tři minut prostojů každý měsíc, kdy požadavek API může vrátit chybu pět set. Ale S3 slibuje jedenáct devítek odolnosti: devadesát devět celých devět devět devět devět devět devět devět devět devět procent. Pokud uložíte deset milionů souborů v S3, můžete statisticky očekávat ztrátu jednoho

11:56 souboru každých deset tisíc let. S3 toho dosahuje kódováním objektů s opravou chyb a replikací částí napříč alespoň třemi geograficky oddělenými datovými centry. Během velkého regionálního výpadku sítě může být S3 dočasně nedostupný, ale vaše data nejsou nikdy zničena.

- 10. Infrastruktura jako kód (Terraform vs. Console Drift)

12:14 Desátý koncept: Infrastruktura jako kód, neboli IaC. V počátcích cloud computingu se inženýři přihlašovali do AWS webové konzole pro správu a ručně klikali, aby vytvořili virtuální stroje, nakonfigurovali podsítě a připojili bezpečnostní skupiny. V oboru se tomu říká ClickOps a v produkci je to naprostá katastrofa. Ruční změny v konzoli nemají auditní záznam, mechanismus pro vrácení zpět a nevyhnutelně způsobují konfiguraci drift mezi staging a produkčními prostředími. S nástroji Infrastructure

12:48 as Code, jako je Terraform, OpenTofu, Pulumi nebo AWS CDK, definujete svou celou cloudovou architekturu v deklarativních konfiguračních souborech uložených v Gitu. Každá změna otevřeného portu nebo repliky databáze prochází pull requestem a peer review. Spuštění terraform plan zobrazí přesný rozdíl API předtím, než se cokoli dotkne, a spuštění identické repliky vašeho produkčního stacku trvá čtyři minuty namísto čtyř týdnů.

- 11. Cloudové sítě (VPC, Subnety, NAT & Bezpečnostní skupiny)

13:20 Jedenáctý koncept: Cloud Networking a virtuální privátní cloudy. Když nasazujete servery do cloudu, nesedí vystavené na surovém veřejném internetu. Žijí uvnitř softwarově definované izolované hranice nazývané VPC. Uvnitř vašeho VPC přidělíte soukromý IP adresní prostor jako deset tečka nula tečka nula tečka nula lomítko šestnáct a rozdělíte jej na veřejné a soukromé podsítě. Veřejná podsíť má přímou cestu k internetové bráně.

13:51 Obsahuje veřejně dostupné zdroje, jako jsou vaše Application Load Balancery a NAT Gateways. Je to jediná část vaší sítě, která má veřejné IP adresy. Vaše aplikační servery a produkční databáze striktně žijí v soukromých podsítích bez veřejných IP a s nulovými příchozími cestami z internetu. Když vaše backendové servery potřebují stáhnout bezpečnostní aktualizace, jejich odchozí provoz směřuje přes NAT Gateway ve veřejné podsíti. Každou instanci obklopují bezpečnostní skupiny: stavové virtuální firewally, které vynucují princip nejmenších oprávnění.

- 12. Kompletní podnikový plán a verdikt

14:28 Bezpečnostní skupina vaší databáze přijímá připojení pouze na portu 5432 striktně z bezpečnostní skupiny vašich aplikačních serverů, což znemožňuje vnější průnik matematicky. Když se podíváte na celek, těchto jedenáct primitiv se spojuje do jednoho koherentního systému. Váš DNS směruje na Load Balancer ve veřejné podsíti, skupiny s automatickým škálováním zvládají nárůsty provozu napříč více zónami dostupnosti, sběrnice událostí oddělují backendové pracovníky a celý váš stack je nasazen z Gitu pomocí Infrastructure as Code.

15:02 Verdikt dnešní mistrovské třídy: SHIP IT. Přestaňte si pamatovat stovky marketingových zkratek cloudu. Ovládněte těchto jedenáct architektonických vzorů, oddělte svůj stav, a budujte systémy, které nemohou selhat. Řekněte mi, který cloudový koncept vám způsobil největší bolesti hlavy, když jste poprvé začali stavět v komentářích. A pro získání kompletního podvodného listu architektury, přihlaste se k odběru newsletteru na the daily diff dot dev,

15:28 odkaz níže. A to je pro dnešek vše. Jsem Niko z Axrisi. Sloučit zodpovědně.

Zdroje

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