Vorbereitung auf Wachstum
Sie kennen wahrscheinlich die Redewendung Vorbereitung ist der Schlüssel zum Erfolg. Dieses Sprichwort gilt insbesondere für ein reibungsloses, erfolgreiches und zuverlässiges Wachstum.
Einer der größten Vorteile von Cloud Computing ist die Skalierbarkeit. Dies hat mitunter zu der falschen Annahme geführt, dass eine Vorbereitung oder Planung für das Wachstum in der Cloud nicht erforderlich sei, weil die Cloud unbegrenzt skalierbar ist.
Es ist richtig, dass es in der Cloud höchstwahrscheinlich mehr als genug Ressourcen gibt, um die Anforderungen Ihrer Anwendung zu erfüllen. Es gibt jedoch einige Gründe, warum es für Sie immer noch wichtig ist, Ihre Kapazitätsanforderungen zu verstehen:
Obwohl es wahrscheinlich ausreichend Ressourcen in der Cloud gibt, um Ihre Anforderungen zu erfüllen, werden nicht alle Dienste, die Sie nutzen, automatisch skaliert oder sind inhärent skalierbar. Deshalb müssen Sie die Dienstlimits kennen und wissen, wann eine Hochskalierung von Diensten und Ressourcen erforderlich ist.
Cloudressourcen können zwar unbegrenzt sein, aber Ihr Budget ist es wahrscheinlich nicht. Sie müssen die Kosten berücksichtigen, und die Kolleg*innen in der Finanzabteilung möchten die prognostizierten Cloudausgaben wissen.
Planung des organischen Wachstums
Organisches Wachstum in der Geschäftswelt bezieht sich auf den Prozess, mit dem Organisationen ihre eigene Kapazität erweitern, wobei sie sich auf eigene Ressourcen und Fertigkeiten verlassen, um ein langsameres, natürlicheres Wachstum zu fördern.
Beim organischen Wachstum Ihres Unternehmens besteht der erste Schritt der Kapazitätsplanung in der Cloud darin, die aktuellen Ressourcenanforderungen für größere Komponenten Ihrer Anwendung zu bestimmen.
Szenario: organisches Wachstum
Kehren wir nun zu der Architektur zurück, die wir uns in diesem Modul bereits angesehen haben. Tailwind Traders ist im Begriff, ein innovatives neues Produkt auf den Markt zu bringen, das ein deutliches Wachstum zur Folge haben dürfte. Nur zur Erinnerung: Das Architekturdiagramm sieht folgendermaßen aus:
Um die Kapazitätsplanung zu beginnen, müssen Sie die größeren Komponenten identifizieren. Dieses Beispiel umfasst Folgendes:
- Azure Kubernetes Service-Cluster
- Die Rewards-App, die in Azure App Service ausgeführt wird
- Verschiedene Datenbanken, z. B. Cosmos DB, Azure SQL o. ä.
Sie müssen die aktuelle Ressourcennutzung jeder dieser großen Komponenten kennen, um die zukünftige Nutzung besser planen zu können. Sehen Sie sich nachfolgend die Ressourcennutzung für eine der größere Komponenten an.
Messen der Kapazität von Cosmos DB
Bei Cosmos DB wird der Speicher in Gigabyte gemessen und automatisch skaliert, auch wenn Sie die Messungen aus Kostengründen weiterhin berücksichtigen müssen.
Der Durchsatz wird vorab bereitgestellt, und zur Messung des Durchsatzes wird eine Metrik mit dem Namen Anforderungseinheiten verwendet. Anforderungseinheiten (Request Units, RUs) sind eine Mischung aus Arbeitsspeicher, CPU und IOPS, sodass Sie eine einzelne Metrik erhalten, mit der Sie Kapazität planen können. Sie stellen Anforderungseinheiten in Schritten von 100 Anforderungseinheiten pro Sekunde bereit.
Jeder DB-Vorgang wird in Anforderungseinheiten pro Sekunde (RU/s) gemessen. Lesevorgänge sind einfach: 1 KB Lesevorgang ist eine einzelne Anforderungseinheit. Andere Vorgänge werden basierend auf verschiedenen Faktoren berechnet, z. B. basierend auf der Elementgröße, der Datenkonsistenz, Abfragemustern usw.
Bei der Profilerstellung für Ihre Anwendung enthält jede Antwort von Cosmos DB den request-charge-Header, der genau anzeigt, wie viele Anforderungseinheiten von der Anforderung verwendet wurden. Sie können die Anzahl der genutzten Anforderungseinheiten mit der Anzahl der bereitgestellten Anforderungseinheiten vergleichen, um zu überprüfen, ob Sie aktuell mehr als genügend Kapazität haben.
Es empfiehlt sich, Ihre Ressourcennutzung mit einer Geschäftsmetrik zu korrelieren, z. B. mit monatlich aktiven Benutzern oder Umsätzen. Mit dieser Korrelation können Sie basierend auf der Wachstumsprognose die Kapazität besser planen. Sie können diese Kapazitätsmetriken in Azure Monitor abrufen. Wenn Sie die Ressourcennutzung des Systems kennen, wissen Sie, wann Sie hochskalieren müssen und welche Kosten im Laufe der Zeit anfallen.
Sehen wir uns jetzt die Daten der Cosmos DB-Nutzung von Tailwind Traders an. Nachfolgend sehen Sie ein entsprechendes Nutzungsdiagramm.
In diesem Beispiel wächst Tailwind Traders mit einem durchschnittlichen Wert von 2.500 monatlich aktiven Benutzern mit einer aktuellen Benutzerbasis von 10.000 Benutzern.
Bei einem Blick auf den Speicher sehen wir, dass die Datenbank 300 GB der verfügbaren 5 TB (6 %) verwendet. Das Wachstum liegt bei 1 % bzw. 50 GB im Monat.
Der Durchsatz beträgt 300/1000 und wächst um 10 % pro Monat:
Da wir nun die Ressourcenmetriken der Systeme kennen, wissen wir, wann der Durchsatz wahrscheinlich skaliert werden muss. Außerdem können wir die Kosten im Laufe der Zeit prognostizieren.
Wir können jetzt ein Diagramm erstellen, das uns bei der Kapazitätsplanung unterstützt.
Jetzt wissen wir, dass im Mai die Kapazität der Anforderungseinheiten (RUs) für unsere Datenbank ausgeschöpft sein werden. Wir müssen also vorher eine Skalierung durchführen. Ein weiterer interessanter Einblick ist, dass die Cosmos DB-Datenbank vielleicht aktuell sogar herunterskaliert werden kann, da die vorab bereitgestellte Kapazität gar nicht ausgeschöpft wird.
Planung des anorganischen Wachstums
Im vorangegangenen Beispiel haben Sie das organische Wachstum geplant. Anorganisches Wachstum entsteht aus externen Faktoren und nicht aus einer Erhöhung der unternehmenseigenen Geschäftsaktivitäten. Es ist keine natürliche Weiterentwicklung, sondern besteht tendenziell in einer plötzlichen und größeren Steigerung der Auslastung.
Manchmal können Sie im Vorfeld nicht wissen, dass Datenverkehr, Benutzeranzahl usw. ansteigen werden. In Vorbereitung auf solche Fälle müssen Sie Ihr System so aufbauen, dass es weitestgehend automatisch skaliert wird und mit einer Fehlermeldung abbricht, falls dies nicht möglich ist. Dieser Punkt wird später in diesem Modul behandelt.
In anderen Situationen, z. B. bei einer anstehenden Produkteinführung, kommt es vielleicht zu anorganischem Wachstum, das Sie planen und auf das Sie sich vorbereiten können. Angenommen, Ihre Teams in den Bereichen Engineering, Produktentwicklung, Marketing und Finanzen arbeiten zusammen, und Sie wissen, wie Sie Ihre Ressourcennutzungs- und Wachstumsmuster ermitteln können. Sie können in einem vertretbaren Rahmen die Auswirkungen dieser Ereignisse auf Ihre Ressourcenanforderungen vorhersagen und entsprechend Änderungen vornehmen.
Ob das gelingt, hängt von Ihrer Organisation und dem spezifischen Ereignis ab. Sie werden es vielleicht nicht immer richtig machen, aber durch eine gute Vorbereitung haben Sie auf jeden Fall die besten Voraussetzungen dafür geschaffen.
Szenario: anorganisches Wachstum
Sehen wir uns eine weitere hypothetische Situation als ein Beispiel für die Planung des anorganischen Wachstum an. Demnächst steht eine Marketingveranstaltung für die Einführung eines hochwertigen, innovativen neuen Produkts bei Tailwind Traders an. Man rechnet damit, so 5000 weitere Benutzer*innen auf die Vertriebswebsite zu locken.
Mithilfe der Daten aus dem vorherigen Beispiel für organisches Wachstum (hoffentlich mit einem Kausalzusammenhang), die mit einer Geschäftsmetrik korreliert werden, die Sie von ihren Produkt-/Marketingteams erhalten haben – beispielsweise die Benutzeranzahl –, können Sie mit der Planung für das anorganische Wachstum beginnen.
Sie wissen aus dem vorherigen Szenario, dass auf 2500 Benutzer*innen etwa 50 GB an Speicher und 100 Anforderungseinheiten anfallen. Sie können jetzt anhand dieser Daten ermitteln, ob Sie auf dieses Ereignis vorbereitet sind. Wenn 5000 Benutzer*innen erwartet werden, benötigen Sie 100 GB Speicher und 200 RU/s.
Wir können sehen, dass die Speicherkapazitäten mehr als ausreichend sind, um das erwartete Wachstum nach dem Ereignis abzudecken. Diese Kapazitäten werden automatisch skaliert. Daher müssen Sie sich nur mit den neuen Kosten befassen – darauf kommen wir später zu sprechen.
Sie können auch vorhersagen, dass die Anforderungseinheiten (RUs) nach dem Ereignis nur 50 % der Kapazität erreichen werden. Bedenken hinsichtlich der Cosmos DB-Kapazität für dieses Ereignis sind also unnötig.
Die Kosten werden allerdings beeinflusst.
Sie sehen, dass der zusätzliche Speicher mit 100 GB zusätzliche Kosten von 25 USD/Monat verursacht. Der Preis für den Durchsatz bleibt unverändert, denn die Kunden zahlen für bereitgestellte Anforderungseinheiten, die bereits mehr als ausreichend vorhanden sind. Unter dem Strich erhöht dieses Marketingereignis ihre CosmosDB-Rechnung wahrscheinlich um 25 US-Dollar.