Automatische Skalierung

Die Flexibilität cloudbasierter Architekturen bringt in der Praxis keine nennenswerten Vorteile, wenn die Skalierung nach wie vor von Hand erfolgen muss. Das manuelle Entwickeln von Autoscale-Skripts ist nicht bequem: Im Fall eines Fehlers kann es schnell zu immensen Kosten kommen, die - zumindest in vielen Abonnementplänen - im Backend von Amazon nicht einzuschränken sind.

Die klassische Architektur für einen Load Balancer ist - um einen Server-Pool herum - ein Dreieck aus einem Elastic Load Balancer, einer Cloudwatch-Instanz und einem automatischen Skalierer. Zur Erklärung: Der Balancer hat die Aufgabe, eingehende Anfragen von Kunden auf die im Server-Pool befindlichen Arbeiter (Worker-Prozesse) zu verteilen. Die Interaktion zwischen Endgerät und Server erfolgt also ausschließlich im Arbeiter und im Balancer. Cloudwatch hat die Aufgabe, Limits vorzuhalten und die Autoscaling-Politik vorzugeben. Der Autoscaler passt die Größe des auch als Auto Scaling Group bezeichneten Server-Pools dynamisch gemäß den Richtlinien des Entwicklers an, um sicherzustellen, dass immer ausreichend Kapazität zur Verfügung steht. Dabei empfiehlt es sich, Instanzen nicht auf Volldampf zu fahren. Das Hochfahren weiterer Elemente nimmt mitunter etwas Zeit in Anspruch, was zu schlechter User Experience führen kann.

Schon an dieser Stelle sei gewarnt: Load Balancer behalten die Interessen von Amazon sehr offensichtlich im Hinterkopf. Sie dürfen nicht davon ausgehen, dass ein Load Balancer nicht mehr benötigte EC2-Instanzen beendet. Es gibt Konfigura­tionen, in denen eine einmal gestartete Maschine bis zum Sankt-Nimmerleins-Tag weiterlaufen darf.

Zur Unterscheidung der verschiedenen Load Balancer ist es hilfreich, auf das klassische OSI-Schichtenmodell zurückzugreifen. Auf Layer vier findet sich die Transportschicht: In der Welt von TCP/IP handelt es sich dabei um TCP. Sowohl ein Network Load Balancer als auch ein Classic Load Balancer bewerkstelligen ihre Arbeit ausschließlich auf dieser Ebene, beschäftigen sich also nicht weiter mit den angelieferten Inhalten. Der primitivste Load Balancer hört auf den Namen Classic Load Balancer. Er ist eine Verteilungs-Engine, die TCP-, SSL-, HTTP- und HTTPS-Sessions vermitteln kann.

Der wichtigste Vorteil des Oldies ist, dass er das - formal 2013 eingestellte - EC2-Classic-Vernetzungssystem unterstützt. Trotz der Einstellung ist es nämlich möglich, bestehende Applikationen weiterhin zu warten. Wenn Sie in einer derartigen Infrastruktur Balancing durchführen wollen, müssen Sie auf Classic setzen. Sein modernerer, also in der VPC-Umgebung arbeitender Kollege namens Network Load Balancer, beschränkt sich auf TCP, bietet dafür aber fortgeschrittene Funktionen. So ist er in der Lage, auf einer Instanz mehrere Ports als voneinander unabhängige Ziele zu betrachten und voneinander unabhängig mit Sessions zu belagern. Das ist etwa dann sinnvoll, wenn man sehr alte Server-Software verwendet, die einen einzigen Kern auslasten kann - Single-Core-VMs sind nicht kosteneffektiv.

Ein weiterer Vorteil des Network Load Balancers ist seine Leistungskraft. Der Dienst bewältigt laut Amazon mehrere Millionen Anfragen pro Sekunde ohne Probleme.

Während der Network Load Balancer unter einer statischen API ansprechbar ist, ist der fortgeschrittene Application Load Balancer nur über einen DNS-String erreichbar. Der wichtigste Unterschied zu seinen Kollegen ist, dass er ausschließlich HTTP und HTTPS unterstützt. Es handelt sich also um einen auf OSI-Layer sieben arbeitenden Lastverteiler.

Wer einen solchen Balancer einsetzt, wird von Amazon automatisch als Kunde mit besonderen Zuverlässigkeitsansprüchen eingeschätzt. Daraus folgt, dass der Balancer die Verwendung von mehr als einer AZ voraussetzt. Dies kann im Fall von Server-Ausfällen Gold wert sein.

Zwei weitere interessante Features betreffen die Möglichkeit zur Inspektion des Contents. Die Zuweisung zwischen Balancer und dem für die Ausführung verantwortlichen Element kann sowohl anhand von Header-Feldern als auch anhand von Static Sessions durchgeführt werden. Der Load Balancer merkt sich beim erstmaligen Auftauchen des Clients, wo dieser wohnt. Spätere Anfragen werden immer an dasselbe Gerät weitergeleitet, was das Recyceln von in lokalen Caches befindlichen Informationen erleichtert.

In der Praxis entscheidet man zwischen Classic und Application Load Balancer, der NLB findet sich in der Literatur nur selten. Der Weg zur Unterscheidung ist einfach: Wenn Ihre Algorithmen mit IP-Adressen und TCP-Ports auskommen, so reicht der im Betrieb preiswertere Classic aus. Wollen Sie stattdessen in die HTTP-Informationen einsteigen, um detailliert zu makeln, so müssen Sie den ALB loslassen.

Abschließend noch ein paar Worte zum Internet of Things. Amazon bietet dafür eine Komplettlösung vom Embedded-Betriebssystem bis zur Event-Verarbeitung. Analog zu Microsoft setzt man auf ein Gateway, das die von den verschiedenen Endgeräten eingehenden Informationen entgegennimmt und mit AWS-Ressourcen verbindet.

Das unter AWS IoT Core laufende Produkt arbeitet im Großen und Ganzen mit dem MQTT-Protokoll, erlegt Entwicklern allerdings Schwierigkeiten auf. So wird der QoS-Level 2 prinzipiell nicht unterstützt, was bei Hochverfügbarkeitsanwendungen für Probleme sorgt. Auf der Haben-Seite steht eine als Rules Engine bezeichnete Komponente: Eingehende Informationen werden im ersten Schritt analysiert, mit diesen Daten lässt sich eine Lambda-Funktion oder Ähnliches anstoßen.

Das arbeitsintensive Makeln zwischen eingehenden Sen­sordaten und den sie bearbeitenden Aktoren sollen dabei Amazons Cloud-Dienste übernehmen - zu nicht unerheblichen Kosten. Deshalb hält sich Amazon auch nicht aus dem Geschäft mit Device Shadows und Provisionierung heraus.

Ein interessanter Aspekt, der zum Abschluss unseres Streifzugs durch AWS nicht unerwähnt bleiben soll, betrifft Free RTOS. Der einst durchaus teure Industriestandard steht seit der Übernahme durch Amazon komplett kostenlos zur Ver­fügung – und Amazon ist damit einer der we­nigen Anbieter von IoT-Cloud-Diensten mit einem eigenen Echtzeit-Betriebssystem.