Výpadek Cloudflare v roce 2019 ukázal, jak kritická je správná správa konfigurace. Tento článek vysvětluje, proč by měla být konfigurace považována za kód, jak se vyhnout chybám při nasazování, a proč tradiční přístupy nemusí stačit pro zajištění stability a výkonnosti systémů.

Pravděpodobně jste to sami zažili, nebo o tom alespoň slyšeli. Internet se na půl hodiny dne 2. července 2019 rozpadl. Co se opravdu stalo, bylo, že Cloudflare, hlavní poskytovatel CDN (content delivery network), měl globální výpadek. Efektivně to přerušilo internet, protože většina webových stránek buď používá Cloudflare přímo, nebo závisí na službě, která jej využívá.

To nám ukazuje, jak se celý web stále více centralizuje a pokud má jeden z hlavních hráčů problémy, pocítí to všichni. Ale nebudeme zde lamentovat nad centralizací a jak špatná je. Je špatná.

Ne. Chci mluvit o souvisejícím tématu, které (pravděpodobně) hrálo roli v tomto výpadku.

A ještě jedna věc, než začneme. V žádném případě si nemyslím, že Cloudflare jsou nekompetentní nebo udělali něco špatně. Pokud vůbec něco, řešili incident otevřeně a rychle, jak by to mělo být. Dobrá práce!

Kód je král

Vývojáři mají rádi kód. Někdy se do svého kódu dokonce zamilují, což je samo o sobě problém. Naučili se zacházet s kódem dobře už dávno. Máme úžasné systémy pro správu verzí a nástroje. Máme skvělé testovací rámce a každý vývojář, který za něco stojí, píše automatizované testy, které se spouštějí při každém commitu.

Dávno jsou pryč doby, kdy jsme FTPovali náš kód na servery z lokálních strojů. Naučili jsme se automaticky balit a nasazovat kód, s věcmi jako blue/green nasazení, canary deploys, rolling upgrades a tak dále. Samé skvělé věci.

Konfigurace je, ehm, …

Za běhu vyžaduje každý, kromě nejjednoduššího softwaru, nějakou formu konfigurace. Aby to bylo ještě složitější, existuje několik typů konfigurace.

Jak zacházíme s touto konfigurací? Vnitřní konfigurace aplikace se pravděpodobně zachází jako s kódem, což je dobrá věc. Začíná to být chaotické, když je tento typ konfigurace smíchán s jinými typy konfigurace v jednom souboru. To by mělo být vyloučeno, ale to obecně není příliš složité.

Konfigurace infrastruktury žije v konfiguračních souborech různých druhů: INI soubory, YAML soubory, JSON soubory nebo dokonce XML soubory, bůh nás ochraňuj. Protože tyto soubory nejsou dodávány s aplikací, musí být generovány nebo aktualizovány jinými prostředky. Nástroje pro správu infrastruktury, jako je Chef nebo Puppet, se snaží tento úkol automatizovat, ale i tak musíte udržovat hodnoty konfigurace v nějaké jiné formě v rámci těchto nástrojů. Chef, například, ukládá konfigurační hodnoty v environment souborech, které jsou obvykle ve formátu JSON. Ty mohou být verzovány, takže alespoň to je, ale hodně štěstí s prováděním jakýchkoliv automatizovaných testů samotných hodnot nebo skutečných souborů, které budou generovány.

A běhová konfigurace? Jak jsem psal dříve, většina lidí to považuje za data. A kde ukládáme data? V databázi, samozřejmě! A jak provedete canary deployment změněné hodnoty v řádku databáze? Neprovedete. Pokud pro to speciálně něco nevybudujete, což je nevídané.

Co to má společného s Cloudflare

Proč o tom vůbec píšu v souvislosti s incidentem Cloudflare? Pokud si přečtete předběžnou zprávu, najdete tuto větu.

Příčinou tohoto výpadku bylo nasazení jediného špatně nakonfigurovaného pravidla v Cloudflare Web Application Firewall (WAF) během rutinního nasazení nových spravovaných pravidel WAF od Cloudflare.

Cloudflare nejsou amatéři. Jsou to vysoce úspěšná a kompetentní firma. Na internetu můžete najít spoustu zajímavých informací o jejich infrastruktuře. Provádějí canary deploys, dělají dark launching, provádějí rolling upgrades. Kromě toho, když mění filtrační pravidla. Toto je jen změna konfigurace. Pravděpodobně záznam v databázi někde, který se pak replikuje do jejich POPs. Zdá se, že s konfigurací nezacházejí jako s kódem. A pravděpodobně k tomu mají několik dobrých důvodů. Jedním z nich, a pravděpodobně nejdůležitějším, je, že je to rychlejší.

Vidíte, stavění, testování, canary deploys, postupná nasazení, tyto věci zabírají čas. Pokud přidáte nebo změníte pravidlo v sadě filtrů, chcete, aby se to stalo okamžitě. Sakra, chcete to i s nasazením softwaru, ale nějak jsme přijali fakt, že pokud to chcete udělat bezpečně, zabere to trochu času. Ale jen změna konfigurace? Ne, to je jen hloupost, pojďme to prostě změnit.

Konfigurace jako kód

Tím se dostávám k jádru tohoto příspěvku: Konfigurace je kód. Může to tak nevypadat, ale mění to způsob, jakým naše software funguje. Splňuje všechny charakteristiky kódu, jen “vypadá” mnohem jednodušeji. Vzhled může klamat.

Měli byste si položit všechny stejné otázky jako u kódu. Je to ve správě verzí? Prošlo to code review? Je to pokryto testy? Je nasazení automatizované? Máme dokumentaci?

Jednoduše, zacházejte s vaší konfigurací tak, jak zacházíte s vaším kódem.

PS: Dark launching není zdarma

Jedna další zajímavá perlička moudrosti vyplynula z incidentu Cloudflare. Přečtěte si následující větu ze zprávy:

Tato pravidla byla nasazována v simulovaném režimu, kde problémy jsou identifikovány a zaznamenány novým pravidlem, ale žádný zákaznický provoz není skutečně blokován, aby se mohly měřit míry falešně pozitivních nálezů a zajistilo se, že nová pravidla nezpůsobí problémy, když budou nasazena do plné produkce.

Takže, opět, Cloudflare ví, co dělají. Nevydávají změnu, aniž by ji spustili v nějakém “neaktivním režimu”. Pokud nevíte, technika zvaná dark launching je způsob, jak nasadit novou funkčnost do produkce, aniž by to skutečně ovlivnilo uživatele. Možná nasadíte nový algoritmus vyhledávání, ale povolíte ho pouze pro uživatele se speciálně vytvořeným cookie. Nebo pošlete vaše vyhledávací dotazy novému enginu a porovnáte výsledky se starým, ale uživatelům stále sloužíte ze starého. Tato technika je obecně lepší než to prostě spustit ve vašem testovacím prostředí, protože pro jakoukoli netriviální aplikaci je téměř nemožné simulovat skutečné uživatele v testu. Ale jak jsme viděli, není to zdarma. Pokud uděláte určitý druh chyby při implementaci této temné funkce, může to stále ovlivnit vaši produkci. Takže nepovažujte dark launching za náhradu za jakékoliv druhy testování. Není. Je to strategie nasazení.

PS2: Testování výkonu

Zpráva je dárek, který stále dává. Podívejme se na další část:

Bohužel jedno z těchto pravidel obsahovalo regulární výraz, který způsobil nárůst CPU na 100 % na našich strojích po celém světě.

Tipoval bych, že Cloudflare má nějaký druh kontroly syntaxe regulárních výrazů, aby nevydali neplatný. Ale očividně nekontrolovali výkonnost výrazů. A neviním je, protože to je opravdu těžké.

Nechci zde nadávat na regulární výrazy. Jsou skvělým nástrojem, ale ostrým. Přizpůsobte podle toho jejich používání.

Co chci říci, je, že testování výkonu by mělo být součástí procesu vydání. Což očividně neměli. A buďme upřímní: skoro nikdo opravdu nemá, kromě možná Cloudflare po tomto incidentu. Tvrdil bych, že alespoň nějaké základní testy výkonu by měly být součástí jakéhokoliv zralého continuous integration pipeline. Není to snadné, ale jde to.

Nebo pokud to není možné, alespoň nastavte denní testy výkonu, pomocí vašeho Selenium serveru nebo čímkoli máte. Existuje několik společností, které nabízejí syntetické sady testů výkonu. Zejména mám rád SpeedCurve, ale jsou i jiné. Nasměrujte je na svou produkci, ale také na svůj testovací web a nechte testy běžet několikrát denně. A ujistěte se, že nastavíte limity výkonu a upozornění, když je překročíte.

UPDATE 13. července 2019: Cloudflare publikoval rozsáhlý post-mortem na svém blogu.

Tags: odolnost, architektura

Comments