Celkem často slyšíme od našich vývojářů a dalších zákazníků stesky, že neví, jakým způsobem vypočítat náklady na provozování řešení ve Windows Azure. Nejde o to, že by nebyly k dispozici přesné informace Problém spočívá v jejich interpretaci a dobrání se k finálnímu číslu. Tento text se vám to pokusí na dvou příkladech ilustrovat.

Obecné principy

Windows Azure, stejně jako ostatní podobná cloudová řešení, je založen na platbě za spotřebu. Účtování je podobné jako např. u mobilních operátorů, kde máte tarif na hovory, SMSky, poplatky za datové přenosy apod. U Windows Azure je to velmi podobné. Celková platba se může skládat z těchto položek (některé služby samozřejmě nemusíte využívat, tudíž za ně neplatíte):

  • Hodiny existence vašich virtuálních počítačů – účtuje se za každou hodinu, kdy počítač existuje a je nasazen, ať už běží nebo neběží. Cena závisí na velikosti vybraného virtuálního stroje, nejběžnější model má velikost Small, obnáší 1.6 GHz CPU, 1.75 GB RAM, 225 GB HDD a stojí 0.12 $/hodina.
  • Relační databáze SQL Azure – základní sazba je 9.99 $/GB/měsíc. Můžete si objednat různé pevně dané velikosti databáze a ty určují maximální nepřekročitelnou velikost (a tedy horní hranici nákladů). Platíte ovšem podle skutečné spotřeby zaokrouhlované nahoru na pevně dané velikosti. Například pokud si objednáte edici Business velikosti 30 GB, vaše platba nikdy nemůže být vyšší než 299.97 $/měsíc. Pokud ovšem data v databázi zabírají pouze 14 GB, platíte pouze 199.98 $/měsíc, což je cena za nejbližší vyšší velikost v Business edici (20 GB). Do velikosti se počítají tabulky, indexy a definice objektů (technicky MDF soubor), nikoliv pak transakční logy nebo replikovaná data. Částka se rozpočítává po dnech tak, aby to měsíčně vyšlo podle výše uvedených částek.
  • Přenenesené GB přes hranice serverovny. Cena záleží na umístění vašich prostředků, pro Evropu činí 0.10 $/GB pro směr dovnitř do serverovny a 0.15 $/GB pro směr ven ze serverovny.
  • Data uložená v Azure Storage – platí se jednoduše, a to přesně lineárně 0.15 $/GB/měsíc. Částka se rozpočítává po dnech tak, aby se účtovalo podle skutečné spotřeby v jednotlivých dnech a měsíčně vyšlo tak, je je výše uvedeno.
  • Transakce provedené nad Azure Storage – platí se za každou operaci čtení a zápisu, cena je 0.01 $/100.000 transakcí.
  • Azure AppFabric – tyto služby jsou využívány pouze ve zlomku řešení, představují obvykle zanedbatelnou částku a nebudeme si jimi komplikovat situaci.

Příklad 1: Vysoce dostupná firemní aplikace

Firma potřebuje dát zaměstnancům k dispozici aplikaci, která musí být vysoce dostupná. Nechce ale budovat farmu webových serverů a cluster databázových serverů, nechce platit za licence, neboť se jedná o jednorázovou částku v řádu statisíců korun. Aplikace bude spravovat řádově jednotky GB dat v relační databázi. Přistupuje k ní každý den 100 uživatelů. Každý uživatel vygeneruje každý pracovní den (21 pracovních dní) provoz 8 MB směrem k uživateli a 2 MB směrem od uživatele. Z důvodu vysoké dostupnosti byla zvolena farma 2 serverů velikosti Small a databáze SQL Azure Buiness Edition o velikosti 10 GB (zde je vysoká dostupnost dat zajištěna přímo platformou).

Položka

Jednotka

Množství

Jednotková cena/$

Celková cena/$

Výpočetní hodina instance Small

1 hodina

2 instance x 31 dní x 24 hodin = 1488 hodin

0.12

178.56

SQL Azure, Business

10 GB

1

99.99

99.99

Provoz k uživateli

1 GB

100 uživatelů x 21 dní x 8 MB/1024 = 16.41 GB

0.15

2.46

Provoz od uživatele

1 GB

100 uživatelů x 21 dní x 2 MB/1024 = 4.10 GB

0.10

0.41

Data v Azure Storage

     

0

Transakce Azure Storage

     

0

CELKEM za 1 měsíc

     

281.42

Příklad 2: Web pro reklamní kampaň

Firma připravuje virální reklamní kampaň založenou na videích ve vysokém rozlišení. Kampaň bude trvat pouze měsíc, tudíž se nevyplatí investovat do vlastního hardwaru. Hardware lze sice pronajmout, ale předem nelze odhadnout, jak bude kampaň úspěšná a jaký hardware bude potřebovat – elasticita cloud řešení se jeví velmi výhodná, neboť lze očekávat mimořádný nápor, jehož nezvládnutí by nenapravitelně poškodilo celou kampaň. V modelovém výpočtu se uvažuje se 100,000 návštěvníky během měsíce. Videa budou uložena v Azure Storage, průměrná délka videa je 30 MB, bude jich celkem 10 a průměrný návštěvník se podívá na 3 videa. Ostatní síťový provoz je zanedbatelný – 1 MB směrem k uživateli a 100 kB od uživatele. Web bude zpočátku spuštěn na farmě 2 serverů velikosti Small, v případě velkého zájmu lze jejich počet snadno navýšit. Řešení nevyžaduje relační databázi – bude se ukládat pouze profil uživatele, což obnáší uložených 10 kB a 5 transakcí na uživatelskou návštěvu. Celé řešení je mimořádně škálovatelné.

Položka

Jednotka

Množství

Jednotková cena/$

Celková cena/$

Výpočetní hodina instance Small

1 hodina

2 instance x 31 dní x 24 hodin = 1488 hodin

0.12

178.56

SQL Azure

     

0

Provoz k uživateli (videa)

1 GB

100,000 uživatelů x 3 přístupy x 30 MB/1024 = 8789 GB (téměř 9 TB !!!)

0.15

1318.35

Provoz k uživateli (ostatní)

1 GB

100,000 uživatelů x 1 MB /1024 = 98 GB

0.15

14.7

Provoz od uživatele

1 GB

100,000 uživatelů x 100 kB/1024/1024 = 9.5 GB

0.10

0.95

Data v Azure Storage (videa)

1 GB

10 videí x 30 MB/1024 = 0.29 GB

0.15

0.04

Data v Azure Storage (ostatní)

1 GB

100,000 uživatelů x 10 kB/1024/1024 = 0.95 GB

0.15

0.14

Transakce Azure Storage (videa)

10.000 transakcí

100,000 uživatelů x 3 transakce = 300,000 transakcí

0.01

0.30

Transakce Azure Storage (ostatní)

10.000 transakcí

100,000 uživatelů x 5 transakcí = 500.000 transakcí

0.01

0.50

CELKEM za 1 měsíc

     

1513.54

Dodatek: Jak zjistit množství přenášených dat

Na Internetu najdete celou řadu různých nástrojů a doplňků prohlížečů umožňující zjistit velikost stránky a měřit provoz mezi uživatelem a serverem. Nemám ambice je hodnotit nebo srovnávat. Jako příklad uveďme Internet Explorer 9. Pokud stisknete F12, objeví se nástroje pro vývojáře. Přejdete-li na stránku Network a zvolíte Start capturing, zobrazí se vám po načtení stránky objem dat putujících oběma směry dole ve stavovém řádku.

image

Další alternativou je měřit skutečnou spotřebu na straně serveru, např. dlouhodobým sledování výkonnostních čítačů anebo analýzou zaznamenaných logovacích souborů.

Michael