Redakční poznámka: Toto je první díl ze seriálu o použití cloudu a jeho spojení s open-source nástroji. V seriálu se budeme postupně věnovat různým službám a jejich praktickému využití.
Proč Cloud? Proč Azure?
V oddělení redakčního vývoje IHNEDu jsme se naučili používat cloudové služby poměrně intenzivně. Naše projekty jsou totiž obvykle narychlo zbastlené slepence, u kterých je čas sotva na otestování funguje-nefunguje, rádi tedy místo několikadenní výkonnostní optimalizace nahodíme tři (desítky) serverů navíc. Také nemusíme řešit potenciální přetížení naší infrastruktury námi vyvinutou vizualizací, jejímž vedlejším efektem je DDoSování hostujícího stroje.
Při výběru obláčku samozřejmě není Azure jediná možnost, mezi full-featured systémy (umí alespoň out-of-the-box loadbalancing a nějakou formu statického storage) se nabízí přinejmenším Amazon Web Services. Azure u nás vyhrál díky jeho místní podpoře a komunitě – Microsoft intenzivně investuje do svých zaměstnanců i partnerů z řad MVP, máme tedy možnost se poradit s živým člověkem mluvícím naší mateřštinou. Ostatně, během pár dní po založení trialového účtu na Azure vám obvykle místní microsofťák zatelefonuje, zeptá se, zda vše šlape jak má a nabídne, abyste mu v případě potřeby neváhali zavolat. (Ne, tohle vážně není reklama, to je autorova zkušenost. – pozn. red.)
Oproti tomu Amazon na mně nechal dojem předpokladu, že když už máte dost rozumu chtít pokročilé cloudové služby, tak i víte, jak je optimálně nastavit a využít. Což je pravděpodobně případ profesionálních systémáků ve velkých korporacích, naši tržní niku (v oboru jen málo zběhlí programátoři s vysokými nároky na výkon) však lépe chytli redmondští. Amazon bohužel neoslňuje ani technickými parametry, ve většině našich usecasů je Azure stejně, nebo i trochu více výkonný.
Ostatní poskytovatelé cloudových řešení buď nenabízeli požadované služby (ano, mohli jsme si postavit vlastní loadbalancer u VirtualMasteru, za nižší cenu. Ale nemáme na to ani čas, ani znalosti), neměli dostatečně zajímavé ceny nebo jsme si jich prostě nevšimli.
Azure Blob Storage
Nyní se však již přesuneme k popisu první z nabízených služeb, Blob Storage. Jak název napovídá, je to systém na ukládání všeho obsahu na discích v cloudu. A zde opravdu myslím všeho – pokud si například vytvoříte virtuální mašinu, její disk(y) jsou uloženy jako Bloby. Můžete si stroj tedy kdykoliv zálohovat a/nebo klonovat, můžete vytvářet RAID (se slušným výkonnostním ziskem) nebo si mountnout disk jiného stroje – třeba kvůli opravě nebootovatelného systému nebo alespoň pro záchranu dat.
Celý Storage se dělí na Účty, ty pak na Kontejnery a v kontejnerech jsou jednotlivé Bloby (soubory). Každému účtu lze nastavit geografické umístění (ovlivňuje latenci a v menší míře šířku pásma), subdoménu ve tvaru nazev-uctu.core.windows.net (přes CNAME přepisovatelné na vlastní doménu) a míru redundance (lokální zálohování uvnitř datacentra nebo zálohování ve dvou blízkých, ale oddělených datacentrech. V preview režimu je také georedundantní zálohování s trvalým zachováním read-only přístupu).
Na úrovni účtu jsou také dva klíče pro API přístup, přičemž jinak než přes API s Cloud Storage nehnete, webový interface na rozdíl od Amazonu nemá. Oba klíče (primary a secondary) jsou si naprosto rovnocenné a jsou implementovány kvůli eliminaci downtimu při změnách klíčů (klíče se doporučuje jednou za čas přegenerovat pro případ, že by v nějakou chvíli unikly). Pokud totiž aplikace zná oba klíče, může se v době mezi změnou primárního klíče a deployem konfigurace s novým klíčem připojovat klíčem sekundárním.
Jednotlivé účty mají oddělené statistiky přístupu (počet úspěšných/neúspěšných requestů, množství dat dovnitř/ven) s hodinovou granularitou a možností exportu a hlavně oddělené vyúčtování. Prakticky vám tedy obvykle bude stačit jeden účet na jeden druh služeb – u nás máme jeden účet s virtuálními disky a jeden pro veškerý čtenářský obsah.
Entity další úrovně, kontejnery, představují první adresář za lomítkem domény, tedy nazev-uctu.core.windows.net/kontejner/. Jednotlivým kontejnerům se nastavuje úroveň přístupu, tedy zda si blob může stáhnout pouze klient s klíčem nebo kdokoliv se správnou URL (tím si ze Storage uděláte jednoduchý server statického obsahu, o tom podrobněji níže).
Jednotlivé bloby se nahrávají i stahují jako key-value páry, přičemž klíč může obsahovat lomítka (/) a vytvářet dojem souborové struktury. Jak je ale poznat z API, samotný Blob Storage strukturu za úrovní kontejneru neřeší.
Každému blobu lze také nastavit řadu metadat. Ty mohou využít jednak aplikace přistupující k datům přes API, ale hlavně je Storage využívá při servírování statického obsahu jako zdroj HTTP hlaviček.
Zajímavá je možnost přiřazovat jednotlivým blobům tzv. Shared Key Signatures, kdy můžete jednotlivým klientům (uživatelům) poslat unikátní, expirující odkaz na stažení souboru z jinak privátního kontejneru.
Blob Storage v praxi jako statický server
Server statických dat byla první Azure služba, kterou jsme začali v IHNEDu využívat. V jednom projektu jsme neuhlídali datovou zátěž a z pomocného serveru, kde hostujeme vizualizace, jsme začali tahat 80 Mbps při stovkách požadavků za sekundu. Nic nezvládnutelného, ale admini nám řekli, abychom podobnou radost příště pokud možno dělali někomu jinému.
Většina podobných „DDoSujících“ projektů jsou mapy, sestávající z desetitisíců malých souborů (mapových dlaždic), které jsou interaktivně načítány, když uživatel posouvá a přibližuje mapu. Naše hlavní starost tedy byla latence, spíš než šířka pásma. Zároveň jsme ale nechtěli plnohodnotnou CDN – hlavně kvůli ceně, možná bychom také při našem extrémním množství souborů mohli mít problém s dobou synchronizace. Navíc jsou čtenáři IHNEDu téměř výhradně z ČR, SR a sousedních evropských států. Pokud tedy vybereme vhodnou lokaci, dostaneme optimální výkon pro více než 95 % uživatelů.
Protože Azure nabízí v Evropě dvě lokace a Amazon jednu, napsal jsem si jednoduchý skript, který z každého datacentra stáhne malý javascriptový soubor a změří čas mezi požadavkem a evaluací. Nakonec takhle vznikl nástroj na porovnaní a nalezení nejbližšího datacentra celosvětově, z nabídky Amazonu i Microsoftu. Pro srovnání jsem přidal i náš lokální, nevirtualizovaný server s Apache – je na něm vidět, že fyzicky vzdálenější cloudové řešení nepřinese mnoho milisekund zdržení.
Následující tabulka tedy shrnuje konkrétní latence pro vaše připojení, s dvaceti měřeními na každý endpoint. Graf má mocninnou škálu, šedý pás značí velikost směrodatné odchylky. Naše měření obvykle vyhrál Azure West Europe, následován na střídačku Azure North Europe a Amazon Europe.
Latenci jsme tedy uspokojivě vyřešili a mapy uživatelům naskakovaly pomalu dřív, než klikli na odkaz. S klesajícím vytížením serverů našich administrátorů ale začaly stoupat poplatky za Azure, potřebovali jsme nějak snížit počet požadavků a hlavně průtok dat (tedy počet gigabajtů za měsíc).
Jak jsem již zmínil, Azure nabízí možnost pomocí metadat nastavit každému souboru konkrétní HTTP hlavičky. Poladěním Cache-control a Expires jsme tak vylepšili cachování na straně prohlížeče a mírně snížili počet požadavků. Hlavičky Last-Modified a Etag potom vyplňuje Blob Storage sám a správně na ně reaguje HTTP 304 Not Modified.
Hlavní úspora ale přišla díky možnosti soubory před nahráním komprimovat a nastavit adekvátní Content-Encoding. Sice v rozporu s HTTP servírujeme gzip-encoded data vždy, nejen po přijetí správné Accept-Encoding hlavičky, ale dnes už snad neexistuje prohlížeč, který by si s tím neporadil. U textových JSONů, které v našich mapách tvoří cca polovinu datového toku, není problém dosáhnout komprese 70–80 %.
Gzipování před nahráním a nastavení správných hlaviček bohužel standardně neumí snad žádný „klikací“ software. Použil jsem tedy Azure SDK pro Node.js (Apache licensed) a napsal si asi 80řádkový skriptík, který prošel adresář, zabalil textové soubory a poté všechno poslal na server. Postupnou evolucí vznikl Azure Uploader, node.jsová command line utilitka s interaktivním průvodcem, která navíc umí vícevláknový upload a v případě opakovaného použití v jednom adresáři nahraje pouze soubory od minula změněné.
Celkově je Blob Storage jako statický server velice výkonný, přitom extrémně jednoduchý na nastavení a cenově za měsíc levnější než půl dne schopnějšího serveráře. Má funkčními SDK pro víc než 10 prostředí (node.js, PHP, Python…) i silné, multiplatformní nástroje pro práci z příkazové řádky (postavené v node.js a bohužel s poněkud… nedokonalou dokumentací. Mnohem lepší je se podívat přímo do JavaDoc komentářů v kódu). Za redakční vývoj IHNEDu můžu Azure rozhodně doporučit.
ČLÁNKY DO MAILU