Platformní služby jsou skvělé. Dostáváte SLA na službu a patching OS a prostředí či služby necháváte na Microsoft. Nemusíte to řešit. Vrtá vám ale hlavou, jak to Azure dělá? Posbírejme informace z veřejně dostupných blogů a podívejme se tomu pod kapotu.
Připomeňme zásadní výhodu PaaS. Celá služba je samozřejmě bezpečná a aktualizovaná jak z pohledu OS tak z hlediska runtime či prostředí (například PHP stack v App Service nebo SQL služba u Azure SQL DB apod.). Dodržuje dané SLA a patching není výmluva - ten se do toho samozřejmě počítá. Například na SQL DB máte SLA 99,99% na službu, tedy na funkční přístup do vaší databáze a do toho se musí vejít havárie serverů, racků, datových center a samozřejmě i věci jako je patching. Zajímá vás jak to Azure dělá?
Podívejme se nejprve na službu App Service. Jde o platformní řešení pro vaše webové aplikace. Funguje tak, že existují nějaké řídící zdroje (pushování kódu, monitoring, load-balancing, TLS šifrování a tak podobně) a pro vlastní aplikace se používá tzv. Service Plan. Jde v zásadě o jedno a více VM, které jsou přiděleny jen vám, ale které jsou plně spravované Microsoftem. Uvnitř těchto VM pak vznikají izolované prostory pro vaše webové aplikace (řekněme například jakési IIS kontejnery). Patching se týká dvou věcí - operačního systému pod tím, typicky Windows, a patching aplikační prostředí, například PHP stacku. Oboje pro vás platforma řeší automaticky (nutno zmínit, že u aplikačního prostředí se takto aplikují typicky minor patche, které nemají vliv na stávající kód - generační obměna runtime na novou major verzi je obvykle řešena tak, že se objeví jako nový runtime, na který můžete zmigrovat dle svého uvážení postupně, jak otestujete aplikaci - některé nejstarší pak mohou z platformy odejít, ale o tom jste s dostatečným předstihem informováni).
Fajn, jak se to tedy dělá? Obvykle to probíhá v pravidelném cyklu jednoho měsíce, který koreluje s uvolňováním záplat Windows, nicméně v případě kritických chyb se tyto implementují dle potřeby i mimo cyklus. Prvním krokem je, že testovací tým si všechno důkladně otestuje. Co se děje dál?
Druhým krokem je deployment do tzv. canary regionů. To je něco, co v portálu nevidíte, a většina zákazníků o těchto regionech netuší. Jedná se o testovací regiony, takovou laboratoř pro testování změn v Azure, než se pustí do produkčních regionů. Někteří velcí zákazníci mohou o přístup do canary regionu požádat. Dělají to ti největší uživatelé a běží tam svoje testy (případně získají přístup k prototypům budoucích funkcí Azure - ty jsou obvykle nejprve v canary pro private preview pro velmi omezené publikum, následně v private preview v normálním regionu pro širší, ale stále omezené publikum, potom v public preview dostupném pro všechny, ale bez SLA, a pak jde funkce do General Availability). Patche se tedy nasadí v canary regionu a neustále se sbírají metriky jak z obrovského množství testovacích aplikací, tak i z testovacích prostředí "interních zákazníků" (XBOX, Office365 apod.) a externích zákazníků (zmíněné velké firmy, které získají do canary přístup). Teprve pokud je tady vše v pořádku, postupuje se dál.
Začíná se nasazovat do ostrých regionů. Patche už jsou brutálně otestované a jakékoli problémy jsou nepravděpodobné, přesto Microsoft postupuje opatrně. V rámci světadílů existují jakési páry datových center, v Evropě například Amsterdam a Dublin. Vždy se nasazuje pouze do jednoho z nich (pokud má globální zákazník aplikaci distribuovanou do obou center v režimu active/active, nikdy nedochází ke změnám v obou současně). Při nasazování se neustále sledují nejrůznější metriky a monitorují případné support tickety. Teprve když je všechno dobré, jde se na druhý region.
Jak to vypadá uvnitř regionu? Služba je nasazena v stavebních blocích označovaných jako stamp (představte si třeba 1000 VM) a stampů je v regionu samozřejmě velké množství. V každém stamp najdete servery zařazené do několika menších škatulek. Pro zjednodušení řekněme box1, box2, box3 a box4. V boxech 1-3 jsou VM přiřazené zákazníkům, ale box4 je jiný. Tam jsou VM, které jsou plně nastartované a připravené, ale nepřiřazené zákazníkovi (tedy neběží na nich aplikace). Ty jsou tam vždy pro schopnost rychlého přesunutí aplikace v případě nějakého výpadku nebo požadavku na zvýšení výkonu. Vaše webové aplikace jsou na sdílené storage, takže jejich rozchození na předem nastartovaném stroji je velmi rychlé (to je důvod, proč má App Service SLA i v případě, že máte jen jednu instanci v servisním plánu). Toho se dá krásně využít. Mimochodem aplikace patch v regionu se provádí typicky mimo dobu hlavní zátěže, tedy v noci. Nejprve dojde k aktualizaci box4. Následně se aplikace z box1 přesunou na box4 (v závislosti na tom jak rychle se vaše aplikace startuje můžete v okamžiku překlopení zaznamenat na chviličku prodloužené latence). Následně se box1 zaktualizuje a stává se zněj nový spare pool. Aplikace z box2 přesunete na box1 a box2 se aktualizuje. A tak dále, dokud není všechno hotové. Jako vždy se neustále sledují metriky a v případě identifikace problému se roullout patchů zastaví.
Ve finále žádná magie, jen velmi dobře vymyšlený proces. Ten si můžete udělat i u sebe, ale je to pracné, bez perfektní automatizace riskantní a potřebujete dostatek volných zdrojů.
Nebudu popisovat úvodní kroky, protože ty jsou stejné - testování, canary release, postupné nasazování do párů regionů. Vaše databáze neběží na dvojici v clusteru (jak se to obvykle dělá v on-premises), ale na trojici. Důvodem je, že se dá jeden uzel poslat do offline a stále vám ještě běží dvě instance, tedy nepřicházíte o redundanci. Update na dvojici způsobem offline je riskantní, protože v okamžiku update můžete náhodou přijít o tu poslední instanci a máte problém. Skvělé SLA 99,99% je možné právě díky třem instancím, což je v ceně služby. Clusteru se tedy řekne, že budeme jednu instanci odebírat, ta se aktualizuje, zařadí zpátky a odebírá se další. Z pohledu dostupnosti tady dochází k překlopení na jinou instanci (plánovanému, čili není to nic drastického), takže se vám může resetovat session. Dejte tedy do své aplikace retry logiku, stačí se okamžitě připojit znova a jedete dál. Celý proces je automatizovaný a telemetrií velmi dobře kontrolovaný. Opět - něco takového si můžete udělat i u sebe, ale stojí to hodně práce, je tam potenciál pro chybu a spotřebujete víc zdrojů.
Vrtalo vám hlavou jak to funguje a jak je možné nabízet vysoké SLA na samotnou komplexní službu, které je vyšší, než SLA na jednotlivé infrastrukturní komponenty, které jsou pod tím? Dokonalá automatizace, brutální telemetrie a dobře implementovaný proces. A to všechno je v ceně PaaS a vy se můžete soustředit na to důležitější - vaše aplikace a data.