Amazon Web Services

Die 5 häufigsten Fehler auf AWS

Michael Wittig

© Adisorn Saovadee

Nicht immer läuft alles rund in der Cloud. Der Experte für Amazon Cloud Services Michael Wittig zeigt die fünf häufigsten Fehler und wie man sie einfach in den Griff bekommt.

Seit Anfang 2015 arbeite ich als AWS Cloud Consultant und sehe jede Menge kleine und mittelgroße AWS-Umgebungen. Die meisten sind typische Web-Applikationen. Ich will die fünf häufigsten Fehler zusammenfassen, die mir dabei begegnen:

  • die Infrastruktur wird manuell verwaltet
  • Auto Scaling Groups werden nicht überall verwendet
  • CloudWatch-Metriken werden ignoriert
  • der Trusted Advisor wird nicht um Rat gefragt
  • Virtuelle Maschinen werden nicht ausgelastet

Typische Web-Applikation

Eine typische Web Applikation besteht mindestens aus:

  • Load Balancer
  • skalierbares Web Backend
  • Datenbank
typical-web-application

Eine typische Web-Applikation sieht wie im Bild aus. © Michael Wittig

Diese Architektur ist de facto Standard. Wenn Ihr System anders aussieht, sollten Sie einen guten Grund dafür haben

Fehler 1: Infrastruktur wird manuell verwaltet

Wenn Ihr AWS-Account über die webbasierte Management Console administriert wird, verwalten Sie Infrastruktur manuell. Die größten Probleme dabei sind: Es ist nicht reproduzierbar, nicht dokumentiert und fehleranfällig. Glücklicherweise löst AWS CloudFormation genau dieses Problem. Und zwar kostenlos! Statt alle AWS-Ressourcen (z. B. EC2-Instanzen, Security Groups oder Subnets) manuell zu erstellen, beschreiben Sie sie in einem Template. CloudFormation findet dann heraus, wie dieses Template in ein lauffähiges System umgewandelt werden kann. Dazu erstell CloudFormation alle Ressourcen in der richtigen Reihenfolge.

fig_infrastructureautomation

CloudFormation erstellt alle Ressourcen in der richtigen Reihenfolge © Michael Wittig

Sie können sogar Änderungen an Templates auf bereits existierende Systeme anwenden. Eine typische Web-Applikation lässt sich einfach in ein Template verwandeln. Ein Beispiel für solch ein Template finden Sie unter github.com/AWSinAction.

Es gibt keinen Grund die Infrastruktur manuell zu verwalten. Es ist unprofessionell und ein einziges Durcheinander!

Fehler 2: Auto Scaling Groups werden nicht überall verwendet

Das größte Missverständnis der Auto-Scaling-Gruppe ist, dass sie nicht nicht nur zum Vergrößern oder Verkleinern Ihrer Server-Flotte gedacht sind. Jede EC2-Instanz sollte in einer Auto-Scaling-Gruppe gestartet werden. Auch wenn es nur eine einzige Instanz ist. Die Auto-Scaling-Gruppe beobachtet Ihre Instanzen, ersetzt fehlerhafte Instanzen, bildet eine logische Einheit zur Verwaltung von mehreren EC2-Instanzen und ist kostenlos.

Für eine typische Web-Applikation sollten die Backend Server in einer Auto-Scaling-Gruppe verwaltet werden. Hauptsächlich kümmert sich die Auto-Scaling-Gruppe darum, eine bestimmte Anzahl an funktionstüchtigen Server bereitzustellen. Der Auto Scaling Part wird dadurch erreicht, dass Alarme auf Metriken wie CPU-Auslastung definiert werden, welche die Soll-Anzahl der funktionstüchtigen Servern in der Gruppe erhöht. Die Auto-Scaling-Gruppe passt dann den Ist-Zustand an den neuen Soll-Zustand an.

Lesen Sie auch: Verdächtige Aktivitäten im AWS-Account aufspüren

Fehler 3: CloudWatch-Metriken werden ignoriert

Jeder AWS Service schickt interessante Metriken an CloudWatch. Virtuelle Maschinen melden CPU-Auslastung, Netzwerk-Auslastung und Festplatten-Aktivität. Datenbanken melden Speicher- und IOPS-Auslastung. Ihr Job ist es, diese Metriken zu analysieren. Schau Sie sich die folgende CPU-Auslastung über einen Tag an.

cpu_usage

CPU Auslastung über einen Tag © Michael Wittig

Der Zacken am Anfang des Tages konnte jeden Tag beobachtet werden; immer zur selben Zeit. Riecht nach Cronjob? War ein Cronjob. Aber leider war es ein Web-Backend. Wegen diesem Cronjob war die Latenz des Systems jeden Tag für eine kurze Zeit deutlich höher. Die Lösung: Den Job auf einer extra Maschine laufen lassen. Solche Probleme lassen sich mit CloudWatch erkennen. Sie müssen nur die Metriken auswerten.

Nachdem Sie mit Ihren Metriken vertraut sind, folgt der zweite Schritt: Alarme definieren. So überwachen Sie in Zukunft das System automatisiert. Bitte aber die Reihenfolge nicht vertauschen!

Fehler 4: Trusted Advisor wird nicht um Rat gefragt

Kennen Sie den Trusted Advisor? Er checkt Ihren AWS-Account und prüft ob Sie sich an bewährte Vorgehensweisen halten. Im Fokus stehen:

  • Kosten
  • Leistung
  • Sicherheit
  • Ausfallsicherheit

Wenn Ihr Trusted Advisor Dashboard aussieht wie die folgende Abbildung, gibt es Arbeit für Sie.

trusted_advisor

Das Trusted Advisor Dashboard © Michael Wittig

Ich empfehle Ihnen, sich zuerst um die Sicherheit zu kümmern. Der Trusted Advisor kann Ihnen eine wöchentliche E-Mail schicken. Dazu müssen Sie in den Preferences nur Ihre E-Mail hinterlegen. Wenn Sie den Business Support in Ihrem AWS-Account nutzen, ist der Trusted Advisor deutlich umfangreicher.

Fehler 5: Virtuelle Maschinen werden nicht ausgelastet

Es gibt keinen Grund – außer manuell verwaltete Infrastruktur – EC2-Instanzen nicht zu verkleinern (sowie Anzahl der Maschinen als auch c3.xlarge zu c3.large), wenn diese nicht ausgelastet sind. Woher wissen Sie, ob Ihre EC2-Instanzen ausgelastet sind oder nicht? CloudWatch! So einfach ist es. Wenn Sie Auto-Scaling-Gruppen mit Scaling Rules benutzen, prüfen Sie, ob Ihre Regeln zu früh oder spät anschlagen.

Jetzt ist es an Ihnen Ihren AWS-Account zu prüfen!

wittig-meapWollen Sie mehr über Amazon Web Services erfahren? Andreas und Michael Wittig schreiben ein Buch mit dem Titel Amazon Web Services in Action. Das Buch erscheint in englischer Sprache und wurde für Entwickler und Administratoren mit Interesse an der DevOps-Bewegung geschrieben. Ohne Vorkenntnisse vorauszusetzen wird gezeigt, wie verteilte Anwendungen auf der AWS-Plattform betrieben werden.

Aufmacherbild: stormy clouds von Shutterstock / Urheberrecht: Adisorn Saovadee

Verwandte Themen:

Geschrieben von
Michael Wittig
Michael Wittig
Michael Wittig migrierte in einem kleinen Team die IT der ersten Bank in Deutschland komplett in die AWS-Cloud. Er hat einen starken Hintergrund im algorithmischen Handel, wo er tausende Gigabytes an Finanzmarkt­zeitreihen analysierte. Er benutzt die AWS-Cloud für die historische und Echtzeitanalyse von Finanzmarktdaten mit einer Vielzahl an Technologien und Programmiersprachen. Heute berät er zusammen mit seinem Bruder andere Unternehmen, wie sie die AWS-Cloud nutzen können, um ihren Datenschatz zu bergen, und er ist Entwickler der SaaS-Zeitreihen­datenbank „TimeSeries.Guru“.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: