Architektonické vzory aplikací na AWS

Nasazování aplikací na AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Tvůj instruktor

Instruktor kurzu Dunieski Otano, AWS Solutions Architect s přibližně deseti lety zkušeností s cloudem

Proč záleží na správné architektuře

Rozhodovací diagram se světlým motivem: jeden uzel volby architektury se větví do tří faktorů – provázanost, stav a komunikace – nad malou ikonou váhy znázorňující kompromisy

Architektura je soubor kompromisů, ne jediná správná odpověď
- Každou volbu určují tři otázky:
  - Jak těsně jsou komponenty provázány?
  - Kde žije stav?
  - Je komunikace synchronní, nebo asynchronní?
- Vzor přizpůsob zátěži, ne módním trendům

Páteční noční kaskáda

Pomalé platební API zablokuje celý checkout
Každá služba na něj synchronně čekala
Řešení je jiná architektura, ne rychlejší API

Srovnání těsně provázaných služeb, které se zaseknou, a služeb oddělených frontou zpráv

Proč architektura rozhoduje o nasazení

Diagram porovnávající křehkou, těsně provázanou architekturu, kde selhání jedné služby kaskádovitě zasáhne všechny ostatní, s odolným návrhem, kde fronta izoluje selhání a ostatní služby dál fungují

Zvolený vzor určuje, jak aplikace škáluje a selhává
- Těsně provázaný návrh se pod zátěží hroutí
Správný vzor činí nasazení předvídatelným
- Stejný kód, velmi odlišné chování v produkci

Základní architektonické vzory

Monolitická: jeden nasaditelný celek, jednoduchý start
Mikroslužby: nezávislé služby nasazované odděleně
Událostmi řízená: komponenty reagují na události, ne na přímá volání
- Fanout je podvzor: jedna událost osloví mnoho konzumentů

Tři architektonické vzory vedle sebe: monolitická jako jeden blok, mikroslužby jako nezávislé nasaditelné služby a událostmi řízená architektura s event busem; fanout je vyznačen jako podvzor publikující jednu událost mnoha konzumentům

Stavová vs. bezstavová architektura

Bezstavová: mezi požadavky se neuchovávají data klienta
- Jakákoli instance zvládne jakýkoli požadavek
Stavová: instance si pamatuje předchozí interakce
Bezstavovost umožňuje horizontální škálování
- Sdílený stav přesuň do DynamoDB nebo ElastiCache

Bezstavová instance funkce dostupná z libovolného požadavku vlevo versus stavová instance svázaná s jednou klientskou relací vpravo

Těsné vs. volné provázání

Těsné provázání: volající čeká na pomalého volaného; volné provázání: fronta SQS bufferuje zprávy a producent pracuje dál

Těsné provázání: volající čeká na odpověď volaného
Jedna pomalá služba zablokuje celý řetězec
Volné provázání: mezi službami stojí fronta Amazon SQS
Producent pracuje dál, i když je konzument nedostupný

Synchronní vs. asynchronní komunikace

Synchronní: volající čeká na výsledek
Použij, když volající potřebuje odpověď okamžitě
Asynchronní: volající předá práci a vrátí se
Použij pro pomalou, nárazovou nebo nekritickou práci

Synchronní volání s čekajícím volajícím vlevo versus asynchronní předání s okamžitým návratem a zpracováním na pozadí vpravo

Vzory odolnosti pro volání třetích stran

Opakování s exponenciálním zpožděním: mezi pokusy se čeká stále déle
Jistič (circuit breaker): volání selhávající služby se dočasně zastaví
Fronta nedoručených zpráv (DLQ): zprávy, které selhávají opakovaně, se odloží
Kombinuj je; plošné opakování výpadky zhoršuje

Tři vzory odolnosti: křivka exponenciálního zpožděného opakování, jistič zastavující volání selhávající služby a fronta nedoručených zpráv zachycující zprávy, které vyčerpaly všechny pokusy

Pojďme cvičit!

Nasazování aplikací na AWS