Další velký výpadek
Jednou za čas vypadne každá služba, to se prostě stává. Když ale vypadne jedna z těch velkých, je to vidět. Nejen pro to, že přestanou fungovat věci, u kterých byste to v danou chvíli čekali, ale rozbije se toho překvapivě daleko více. Naposledy jsme to zaznamenali minulý čtvrtek 12. června, kdy se odporoučela velká část sítě společnosti Google.
Taková věc je nepříjemná zejména proto, že se šíří i napříč dalšími službami, které s Googlem nemají nic společného. Přestala tedy fungovat hudební služba Spotify, diskusní server Discord nebo třeba velká služba Cloudflare. Tu podle statistik W3Techs používá 20 % webů a část z nich byla tedy také nedostupná.
Toto lavinovité šíření problému zaznamenala služba Down Detector, která sleduje dostupnost mnoha různých velkých webů a služeb.
Každá služba se po svém snažila problém řešit, přesto měli někteří klienti Cloudflaru problémy asi dvě hodiny. Nakonec Google ve čtvrtek ve večerních hodinách oznámil, že všechny služby fungují ve všech regionech normálně. Celkem primární výpadek služeb trval přes tři hodiny.
Příčinou byl nový kód
Vysvětlení společnosti Google začíná tím, že jeho API a Google Cloud jsou poskytovány pomocí řídicích a správcovských systémů Google API. Tyto dva systémy jsou distribuovány regionálně a jsou zodpovědné za zajištění toho, že každý příchozí požadavek na API je autorizován, má stanovenou politiku a odpovídající kontroly (jako například kvóty), aby splnil dané požadavky.
Jádrem tohoto řešení je systém zvaný Service Control. To je regionální služba, která má vlastní úložiště, ze kterého čte informace o kvótách a politikách. Metadata tohoto úložiště se téměř okamžitě replikují globálně, aby byly stále přístupné kvótové politiky pro Google Cloud a všechny zákazníky z celého světa.
Ve čtvrtek 29. května, tedy dva týdny před incidentem, přidali vývojáři do tohoto řídicího systému novou funkci doplňující další kontroly politiky kvót. Tato změna kódu a nová verze nástroje prošly postupným nasazením po jednotlivých regionech a vše se zdálo být v pořádku. V kódu ovšem byla chyba, ale ta se v průběhu nasazování neprojevila, protože pro použití nové funkce bylo potřeba změnit politiku, která by upravený kód spustila.
Vývojáři se podle všeho nasazení nové verze báli už předem, protože do nástroje přidali funkci pro rychlé vypnutí podpory pro novou politiku. Pokud by přišly potíže, stačilo by „stisknout červené tlačítko“ a vše se mělo vrátit do původního stavu, bez použití přídavných funkcí.
Nový kód ovšem neměl odpovídající zpracování chyb a nepoužíval ani funkční příznaky (feature flags) pro zapínání a vypínání nových vlastností. Pokud by tomu tak bylo, problém by byl odhalen už v testovacím prostředí. Kvůli neinicializovanému ukazateli totiž došlo při použití nové funkce k pádu celého programu. Tahle zrada tam dva týdny čekala na svou šanci se projevit.
Právě 12. června pak správci v Googlu změnili nastavení politiky a nové vydání obsahovalo neúmyslná prázdná pole. Toto nastavení se pak rozšířilo do všech regionálních úložišť, čímž se všude najednou začal používat nový chybný kód a řídicí procesy po celém světě popadaly.
Reakce správců a systémů
Google ve svém vysvětlení uvádí, že tým zodpovědný za spolehlivost (Site Reliability Engineering) začal tento incident řešit během dvou minut. Příčiny byly identifikovány asi během deseti minut a zhruba za 25 minut byla hotová příprava na aktivaci „červeného tlačítka“ – vyřazení chybného kódu. To proběhlo ve všech regionech během 40 minut od začátku incidentu. Poté začali technici pracovat na obnovení běžné funkce jednotlivých služeb a začali od nejmenších regionů.
V některých větších regionech ale způsobil restart řídicí služby Service Control kaskádovitý jev nazvaný „efekt stáda“. Tím se obvykle popisuje situace, kdy se při vysokém zatížení systému nebo infrastruktury začnou jednotlivé komponenty chovat podobně a jejich činnost se nechtěně synchronizuje, což může vést k přetížení nebo selhání celého systému.
Pokud se například více serverů nebo služeb pokouší zpracovat velké množství požadavků současně nebo neustále kontaktuje nefunkční službu, může to způsobit další přetížení infrastruktury, která tak začne selhávat. Je to způsobeno tím, že jednotlivé části systému reagují na zatížení podobným způsobem.
Služba Service Control ale nebyla navržena tak, aby podobný nápor zvládala. Neměla totiž implementovaný vhodný mechanismus náhodného rozložení požadavků, který by vzniku úzkého hrdla předešel. Proto nakonec trvalo téměř tři hodiny, než byla situace vyřešena ve větších regionech. Dotčené týmy uvnitř Googlu totiž musely zahájit úkony nutné k obnově dalších postižených služeb.
Omluva a ponaučení
Google se za výpadek omluvil a slíbil, že už do budoucna nebude opakovat chyby, které k popsanému problému vedly. Společnost ovšem také slíbila několik provozních změn, zejména v komunikaci se zákazníky a veřejností, která dlouho nevěděla, co přesně se v systémech Googlu stalo.
Firma hodlá zlepšit externí komunikaci, jak automatizovanou, tak lidskou, aby zákazníci dostávali co nejdříve informace, které potřebují. Zajistíme, aby naše monitorovací a komunikační infrastruktura zůstala funkční a sloužila zákazníkům i v případě, že Google Cloud a naše hlavní monitorovací produkty jsou mimo provoz,
slibuje firma v oznámení.
Kromě toho budou přijata také technická opatření. Architektura řídicí služby bude modularizována, aby byly jednotlivé funkce izolovány. V případě selhání některé části tak systém bude dál fungovat a bude se chovat předvídatelně a stále zpracovávat požadavky na API.
Proběhne také kontrola všech systémů, které využívají globálně replikovaná data. Současné systémy vyžadují téměř okamžitou konzistenci dat na celosvětové úrovni (například nastavení správy kvót jsou globální), ale replikace bude v budoucnu prováděna postupně, s dostatečnými časovými prodlevami na ověření a detekci případných problémů.
Vylepšena bude také kontrola kódu, jeho statická analýza a možnost ovládání kritických funkcí pomocí příznaků. Postupy při vývoji budou upraveny tak, aby se zlepšilo testování a bylo vždy funkční odchytávání programových chyb. Systémy budou upraveny a budou moci náhodně rozkládat požadavky, aby se předešlo ucpání úzkých míst kvůli efektu stáda.