Effizienz im großen Maßstab: Eine Geschichte der AWS-Kostenoptimierung

Veröffentlicht: 2022-07-22

Ich habe kürzlich eine Analyseplattform für Kryptowährungen gestartet und erwarte eine kleine Anzahl von täglichen Benutzern. Als jedoch einige beliebte YouTuber die Seite hilfreich fanden und eine Bewertung veröffentlichten, wuchs der Datenverkehr so ​​schnell, dass der Server überlastet wurde und die Plattform (Scalper.AI) nicht mehr zugänglich war. Meine ursprüngliche AWS EC2-Umgebung benötigte zusätzliche Unterstützung. Nachdem ich mehrere Lösungen in Betracht gezogen hatte, entschied ich mich, AWS Elastic Beanstalk zu verwenden, um meine Anwendung zu skalieren. Die Dinge sahen gut aus und liefen reibungslos, aber ich war verblüfft über die Kosten im Abrechnungs-Dashboard.

Dies ist kein ungewöhnliches Problem. Eine Umfrage aus dem Jahr 2021 ergab, dass 82 % der IT- und Cloud-Entscheidungsträger auf unnötige Cloud-Kosten gestoßen sind und 86 % nicht der Meinung sind, dass sie einen umfassenden Überblick über alle ihre Cloud-Ausgaben erhalten können. Obwohl Amazon in seiner Dokumentation einen detaillierten Überblick über zusätzliche Ausgaben bietet, ist das Preismodell für ein wachsendes Projekt komplex. Um die Dinge verständlicher zu machen, werde ich einige relevante Optimierungen aufschlüsseln, um Ihre Cloud-Kosten zu senken.

Warum ich mich für AWS entschieden habe

Das Ziel von Scalper.AI ist es, Informationen über Kryptowährungspaare (die beim Handel an einer Börse ausgetauschten Vermögenswerte) zu sammeln, statistische Analysen durchzuführen und Kryptohändlern Einblicke in die Marktlage zu geben. Der technische Aufbau der Plattform besteht aus drei Teilen:

  • Skripte zur Datenaufnahme
  • Ein Webserver
  • Eine Datenbank

Die Aufnahmeskripte sammeln Daten aus verschiedenen Quellen und laden sie in die Datenbank. Ich hatte Erfahrung in der Arbeit mit AWS-Services, also entschied ich mich, diese Skripte durch die Einrichtung von EC2-Instances bereitzustellen. EC2 bietet viele Instance-Typen und lässt Sie Prozessor, Speicher, Netzwerk und Betriebssystem einer Instance auswählen.

Für die restliche Funktionalität habe ich mich für Elastic Beanstalk entschieden, weil es ein reibungsloses Anwendungsmanagement versprach. Der Load Balancer verteilte die Last ordnungsgemäß auf die Instanzen meines Servers, während die Autoscaling-Funktion das Hinzufügen neuer Instanzen für eine erhöhte Last handhabte. Das Bereitstellen von Updates wurde sehr einfach und dauerte nur wenige Minuten.

Scalper.AI funktionierte stabil und meine Benutzer hatten keine Ausfallzeiten mehr. Natürlich erwartete ich einen Anstieg der Ausgaben, da ich zusätzliche Dienste hinzufügte, aber die Zahlen waren viel größer als ich vorhergesagt hatte.

Wie ich die Cloud-Kosten hätte senken können

Rückblickend gab es viele komplexe Bereiche bei der Nutzung von AWS-Services in meinem Projekt. Wir werden die Budgetoptimierungen untersuchen, die ich bei der Arbeit mit gängigen AWS EC2-Funktionen entdeckt habe: Instanzen mit Spitzenleistung, ausgehende Datenübertragungen, elastische IP-Adressen sowie Beendigungs- und Stoppzustände.

Burstable-Performance-Instanzen

Meine erste Herausforderung bestand darin, den CPU-Energieverbrauch für mein wachsendes Projekt zu unterstützen. Die Datenerfassungsskripte von Scalper.AI bieten Benutzern eine Echtzeit-Informationsanalyse; Die Skripte laufen alle paar Sekunden und füttern die Plattform mit den neuesten Updates von Krypto-Börsen. Jede Iteration dieses Prozesses generiert Hunderte von asynchronen Jobs, sodass der erhöhte Datenverkehr der Site mehr CPU-Leistung erforderte, um die Verarbeitungszeit zu verkürzen.

Die günstigste von AWS angebotene Instanz mit vier vCPUs, a1.xlarge, hätte mich damals ~75 Dollar pro Monat gekostet. Stattdessen habe ich mich entschieden, die Last auf zwei t3.micro-Instanzen mit jeweils zwei vCPUs und 1 GB RAM zu verteilen. Die t3.micro-Instanzen boten genug Geschwindigkeit und Speicher für den Job, den ich brauchte, zu einem Fünftel der Kosten von a1.xlarge. Trotzdem war meine Rechnung am Ende des Monats immer noch größer als ich erwartet hatte.

Um zu verstehen, warum, habe ich die Dokumentation von Amazon durchsucht und die Antwort gefunden: Wenn die CPU-Auslastung einer Instanz unter eine definierte Baseline fällt, sammelt sie Credits, aber wenn die Instanz über die Baseline-Nutzung hinausgeht, verbraucht sie die zuvor verdienten Credits. Wenn keine Credits verfügbar sind, gibt die Instance von Amazon bereitgestellte „überschüssige Credits“ aus. Diese Möglichkeit, Credits zu verdienen und auszugeben, veranlasst Amazon EC2, die CPU-Auslastung einer Instance über 24 Stunden zu mitteln. Wenn die durchschnittliche Nutzung über die Basislinie hinausgeht, wird die Instanz zusätzlich pauschal pro vCPU-Stunde in Rechnung gestellt.

Ich habe die Datenaufnahmeinstanzen mehrere Tage lang überwacht und festgestellt, dass mein CPU-Setup, das die Kosten senken sollte, das Gegenteil bewirkte. Die meiste Zeit war meine durchschnittliche CPU-Auslastung höher als die Grundlinie.

Ein Diagramm verfügt über drei Dropdown-Auswahlmöglichkeiten, die oben auf dem Bildschirm ausgewählt werden. Die ersten beiden links sind „10. Februar 2022 – 19. Februar 2022“ und „Täglich“, gefolgt von einem kleinen eingekreisten „i“. Die dritte befindet sich auf der rechten Seite des Bildschirms und sagt "Linie" mit einem Symbol für ein Liniendiagramm. Unterhalb der Dropdown-Auswahl enthält das Diagramm zwei Liniendiagramme mit Filtern. Oben steht in der Filterzeile „Gruppieren nach: Nutzungstyp“ (der ausgewählte Filter mit blauem Hintergrund) und zeigt dann die nicht ausgewählten Filter an: „Dienst, Verknüpftes Konto, Region, Instanztyp, Ressource, Kostenkategorie, Tag , Mehr“, wobei „Ressource“ ausgegraut ist und neben den letzten drei Dropdown-Pfeile angezeigt werden. Das obere Liniendiagramm hat "Kosten ($)" auf der y-Achse, die von 0,0 bis 2,5 reichen. Das untere Liniendiagramm hat „Nutzung (vCPU-Stunden)“ auf der y-Achse, die von 0 bis 40 reicht. Beide Liniendiagramme teilen Daten, die auf der x-Achse beschriftet sind, die vom 10. Februar bis zum 19. Februar reichen, und einen Schlüssel Kennzeichnung ihrer violetten Linien: „USE2-CPUCredits:t3“. Das obere Liniendiagramm hat ungefähr acht Punkte, die linear verbunden sind, und tendiert im Laufe der Zeit nach oben: ein Punkt um (10. Februar, 0,3 $), ein zweiter um (11. Februar, 0,6 $), ein dritter um (12. Februar, 0,5 $), a ungefähr vier (14. Februar, 2,1 $), ein fünfter ungefähr (15. Februar, 2,4 $), ein sechster ungefähr (16. Februar, 2,3 $), ein siebter ungefähr (18. Februar, 2,3 $) und ein achter ungefähr (Febr. 19, $2,6). Das untere Liniendiagramm hat ebenfalls ungefähr acht Punkte, die linear verbunden sind und im Laufe der Zeit nach oben tendieren: ein Punkt um (10. Februar, 5 vCPU-Stunden), ein zweiter um (11. Februar, 15 vCPU-Stunden), ein dritter um (Feb -12, 10 vCPU-Stunden), eine vierte ungefähr (14. Februar, 40 vCPU-Stunden), eine fünfte ungefähr (15. Februar, 50 vCPU-Stunden), eine sechste ungefähr (16. Februar, 45 vCPU-Stunden) , ein siebtes ungefähr (18. Februar, 45 vCPU-Stunden) und ein achtes ungefähr (19. Februar, 55 vCPU-Stunden).
Das obige Diagramm zeigt Kostenspitzen (oberes Diagramm) und eine zunehmende CPU-Guthabenauslastung (unteres Diagramm) während eines Zeitraums, in dem die CPU-Auslastung über dem Ausgangswert lag. Die Dollarkosten sind proportional zu den ausgegebenen überschüssigen Credits, da die Instanz pro vCPU-Stunde abgerechnet wird.

Ich hatte zunächst die CPU-Auslastung für ein paar Krypto-Paare analysiert; Die Ladung war gering, also dachte ich, ich hätte viel Platz zum Wachsen. (Ich habe nur eine Mikroinstanz für die Datenaufnahme verwendet, da weniger Kryptopaare nicht so viel CPU-Leistung erforderten.) ​Ich erkannte jedoch die Grenzen meiner ursprünglichen Analyse, als ich mich entschied, meine Erkenntnisse umfassender zu machen und die Datenaufnahme zu unterstützen für Hunderte von Kryptopaaren – Cloud-Service-Analyse bedeutet nichts, wenn sie nicht im richtigen Maßstab durchgeführt wird.

Ausgehende Datenübertragungen

Ein weiteres Ergebnis der Erweiterung meiner Website waren erhöhte Datenübertragungen von meiner App aufgrund eines kleinen Fehlers. Da der Datenverkehr stetig zunahm und es keine Ausfallzeiten mehr gab, musste ich Funktionen hinzufügen, um die Aufmerksamkeit der Benutzer so schnell wie möglich zu erregen und zu halten. Mein neuestes Update war ein Audioalarm, der ausgelöst wurde, wenn die Marktbedingungen eines Krypto-Paares mit den vordefinierten Parametern des Benutzers übereinstimmten. Leider habe ich einen Fehler im Code gemacht, und Audiodateien wurden alle paar Sekunden hunderte Male in den Browser des Benutzers geladen.

Die Wirkung war enorm. Mein Fehler erzeugte Audio-Downloads von meinen Webservern, was zusätzliche ausgehende Datenübertragungen verursachte. Ein winziger Fehler in meinem Code führte zu einer fast fünfmal höheren Rechnung als die vorherigen. (Dies war nicht die einzige Folge: Der Fehler konnte ein Speicherleck im Computer des Benutzers verursachen, so dass viele Benutzer nicht mehr zurückkamen.)

Ein Diagramm ähnlich dem vorherigen, aber mit der ersten Dropdown-Liste „06. Januar 2022 - 15. Januar 2022“, den „Kosten ($)“ des oberen Liniendiagramms von 0 bis 30 und dem unteren Liniendiagramm mit „ Nutzung (GB)" auf der y-Achse, die von 0 bis 300 reicht. Beide Liniendiagramme teilen sich Daten auf der x-Achse, die vom 06. Januar bis zum 15. Januar reichen, und einen Schlüssel, der ihre violetten Linien kennzeichnet: "USE2- DataTransfer-Out-Bytes." Das obere Liniendiagramm hat ungefähr acht Punkte, die linear verbunden sind, und tendiert im Laufe der Zeit nach oben: ein Punkt um (Jan-06, 2 $), ein zweiter um (Jan-08, 4 $), ein dritter um (Jan-09, 7 $), a vierter (10. Januar, 6 $), ein fünfter (12. Januar, 15 $), ein sechster (13. Januar, 25 $), ein siebter (14. Januar, 24 $) und ein achter (14. Januar, 24 $) 15, $29). Das untere Liniendiagramm hat auch ungefähr acht Punkte, die linear verbunden sind und im Laufe der Zeit nach oben tendieren: ein Punkt um (Jan-06, 10 GB), ein zweiter um (Jan-08, 50 GB), ein dritter um (Jan-09, 80 GB), ein viertes etwa (10. Jan., 70 GB), ein fünftes etwa (12. Jan., 160 GB), ein sechstes etwa (13. Jan., 270 GB), ein siebtes etwa (14. Jan., 260 GB) , und ein Achtel (15. Januar, 320 GB).
Das obige Diagramm zeigt Kostensprünge (oberes Diagramm) und zunehmende ausgehende Datenübertragungen (unteres Diagramm). Da ausgehende Datenübertragungen pro GB abgerechnet werden, sind die Dollarkosten proportional zur ausgehenden Datennutzung.

Die Kosten für die Datenübertragung können bis zu 30 % der AWS-Preissteigerungen ausmachen. Die eingehende EC2-Übertragung ist kostenlos, aber die Gebühren für die ausgehende Übertragung werden pro GB abgerechnet (0,09 USD pro GB, als ich Scalper.AI erstellte). Wie ich auf die harte Tour gelernt habe, ist es wichtig, mit Code vorsichtig zu sein, der ausgehende Daten beeinflusst. Das Reduzieren von Downloads oder Laden von Dateien, wo möglich (oder die sorgfältige Überwachung dieser Bereiche), schützt Sie vor höheren Gebühren. Diese Pfennige summieren sich schnell, da die Gebühren für die Übertragung von Daten von EC2 ins Internet von der Arbeitslast und den AWS-regionsspezifischen Tarifen abhängen. Ein letzter Vorbehalt, der vielen neuen AWS-Kunden unbekannt ist: Die Datenübertragung zwischen verschiedenen Standorten wird teurer. Die Verwendung privater IP-Adressen kann jedoch zusätzliche Kosten für die Datenübertragung zwischen verschiedenen Verfügbarkeitszonen derselben Region vermeiden.

Elastische IP-Adressen

Auch bei Verwendung öffentlicher Adressen wie Elastic IP-Adressen (EIPs) ist es möglich, Ihre EC2-Kosten zu senken. EIPs sind statische IPv4-Adressen, die für dynamisches Cloud-Computing verwendet werden. Der „elastische“ Teil bedeutet, dass Sie jeder EC2-Instance ein EIP zuweisen und es verwenden können, bis Sie sich entscheiden, es zu beenden. Mit diesen Adressen können Sie fehlerhafte Instanzen nahtlos durch fehlerfreie ersetzen, indem Sie die Adresse einer anderen Instanz in Ihrem Konto neu zuordnen. Sie können EIPs auch verwenden, um einen DNS-Eintrag für eine Domäne anzugeben, sodass er auf eine EC2-Instance verweist.

AWS bietet nur fünf EIPs pro Konto und Region, was sie zu einer begrenzten Ressource macht und bei ineffizienter Nutzung kostspielig ist. AWS berechnet einen niedrigen Stundensatz für jeden zusätzlichen EIP und stellt zusätzliche Rechnungen, wenn Sie einen EIP mehr als 100 Mal in einem Monat neu zuordnen; Wenn Sie diese Grenzen unterschreiten, werden die Kosten gesenkt.

Zustände beenden und stoppen

AWS bietet zwei Optionen zum Verwalten des Status laufender EC2-Instances: Beenden oder Anhalten. Durch das Beenden wird die Instanz heruntergefahren und die dafür bereitgestellte virtuelle Maschine ist nicht mehr verfügbar. Alle angehängten Elastic Block Store (EBS)-Volumes werden getrennt und gelöscht, und alle lokal in der Instanz gespeicherten Daten gehen verloren. Die Instanz wird Ihnen nicht mehr in Rechnung gestellt.

Das Stoppen einer Instanz ist ähnlich, mit einem kleinen Unterschied. Die angehängten EBS-Volumes werden nicht gelöscht, sodass ihre Daten erhalten bleiben und Sie die Instanz jederzeit neu starten können. In beiden Fällen berechnet Amazon keine Gebühren mehr für die Nutzung der Instanz, aber wenn Sie sich für das Stoppen statt für das Beenden entscheiden, verursachen die EBS-Volumes Kosten, solange sie vorhanden sind. AWS empfiehlt, eine Instance nur dann zu stoppen, wenn Sie davon ausgehen, dass sie bald reaktiviert wird.

Aber es gibt eine Funktion, die Ihre AWS-Rechnung am Ende des Monats erhöhen kann, selbst wenn Sie eine Instanz beendet haben, anstatt sie zu stoppen: EBS-Snapshots. Dies sind inkrementelle Sicherungen Ihrer EBS-Volumes, die im Simple Storage Service (S3) von Amazon gespeichert sind. Jeder Snapshot enthält die Informationen, die Sie zum Erstellen eines neuen EBS-Volumes mit Ihren vorherigen Daten benötigen. Wenn Sie eine Instance beenden, werden die zugehörigen EBS-Volumes automatisch gelöscht, aber ihre Snapshots bleiben erhalten. Da S3 nach dem gespeicherten Datenvolumen berechnet wird, empfehle ich Ihnen, diese Snapshots zu löschen, wenn Sie sie in Kürze nicht verwenden. AWS bietet die Möglichkeit, die Speicheraktivität pro Volume mit dem CloudWatch-Service zu überwachen:

  1. Suchen und öffnen Sie, während Sie bei der AWS-Konsole angemeldet sind, im Dienstemenü oben links den CloudWatch -Dienst.
  2. Klicken Sie links auf der Seite unter dem reduzierbaren Menü Metriken auf Alle Metriken .
  3. Die Seite zeigt eine Liste der Dienste mit verfügbaren Metriken, einschließlich EBS, EC2, S3 und mehr. Klicken Sie auf EBS und dann auf Pro-Volume-Metriken . (Hinweis: Die EBS- Option ist nur sichtbar, wenn Sie EBS-Volumes in Ihrem Konto konfiguriert haben.)
  4. Klicken Sie auf die Registerkarte Abfrage . Kopieren Sie in der Ansicht Editor den Befehl SELECT AVG(VolumeReadBytes) FROM "AWS/EBS" GROUP BY VolumeId und fügen Sie ihn ein und klicken Sie dann auf Ausführen . (Hinweis: CloudWatch verwendet einen SQL-Dialekt mit einer eindeutigen Syntax.)

Eine Webseite wird mit einem dunkelblauen Kopfzeilenmenü oben auf der Seite angezeigt, das von links nach rechts das aws-Logo, ein Dropdown-Menü „Services“, eine Suchleiste, ein Codesymbol, ein Glockensymbol, ein Fragezeichensymbol, ein Dropdown-Text mit der Aufschrift „N. Virginia“ und ein Dropdown-Text mit der Aufschrift „Toptal Test Account“. Darunter sehen wir den Hauptteil der Webseite in Weiß. Links auf der Seite befindet sich ein Bildlaufmenü mit dem Titel „CloudWatch“ und einem „X“. Darunter, von oben nach unten, lautet das Menü: „Favoriten und zuletzt“, „Dashboards“, „Alarme“ (fett gedruckt, mit drei Drop-down-Menüs: „In Alarm“, „Alle Alarme“ und „Abrechnung“). „Logs“ (fett gedruckt, mit zwei Drop-down-Menüs: „Log-Gruppen“ und „Log-Einblicke“), „Metriken“ (fett gedruckt, mit drei Drop-down-Menüs: „Alle Metriken“, hellorange hervorgehoben, „ Explorer“ und „Streams“), „Röntgenspuren“ (fett), „Ereignisse“ (fett) und „Anwendungsüberwachung“ (fett). Alle fett gedruckten Texte im Menü haben ein Dropdown-Menü-Dreieck links vom Text. In der Mitte der Webseite wird in der oberen Hälfte der Seite ein Diagramm und in der unteren Hälfte der Seite ein Editor angezeigt. Das Diagramm hat zwei Kopfzeilen. In der ersten Zeile steht links „CloudWatch > Metrics“ (mit „CloudWatch“-Text in Blau) und rechts in Blau „Switch to your original interface“. Die zweite Zeile lautet „Unbenanntes Diagramm“ mit einem Bearbeitungssymbol auf der linken Seite und zeigt Optionen auf der rechten Seite an: „1h, 3h, 12h, 1d, 3d, 1w, Custom“ (mit „3h“ in blau und „Custom“ mit einem Kalendersymbol), „Linie“ (mit einem Dropdown-Symbol), „Aktionen“ (mit einem Dropdown-Symbol) und eine Aktualisierungsschaltfläche mit einem Dropdown-Symbol. Das Diagramm selbst enthält in der Mitte Text: „Ihr CloudWatch-Diagramm ist leer. Wählen Sie einige Metriken aus, die hier angezeigt werden sollen.“ Der Editor hat auch zwei Kopfzeilen. Die erste Zeile lautet „Browse“, „Query“ (orange hervorgehoben), „Graphed metrics“, „Options“ und „Source“ auf der linken Seite und „Add math“ (mit einem Dropdown-Symbol) und „Add Abfrage" (mit einem Dropdown-Symbol) auf der rechten Seite. In der zweiten Zeile steht links „Metrics Insights – Abfrageeditor“ und „Info“ (in Blau) und rechts „Builder“ und „Editor“ (wobei „Editor“ ausgewählt ist). Unterhalb des Editors befindet sich links eine orangefarbene Schaltfläche „Ausführen“ und rechts der Text „Use Ctrl + Enter to run query, Ctrl + Space to autocomplete“. Rechts auf der Webseite befindet sich ein weißes Menü, in dem von oben nach unten „Abfragen“ und „Hilfe“ stehen.
Eine Übersicht über die oben beschriebene Einrichtung der CloudWatch-Überwachung (dargestellt mit leeren Daten und ohne ausgewählte Metriken). Wenn Sie bereits EBS-, EC2- oder S3-Instances in Ihrem Konto haben, werden diese als Metrikoptionen angezeigt und füllen Ihr CloudWatch-Diagramm.

CloudWatch bietet eine Vielzahl von Visualisierungsformaten zur Analyse der Speicheraktivität, wie Tortendiagramme, Linien, Balken, gestapelte Flächendiagramme und Zahlen. Die Verwendung von CloudWatch zur Identifizierung inaktiver EBS-Volumes und Snapshots ist ein einfacher Schritt zur Optimierung der Cloud-Kosten.

Zusätzliches Geld in Ihrer Tasche

Obwohl AWS-Tools wie CloudWatch anständige Lösungen für die Cloud-Kostenüberwachung bieten, lassen sich verschiedene externe Plattformen für eine umfassendere Analyse in AWS integrieren. Beispielsweise zeigen Cloud-Management-Plattformen wie CloudHealth von VMWare eine detaillierte Aufschlüsselung der Bereiche mit den höchsten Ausgaben, die für Trendanalysen, Anomalieerkennung und Kosten- und Leistungsüberwachung verwendet werden können. Ich empfehle außerdem, dass Sie einen CloudWatch-Abrechnungsalarm einrichten, um Gebührenspitzen zu erkennen, bevor sie übermäßig werden.

Amazon bietet viele großartige Cloud-Services, die Ihnen helfen können, die Wartungsarbeiten von Servern, Datenbanken und Hardware an das AWS-Team zu delegieren. Obwohl die Kosten für Cloud-Plattformen aufgrund von Fehlern oder Benutzerfehlern leicht steigen können, geben AWS-Überwachungstools Entwicklern das Wissen an die Hand, um sich vor zusätzlichen Kosten zu schützen.

Mit diesen Kostenoptimierungen im Hinterkopf sind Sie bereit, Ihr Projekt auf den Weg zu bringen – und dabei Hunderte von Dollar zu sparen.

Das AWS-Logo mit dem Wort „PARTNER“ und dem Text „Advanced Tier Services“ darunter.
Als Advanced Consulting Partner im Amazon Partner Network (APN) bietet Toptal Unternehmen auf Abruf weltweit Zugang zu AWS-zertifizierten Experten.