Amazon Web Services (AWS) Monitoring Tutorial I - Einführung und Load-Balancer Überwachung

geschrieben am 29.08.2014
Mit Amazon Web Services (AWS) lassen sich kostengünstig IT-Strukturen in der Cloud abbilden und skalieren. Diese Tutorial-Serie zeigt anhand eines praktischen Beispiels, wie sich die verwendeten AWS-Ressourcen mit Livepane überwachen lassen. Als Beispiel für diese Tutorial-Serie soll ein klassisches Szenario dienen: der Betrieb eines skalierbaren Webshops, bestehend aus PHP-Skripten, Caching und Datenbank.

Die Architektur: Ein paar Details zu unserem Beispiel-Szenario

Bevor wir uns dem eigentlichen Monitoring zuwenden, schauen wir uns die Architektur unseres Beispiels (siehe Bild) etwas genauer an. Es werden verschiedene Dienste aus dem AWS-Universum verwendet. Allen voran die Elastic Compute Cloud (EC2). Mit EC2 können virtuelle Server betrieben werden, die manuell oder automatisch gestartet, gestoppt und dupliziert werden können. Im AWS-Jargon werden diese virtuellen Server als Instanzen bezeichnet.

Vorlagen für Instanzen - die Amazon Machine Images (AMI)

Instanzen werden in der Amazon Management Konsole gestartet. Hierzu muss ein Machine-Image ausgewählt werden. Es werden mittlerweile viele verschiedene AMIs angeboten - von Standard Windows- oder Linux Distributionen, bis hin zu fertig konfigurierten Systemen mit Webservern, Datenbankservern uvm. Das Schöne daran: Nachdem man seine Instanz nach den eigenen Wünschen eingerichtet und konfiguriert hat, kann man aus dieser wiederum ein AMI erstellen. Mit diesem AMI lassen sich dann beliebig viele gleichartige Instanzen per Knopfdruck starten.

Zustandslos und skalierbar - die Webserver

Für die Webserver wurde ein entsprechendes AMI (s.o.) erzeugt. Neben der benötigten Software (Apache, PHP, etc.) wurden hier die PHP-Skripte des Webshops eingerichtet. Dieser ist so konfiguriert, dass er als Datenbankserver die zentrale Datenbank-Instanz verwendet. Außerdem wurde die Session-Verwaltung in die Datenbank verlagert, um die Webserver-Instanzen später zustandslos zu halten. Da der Webshop Caching unterstützt, wurde zudem ein zentraler Caching-Server konfiguriert, um die Datenbank-Anfragen zu minimieren. Zuletzt wurde die Instanz so konfiguriert, dass sich diese nach der erfolgreichen Initialisierung automatisch bei dem zentralen Load-Balancer (s.u.) anmeldet.

Instanzen vom Fließband - die Autoscaling Group

Die Autoscaling Funktion von AWS ermöglicht eine weitestgehend automatische Skalierung von Instanzen. Bei der Einrichtung wird angegeben, welche Art von Instanzen mit welchem AMI gestartet werden soll. Auch eine minimale Anzahl von fehlerfreien Instanzen kann angeben werden. So sorgt Autoscaling z.B. dafür, dass immer eine bestimmte Anzahl fehlerfreier Webserver-Instanzen gleichzeitig laufen. Außerdem lässt sich auf Faktoren wie CPU-Auslastung, Antwortzeiten, etc. reagieren, um automatisch weitere Server-Instanzen zu starten. Zur Kostenersparnis können diese auch automatisch wieder heruntergefahren werden, wenn die Auslastung abnimmt.

Die Verteilung der Last

Mit den Webserver-AMIs und der Autoscaling-Group können nun also beliebig viele Webserver parallel betrieben werden. Es fehlt noch eine Komponente, die die eingehenden Anfragen an den Webshop gleichmäßig auf die verfügbaren Webserver aufteilt. Hierzu nutzen wir die Amazon Elastic Load Balancing Services und richten einen Load-Balancer ein. Alle laufenden Webserver-Instanzen melden sich automatisch beim Load-Balancer an. So weiß dieser, an welche Systeme die Anfragen verteilt werden sollen. Hier beginnt unser Monitoring, denn der Load-Balancer liefert einige Daten, die man gerne im Auge behalten möchte:

Die Antwortzeiten

Der Webshop sollte Anfragen möglichst zügig beantworten, damit die Kunden nicht völlig frustriert woanders einkaufen. Hierzu sollten die Antwortzeiten der Anwendung beobachtet werden. Den Wert können wir uns vom Load-Balancer ausgeben lassen. Dieser misst, wie lange es dauert, bis er auf eine weitergeleitete Anfrage die Antwort der dahinter geschalteten Server bekommt. Die Messung beinhaltet also die Verarbeitungszeit von Webserver + Datenbankserver (sofern dieser für die Anfrage involviert werden musste). Hierzu legen wir in Livepane ein neues CloudWatch Widget mit den folgenden Einstellungen an:

Load Balancer - Antwortzeiten - Einstellungen

Dieses Beispiel geht davon aus, dass sich die Webserver in der Region "EU-Irland" befinden. Der Namespace für Abfrage von Load-Balancer Daten lautet "Elastic Load Balancing". Und als Metrik für die Antwortzeit muss "Latency" ausgewählt werden. Mit den ausgewählten Werten für Zeitraum, Bereich und Anzahl wird festgelegt, dass die Messwerte jeweils für die letzte Stunde ausgegeben werden sollen. Nach Auswahl der Werte im Bereich "Daten" werden von der CloudWatch API die verfügbaren Parameter für die gewählte Metrik ausgegeben. Wenn z.B. mehrere Load-Balancer in der gewählten Region betrieben werden, werden diese im Feld "LoadBalancerName" angezeigt und können dort ausgewählt werden. Nach Übernahme der Parameter werden die Antwortzeiten der letzten Stunde fortlaufend in dem neuen Widget angezeigt:

Load Balancer - Antwortzeiten

Die Anzahl der aktiven Webserver

Wie oben bereits beschrieben, kann z.B. die Antwortzeit als Faktor für die Autoscaling-Group verwendet werden, damit diese bei Bedarf automatisch neue Webserver-Instanzen startet. Dementsprechend ist neben der Antwortzeit auch die Anzahl der aktiven Webserver-Instanzen für uns interessant. Hierzu legen wir ein weiteres CloudWatch Widget an:

Load Balancer - Instanz-Anzahl - Seite1

Als Darstellung wählen wir diesmal "Numerisch"

Load Balancer - Instanz-Anzahl - Seite2

Die richtige Metrik lautet hier "HealthyHostCount". Als Zeitraum verwenden wir die letzte Minute. Die anderen Parameter sind identisch zum Antwortzeiten-Widget (s.o).



Im Ergebnis sehen wir, dass die aktuellen Antwortzeiten im Moment von vier Webserver-Instanzen bewerkstelligt werden.

Es lassen sich natürlich noch weitere Load-Balancer Metriken überwachen, z.B. die Anzahl der HTTP-Fehlercodes, die Anzahl der eingehenden Requests usw. Für unser Beispiel sollen diese beiden Metriken erst einmal reichen. Im nächsten Teil des Tutorials beschäftigen wir uns mit der Überwachung des Datenbankservers und erfahren etwas über benutzerdefinierte Metriken mit Amazon CloudWatch.

Zu Teil 2 des Tutorials

Kommentar hinzufügen

Der Inhalt dieses Feldes wird nicht öffentlich zugänglich angezeigt.
Bild-CAPTCHA
Enter the characters shown in the image.