Při PR krizích velkých společností – například když 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řesunutí komunikace na externí platformy, například Medium.

Když se rozhodneme pro microsite, začneme řešit, kde ji provozovat. Nenapadá mě vhodnější kandidát pro nasazení do cloudu – potřebuji, aby byl web rychle škálovatelný a dal se spustit co nejdříve. Jsem si jistý, že existují i lepší technologie, na kterých by šlo takové řešení postavit, ale museli jsme dělat kompromisy nejen kvůli použitelnosti, ale především kvůli č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í, jak psát všechny informace pro veřejnost v Markdownu, vybrali jsme 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 web ustál takovou zátěž a byl zabezpečený proti útokům.

Níže uvedené řešení je navrhované pro Microsoft Azure, ale obdobně by šlo postavit třeba na AWS (CloudFront, S3, …). Pro Azure jsme se rozhodli hlavně kvůli tomu, že ho většina enterprise společností už má zavedený, například kvůli Azure Active Directory nebo nadstavbám na Office 365.

Architektura řešení

Základem celého řešení je, že návštěvník webu nepřichází do kontaktu přímo s CMS, ale se statickými HTML soubory, které jsou z něj vygenerované. 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ň chráněný IP filtrem). Je nakonfigurovaný pro úplně jinou adresu, 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, spustí se skript, který provede jejich synchronizaci do Azure Blob Storage.

Před 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. Aby mohla CDN vystupovat jako náš web, potřebuje privátní klíč k SSL certifikátu, který je proto uložen v Azure Key Vault.

V diagramu je ještě znázorněná aplikace zaregistrovaná v AAD – tato aplikace má přidělená práva na 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. Nevýhodou tohoto řešení je, že stránky nemůžou mít jakýkoliv interaktivní obsah – například vyhledávání, hlasování apod. Ale to pro krizový web tolik nepotřebujeme.

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, styly 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í shellového skriptu; pár hodin po spuštění jsme spolu s Vladimírem Smitkou napsali vlastní 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 přesměrování HTTP na HTTPS 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ů. 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ší.

Graf dostupnosti webu z Hlídače státu

Než se pustíte do práce

  • Zajistěte si přístupy s dostatečnými oprávněními k Azure – včetně povolení výše uvedených služeb (Azure Policy/nezaregistrovaný typ služby v subscription).
  • Zajistěte si přístupy k Azure AD – většinou musí někdo jiný vytvořit aplikaci v AAD a přidělit jí práva na danou instanci CDN.
  • Nastavte DNS záznamy.
  • Pokud chcete vlastní SSL certifikát, sežeňte si zavčas privátní klíč – ve větší korporaci může chvilku trvat, než se k němu dostanete. (Azure CDN umí zařídit SSL certifikát samostatně, jenom pak musíte mít nastavené DNS správně na CDN.)
  • Pokud použijete vlastní SSL certifikát, zajistěte si ještě práva k Azure AD, abyste mohli nastavit přístup Azure CDN k privátnímu klíči uloženému v Azure Key Vault.

Obecné tipy pro podobný web

  • Stáhněte TTL u DNS záznamů na 5 minut pro případ, že byste je potřebovali rychle změnit.
  • Totéž udělejte i pro nastavení HSTS. Kdyby se vám nepovedla konfigurace HTTPS, neodříznete web návštěvníkům.
  • Pokud microsite běží například na subdoméně krize.spolecnost.cz, dejte si pozor, aby fungovala i adresa www.krize.spolecnost.cz. Novináři rádi zdůrazňují předponu WWW, 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í

Pro základní krizovou stránku je výše popsané úplně dostačující, ale lze vytvořit i variantu, která by fungovala i v případě výpadku Azure regionu, ve kterém je web nasazený. Stačí celé řešení duplikovat do dalšího Azure regionu a před Azure CDN předsadit Azure Traffic Manager, který vyhodnocuje dostupnost primárního regionu a v případě výpadku automaticky přepne na druhý (viz blokový diagram). 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.

(Text původně vyšel na serveru Náš WordPress.)