Automatisches Skalieren in der Amazon Cloud

Selbst ist die Cloud!

Niko Eder, Benjamin Schmeling, Steffen Heinzl
©Shutterstock/Anteromite

Wer sich mit dem Thema Skalierbarkeit befasst, sieht sich meist mit zahlreichen Fragen konfrontiert: Wie muss ich meine Java-Anwendung entwickeln, damit diese skaliert? Welche Teile der Anwendung sollte ich auf einzelne Knoten verteilen, welche sollten dupliziert werden, welche aus Konsistenzgründen nur einmal instanziiert? Zunächst muss man aber wissen, wie man Knoten bzw. Ressourcen überhaupt dynamisch je nach Anforderungen bereitstellen und wieder herunterfahren kann. Häufig betrachtet ein Entwickler lediglich den Anwendungsaspekt. Die Infrastruktur ist aber keineswegs zu vernachlässigen, denn sie bildet die Basis für eine Anwendungsskalierung. Erfahren Sie, wie sich mithilfe von Amazon EC2 automatisiert Infrastrukturressourcen, d. h. Knoten anhand von Kriterien wie CPU-Last hinzu- bzw. abschalten lassen.

Einer der interessantesten Aspekte von Cloud Computing ist die Elastizität (rapid elasticity). Sie beschreibt die Fähigkeit, abhängig von der Last oder anderen Faktoren dynamisch Instanzen virtueller Maschinen hinzuzufügen bzw. wieder herunterzufahren. Amazon bietet in diesem Bereich verschiedene Dienste an, die eine Anwendung der elastischen Infrastruktur zulassen. Der grundlegende Dienst in diesem Bereich ist die Amazon Elastic Compute Cloud (EC2). EC2 ist ein Dienst, der es erlaubt, über eine Web-Service-Schnittstelle Instanzen von virtuellen Maschinen, so genannte Amazon Machine Images (AMI), zu starten und zu stoppen. Die AMIs können dabei entweder vorkonfiguriert, z. B. mit einem gängigen Betriebssystem (Abb. 1) und Webserver verwendet oder auch komplett selbst erstellt werden [1]. Weitere Vorteile von EC2 sind, dass man nur für die Ressourcen und Dienstleistungen bezahlen muss, die man tatsächlich gebraucht hat (Netzwerkverkehr, Instanzstunden etc.) und Anwendungen und Daten in verschiedene Rechenzentren auf der ganzen Welt verteilen und somit hochverfügbar anbieten kann. Geringere Latenzzeiten sind ein weiterer Vorteil, da das nahegelegenste Rechenzentrum die Anfragen eines Clients entgegennehmen kann und die Last auf die Rechenzentren aufgeteilt wird.

Abb. 1: Auswahl der verschiedenen AMI-Typen im Konfigurationsprozess einer Instanz

Um eine elastische Infrastruktur richtig nutzen zu können, muss die zu deployende Anwendung horizontal skalierbar sein, d. h. wenn man mehrere Instanzen der Anwendung verwendet, muss sich daraus eine schnellere Abarbeitung des Gesamtarbeitsvolumens ergeben. In der Regel ist das durch die Verteilung von Anfragen mittels eines Load Balancers möglich. Auch hierfür bietet Amazon EC2 bereits einen Dienst an: Elastic Load Balancing. Dadurch wird der eingehende Netzwerkverkehr auf die EC2-Instanzen verteilt.

Dieser Artikel dreht sich um einen weiteren Baustein, der für die Konfiguration einer skalierbaren Anwendung benötigt wird: automatisches Hoch- und Herunterskalieren. Diese Art der Skalierung wird über einen regelbasierten Ansatz konfiguriert und heißt bei Amazon Auto Scaling.

Ob nun mit oder ohne Load Balancer – mittels hinterlegter Regeln können zusätzliche Instanzen zur Bewältigung von Lastspitzen hinzugeschaltet werden. Für den Endnutzer ist das Zuschalten von Instanzen dabei völlig verborgen. Wird die zusätzliche Rechenleistung nicht mehr benötigt, so lassen sich die hinzugefügten Ressourcen mittels vorher definierter Regeln wieder abschalten. Der Clou an Amazon EC2 ist in so einem Fall die nutzungsgerechte Abrechnung. Demnach muss der Kunde die zusätzliche Rechenleistung nur für die beanspruchte Zeitspanne entrichten. Die teure Anschaffung zusätzlicher Hardware entfällt.

Aufmacherbild: Circuit board and binary code von Shutterstock / Urheberrecht: Anteromite

[ header = Seite 2: Installation ]

Installation

Amazon stellt für die verschiedenen Dienste diverse Möglichkeiten für eine Konfiguration zur Verfügung: eine Weboberfläche, Kommandozeilentools und/oder Web-Service-Schnittstellen. Da über den Auto-Scaling-Dienst normalerweise ein Regelwerk hinterlegt wird, wann eine Instanz hinzu (oder ab-)geschaltet werden soll, muss man zur Laufzeit nicht selbst auf Änderungen reagieren. Der gängige Weg ist daher, ein Kommandozeilentool zu verwenden, um die Regeln aufzustellen, statt dies über den Programmcode zu erledigen. Eine Einrichtung der Regeln über Eclipse ist aber auch möglich. Alle Developer Tools werden von Amazon auf der Developer-Tools-Seite angeboten [2].

Um das Auto-Scaling-Tool verwenden zu können, muss es zunächst heruntergeladen und entpackt werden. Danach muss die Umgebungsvariable AWS_AUTO_SCALING_HOME auf das Verzeichnis, in das das Tool entpackt wurde, gesetzt werden. Eine weitere Umgebungsvariable AWS_CREDENTIAL_FILE muss auf eine Datei, die den Secret Key und den Access Key enthält, gesetzt werden. Der Inhalt der Datei könnte wie folgt aussehen:

 

secretKey=xxx

accessKey=xxx

 

Die Credential-Informationen können über das Web von http://aws.amazon.com/security-credentials abgerufen werden. Als Letztes muss noch die Umgebungsvariable AWS_AUTO_SCALING_URL gesetzt werden, die angibt, für welche Region die Auto-Scaling-Regeln gesetzt werden sollen, z. B. https://autoscaling.eu-west-1.amazonaws.com für die Region eu-west-1.

Nach diesen Einstellungen ist es möglich, Regeln für eine automatische Skalierung festzulegen. Dazu müssen mehrere Schritte durchgeführt werden:

 

  • Anlegen einer Launch Config
  • Anlegen einer Scaling Group
  • Anlegen einer oder mehrerer Scaling Policies
  • Anlegen eines CloudWatch-Metric-Alarms [3]

[ header = Seite 3: Anlegen einer Launch Config ]

Anlegen einer Lauch Config

Innerhalb einer Launch Config wird dem Dienst mitgeteilt, welche Art von Instanzen bei definierten Ereignissen hinzu geschaltet werden sollen. Durch die verschiedenen Parameter wird Folgendes festgelegt:

 

  • der Instanztyp (z. B. t1.Mikro-Instanz) durch –instance-type
  • die softwareseitige Ausstattung (Betriebssystem, Webserver etc.) durch die Angabe der zu verwendenden AMI durch –image-id
  • das Monitoring (z. B. CloudWatch oder auch keins) durch –monitoring
  • die Zugreifbarkeit zukünftiger Instanzen durch –key
  • die Security Group durch –group, Letztere regelt zum Beispiel die verfügbaren Ports der VM

 

Über den folgenden Befehl wird die Launch Config mit der Bezeichnung MyLC angelegt:

 

as-create-launch-config MyLC –image-id ami-d0929fa4

–instance-type t1.micro –monitoring-disabled –key EC2_Test

–group quicklaunch-1

 

Diese soll lediglich Instanzen vom Typ t1.micro erstellen, auf Basis der verwendeten AMI mit der ID ami-d31515a7. Das detaillierte und kostenpflichte Monitoring soll dabei ausgeschaltet bleiben. Gleichzeitig soll auf den Sicherheitsschlüssel EC2-Test zurückgegriffen werden sowie auf die Security Group quicklaunch-1.

[ header = Seite 4: Anlegen einer Scaling Group ]

Anlegen einer Scaling Group

Nachdem eine Launch Config für das Auto Scaling eingerichtet wurde, wird im nächsten Schritt eine Auto Scaling Group erstellt. Diese bildet das Herzstück des Auto Scalings und dient der Referenzierung in allen weiteren Vorgängen. Eine Auto Scaling Group beschreibt dabei eine Sammlung von EC2-Instanzen, deren minimale sowie maximale Größe eingangs festgelegt wird. Ihr können wiederum Richtlinien, so genannte Scaling Policies, zugeordnet werden, die dafür sorgen, dass zu der Gruppe weitere Instanzen hinzugefügt oder von der Gruppe Instanzen entfernt werden können. Dies geht selbstverständlich nur bis zu der in der Scaling Group hinterlegten minimalen und maximalen Größe. Gleichzeitig ist ein Verweis auf die zu verwendende Launch Config notwendig.

Für das vorliegende Anwendungsszenario wird eine Scaling Group mit den folgenden Parametern erzeugt:

 

as-create-auto-scaling-group MyGroup –launch-configuration MyLC

–availability-zones eu-west-1c –min-size 1 –max-size 2

–desired-capacity 1

 

Über den Befehl as-create-auto-scaling-group wird eine Gruppe mit der Bezeichnung MyGroup erzeugt. Deren zugrunde liegende Launch Config ist die im vorherigen Schritt erzeugte MyLC. Dies hat zur Folge, dass alle der Launch Group neu hinzugefügten Instanzen mit den Hard- und Softwarespezifikationen gestartet werden, die innerhalb der Launch Config MyLC spezifiziert sind. Die availability zone regelt wiederum, in welchem Rechenzentrum die Instanzen erzeugt werden sollen. Innerhalb der Launch Config wurde lediglich die Region festgelegt. Für unser Szenario wählen wir die Zone eu-west-1c. Die Parameter min-size und max-size regeln jeweils die minimale sowie maximale Größe der Launch Group. Der minimale Wert muss dabei mindestens eins sein. Über den Parameter desired-capacity wird die Anzahl der Instanzen festgelegt, die nach Bestätigung des Befehls initial erzeugt werden sollen. In unserem Beispiel wäre dies eine Instanz.

Nach dem erfolgreichen Erstellen einer Scaling Group soll diese im weiteren Vorgehen mit zwei verschiedenen Regelwerken verknüpft werden, die die Skalierung organisieren.

[ header = Seite 5: Anlegen einer Scaling Policy ]

Anlegen einer Scaling Policy

Dazu werden der Scaling Group MyGroup zwei so genannte Scaling Policies hinzugefügt. Eine Scaling Policy legt hierbei die Regeln fest, in welchem Rahmen neue Instanzen hinzugefügt werden dürfen. Als Pflichtangaben einer Policy gelten neben der zu referenzierenden Scaling Group die Menge von Instanzen, die nach Auslösung hinzugeschaltet werden sollen, sowie die Art der Änderung, also ob die Anzahl der neu gestarteten oder heruntergefahrenen Menge einem prozentualen Wert oder einer festen Anzahl entsprechen soll. Die Scaling Policy steht im direkten Zusammenhang mit der Scaling Group sowie einem Metric Alarm – ein Kommando des CloudWatch Command Line Tools, das die Bedingungen für eine Scaling-Aktion festlegt und im folgenden Abschnitt genauer erläutert wird. Eine Scaling Group kann bis zu 25 Scaling Policies besitzen. Für den Anwendungsfall wird der Scaling Group MyGroup eine Policy für das Hinzufügen von weiteren Instanzen sowie eine Policy für das Herunterfahren von nicht mehr benötigten Ressourcen über die folgenden beiden Befehle hinzugefügt:

 

as-put-scaling-policy MyScaleUp –auto-scaling-group MyGroup

–adjustment=1 –type ChangeInCapacity –cooldown 60

 

as-put-scaling-policy MyScaleDown –type ChangeInCapacity

–auto-scaling-group MyGroup „–adjustment=-1“ –cooldown 60

 

Über den ersten Befehl wird die Scaling Policy MyScaleUp erstellt. Über die Angabe der –auto-scaling-group wird dabei auf die Scaling Group MyGroup referenziert. Die Maschine weiß somit, welcher Gruppe die benötigten Ressourcen hinzugefügt werden müssen. Im vorliegenden Beispiel soll der Typ der Änderung eine Veränderung der Kapazität bedeuten, die bei Auslösung um eins erhöht wird. Der Parameter cooldown ist optional und legt fest, wie vielen Sekunden nach Auslösung einer Policy die nächste Policy-Aktion ausgeführt werden darf. Dies ist besonders bei automatisierten Prozessen von Nutzen, da zum Beispiel nach dem Hinzufügen von neuen Rechenkapazitäten Leistungsspitzen entstehen, die je nach festgelegter Policy ungewollt weitere Ereignisse auslösen können.

Über den zweiten Befehl wird die Scaling Group MyScaleDown erstellt. Das Anlegen der Scaling Policy für das Entfernen von nicht mehr benötigten Instanzen verläuft analog. Neben der Änderung der frei wählbaren Bezeichnung wird lediglich der Parameter –adjustment= mit dem Wert -1 initiiert. Bei Ausführung der Policy soll somit die Anzahl der Instanzen um eine Maschine reduziert werden. Es ist anzumerken, dass der Parameter unter Windows in Hochzeichen gesetzt werden muss.

Nach erfolgreicher Durchführung wurden der Scaling Group MyGroup die Scaling Policies MyScaleUp und MyScaleDown hinzugefügt. Innerhalb des Kommandotools wird daraufhin je eine arn ausgegeben. Dies ist eine Zeichenkette, die im weiteren Verlauf gebraucht wird und eine Referenzierung eines CloudWatch-Alarms auf eine konkrete Scaling Policy ermöglicht. Über den Befehl

 

as-describe-policies –auto-scaling-group MyGroup

 

können die Scaling Policies von MyGroup aufgelistet werden. Das Ergebnis ist in Abbildung 2 zu sehen.

Abb. 2: Liste der Policies der Scaling Group „MyGroup“

[ header = Seite 6: Anlegen eines CloudWatch-Metric-Alarms ]

Anlegen eines CloudWatch-Metric-Alarms

Im letzten Schritt werden die erstellten Scaling Policies mit einem CloudWatch-Alarm verbunden. Dieser legt die exakten Bedingungen für das Auslösen einer Scaling Policy fest. Hierbei wird eine konkrete CloudWatch-Metrik zur Überwachung ausgewählt. Überschreitet diese einen Regelwert, wird mittels Alarm die Ausführung der jeweiligen Policy angestoßen. Da ein Alarm ein CloudWatch-internes Werkzeug ist, kann dieser nicht innerhalb des Auto Scaling Command Line Tools erstellt werden, sondern bedarf der Installation und Einrichtung des CloudWatch-spezifischen Command Line Tools.

Dessen Installation erfolgt dabei ähnlich der des Auto Scaling Tools; lediglich die Namen der Umgebungsvariablen variieren leicht. Die Umgebungsvariable AWS_CLOUDWATCH_HOME gibt an, in welchen Ordner das CloudWatch Command Line Tool (heruntergeladen und) entpackt wurde. Die Umgebungsvariable AWS_CREDENTIAL_FILE muss genauso gesetzt werden wie bei der Einrichtung des Auto Scaling Tools. Die Umgebungsvariable AWS_CLOUDWATCH_URL gibt an, für welche Region ein Monitoring eingestellt wird, in unserem Fall eu-west-1 durch den URL https://monitoring.eu-west-1.amazonaws.com.

Beide Policies werden nun mit einem Metric-Alarm verknüpft. Der generelle Aufbau einer Alarmanweisung setzt sich wie folgt zusammen: Über den Befehl mon-put-metric-alarm kann ein Alarm erstellt werden. Den wichtigsten Parameter stellt dabei der –comparison-operator dar. Er legt fest, ob der Alarm bei Überschreitung oder Unterschreitung einer festgelegten Maßzahl ausgelöst werden soll. Diese wird über den –threshold-Parameter auf die gewünschte Größe gesetzt. Eng an diesen Wert gekoppelt ist die –period. Sie spezifiziert die Zeitspanne anhand von Sekunden, in der die Threshold-Zahl innerhalb der Metrik überschritten oder unterschritten werden muss, ehe der Alarm und damit auch die Scaling Policy ausgelöst wird. Um eine eindeutige Referenzierung der gewünschten Scaling Policy zu ermöglichen, ist für den Parameter –alarm-actions die arn mit anzugeben, die jeweils nach erfolgreicher Erstellung einer Scaling Policy auf der Kommandozeile ausgegeben wurde. Über folgenden Befehl wird ein Metric-Alarm namens HighCPUAlarm angelegt, der die Scaling Policy MyScaleUp referenziert und damit bei Auftreten des Alarms ein Hochskalieren auslöst:

 

mon-put-metric-alarm HighCPUAlarm –comparison-operator GreaterThanThreshold –evaluation-periods 1 –metric-name CPUUtilization –namespace „AWS/EC2“

–period 60 –statistic Average –threshold 50 –alarm-actions arn:aws:autoscaling:eu-west-1:316041782606:scalingPolicy:89636ce2-facb-4ba3-8296-f6121d01abdf:autoScalingGroupName/MyGroup:policyName/MyScaleUp

–dimensions „AutoScalingGroupName=MyGroup“

 

Die Regelauslösung ist dabei von der CPU-Auslastung der Auto Scaling Group MyGroup abhängig, die ab einem überschrittenen Wert von 50 Prozent in einem Zeitfenster von 60 konstanten Sekunden den Alarm auslöst und damit auch die Policy MyScaleUp. Dies hätte zur Folge, dass der Scaling Group eine weitere Instanz hinzugefügt wird.

Die Einrichtung eines Metric-Alarms für das Downscaling verläuft analog zum Upscaling durch folgenden Befehl:

 

mon-put-metric-alarm LowCPUAlarm –comparison-operator LessThanThreshold –evaluation-periods 1 –metric-name CPUUtilization –namespace „AWS/EC2“ –period 60 –statistic Average –threshold 49 –alarm-actions arn:aws:autoscaling:eu-west-1:316041782606:scalingPolicy:d906797b-518b-4cd4-a4d4-09ad599c730d:autoScalingGroupName/MyGroup:policyName/MyScaleDown    –dimensions „AutoScalingGroupName=MyGroup“

 

Ein Unterschied ergibt sich im gewählten Operator LessThanThreshold, der dafür sorgt, dass der Alarm bei einer Unterschreitung der Kenngröße ausgelöst wird. Für das Fallbeispiel wurde der Wert auf eine CPU-Auslastung von 49 Prozent gesetzt. Ein weiterer Unterschied ist die Verknüpfung mit der Policy MyScaleDown. Diese Verknüpfung sorgt dafür, dass bei Eintreten des Alarms innerhalb der Scaling Group MyGroup eine Instanz heruntergefahren wird. Nach erfolgreicher Eingabe wurde den beiden Scaling Policies somit jeweils ein Metric-Alarm zugeordnet. Über den Befehl

 

as-describe-scaling-activities –auto-scaling-group MyGroup –headers –show-long view

 

kann über das Log nachvollzogen werden (Abb. 3), ob eine Skalierung erfolgt ist.

Abb. 3: Logeintrag, der eine Upscaling-Aktivität repräsentiert

Über den Befehl

 

as-describe-auto-scaling-instances –headers

 

kann die Anzahl der aktiven Instanzen erfragt werden (Abb. 4).

Abb. 4: Anzahl der gerade laufenden Instanzen

Wie wir sehen können, wurde ein Upscaling einmal ausgeführt, da derzeit zwei Instanzen laufen. Abbildung 5 zeigt in diesem Zusammenhang die CloudWatch-Metrik der CPU-Auslastung innerhalb der AWS Management Console. Diese verdeutlicht den Rückgang der Rechenlast nach dem Start der zweiten VM.

Abb. 5: CloudWatch-CPU-Auslastung

Da auf ein kostenpflichtiges Monitoring verzichtet wurde, treten ca. fünf Minuten Zeitverzug bei den Messungen auf. Dieser Zeitverzug muss innerhalb des Skalierungsprozesses berücksichtigt werden, um die Skalierung sowie eine realistische Wertausgabe im Zuge des Monitorings zu gewährleisten.

[ header = Seite 7: Fazit ]

Fazit

In diesem Artikel haben wir die automatische Skalierbarkeit von Amazon EC2 gezeigt. Hierbei wird durch das Zusammenspiel mehrerer Features, wie z. B. Auto Scaling und CloudWatch, eine automatische Skalierbarkeit von Ressourcen erreicht. Hierzu haben wir zunächst eine Launch Config angelegt, um zu definieren, welche Arten von Instanzen hochgefahren werden sollen. Weiterhin haben wir eine Scaling Group erstellt, die die Launch Config referenziert und u. a. die maximale, minimale und angestrebte Zahl der Instanzen festlegt. Diese Gruppe wird dann wiederum von mehreren Scaling Policies referenziert, die u. a. definieren, wie viele Instanzen beim Skalieren zu- bzw. abgeschaltet werden sollen. Schließlich wurden CloudWatch-Metric-Alarme definiert, die bei bestimmten Bedingungen, wie z. B. bei hoher CPU-Last, eine der definierten Policies auslösen und somit für das automatische Skalieren sorgen. All das ließ sich bequem von der Kommandozeile konfigurieren und erfordert zur Laufzeit keinerlei manuelle Eingriffe. Es ist jedoch auch möglich, die Ereignisse in Logs und Auslastungsvisualisierungen manuell zu beobachten und ggf. einzugreifen, falls dies erforderlich ist. Alles in allem ist Amazon EC2 in Bezug auf automatische Skalierbarkeit eine runde Sache. Wer noch einen Schritt weitergehen möchte und sogar die beschriebenen Konfigurationsschritte automatisch zur Laufzeit durchführen möchte, kann dies mit den angebotenen Java-Programmierschnittstellen unter Eclipse tun [4].

Geschrieben von
Niko Eder
Niko Eder
Niko Eder ist Studierender an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt. Nach erfolgreichem Abschluss des Bachelorstudiums der Wirtschaftsinformatik mit dem Schwerpunkt E-Commerce studiert er im Zuge des konsekutiven Masterprogramms Informationssysteme.
Benjamin Schmeling
Benjamin Schmeling
Benjamin Schmeling ist Teamleiter der Softwareentwicklung bei UBL Informationssysteme und ist dort zuständig für die Entwicklung von kundenindividuellen Softwarelösungen, Integrationslösungen und Strategy Services. Er beschäftigt sich in diesem Rahmen u. a. mit Themen wie der modellgetriebenen Softwareentwicklung, serviceorientierten Architekturen und Cloud Computing.
Steffen Heinzl
Steffen Heinzl
  Steffen Heinzl ist Professor an der Hochschule für angewandte Wissenschaften Würzburg-Schweinfurt in den Bereichen Web-Engineering und Cloud Computing. Nach seiner Promotion an der Philipps-Universität Marburg arbeitete er als Forscher bei SAP Research und als IT-Architekt bei der T-Systems International GmbH. Seine Forschungs- und Entwicklungsinteressen liegen in den Bereichen Cloud Computing – insbesondere Platform as a Service – und Web Services. Ferner ist er Autor des Buchs „Middleware in Java“.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.