Cloud-Ressourcen stundenweise mieten

Es dürfte der Albtraum jedes Entwicklers sein: Ein US-Medium erwähnt um drei Uhr nachts den hauseigenen Service, woraufhin die Zugriffszahlen raketenartig in den Himmel schießen. Leider ist der Administrator der Server-Farm nicht erreichbar, außerdem gibt es im Rechenzentrum sowieso nur noch wenig verfügbare Kapazität.

Wer seine Ressourcen aus der Cloud bezieht, bezahlt unterm Strich sicher mehr als beim Kauf. In der Industrie kursiert die Faustregel, dass man nach dem einjährigen Mieten einer Ressource diese auch kaufen kann. Auf der Haben-Seite der Cloud-Lösung steht, dass man komplett flexibel ist: Braucht man zu einem gewissen Zeitpunkt nur wenige Ressourcen, so kann man unbenötigte Instanzen zurückgeben. Die Arbeit in der Cloud setzt jedoch ganz unterschiedliche architekturale Konzepte vo­raus, die wir näher vorstellen wollen.

Das universelle Gesetz von Cloud-Ressourcen lautet: Jede Ressource, die in der Cloud lebt, muss als vergänglich betrachtet werden. Permanent ist nur die Infrastruktur selbst. Amazon-Vertreter erklären etwa, dass es sich nicht lohnt, in ein Problem viel Aufwand zu investieren, das durch einen Reboot der Ressource problemlos behoben werden kann.

Dieses Vorgehen bewirkt Unterschiede bei der Abbildung von Strukturen aus dem gewöhnlichen Bereich in die AWS-Domäne. Statt physikalischer Server kommen in der Amazon-Welt als EC2 bezeichnete Instanzen zum Einsatz. Es handelt sich um virtuelle Maschinen, die sich im AWS-Backend ohne großen Aufwand erzeugen und wieder herunterfahren lassen. Sicherheitsbewusste Entwickler können anweisen, dass ihre VMs auf einer exklusiv genutzten Maschine laufen müssen. Dann entstehen allerdings empfindliche Zusatzkosten.

Aus der Vergänglichkeit dieser Maschinen folgt, dass der Aufbau der Speicherstruktur komplett unterschiedlich ist. Während man in einem gewöhnlichen Enterprise-Deployment oftmals davon ausgeht, dass die auf Festplatte oder SSD gespeicherten Daten zumindest eine gewisse Zeit lang überleben, ist in der AWS-Welt die Veränderung ständiger Partner. Daraus folgt, dass man für die Ewigkeit vorgesehene Informationen in separaten Speicherdiensten ablegt. Dazu bietet Amazon eine Vielzahl verschiedener Storage-Backends an, denen wir uns weiter unten zuwenden.

Vorher wollen wir einen Blick auf die geografische Verteilung der Ressourcen werfen. Denken Sie daran, dass Latenzen auch in Zeiten immer schnellerer Verbindungen ein Thema sind. Bis ein Paket aus den USA nach Australien gelangt ist, vergeht Zeit. Die Lösung ist, die Infrastruktur nahe zum Kunden zu bringen.

Als oberstes Hierarchieelement dient die Region, die die geografische Lokalisierung festlegt. Der String auf der linken Seite beschreibt den Namen, unter dem die jeweilige Region im Backend bekannt ist, rechts steht der geografische Ort.

Innerhalb der einzelnen Regionen findet sich eine Amazon-spezifische Konstruktion, die als Availability Zone (AZ) bezeichnet wird. Es sind redundante Zonen innerhalb einer Region, die über ein Hochgeschwindigkeitsnetz miteinander verbunden, sonst aber voneinander unabhängig sind. In der Praxis kann es sinnvoll sein, zusammengehörende Ressourcen in einer AZ unterzubringen, um die Latenzen zu reduzieren. Manche Dienste belegt Amazon mit Einschränkungen, die die Verteilung der Komponenten in verschiedene AZs oder Regionen unterbinden. Die Anzahl der AZs pro Region ist unterschiedlich. Amazon verspricht, in jeder Region mindestens zwei Verfügbarkeitszonen zu betreiben.

Zu guter Letzt gibt es als Edge Locations bezeichnete Standorte. Zu Redaktionsschluss waren es 149. Es handelt sich um Tore, an denen sich die AWS-Infrastruktur mit dem öffentlichen Internet verbindet. An diesen Stellen betreten oder verlassen Daten den Amazon-spezifischen Teil des Netzes.