Pokud potřebujeme z AWS distribuovat statická data, můžeme je uložit do Simple Storage Service – S3, což je obdoba popisovaného Azure Blob Storage. Jedná se také o úložiště, do kterého je možné ukládat binární objekty a přistupovat k nim přes klíče, které nápadně připomínají URL a dokonce stejně fungují. Pokud budete řešení porovnávat, zjistíte, že se podobají „jako vejce vejci“ a kdo pochopil používání jednoho, dokáže používat to druhé během několika hodin. Stačí se jen seznámit s terminologií dané platformy.
Kontejnerům se v AWS říká Buckets (kbelíky), jsou základní úrovní, nad kterou se nastavují přístupová práva a politika ukládání. Ty jsou dvě, buď základní pro data, na kterých nám záleží, a nebo Reduced redundancy pro data, která zas tak důležitá nejsou. Rozdíl je v počtu replik uložených dat a tím i v ceně. Pro statický obsah k distribuci asi zvolíte Reduced verzi, protože se jedná jen o kopii dat. Kbelíků můžete mít kolik chcete, jedinou podmínkou je, že jejich název musí být unikátní. Kromě kbelíku s daty k distribuci si můžete aktivovat kbelík, do kterého se budou ukládat přístupové logy.
AWS používá ještě další typy úložišť, EBS (virtualizované pevné disky, v podstatě logické disky nad LVM), iSCSI a Glacier, což je úložiště pro dlouhodobou archivaci. Ani jedno z nich ale není pro tento popis relevantní.
Stejně jako v prvním článku se masivně používá finta s uložením gzipovaných souborů vybavených patřičnými hlavičkami. Na screenshotu je vidět, jak se hlavičky přidávají při ruční správě, ale v reálném provozu budete používat nějakou knihovnu, např. pro Python je to knihovna Boto. Mám tu schovanou ukázku hromadného nahrazení hlaviček. Když jsem potřeboval změnit/nastavit expiraci obsahu.
from boto.s3.connection import S3Connection
conn = S3Connection()
bucket = conn.get_bucket('jméno kyblíčku')
keys = bucket.list()
for key in keys:
key.set_metadata("Cache-Control","max-age=2592000, public")
key.update_metadata({"Cache-Control":"max-age=2592000, public"})
V ukázce nevidíte autorizaci, ta probíhá přes klíče, které se dají předat z environmentu. Klíčů se generuje spousta, mají přiřazena různá oprávnění, takže při jejich odcizení můžete omezit škody jen na jeden projekt nebo jeho část, případně mít různé klíče pro mazání a upload, takže přidávat data do úložiště může každý webserver ve farmě, ale mazat jen administrátor ze své pracovní stanice.
Soubor nahraný do S3 kbelíku (má-li nastavena práva pro čtení bez omezení) získává URL, které můžete použít přímo pro přístup k souboru. Tento ukázkový jsem dal na URL http://s3-eu-west-1.amazonaws.com/root-demo/jquery-2.1.0.min.js. Pokud se chystáte provozovat na S3 celý web, bude lepší zapnout podporu pro webhosting.
Tím se chování změní hned v několika směrech. To nejviditelnější je, že název kbelíku se přestěhoval do názvu domény a neruší v cestě k souboru, URL tedy nyní vypadá takto – http://root-demo.s3-eu-west-1.amazonaws.com/jquery-2.1.0.min.js. Můžete si i zapnout, že pokud někdo přistoupí na kořen kbelíku, je mu odeslán zvolený soubor (v konfiguraci Apache by se jednalo o parametr DirectoryIndex) a zvolit i jiný soubor, který bude odeslán v případě, že uživatel bude chtít zobrazit neexistující soubor/stránku.
V neposlední řadě je možné po zapnutí tohoto režimu nastavit vlastní doménu, na které budete celý web provozovat. Pokud se to rozhodnete udělat, budete se muset seznámit s další komponentou AWS, a tou je Route 53. Ve zkratce se jedná o nameserver, který současně zajistí resolving jména vaší domény na IP adresu dané S3 instance, ale současně směrem k S3 odsignalizuje, že je „virtualhostem“ pro dané doménové jméno. Nemusíte tam nutně delegovat správu celé domény, stačí jen jména, která budete používat pro statický obsah.
Perlička bokem: Route 53 je snad jediná IT služba, u které provozovatel garantuje 100% SLA, byť jen se symbolickým penále při jeho nesplnění.
A můžeme zkusit první test rychlosti:
$ ab -n 10000 -c 1000 http://s3-eu-west-1.amazonaws.com/root-demo/jquery-2.1.0.min.js
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Server Software: AmazonS3
Server Hostname: s3-eu-west-1.amazonaws.com
Server Port: 80
Document Path: /root-demo/jquery-2.1.0.min.js
Document Length: 29222 bytes
Concurrency Level: 1000
Time taken for tests: 4.827 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 296710000 bytes
HTML transferred: 292220000 bytes
Requests per second: 2071.64 [#/sec] (mean)
Time per request: 482.710 [ms] (mean)
Time per request: 0.483 [ms] (mean, across all concurrent requests)
Transfer rate: 60026.90 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 34 62 161.2 35 1039
Processing: 70 218 245.8 152 3467
Waiting: 35 63 177.6 41 3163
Total: 104 280 290.0 191 3501
Percentage of the requests served within a certain time (ms)
50% 191
66% 247
75% 290
80% 362
90% 508
95% 711
98% 1179
99% 1267
100% 3501 (longest request)
Jak vidíte, výkon není špatný a velmi pravděpodobně jsme narazili na limit zahraniční konektivity spíše než na limit daného řešení.
Amazon ale doporučuje pokračovat dalším krokem. A tím je použití jejich CDN. Ta se jmenuje CloudFront a její nastavení není nijak složité. Stačí vytvořit tzv. Distribuci a připojit ji na S3 Bucket. Asi takto:
A po chvíli čekání dostaneme další jméno, pod kterým jsou naše soubory přístupné. V tomto případě http://d22ntagnekgxkf.cloudfront.net/root-demo/jquery-2.1.0.min.js.
Zde jistě s napětím čekáte na další měření, které ukáže další nárůst výkonu. Měření ale nebude, protože nárůst výkonu nepřesáhl 20 %, i když mi pomáhalo měřit několik kolegů u různých poskytovatelů. Výrazných rozdílů jsme dosáhli jen při měření v Singapuru a u jiných podobně exotických destinací, ale pro ČR rozdíl není zásadní. Nasazení CDN samozřejmě smysl má, umožní lépe škálovat, u globálních projektů přiblíží obsah ke konzumentovi, jen nedokážu snadno ukázat nějaký měřitelný výsledek. Lze očekávat, že pokud nebude S3 zrovna v kondici na odbavení 600 Mbit, CloudFront s jeho lokálním cachováním si poradí lépe.
Samozřejmě je opět možné nastavit vlastní CNAME. A nebo místo S3 použít jako zdroj dat vlastní server, CloudFront potom získá data z něj a pošle je dál.
A závěrem pár důvodů, proč asi nebudete chtít toto řešení použít. Prvním je určitě cena. Pro malý startup není cena problém, bude se pohybovat v haléřových položkách s placením měsíc po měsíci bez jakéhokoliv závazku, ale pro větší subjekty s perspektivou delší existence už je potřeba dobře počítat a mít i rezervu, protože určit předem cenu AWS je velmi těžké. Sestává ze spousty položek (počty requestů na CloudFront, počty requestů na S3, datové přenosy mezi AWS datacentry, datové přenosy ven mimo AWS sít.) a teprve skutečný provoz ukáže reálnou cenu se kterou se dá počítat při škálování služby. A protože všechny studie dokládající výhodnost cloudu jsou počítány na náklady „západního“ světa, vyjde serverová farma v Čechách většinou lépe. Situace se může obrátit u subjektů, které míří do zahraničí, protože žádný server v Praze nebude mít takové odezvy pro uživatele v USA nebo třeba Brazílii, jaké dokáže zajistit CloudFront (a nebo Azure, či jejich další konkurenti).
První požadavek na CloudFront má vždy vyšší latenci, protože musí proběhnout celé kolečko – uživatel provede GET, CloudFront zjistí, že soubor nemá, provede GET na backend s daty, ten data pošle a CloudFront je pošle uživateli. Pokud máte webík s pár návštěvami za den, je jisté, že jeho data v CloudFront nebudou a každý návštěvník si užije latenci první návštěvy. Časovou platnost dat nastavenou v hlavičce CloudFront respektuje jen tím směrem, že pokud jsou data stará, tak si stáhne nová, ale pokud k datům není mnoho přístupů, klidně je z cache smaže daleko před expirací a pokud se přece jen nějaký požadavek najde, tak si je stáhne znovu. Pokud posíláte data z vlastního serveru, uvidíte v logu, že CloudFront stejný soubor bude stahovat opakovaně z různých IP adres, protože jednotlivé instance si data mezi sebou nepředávají a pokud je potřebují, stáhnou si je přímo ze zdroje. Nakonec i provedené měření ukazuje, že jeden z požadavků trval 3,5 sekundy, což není na tak malý soubor nijak oslnivý výsledek.
Dalším důvodem je, že provoz z AWS je pro všechny české poskytovatele provozem zahraničním, a tedy dražším. Hezké grafy, které naměříte v kanceláři připojené přes špičkového poskytovatele (a tedy ukazující vysoké výkony), nemusí pro běžné vesnické připojení vůbec platit, protože má 1 G do NIX.CZ, ale jen 100 M do zahraničí.
Zatím platí, že S3 budete mít pravděpodobně nejrychlejší z Irska, CloudFront a Route 53 odezvy budete dostávat buď z Frankfurtu nebo z Amsterodamu.
AWS samo o sobě nemá českou podporu, takže v tom s Azure prohrává. Když jsem potřeboval povolení pro překročení limitu 1000 req/s, což je limit při základní registraci, tak jsem se musel dohodnout s dohledovým centrem v Německu, ale nebyl to problém.
Pokud vás zajímá hraní si s takovými technologiemi, tak AWS nabízí tzv. Free Tier, kde je možné vyzkoušet všechny komponenty a klidně i provozovat malý projekt rok zdarma. Azure má podmínky nastavené trochu jinak, v prvním měsíci nabízí kredit 200 USD, takže projekt, který se vejde do této částky, má první měsíc zdarma. Případně je možné provozovat deset malých webů trvale zdarma.
V obou případech budete pro registraci potřebovat platební kartu, aby provozovatel zabránil zneužívání služby masovou registrací. Systém sice bude tvrdit, že máte použít kreditní kartu, ale běžná česká debetní karta s povolenými platbami po internetu projde bez problémů. Objeví se na ní blokace 1 USD, která po měsíci vyprší.
