Diagnose (und Vermeidung) der 3 wichtigsten AWS EC2-Probleme

Es gibt eine überwältigende Anzahl von Unternehmen, die ihre Kernanwendungen um die Cloud-Angebote von Amazon Web Services herum entwickeln, wie beispielsweise ihre Elastic Compute Cloud (EC2). Im Jahr 2010 meldete Amazon eine EC2-Wachstumsrate von 35 %. Es wurde für alles verwendet, von der Erstellung eines On-Demand-Supercomputing-Clusters für die Pharmaforschung bis hin zur Verstärkung des Backends für die Musikerkennungs-App Shazam.

EC2 ist äußerst nützlich für Business-IT-Teams, die enorme Rechenleistung aufbauen möchten, ohne eine physische Infrastruktur zu kaufen, und für diejenigen, die sich auf regelmäßige Spitzen der Kundennachfrage vorbereiten müssen. Davon abgesehen ist EC2 ein Werkzeug wie jedes andere. Es ist anfällig für Missbrauch oder Fehlkonfiguration, und wenn dies auftritt, kann Ihr Unternehmen keine Skalierungsmöglichkeiten mehr haben. So vermeiden Sie die häufigsten EC2-Fehler, bevor Ihre Anwendung abstürzt.

1. Verwirrende Speicherlatenz

Die Speichervolumes von Amazon EC2 (als Elastic Block Storage oder EBS bezeichnet) gibt es in zwei Varianten. Standard-Volumes liefern Daten ungefähr mit der gleichen Rate wie eine Standard-Desktop-Festplatte, aber bereitgestellte Volumes sind so konzipiert, dass sie Daten viel schneller bereitstellen. Wenn Sie einen Durchsatz von bis zu 4.000 IOPS (Eingabe-/Ausgabevorgänge pro Sekunde) benötigen, können bereitgestellte Volumes dies für Sie erledigen – vorausgesetzt, Sie springen durch mehrere Reifen.

Beispielsweise muss die verwendete Instanz mit der von Ihnen benötigten IOPS-Zahl kompatibel sein. Sie müssen die Blockgröße auf 16 KB oder weniger einstellen und auf die Blöcke muss mindestens einmal zugegriffen worden sein. Ihre Volumes werden langsamer, wenn eine Sicherung durchgeführt werden soll. Schließlich enthält Amazon EC2 anscheinend kein Tool, das Ihnen Echtzeit-IOPS-Daten von einem bestimmten Volumen liefert (obwohl dies mit Überwachungsanwendungen von Drittanbietern berechnet werden kann).

Diese letzte Einschränkung kann zu einigen Schwierigkeiten führen. Folgendes kann passieren:

• IOPS steigen ohne Administratorkenntnisse an, bis sie den Schwellenwert für ein Volume erreichen,
• Operationen beginnen anschließend in der Warteschlange
• Die gesamte Anwendung wird dann von der EBS ratenbegrenzt,
• Die Anwendung schlägt vollständig fehl.

Um dieses Problem zu beheben, müssen Sie andere Wege finden, um IOPS zu verfolgen. Die VolumeQueueLength-Metrik verfolgt die Anzahl anstehender E/A-Anforderungen. Wenn Sie feststellen, dass Ihre EBS-Volumes langsamer werden und eine hohe VolumeQueueLength zugeordnet ist, kann dies auf ein Problem mit IOPS hinweisen.

2. Inaktive EC2-Instances

Amazon kann nun sekundengenau für die Nutzung einer EC2-Instance abrechnen. Für einige Unternehmen – zum Beispiel diejenigen, die weniger als zwei Minuten flexible Kapazität gleichzeitig nutzen müssen – ist dies ein gutes Geschäft. In anderen Fällen kann es sich um ein langsames Rinnsal von Geldverschwendung handeln. Übrig gebliebene Testumgebungen, leistungsschwache Anwendungen und andere Anwendungsfälle eignen sich für nicht ausgelastete EC2-Instanzen. Wie können Sie sie aufspüren?

Metriken sind eine Möglichkeit, dieses Problem zu lösen, aber sie sind ein bewegliches Ziel. Verschiedene Anwendungen verwenden beispielsweise unterschiedliche Mengen an CPU, sodass Sie nicht einfach die CPU-Auslastung betrachten können, um zu sehen, wo die Leistungsschwächeren liegen. Sie müssen Instanzen aussortieren, bei denen alle Nutzungsmetriken niedrig sind, wobei „niedrig“ „niedriger als die Basisauslastung aller Ihrer EC2-Instanzen“ bedeutet. Instanzen mit allgemein niedrigen Nutzungsmetriken können heruntergefahren oder konsolidiert werden.

3. EC2-Speicherlecks

Es ist möglich, dass EC2-Instances nicht mehr genügend Arbeitsspeicher haben. Da einige EC2-Instances keine Swap-Volumes enthalten, können zugehörige Anwendungen nicht gleichzeitig mit der Zuweisung Speicher freigeben. Da dies in Zeiten besonders starker Anwendungsnutzung der Fall ist, ist es daher möglich, dass EC2 während der Arbeitsspitzenzeit einfriert, was den Zweck des Kaufs von EC2-Instances von vornherein mehr oder weniger vollständig zunichte macht.

Wie bei IOPS kann es schwierig sein, unter die Haube von EC2 zu sehen, um herauszufinden, welche Anwendungen zu viel Speicher verbrauchen. Während EC2 speicherintensive Prozesse automatisch beendet, ist es besser, diese Prozesse gar nicht erst beenden zu müssen. Es ist auch möglich, weitere EC2-Instances hinzuzufügen, um als Swap-Volume oder als Failover zu fungieren, falls ein wichtiger Prozess beendet wird. Das Hinzufügen dieser Instanzen ist jedoch teuer. Es gibt einen besseren Weg.

Überwachen Sie AWS EC2 mit AppNeta

Eines ist klar:AWS EC2-Instances bieten Administratoren nicht viele integrierte Tools zum Anzeigen der Leistung. Intelligente Programmierung, Failover-Planung und manuelle Überwachung von Implementierungen können Sie nur bis zu einem gewissen Punkt bringen. AppNeta bietet eine Performance-Visibility-Lösung für AWS, mit der Administratoren Fehler proaktiv aufspüren können.

Werfen Sie einen Blick in das Amazon SDN (ja, es ist tatsächlich möglich) und verstehen Sie Engpässe und Verlangsamungen mit sofortiger Klarheit. Testen Sie noch heute unsere Demo, um weitere Informationen zu erhalten.