Pro Ministerstvo zdravotnictví jsme pomohli v rámci inciativy Česko.Digital připravit krizový web o koronaviru, který se okamžitě stal jedním z hlavních informačních kanálů pro všechny občany. Tento článek popisuje, jak jsme web ve spolupráci s techniky Ministerstva upravili, aby zvládl takový nápor.
Při PR krizích velkých společností (např. nefunguje důležitý produkt, na který podnikatelé spoléhají ve svém podnikání) bývá hlavní web organizace přetížený. To vede k nárůstu hovorů na infolinku, kterou to také přetíží. Posílit hlavní web organizace většinou trvá nějakou dobu (takové weby bývají postavené na enterprise CMS) a infolinky se také neškálují zrovna snadno, navíc jejich provoz je drahý. Proto se při takových krizích většina firem rozhodne pro vytvoření microsite nebo přesunout komunikaci na externí platformy (např. Medium).
Když se rozhodneme pro microsite (vypadá profesionálněji), začneme řešit, kde ji provozovat. Nenapadá mě vhodnější scénář pro web nebo aplikaci, se kterou jít do cloudu – potřebuji aby byla rychle škálovatelnelná a spustit ji co nejdříve. Jsem si jistý, že existují i lepší technologie, na kterých by šlo takové řešení postavit, ale v našich rozhodnutích jsme museli dělat kompromisy nejen kvůli použitelnosti, ale většinou vítězilo hledisko času – co se snadno nastavuje, s čím máme nejvíc zkušeností, abychom mohli co nejdříve spustit MVP (Minimum Viable Product).
Aby řešení bylo stabilní a zároveň jsme nemuseli školit PR oddělení psát všechny informace pro veřejnost v Markdown, nejvhodnějším řešením je WordPress. Toto CMS přináší příjemné a snadné ovládání i pro laiky, ale je větší výzvou ho nakonfigurovat tak, aby ustál takovou zátěž a byl zabezpečený proti útokům.
Níže uvedené řešení je navrhované pro Microsoft Azure, ale řešení postavené na stejném principu lze udělat i v AWS (CloudFront, S3 atd.). Pro Azure jsme se rozhodli hlavně kvůli tomu, protože ho většina enterprise společností už má zavedený (kvůli Azure Active Directory nebo nadstavbám na Office 365).
Architektura řešení
Jádro celého řešení stojí na přístupu, že standardní návštěvník webu nepřichází do kontaktu s CMS, ale se s statickými HTML soubory, vygenerovanými z tohoto CMS. Díky tomu získáme požadovaný výkon i zabezpečení.
WordPress (dále jen WP) je nainstalovaný na virtuálním serveru, který je izolovaný a přístupný pouze pomocí VPN (nebo alespoň IP filtrem). Je nakonfigurovaný pro úplně jinou URL, než na které je dostupný web pro veřejnost – bez toho nefunguje instalace WP správně. V okamžiku, kdy redaktor vygeneruje z administrace statické soubory (na filesystem serveru), spustí se skript, který provede synchronizaci těchto vygenerovaných souborů na Blob storage přes Shared access signature (šlo by zjednodušit namountováním Blob storage přímo jako adresář na serveru).
Před tímto Blob Storage je předsazená Azure CDN, která zajišťuje distribuci požadavků k nejbližší cache (a fakticky pro nás řeší veškeré výkonnostní problémy). V okamžiku, kdy je redaktor spokojený s vyexportovanou verzí, provede invalidaci cache CDN a změnu uvidí po pár minutách všichni čtenáři. V Key Vault je uložený privátní klíč k SSL certifikátu, který Azure CDN používá, aby mohla vystupovat jako náš web.
V diagramu je ještě znázorněná zaregistrovaná aplikace v AAD – tato aplikace má přidělená práva dělat invalidaci CDN cache a slouží jako „servisní účet“, díky kterému můžeme vyvolat invalidaci přímo z rozhraní WP pomocí námi napsaného pluginu, který volá Azure REST API. Limitace tohoto řešení je, že stránky nemůžou mít jakýkoliv interaktivní obsah – např. vyhledávání, hlasování apod. Ale to pro krizový web tolik nepotřebujete.
Detaily řešení
Pro export do statického formátu jsme použili plugin WP2Static. Plugin funguje tak, že projde všechny stránky a příspěvky, vygeneruje z nich statické html soubory a stáhne všechny potřebné soubory, co na stránkách jsou – obrázky, css apod., Plugin zároveň nahrazuje v exportovaných souborech URL instalace WP za produkční URL webu.
Publikace nových informací byla v rámci MVP dělána ručně pomocí bash skriptu, pár hodin po spuštění jsme spolu s Vladimírem Smitkou napsali custom WP plugin a skript, který detekuje dokončený nový export a nahraje ho na Blob Storage. Díky tomu mohou redaktoři udělat publikaci přímo z rozhraní WP sami.
Na Azure CDN také doporučuji nastavit HTTPS-only přesměrování (a přesměrování z www. ) pomocí vlastních pravidel v Rules engine.
Výsledek
Web se ani trochu nezakuckal ani při čísle okolo 11 tisíc souběžných aktivních uživatelů zároveň. Věřím, že kapacity Azure CDN by zvládly i větší číslo, ale zatím jsme ho nepotřebovali.
I přes tuto návštěvnost byl web velmi stabilní, i podle Hlídače webů. Na grafu jsou patrné momenty, kdy docházelo k publikování nové verze a invalidace CDN cache – tyto požadavky byly v monitoringu pomalejší.
Checklist, než začnete tvořit řešení
- Zajistit přístupy s dostatečnými oprávněními k Azure – včetně toho, že výše uvedené služby jsou povolené (Azure Policy/nezaregistrovaný typ služby v subscription).
- Zajistit přístupy k Azure AD – většinou někdo jiný musí vytvořit aplikaci v AAD a přidělit ji práva na danou instanci CDN.
- Nastavit DNS záznamy.
- Mít privátní klíč, pokud chcete vlastní SSL certifikát (Azure CDN umí zařídit jejich SSL certifikát, jenom musíte mít nastavené DNS správně na CDN).
- Při vlastním SSL certifikátu ještě zajistit práva k Azure AD, abyste mohli nastavit přístup Azure CDN k privátnímu klíči uloženém v Azure Key Vault.
Obecné tipy pro podobný web
- Stáhněte TTL u DNS záznamů na 5 minut. Pro případ, že je budete potřebovat rychle změnit
- To samé udělejte i pro nastavení HSTS. Pro případ, kdy se vám nepovede konfigurace HTTPS, abyste web neodřízli návštěvníkům
- I přesto, že microsite bude třeba subdoména krize.spolecnost.cz, zařiďte aby fungovala i s předponou www.krize.spolecnost.cz. Novináři rádi zdůrazňují URL předponou, aby si každý všiml, že se jedná o web
- Nastavte si Google Analytics. I kdybyste je nepoužili k vyhodnocování co návštěvníci hledají, je dobré vědět kolik web ustál a na co musíte připravit ostatní weby.
High-availability řešení
Aby řešení mohlo fungovat i v případě, kdyby došlo k výpadku Azure regionu, ve kterém je řešení nasazené, přikládám ještě variantu tohoto řešení v HA verzi. Pro základní krizovou stránku je výše popsané úplně dostačující.
Celé řešení je duplikováno i do dalšího Azure regionu. Před Azure CDN je předsazený ještě Azure Traffic Manager, který vyhodnocuje dostupnost primárního regionu a v případě výpadku automaticky přepne na druhý.
Pro replikaci VM s WP administrací je využitá služba Azure Site Recovery. Skript+plugin by pak vyžadoval drobnou úpravu, aby publikaci dělal na obou Azure Storage a CDN.
Zdrojové kódy a nastavení
WP plugin, skript a potřebné nastavení služeb jsme publikovali na GitHub.
