Nedávný výpadek v regionu us-east-1 služeb Amazon Web Services (AWS) způsobil značné komplikace mnoha globálním službám, včetně komunikačních platforem a tisíců webových aplikací. Tento incident, který trval celých 14 hodin, si zaslouží hlubší analýzu, aby bylo možné pochopit jeho kořeny a poučení.
Primární příčinou tohoto výpadku bylo selhání DNS služby pro databázi DynamoDB. DynamoDB je NoSQL databáze navržená pro vysokou dostupnost a odolnost, s garancí 99.99% dostupnosti (SLA) při konfiguraci s replikací napříč více zónami dostupnosti (AZ). Je to oblíbená volba pro mnoho aplikací a klíčová komponenta pro řadu interních služeb samotného AWS. Během incidentu však adresa dynamodb.us-east-1.amazonaws.com začala vracet prázdný DNS záznam, což vyvolalo dojem, že DynamoDB v regionu zcela zmizelo.
Pro pochopení mechanismu selhání je nezbytné nahlédnout do způsobu správy DNS pro DynamoDB. Systém využívá dva klíčové komponenty: DNS Planner a DNS Enactor. DNS Planner monitoruje stav load balancerů a vytváří plány pro distribuci zátěže. DNS Enactor je pak zodpovědný za aktualizaci těchto tras v interní DNS službě Route 53. Pro zajištění odolnosti je v každé zóně dostupnosti spuštěna instance DNS Enactoru, což v regionu us-east-1 znamenalo tři paralelně běžící instance.
Ačkoliv jsou v takovém paralelním prostředí časové kolize (race conditions) očekávané a systém je navržen tak, aby je řešil pomocí principu eventuální konzistence, souhra několika nešťastných událostí vedla k selhání. Jedna z instancí DNS Enactoru (Enactor #1) začala zpracovávat aktualizace neobvykle pomalu. Současně DNS Planner začal generovat nové plány mnohem rychleji, a další instance Enactoru (Enactor #2) tyto nové plány zpracovávala s velkou rychlostí. Jakmile Enactor #2 dokončil zápis nejnovějších plánů do Route 53, vrátil se k DNS Planneru a smazal staré plány.
Tato sekvence událostí uvrhla systém do nekonzistentního stavu. Pomalu pracující Enactor #1 nevědomky použil starý plán, který již byl smazán Enactorem #2. Když Enactor #2 detekoval použití starého plánu, spustil se jeho mechanismus čištění, který v tomto případě vymazal všechny IP adresy pro regionální endpointy v Route 53, čímž efektivně vynuloval DNS záznam pro DynamoDB v us-east-1. Tento stav způsobil, že všechny služby, které se snažily připojit k DynamoDB v daném regionu, začaly zažívat selhání DNS.
Výpadek DynamoDB se následně projevil i na službách Amazon EC2. Subsystém DropletWorkflow Manager (DWFM), který spravuje fyzické servery pro EC2 instance (nazývané "droplety"), zaznamenává "leasing" každého serveru, aby věděl, zda je obsazen, nebo může být alokován zákazníkovi. Výsledky kontrol stavu serverů jsou ukládány v DynamoDB. Kvůli nedostupnosti DynamoDB začaly leasingy dropletů vyprchávat a DWFM začal vracet chyby "nedostatečné kapacity", jelikož si myslel, že servery nejsou dostupné.
Máte nápad na web nebo aplikaci?
Proberme ho spolu — nezávazně, bez tlaku a s konkrétním doporučením dalšího kroku.
Ani po obnovení DynamoDB se situace okamžitě nezlepšila. Pokusy o opětovné navázání leasingů na obrovské množství dropletů trvaly tak dlouho, že se práce nestihla dokončit před dalším vypršením časových limitů. DWFM se dostal do stavu "kongektivního kolapsu", kdy nebyl schopen efektivně pokročit v obnově leasingů. Inženýři AWS museli strávit další hodiny vývojem a aplikací zmírňujících opatření, aby alokace EC2 instancí opět začala fungovat.
Problémy se však neomezily jen na EC2. Následovaly chyby v síťové propagaci. I když EC2 instance uvnitř vypadaly zdravě, nemohly komunikovat s vnějším světem kvůli zahlcení v systému Network Manager, který zpracovává změny síťového stavu. Tato komplikace trvala dalších pět hodin, než se podařilo snížit zátěž na Network Manager a zrychlit obnovu síťové konektivity.
Celková obnova systému byla dokončena po 14 hodinách, kdy byly postupně odstraněny omezení (throttles) requestů, která byla zavedena pro snížení zátěže na jednotlivé EC2 subsystémy. Během tohoto náročného období tým inženýrů AWS intenzivně pracoval na odstranění komplikací, které měly široký dopad i na další služby, jako jsou Network Load Balancer (NLB), Lambda funkce, ECS, EKS a řadu dalších.
Tento incident zdůraznil komplexnost a vzájemnou provázanost moderních cloudových infrastruktur. Ukázal, že i systémy navržené pro vysokou dostupnost mohou selhat v důsledku neočekávané kombinace faktorů v jejich distribuovaných komponentách. Je klíčové neustále revidovat a vylepšovat mechanismy odolnosti, zejména v kritických oblastech jako je DNS a správa zdrojů.