Blog
Azure Cloud-Ressourcen optimieren & Kosten senken
Natürlich kostet der Einsatz von Softwaresystemen Geld. Wenn Sie sie On-Premises betreiben, kann es passieren, dass Sie zu viel Hardware gekauft haben, um mit eventuellem Geschäfts- und Entwicklungsbedarf Schritt zu halten oder Lastspitzen zu bewältigen. In der Cloud hingegen ist es nicht nötig, übermäßig viel Ressourcen bereitzuhalten, wodurch Projekte und Unternehmen dieses Risiko ganz vermeiden können. Kann sich also der IT-Manager zurücklehnen und darauf vertrauen, für sein Budget den bestmöglichen Wert zu erhalten?
Es gibt zwei klassische Situationen, in denen zu viele oder zu große Ressourcen in der Cloud bereitgestellt werden. Das positive Szenario: Das Unternehmen startet viele neue Projekte und ist sehr innovativ. Das negative Szenario: Es wurde nicht genügend Wissen über den IT-Betrieb in der Cloud aufgebaut. Denn dort erfolgt die Bereitstellung unter anderen Bedingungen als beim herkömmlichen On-Premises-Betrieb, bei dem neue oder größere Ressourcen erst zur Verfügung stehen, wenn die Betriebsabteilung („Operations“) sie installiert hat.
In beiden Fällen ist es möglich, die Kosten in der Cloud unter Kontrolle zu halten. So können Sie beispielsweise Überwachungssysteme einrichten, die Betriebsabteilung bei der Bereitstellung neuer Ressourcen einbeziehen und regelmäßig aufräumen. Um diese neue Verantwortung zu übernehmen, muss die Betriebsabteilung jedoch neue Kompetenzen aufbauen.
Weiterhin können Sie bei DevOps-Projekten im Unternehmen den Fokus auf die Kosten als Anforderung definieren. Dieser Blog basiert auf einer DevOps-Mentalität, aber die Prinzipien lassen sich auch in einer Organisation anwenden, in der Entwicklung und Betrieb getrennt voneinander laufen.
Im Folgenden werden wir die horizontale und vertikale Skalierung behandeln. Bei der vertikalen Skalierung werden Ressourcen vergrößert oder verkleinert, bei der horizontalen Skalierung hingegen werden sie hinzugefügt oder entfernt.
Das Timing
Wenn Sie sich mit den Kosten befassen müssen, kann es dafür folgende Auslöser geben:
Sie entscheiden sich, dies von Beginn an zu tun. Aber dann wissen Sie nicht, worauf Sie Ihre Bemühungen konzentrieren sollen. Sie haben noch keine Erfahrungswerte, wie die Ressourcen im Laufe der Zeit genutzt werden.
Alternativ können Sie das angehen, wenn der in Azure integrierte Assistent es Ihnen empfiehlt. Aber in dieser Situation fehlen Azure möglicherweise Informationen über die Nutzung der Ressourcen.
Oder Sie beschäftigen sich erst damit, wenn Benachrichtigungen/Alarme von Azure eingehen, dass ein Budget überschritten wurde. Das setzt allerdings voraus, dass Sie im Voraus ein realistisches Budget festlegen konnten. Das kann schwierig sein, da auch dann empirische Daten über die Nutzung der Daten im Zeitverlauf fehlen.
Bei uns erfolgt das kontinuierlich, während unsere Projekte reifen und der Fokus unserer Kunden auf die mit ihren „neuen“ Cloud-Lösungen verbundenen Kosten steigt.
58 % Kosteneinsparung
Bei einem unserer Projekte im Finanzsektor, bei dem wir einen großen Teil der Infrastruktur unseres Kunden betreiben, konnten wir mehrere Einsparungsbereiche eindeutig identifizieren.
Ein Großteil seiner Systeme basiert auf Azure App Service, der einen beinahe unbegrenzten Zugang zu IT-Ressourcen ermöglicht. So können wir neue Geschäftsanforderungen reibungslos umsetzen, sobald sie anfallen.
Nachdem die Systeme ausgereift sind und sich eindeutige Nutzungsmuster identifizieren und vorhersagen lassen, analysieren wir kontinuierlich die genutzten Kapazitäten im Vergleich zu den bereitgestellten. Damit lassen sich Bereiche identifizieren, in denen Kapazitätsanpassungen möglich sind.
Der Entwicklungsprozess für den Kunden erfolgt nach CI/CD-Prinzipien, weshalb Entwicklungs- und Testumgebungen notwendig sind, in denen alle Änderungen einem Belastungstest unterzogen werden, bevor sie in Betrieb gehen. In der Anfangsphase des Projekts ließ sich der Bedarf für die Verfügbarkeit dieser Umgebungen nur schwer vorhersagen. Doch mit der Zeit waren bessere Prognosen über den Ressourcenbedarf sowohl für manuelle als auch für automatische Tests möglich. Daraus ergaben sich Möglichkeiten, die Kosten für diese Ressourcen zu minimieren.
Durch die Vorhersagbarkeit konnten wir eine automatische Anpassung der Anzahl an Instanzen im App Service-Plan für die Testumgebung einstellen, die von der geplanten Arbeitszeit abhing.
Das folgende Diagramm zeigt die daraus resultierenden Einsparungen (die Skala der Y-Achse wurde in einen Index umgewandelt). Es ist leicht zu erkennen, dass sich die automatische Anpassung etwa ab dem 3. Mai ausgewirkt hat. Verglichen mit der Konfiguration vor dem 3. Mai konnten wir eine Einsparung von 28,6 % erzielen.
Natürlich nutzen all unsere Projekte die in Azure integrierten Methoden zur automatischen Skalierung von Ressourcen, unter anderem die verschiedenen Skalierungsoptionen für App Services. Allerdings bietet Azure keine automatische Skalierung der bereitgestellten App Service-Plan SKU (Stock Keeping Unit) an, wodurch ein größerer Teil der Betriebskosten gebunden wird. Mit SKU bezeichnet Azure eine spezifische Konfiguration eines Azure-Produkts. So ist zum Beispiel die App Service-Plan SKU „P2v3“ die Bezeichnung für eine bestimmte „Servergröße“ mit 4 Cores, 16 GB RAM und 250 GB Speicher.
Deshalb haben wir Mechanismen entwickelt, mit denen App Service-Plan SKUs für die Entwicklungsumgebung außerhalb der regulären Arbeitszeiten heruntergefahren werden können ‒ selbstverständlich so konzipiert, dass sie sich schnell wieder reaktivieren lassen, wenn eine Situation dies außerhalb der Arbeitszeiten erfordert.
Das nächste Diagramm zeigt die resultierenden Einsparungen (die Skala der Y-Achse wurde in einen Index umgewandelt). Um den 16. April herum wurde eine automatische Skalierung der SKU für die App Service-Pläne in der Entwicklungsumgebung eingerichtet, sodass in den Abendstunden und an Wochenenden eine kleinere SKU genutzt wird. Verglichen mit der Konfiguration vor dem 16. April konnten wir eine Einsparung von 58 % erzielen.
Ressourcen unter der Lupe
Für einen anderen Kunden haben wir das Backend für einen umfangreichen Online-Shop erstellt. Als das Projekt eine gewisse Reife erzielt hatte, vereinbarten wir mit dem IT-Manager des Kunden, die Kosten für ihre Cloud-Ressourcen zu ermitteln, um zu sehen, ob diese sich senken ließen. Da die Auslastung der Ressourcen bekannt war, waren auch die Voraussetzungen für Einsparungen gut.
Wir haben also die größten Posten in den Entwicklungs-, Test- und Produktionsumgebungen genau unter die Lupe genommen. Dabei lag der Fokus vor allem auf den kostenintensivsten Ressourcen. Viele Ressourcen wurden nicht priorisiert, weil sich der damit verbundene Zeitaufwand nicht durch Einsparungen bei den betreffenden Ressourcen hätten finanzieren lassen.
Konkrete Einsparungen gab es bei Azure SQL, dem API-Management, dem App Service-Plan und bei Data Factory:
Für Azure SQL wurden relativ früh im Projekt reservierte Instanzen genutzt (es besteht die Option, einen festen, niedrigeren Preis für einige Instanzen zu zahlen und sich im Gegenzug über einen bestimmten Zeitraum, zum Beispiel für 1 Jahr, zu binden). Eine Reservierung ist für 1 oder 3 Jahre auf einmal möglich. Dies ist ein gutes Beispiel für eine Ressource, bei der man Kosten nur optimieren kann, wenn die Auslastung bekannt ist.
Das API-Management wird in den Stunden, in denen nicht entwickelt oder getestet wird, in der Entwicklungs- und Testumgebung heruntergefahren.
Der App Service-Plan muss sehr schnell skaliert werden können, wenn Endkunden online einkaufen, um mit der oft großen Anzahl von Anfragen Schritt zu halten. Die meisten Kunden kaufen montags bis freitags zwischen 6 und 16 Uhr ein. Außerdem gibt es bei einigen Anfragen ein Paging (erfolgt bei einer was zu mehr, aber kleineren Anfragen führen kann, wodurch die einzelne Instanz entlastet wird. Darüber hinaus wurden reduzierte Versionen der Antworten erstellt, die verwendet werden können, wenn der Online-Shop nur eine Teilmenge der Daten aus der ursprünglichen Antwort benötigt. Und schließlich haben wir weitere Regeln für die horizontale Skalierung hinzugefügt, sodass außerhalb der Zeiten, in denen die meisten Kunden online sind, nicht so schnell skaliert wird.
Hier ist eine sehr schnelle horizontale Skalierung eines App Service-Plans gegen 7 Uhr morgens zu sehen.
Data Factory kann Teil der Lösung sein
Azure Data Factory kann eine selbst gehostete Integrationslaufzeit nutzen. Bei diesem Kunden gab es diese schon aus anderen Gründen, und sie ist kostengünstiger als eine Azure-Integrationslaufzeit. Außerdem wurden alle Copy-Aktivitäten (eine Unteraufgabe in Data Factory, die Daten kopiert) in Data Factory mit zwei Data Integration Units konfiguriert, sodass die teurere Standardeinstellung nicht verwendet wird. Ebenso haben wir die Datenfluss-Aktivitäten so konfiguriert, dass sie 8 vCores verwenden, es sei denn, es handelt sich um einen kritischen Datenfluss, der mehr benötigt. Pipelines und Datenflüsse sind mit einem Zeitlimit versehen, sodass sie nicht mehr versuchen, den Vorgang abzuschließen, wenn zum Beispiel Daten oder Dienste nicht verfügbar sind. Außerdem werden Pipelines jetzt so geplant, dass die Daten nur während der Hauptgeschäftszeiten des Online-Shops aktualisiert werden. Und eine automatische Überwachung stellt sicher, dass die verschiedenen Aktivitäten in Azure Data Factory weiterhin die kostengünstigste Konfiguration aufweisen.
Nach den Pipeline-Arbeiten für diesen Kunden ließ sich feststellen, dass die Kosten für die oben genannten Ressourcen um 10 % bis 50 % gesenkt werden konnten ‒ eine erhebliche Einsparung im IT-Budget.
Was können Sie tun, um Ihre Lösungen auf den Prüfstand zu stellen?
Erfüllt Ihr Projekt oder Ihre Organisation die richtigen Anforderungen, um die Kosten Ihrer Cloud-Lösung zu optimieren? Hier sind einige Fragen, mit denen Sie sich zunächst beschäftigen sollten:
- Verfügen Sie über die richtigen Kompetenzen, um die Kosten zu optimieren?
- Wollen Sie von einem Set-up mit Betriebs- und Entwicklungsumgebung zu DevOps wechseln?
- Wie viel Geld könnten Sie bei Ihren Cloud-Lösungen einsparen, ohne die Markteinführungszeit zu verlängern oder Ihre Möglichkeiten zu beeinträchtigen, mit neuen Lösungen zu experimentieren, von denen das Geschäft profitiert?
Ob dabei etwas für Sie herausspringt, lässt sich oft in recht kurzer Zeit klären, nachdem man das Set-up unter die Lupe genommen hat. Wenn Sie bei diesem Prozess Hilfe benötigen, unterstützen wir Sie selbstverständlich gern. Wir sind nur einen Anruf entfernt.
*Der obige Text ist eine Übersetzung des dänischen Originals. Die dänischsprachige Version finden Sie hier.