Schätzung der Gesamtbetriebskosten (TCO) für die Modernisierung von Workloads auf AWS mittels Containerisierung – Teil 2

von Kiran Kuppa und Keith Andruch, übersetzt von Tobias Nitzsche.

Einleitung

Im ersten Teil dieser Serie haben wir die Methodik zur Berechnung der Gesamtbetriebskosten (Total Cost of Ownership, TCO) für Containerisierung dargelegt und ein erstes Szenario betrachtet, in dem wir die TCO anhand von Server-Inventardaten schätzten. In diesem zweiten Teil widmen wir uns einem weiteren Szenario, bei dem wir die TCO ausschließlich auf Basis von Informationen auf Anwendungsebene berechnen werden.

Szenario 2: Berechnung der Gesamtbetriebskosten (TCO) basierend auf Anwendungsinformationen

In diesem Szenario haben Sie Zugriff auf ein Inventar von Anwendungen, aber keine spezifischen Informationen über die Server. Trotzdem können Sie die Kosten für AWS- Ressourcen und den Aufwand für die Containerisierung schätzen. Diese Schätzungen basieren auf Annahmen über die Anwendungen, um eine erste Einschätzung der Gesamtbetriebskosten zu erhalten.

Eine kurze Wiederholung aus dem ersten Teil: Um die Gesamtbetriebskosten zu berechnen, müssen wir folgende fünf Schritte befolgen.

Um das beschriebene Vorgehen besser zu verdeutlichen, führen wir den Fünf-Schritte-Prozess an einem beispielhaften Workload durch. Zunächst ist es erforderlich, die Schritte 1 bis 3 zu vollziehen, um festzulegen, welche Anwendungen wir in AWS-Container überführen möchten, bevor wir mit der Kostenschätzung beginnen.

Schritt 1 (Anwendungsbeurteilungen):

Hier zielen wir auf drei mehrschichtige Anwendungen ab, die aus verschiedenen Technologiestacks bestehen.

Schritt 2 (Auswahl des Container-Dienstes):

Wir entscheiden uns für den Amazon Elastic Container Service (ECS) als unseren Container-Dienst. Um die Dinge einfach zu halten, werden wir die Verwendung eines Docker-Image-Registers (Amazon ECR) oder anderer Container-Tools hier nicht berücksichtigen. Beachten Sie jedoch, dass diese zusätzlichen Komponenten Kosten verursachen können, falls sie für Ihr Projekt erforderlich sind.

Schritt 3 (Entwurf der Zielarchitektur):

Bei der Planung der Zielarchitektur sollten Sie verschiedene Aspekte berücksichtigen:

• Ist es möglich, die bestehende Anwendung in mehrere Container zu unterteilen, wobei jeder Container einen eigenen Prozess ausführt (z.B. ein Cron-Job)?
• Hat die Anwendung besondere Hardwareanforderungen, wie zum Beispiel Grafikprozessoren (GPUs), Soundkarten oder USB-Lizenzschlüssel?
• Erfordert Ihre Anwendung dauerhaften Speicher, da Daten nicht dauerhaft in Containern gespeichert werden, sondern in speziellen Speichervolumen?
• Gibt es für das von Ihrer Anwendung verwendete Framework (wie Spring Boot, Tomcat, .NET) bereits existierende Docker-Images?

Für Schritt 3 planen wir, die Anwendungen in ihrer bestehenden Architektur auf eine neue Plattform zu übertragen, ohne strukturelle Änderungen vorzunehmen.

Vorbereitung für Schritte 4 und 5:

Um Ihren Workload effizienter zu schätzen, können Sie Muster in diesen identifizieren. Dies vereinfacht den Prozess, besonders für die Schritte 4 und 5. Hierbei können Sie ein von AWS Professional Services entwickeltes Modell zur Containerisierung nutzen. Dieses Modell ordnet Anwendungen basierend auf ihrer Komplexität in drei Kategorien ein: niedrig, mittel und hoch. Jede Kategorie spiegelt den Aufwand wider, der für die Containerisierung der Anwendungen und die erforderlichen Tasks zum Betrieb auf ECS benötigt wird.

Beispiele für die verschiedenen Komplexitätsstufen sind:

• Eine Anwendung niedriger Komplexität könnte ein einzelnes Java-Paket (WAR-Datei) oder eine Microsoft .Net-Komponente (.NET) sein, entweder ohne Benutzeroberfläche (UI) oder mit einer internen UI.
• Eine mittlere Komplexität haben Anwendungen, die eine oder mehrere .war- oder .NET-Komponenten mit einer externen UI beinhalten.
• Anwendungen hoher Komplexität umfassen mehrere .war- oder .NET-Komponenten mit sowohl internen als auch externen Benutzeroberflächen.

Hier ist eine Tabelle, die Sie als Leitfaden verwenden können:

Die folgende Tabelle zeigt die Komplexität unseres Beispiel-Workloads:

Nachdem Sie Ihre Anwendungen entsprechend ihrer Komplexität in die drei Stufen eingeteilt haben, können Sie feststellen, wie viele Aufgabenbeschreibungen und wie viel Aufwand für die Containerisierung für jede Stufe nötig sind. Diese Erkenntnisse sind wichtig, um die Schritte 4 und 5 erfolgreich durchzuführen.

Die untenstehende Grafik zeigt das aktuell genutzte Modell für den Aufwand der Containerisierung.

Anhand unseres Beispiels könnten Sie Folgendes für die Anzahl der Tasks und den Containerisierungsaufwand ermitteln:

Schritt 4 (Plattformkosten):

Die Anzahl der Aufgaben wird verwendet, um Ihre jährlichen Plattformkosten zu schätzen.

Annahmen und Überlegungen:

Die Nutzung von ECS als Orchestrierungsplattform ist grundsätzlich kostenlos. Falls jedoch eine Verwendung von EKS in Betracht gezogen wird, müssen zusätzliche Laufzeitkosten einkalkuliert werden. Diese Kosten variieren abhängig von der gewählten Region. Es ist daher wichtig, spezifische Kostendaten für die Region zu berücksichtigen, in der die Anwendung bereitgestellt wird. In diesem Beispiel konzentrieren wir uns auf die Region us-east-1. Alle hier dargestellten Kostenberechnungen beziehen sich auf eine jährliche Basis.

Um die Gesamtkosten der Plattform zu bestimmen, müssen wir die Ausgaben für die verschiedenen technischen Bestandteile der geplanten Architektur zusammenrechnen:

1. Rechenkapazität (EC2 & Fargate)
2. Datenspeicherung
3. Netzwerkinfrastruktur (insbesondere Load Balancer)

1. Kosten für Rechenkapazität:

Die Berechnung der Kosten variiert, abhängig davon, ob Sie EC2 oder Fargate als Basis für Ihren Compute-Typ wählen. Zunächst behandeln wir EC2 und danach Fargate:

a. Compute-Typ – EC2:

Um die voraussichtlichen jährlichen Rechenkosten zu ermitteln, nutzen Sie die folgende Formel:

Stundensatz pro Instanz * Anzahl der benötigten Instanzen * durchschnittliche tägliche Nutzungsdauer pro Instanz (in Stunden) * 365 (Tage pro Jahr)

Schauen wir uns nun an, wie Sie die Werte für jede Komponente der Formel bestimmen.

• Stundensatz pro Instanz: Dieser hängt vom gewählten Instanztyp, der Kaufart der Instanz und der Region, in der sie eingesetzt wird, ab. Falls Sie bereits eine genaue Vorstellung von Ihrem benötigten Instanztyp haben, können Sie diesen direkt auswählen. Falls nicht, empfehlen wir für eine grobe Schätzung eine mittelgroße Allzweckinstanz wie m5.large. Informationen zu verschiedenen Instanztypen finden Sie hier: Amazon EC2-Instanztypen
  Die Kosten richten sich nach der von Ihnen gewählten Kaufmethode und etwaigen verfügbaren Sparoptionen. Falls Sie davon ausgehen, dass Sie Reserved Instances für tägliche Aufgaben über einen Zeitraum von mehr als 1 bis 3 Jahren nutzen werden, können Sie sich die entsprechenden Preise unter diesem Link einsehen: https://thinkwithwp.com/de/ec2/pricing/reserved-instances/. Für eine vorsichtige Kostenschätzung empfehlen wir jedoch, zunächst mit den On-Demand-Preisen zu kalkulieren
• Anzahl erwarteter Instanzen: Diese Zahl basiert auf der Anzahl der Aufgaben, die Sie in der vorherigen Übung mit dem Komplexitätsmodell festgelegt haben. Die tatsächlich benötigte Anzahl von Instanzen, um alle Aufgaben zu bewältigen, hängt von der realen Nutzung ab und wird mit der Zeit angepasst. Für Schätzungen empfehlen wir jedoch, von etwa 3 Aufgaben pro Instanz auszugehen, basierend auf bisherigen Erfahrungen.
• Erwartete durchschnittliche tägliche Laufzeit pro Instanz: Üblicherweise wird davon ausgegangen, dass die meisten Arbeitslasten durchgehend laufen, also können Sie 24 Stunden pro Tag ansetzen. Wenn Sie jedoch wissen, dass bestimmte Arbeitslasten nur zeitweise laufen (beispielsweise in Entwicklungs- und Qualitätssicherungsszenarien oder zur Gewährleistung von Flexibilität), könnten Sie eine kürzere Laufzeit in Betracht ziehen. Trotzdem empfehlen wir für eine vorsichtige Schätzung, von einem dauerhaften Betrieb auszugehen.

Beispiel:

Angenommen, Sie verwenden drei unserer Anwendungen, die insgesamt 40 Aufgaben bewältigen, und wählen dafür m5.large-Instanzen. Wenn diese durchgehend in Betrieb sind und Sie den aktuellen Stundentarif für die Region USA-Ost (N.Virginia) zugrunde legen, wie er zum Zeitpunkt dieses Blogbeitrags gilt, dann lässt sich Ihre geschätzte jährliche Rechenkostenberechnung wie folgt darstellen:

$0,096 pro Stunde pro Instanz, multipliziert mit 40 Aufgaben über 3 Instanzen, multipliziert mit 24 Stunden am Tag und 365 Tagen im Jahr, ergibt insgesamt etwa $11.212 als Ihre geschätzten jährlichen Rechenkosten.

b. Rechentyp – Fargate:

AWS Fargate berechnet die Kosten auf Basis der vCPU, des Speichers, des Betriebssystems, der CPU-Architektur und der genutzten Ressourcen. Die Berechnung beginnt, wenn Sie Ihr Container-Image herunterladen und endet, wenn die Amazon ECS-Task oder der Amazon EKS-Pod beendet wird. Die Kosten werden auf die nächste Sekunde aufgerundet.

Um die jährlichen Rechenkosten zu schätzen, verwenden Sie diese Formel:

(Anzahl der Tasks oder Pods pro Tag) * (durchschnittliche Dauer in Stunden pro Tag) * [(zugewiesene vCPU-Menge * Preis pro vCPU/Stunde) + (zugewiesene Speichermenge in GB * Preis pro GB/Stunde)] * 365 Tage

Beispiel:

Betrachten wir ein Beispiel mit drei Anwendungen, die 40 Tasks im US-Ost (N.Virginia) Bereich kontinuierlich betreiben:

40 Tasks * 24 Stunden * [(1 vCPU * 0,04048 $/Stunde) + (2 GB Speicher * 0,00445 $/GB/Stunde)] * 365 Tage = 17.302 $ als geschätzte jährliche Rechenkosten.

Es ist zu beachten, dass die Kosten für Fargate, einen serverlosen Dienst, höher sind als bei der Nutzung des EC2-Starttyps. Aber Fargate, als vollständig verwalteter Dienst, kann die Betriebskosten ausgleichen, die man sonst bei der Verwaltung eines EC2-Starttyps hätte.

Nachdem wir die Rechenkosten betrachtet haben, kommen wir nun zu den Speicherkosten.

2. Kosten für Datenspeicherung:

Um die jährlichen Kosten für den Speicher zu ermitteln, nutzen Sie die folgende Formel:

Speichermenge in GB * Kosten pro GB pro Monat * Anzahl der Tasks * 12 (für die Monate eines Jahres).

Die benötigte Speichermenge in GB ergibt sich aus dem aktuellen Speicherbedarf Ihrer Anwendungen, die in die AWS-Cloud migriert werden sollen, abzüglich des Speicherplatzes, den Ihre Betriebssysteme belegen. Beachten Sie, dass der Speicherplatz für Tasks nicht dauerhaft ist. Für jede Anforderung, die dauerhaften Speicher benötigt, sollten Sie Amazon Elastic File System (Amazon EFS) oder andere AWS-Speicherdienste in Betracht ziehen und in Ihre Kalkulation einbeziehen.

Die Kosten pro GB pro Monat variieren je nach mehreren Faktoren wie Standort, Speichertyp, gewünschter Durchsatz, IOPS usw. Wenn der Speichertyp noch nicht feststeht, können Sie für die Berechnung EBS als Standardannahme verwenden, da die meisten typischen Arbeitslasten diesen Dienst nutzen. Um die spezifischen Kosten für Ihre Organisation zu ermitteln, konsultieren Sie bitte den AWS EBS-Speicherpreisrechner für genauere Informationen.

Beispiel:

Unsere Berechnung basiert auf einem angenommenen Speicherpreis von 0,100 $ pro Gigabyte (GB) und Monat für Allzweck-SSDs (gp2). Zudem gehen wir davon aus, dass EBS-Snapshots für einen Monat gespeichert und danach gelöscht werden. Wenn wir von 20 GB Speicher pro Aufgabe ausgehen, sehen Ihre Speicherkosten folgendermaßen aus:

Die Kosten für 20 GB Speicher bei 40 Aufgaben über ein Jahr berechnen sich so: 20 GB multipliziert mit dem Preis von 0,1 $ pro GB und Monat, multipliziert mit 40 Aufgaben und 12 Monaten. Dies ergibt 960 $ als geschätzte jährliche Speicherkosten.

Bei Fargate sind die ersten 20 GB Speicher pro Aufgabe kostenfrei. In diesem Fall wären Ihre Speicherkosten demnach 0,00 $, solange Sie diesen Freibetrag nicht überschreiten. Wenn Sie mehr Speicher benötigen, können Sie dieselbe Berechnung anwenden, müssen aber nur den Speicher berücksichtigen, der über die kostenfreien 20 GB hinausgeht.

 3. Kosten für Netzwerkinfrastruktur:

Für die meisten Implementierungen von ECS wird empfohlen, einen Elastic Load Balancer (ELB) zu verwenden. Dieser dient vor allem dazu, die Zuverlässigkeit des Systems durch eine hochverfügbare Architektur zu verbessern. Um die Kosten für den Einsatz eines ELB zu schätzen, kann unser Preisrechner verwendet werden, der detaillierte Nutzungsinformationen berücksichtigt. Die Abrechnung von ELBs basiert auf den Betriebsstunden und den Lastcharakteristikeinheiten (LCUs). Da spezifische Kenntnisse über die Lastcharakteristiken jeder einzelnen Anwendung anfangs nicht immer vorliegen, bieten wir eine einfache Berechnungsformel an, die eine grobe Kostenschätzung ermöglicht:

Anzahl der Tasks multipliziert mit dem Stundensatz und 8736 (der Anzahl der Stunden in einem Jahr).

Beispiel:

In unserem Beispiel gehen wir von 40 Tasks aus und nutzen den aktuellen Stundensatz für einen Application Load Balancer (ALB) in der us-east-1 (N. Virginia) Region. Basierend auf dem Stundensatz zum Zeitpunkt dieses Blogbeitrags, lässt sich die Kostenkalkulation wie folgt darstellen:

40 Tasks multipliziert mit dem Preis von 0,0225 $ pro Stunde und 8736 Stunden pro Jahr ergibt eine Summe von 7862,4 $ pro Jahr.

Damit haben wir die Berechnung der Plattformkosten abgeschlossen.

Schritt 5 (Aufwandskosten):

Um die Kosten für Ressourcen und Support abzuschätzen, nutzen Sie die Stundenanzahl, die gemäß dem zuvor beschriebenen Komplexitätsmodell berechnet wurde. Für die Berechnung der Ressourcenkosten multiplizieren Sie einfach die geschätzte Gesamtstundenanzahl (z.B. 280 Stunden im Beispiel) mit dem erwarteten Stundensatz für die benötigten Humanressourcen. Dieser Stundensatz kann entweder auf Basis Ihrer internen Kosteneinschätzung (wenn Ihre eigenen Mitarbeiter die Arbeit durchführen) oder auf Basis des Dienstleistungssatzes (wenn ein Drittanbieter oder eine Mischung aus beidem beteiligt ist) ermittelt werden. Dieser Betrag stellt eine Schätzung der einmaligen Modernisierungskosten dar.

Beispiel:

Angenommen, der interne Stundensatz für Humanressourcen beträgt 100 $ pro Stunde. In diesem Fall würden die Kosten für Ihre Modernisierungsressourcen wie folgt aussehen:

280 Stunden × 100 $ pro Stunde = 28.000 $.

Nachdem wir nun die Aufwandskosten ermittelt haben, können wir die Gesamtbetriebskosten wie folgt berechnen:

Finale TCO-Berechnung

Gesamt-TCO = Kosten aus Schritt 4 + Kosten aus Schritt 5

Beispiel:

Um die Gesamtkosten (TCO) für den EC2-Starttyp in unserem Beispiel zu ermitteln, addieren wir die folgenden Komponenten zusammen:

• Rechenkosten: 11.212,8 $
• Speicherkosten: 960 $
• Netzwerkkosten: 7.862,4 $

Die jährlichen TCO belaufen sich somit auf 20.035,2 $.

Für den Fargate-Starttyp in unserem Beispiel ergibt sich die TCO wie folgt:

• Rechenkosten: 17.302 $
• Speicherkosten: 0 $
• Netzwerkkosten: 7.862,4 $

Die jährlichen TCO betragen in diesem Fall 25.164,4 $.

Es ist ratsam, auch geschätzte wiederkehrende Support- und Wartungskosten (die hier nicht behandelt werden) in Betracht zu ziehen, um eine umfassendere Schätzung der wiederkehrenden TCO zu erhalten. Zudem sollten die einmaligen Modernisierungskosten, hier auf 28.000 $ geschätzt, nicht übersehen werden.

Schlussfolgerung

Teil 1 und Teil 2 schließen das TCO-Berechnungsmodell für die Modernisierung von Anwendungen durch Containerisierung ab. In dieser Blogserie haben wir verschiedene Möglichkeiten für das Hosting von Containern erkundet und einen schrittweisen Ansatz entwickelt, um einen aussagekräftigen TCO zu ermitteln. Dabei stützen wir uns auf die Erfahrungen der AWS Professional Services und branchenübliche Annahmen. Wie bereits im ersten Teil des Blogs erwähnt, dient diese Methodik dazu, eine grobe Kostenschätzung für frühe Investitionsentscheidungen zu liefern. Im Verlauf des Projekts und nach durchgeführten Proof-of-Concept-Experimenten können wir auf Grundlage der Anwendungsarchitektur aktualisierte Zahlen erstellen.

Über die Autoren

	Keith Andruch ist AWS Principal Enterprise Architect Leader mit Sitz in Toronto, Kanada. Er verfügt über umfassende Expertise in Unternehmensumwandlungen, Cloud-Migrationen, Automatisierung und dem Entwurf von Cloud-basierten Lösungen auf Amazon Web Services.
	Kiran Kuppa ist Principal Solutions Architect bei AWS, spezialisiert auf Migrationen und Modernisierung. Kiran hat umfangreiche Erfahrungen darin, sowohl Greenfield- als auch Enterprisekunden bei der Adoption von AWS-basierten Lösungen zu unterstützen.