10 Tipps zum Kostensparen bei der Verwendung der Windows Azure Platform

In einem zurückliegenden Blog-Post habe ich das Kostenmodell unter die Lupe genommen und die Frage beantwortet “Wie viel kostet mich das Ganze nun unterm Strich?”. Während bei Azure keine Bereitstellungskosten anfallen, werden Bereithaltung und Nutzung in Rechnung gestellt. Daraus lässt sich bei der Frage, wie denn nun Kosten gespart werden können unmittelbar zwei naheliegende Empfehlungen ausgesprochen werden:

• Minimiere die Bereithaltung von Azure Ressourcen
  D.h. halte die Menge von Azure Ressourcen (z.B. VM-Instanzen, Datenbanken, Speicherblöcke, …) und die Zeitdauer, für die sie bereitgehalten werden, so gering wie möglich.
• Minimiere die kostenverursachende Nutzung von Azure Ressourcen
  D.h. nutze die benötigten Azure Ressourcen so sparsam wie möglich, vermeide nach Möglichkeit all die Transaktionen, die Kosten verursachen (z.B. Zugriffe auf Windows Azure Storage, Datentransfers, …)
   

Diese beiden Empfehlungen sind freilich recht allgemein gehalten und geben nur unzureichend Hinweise auf konkrete Handlungen, die zur Kostenminimierung durchgeführt werden sollten. Aus diesem Grund möchte ich hier die aus meiner Sicht 10 wichtigsten Tipps zum Kostensparen auflisten:

Tipp 1: Nutze die gebuchten Service-Instanzen so gut es geht aus!

Ja, auch beim Cloud Computing gibt es sie: die “eh da”-Kosten, d.h. Kosten, die für bestimmte Ressourcen ohnehin anfallen und deshalb Anreize geben, diese Ressourcen maximal auszulasten. Im Falle von Azure betrifft dies primär die bereitgehaltenen Rechenkerne. Windows Azure reserviert für den Anwender die Zahl an Rechenkernen, die aufgrund der Service-Architektur für die Rollen und die definierten Instanzgrößen benötigt werden. Bei der Rechnungsstellung wird allerdings nicht berücksichtigt, ob diese Rechenkerne voll ausgelastet, oder zumeist “idle” waren. Es empfiehlt sich deshalb neue Funktionalitäten auf die bestehenden Rechenkerne zu legen, anstatt unnötig neue Rechenkerne zu reservieren. Konkrete Beispiele hierfür sind:

• Betrieb mehrere Websites und Web Applikationen in einer Web Role (dank Full-IIS möglich)
• Kein unnötiges Aufsplitten von Rollen. Für sehr viele Web Anwendungen ist eine einzige Web Role völlig ausreichend. Es kann sinnvoll sein, Geschäftslogik in Worker Roles auszulagern, immer notwendig ist dies aber nicht.
   

Tipp 2: Minimiere (idealerweise automatisiert) die Zahl der ausgeführten Instanzen!

Analog zu Tipp 1, nach dem die bereitgehaltenen Instanzen möglichst ausgelastet werden sollten, empfiehlt es sich natürlich auch, überschüssige Instanzen zur Laufzeit (idealerweise automatisiert) abzuschalten und erst wieder bei steigender Last hinzuzunehmen. In einem zurückliegenden Blog-Post habe ich beschrieben, wie eine solche Auto-Skalierung recht einfach realisiert werden kann.

Es ist an dieser Stelle leider nicht möglich allgemeingültige Regeln aufzustellen, nach denen Instanzen hinzu- oder abgeschaltet werden sollen. Dies hängt vom Typ der Anwendung und der “Last”-Definition ab. Beispielsweise kann als Last-Metrik die Prozessorauslastung herangezogen werden. Über einem gewissen Schwellwert (z.B. mehr als 80%) werden Instanzen hinzugeschaltet, unterhalb eines anderen Wertes (z.B. weniger als 40%) werden Instanzen entfernt.

Tipp 3: Lösche Staging-Deployments, sobald sie nicht mehr benötigt werden!

Windows Azure bietet die Möglichkeit, Cloud Services zunächst in einer eigenen Staging-Umgebung zu testen, bevor sie in die Produktivumgebung eingespielt wird. Die Staging-Umgebung bietet dabei die gleichen Möglichkeiten wie die Produktivumgebung. Aus diesem Grund fallen für den Einsatz dort die gleichen Kosten an wie für die Produktivumgebung. Während Testphasen steht diesen Kosten auch eine konkrete Nutzung der Umgebung gegenüber. Zwischen den Testphasen ist dies allerdings nicht so. Werden entsprechende Deployments also nicht gelöscht, fallen Kosten an, ohne dass diesen eine Nutzung gegenübersteht. Es empfiehlt sich deshalb undbedingt, Staging-Deployments zwischen Testphasen zu löschen.

Tipp 4: Wenn Deployments nicht mehr benötigt werden, lösche sie vollständig!

Die Betonung bei diesem Tipp liegt auf dem Wort “vollständig”. Für die Kosten macht es nämlich durchaus einen Unterschied, ob eine Service-Rolle läuft (Status: running), angehalten ist (stopped) oder gelöscht ist (deleted). Für die Kosten gilt:

• Status “running”: Es fallen Kosten an
• Status “stopped”: Es fallen die gleichen Kosten wie bei “running” an
• Status “deleted”: Es fallen keine Kosten an

Windows Azure gibt zwar im Entwicklerportal eine Warnung aus, falls Instanzen im Zustand “stopped” ist (siehe Abb 1), dies wird aber leicht übersehen.

Abb 1: Warnung bei deaktivierten aber nicht gelöschten Rollen

Deshalb gilt die Regel: wenn Rollen deaktiviert werden sollen, sollten sie auch gelöscht werden, um nicht unnötig Kosten zu verursachen.

Wichtig: Es ist ausreichend die Rollen zu löschen, um Kosten zu vermeiden. Der Service selbst kann bestehen bleiben, wenn beispielsweise der URL für den Service bestehen bleiben soll (wird der Service gelöscht, wird der URL freigegeben).

Tipp 5: Wähle, wenn möglich, immer die kleinste Instanzgröße für Deine Rollen!

Windows Azure bietet für Rollen-Instanzen fünf Größenalternativen an. Sowohl Leistungs- als auch Kostenparameter skalieren hierbei linear, d.h. M ist doppelt so groß und doppelt so teuer wie S, L ist doppelt so groß und doppelt so teuer wie M etc. Um möglichst freingranular skalieren zu können, empfiehlt es sich deshalb, grundsätzlich die kleinste Instanzgröße XS zu wählen (in der Regel verbaut man sich dadurch nichts, da man leicht mehrere Instanzen hinzuschalten kann, um das Äquivalent einer größeren Einheit zu erhalten).

VM Größe	XS	S	M	L	XL
CPU	Shared	1,6GHz	2x1,6GHz	4x1,6GHz	8x1,6GHz
RAM	768 MB	1,7 GB	3,5 GB	7 GB	14 GB
HDD	20 GB	225 GB	490 GB	1000 GB	2040 GB
Mbps	5	100	200	400	800
Preis/h	0,0355€	0,0852€	0,1704€	0,3408€	0,6816€

Tabelle 1: Instanzgrößen in Windows Azure

Natürlich gibt es auch Gründe für die anderen Instanzgrößen, weshalb ich die Regel etwas allgemeiner formulieren möchte:

Wähle immer die kleinste Instanzgröße für eine Rolle, es sei denn…

• es muss die Rechenleistung eines Rechenkerns exklusiv zur Verfügung stehen (dann Größe S oder höher)
• es wird Multi-Core-Funktionalität in der Rolle benötigt (dann Größe M oder höher)
• es besteht hoher Hauptspeicher- oder Bandbreitenbedarf (dann Größe L oder XL)
   

Tipp 6: Beschränke die Überwachung Deiner Anwendung auf das Nötigste!

Durch den Einsatz der Windows Azure Diagnostics API haben Anwender zur Laufzeit je nach Konfiguration Zugriff auf nahezu alle Performanz- und Diagnoseinformationen der Anwendungsinstanzen. Diese Informationen werden in regelmäßigen Abständen oder auf Anforderung in Windows Azure Storage (je nach Information Blob oder Table Storage) übertragen. Für die Nutzung dieses Speichers fallen die üblichen Storage Kosten an: zum einen zur Übertragung der Information in den Storage und zum anderen für den Platz der von den Daten belegt wird. Es empfiehlt sich daher, die Überwachung auf das Nötigste zu beschränken

Tipp 7: Nutze bereits erworbene Kontingente bzw. nutze Paketangebote!

Je berechenbarer der Konsum von Azure Leistung ist, desto mehr Möglichkeiten ergeben sich, durch Nutzung Commitment-basierter Angebote Kosten zu sparen. So lassen sich beispielsweise durch Kauf eines Development Accelerator Core-Pakets bis zu 54% Kosten sparen. Hierbei verpflichtet sich der Nutzer zur Abnahme eines gewissen Kontingents an Azure Ressourcen. Diese erhält er dann zu einem entsprechend herabgesetzten Preis. Während die Kosten bei einer rein nutzungsabhängigen Abrechung linear mit der Nutzung steigen, erhält der Nutzer beim Paketangebot einen Fixpreis. Dieser Sachverhalt ist in Abb 2 dargestellt. Durch einfachen Kostenvergleich lässt sich festhalten, dass sich der Einsatz eines Development Accelerator Core-Pakets bereits ab 500 Nutzungsstunden lohnt (wenn ausschließlich Rechenstunden verglichen werden).

Abb 2: Kostenverlauf bei Einsatz eines Developer Accelerator Core

An dieser Stelle sei auch noch auf andere Pakete hingewiesen, die vielen Anwendern sogar ohne Kosten zur Verfügung stehen:

• MSDN Premium und Ultimate Abonnenten haben bereits Azure Ressourcen in ihrer Subscription
• Microsoft Partner können ebenfalls Azure Ressource über Cloud Essentials nutzen
   

Paketangebote und nutzungsabhängige Abrechnung lassen sich einfach kombinieren. Jeglicher Verbrauch, der über die gebuchten Kontingente hinaus geht, wird rein nutzungsabhängig abgerechnet.

Tipp 8: Speichere große Binärdaten in Windows Azure Blob Storage und nicht in SQL-Azure!

SQL Azure bietet gegenüber dem Windows Azure Storage den Vorteil, dass bereits alle Speicheroperationen über den Datenbank-Preis abgegolten sind. Windows Azure Storage bietet deutlich kostengünstigeren Speicherplatz an, allerdings fallen für Speichertransaktionen (read, write, update, …) Kosten an. Wer für bestimmte Daten also kein relationales Speichermedium benötigt, sollte Daten tendenziell eher im kostengünstigeren Windows Azure Storage ablegen. Dies gilt insbesondere für große Binärdaten (Videos, Bilder etc.). Diese sollten nach Möglichkeit in Windows Azure Blob Storage ausgelagert werden. Dadurch kann die Nutzung von SQL Azure auf rein relationale Daten beschränkt, die Datenbankgröße reduziert und auf eine kostengünstigere Edition umgestiegenwerden.

Tipp 9: Optimiere den Gültigkeitszeitraum von Zugriffs-Token!

Dieser Tipp betrifft die Windows Azure AppFabric bzw. deren Access Control Service (ACS). Bei diesem fallen bei jeder Zugriffsprüfung Transaktionskosten an. Nach erfolgreicher Zugriffsprüfung stellt der ACS dem Client ein Security Token aus, mit der sich der Client für einen gewissen Zeitraum (dem Gültigkeitszeitraum des Tokens) beim Server authentifizieren kann. Um die Zahl der Zugriffsprüfungen zu verringern, sollte der Gültigkeitszeitraum so groß wie möglich gesetzt werden, wie aus sicherheitspolitischen Gründen noch vertretbar ist. Dadurch kann der Client das Token öfter ohne Rücksprache mit dem ACS verwenden.

Tipp 10: Aktiviere Client-seitiges Caching und nutze Paging bei der Anzeige größerer Datenmengen!

Bei der Windows Azure Platform fallen für jeglichen Datentransfer, der über Windows Azure Rechenzentrumsgrenzen hinaus geht, Kosten an. Es liegt deshalb nahe, alle Möglichkeiten auszuschöpfen, die diesen Datentransfer reduzieren. Beispiele für Maßnahmen sind:

• Einsatz von Client-seitigem Caching, um wiederholte Datentransfers von Windows Azure zu vermeiden
• Einsatz von Paging bei der Anzeige größerer Datenbestände
• etc.
   

Natürlich können diese Tipps nicht immer und überall beherzigt werden. Diese 10 Hinweise können allerdings als Checkliste verwendet werden, um eigene Anwendungen auf Kosteneinsparungspotenziale zu prüfen.

Wer noch weitere Hinweise hat … immer nur her damit!!!
Ich freue mich über jeden Kommentar.