Skalierbare Anwendungen machen

Nachdem Sie nun die Grundlagen der Vorbereitung auf das Wachstum verstanden haben und sich mit Faktoren vertraut machen, die sie bei der Kapazitätsplanung berücksichtigen sollten, können Sie die Herausforderung in Anspruch nehmen, Ihre Anwendungen so skalierbar wie möglich zu machen.

Architekturbewertungen

Ein wichtiger Punkt ist, dass Sie regelmäßige Architekturüberprüfungen Ihrer Systeme durchführen sollten.

Sie wissen, dass Sie Methoden wie Infrastruktur wie Code anwenden können, um die Bereitstellung Ihrer Cloudressourcen zu verbessern. Sie aktualisieren und verbessern ihren Anwendungscode regelmäßig, und Sie sollten dies mit den zugrunde liegenden Plattformressourcen tun.

Wenn Sie eine Architekturprüfung durchführen, können Sie die Bereiche identifizieren, die Verbesserung benötigen.

Das Azure Architecture Center verfügt über eine Vielzahl von Ressourcen, mit denen Sie Ihre Anwendungen in der Cloud entwerfen können, und es gibt viele Skalierbarkeitsempfehlungen, die Sie im Leitfaden zur Anwendungsarchitektur unter folgendem Link finden:

Azure Architecture Center

Szenario: Tailwind Traders-Architektur

Ein erster Schritt besteht darin, eine Bewertung der Architektur und Anwendung zu unternehmen – nicht nur, um zu bestimmen, wo ihre Schwächen liegen, sondern auch ihre Stärken zu erkennen. Was ist gut damit?

Sehen Sie sich das Szenario an, das Sie in der vorherigen Einheit gesehen haben. Hier ist erneut ein Diagramm der Architektur der Organisation.

Sie haben die Anwendung in kleinere Microservices dekompiliert, und einige dieser Dienste sitzen als Container auf Azure Kubernetes Service, oder sie können auf VMs oder App Service ausgeführt werden. Sie verwenden auch einige inhärent skalierbare Dienste wie Funktionen und Logik-Apps.

Diese Änderung ist gut, aber es gibt einige Verbesserungen, die die Anwendung skalierbarer machen würden. Als Beispiel konzentrieren Sie sich jetzt auf den Dienst "Produkte". Im Diagramm wird der Produktdienst in Kubernetes ausgeführt, aber wir gehen von dieser Erklärung aus, dass er auf einem virtuellen Computer in Azure ausgeführt wird. Die Skalierungskonzepte, möglicherweise mit einer etwas anderen Implementierung, können auf Anwendungen angewendet werden, unabhängig davon, ob sie auf Servern, App Service oder in Containern ausgeführt werden.

Das Produkt wird derzeit auf einer einzelnen VM ausgeführt, die mit einer einzelnen Azure SQL-Datenbank verbunden ist. Sie müssen diesen virtuellen Computer zum Skalieren aktivieren. Dazu können Sie Azure Skalierungssätze für virtuelle Computer verwenden, mit denen Sie eine Gruppe identischer VMs mit Lastenausgleich erstellen und verwalten können. Da Sie jetzt über mehr als einen virtuellen Computer verfügen, müssen Sie einen Lastenausgleich einführen, um den Datenverkehr über die virtuellen Computer zu verteilen.

Virtual Machine Scale Sets

Durch die Anwendung von Skalierungssätzen für virtuelle Computer über einzelne virtuelle Computer erhalten Sie einige Vorteile:

• Sie können die automatische Skalierung basierend auf Hostmetriken, Gastmetriken, Anwendungserkenntnissen oder einem Zeitplan vornehmen.
• Sie können Verfügbarkeitszonen (AZ) verwenden, die physisch getrennte Standorte innerhalb einer Azure Region sind, die jeweils aus einem oder mehreren Rechenzentren bestehen. Mit AZ-Unterstützung können Sie Ihre virtuellen Computer über mehrere AZs verteilen, wodurch Ihre Anwendung zuverlässiger wird und sie vor Rechenzentrumsfehlern schützt. Neue Instanzen in einer Skalierungsgruppe werden automatisch gleichmäßig auf Verfügbarkeitszonen verteilt.
• Das Hinzufügen eines Lastenausgleichs wird einfacher. VM-Skalierungsgruppen unterstützen die Verwendung von Azure Load Balancer für die einfache Verteilung von Schicht-4-Datenverkehr. Sie unterstützen auch Azure Application Gateway für erweiterte L7-Datenverkehrsverteilung und SSL-Beendigung.

Es gibt einige wichtige Faktoren, die Sie berücksichtigen müssen, bevor Sie Skalierungssätze implementieren. Dies gilt insbesondere in folgenden Fällen:

• Vermeiden Sie Die Instanz-Klebigkeit, sodass kein Client an ein bestimmtes Back-End hängen bleibt .
• Entfernen Sie persistente Daten aus dem virtuellen Computer, und speichern Sie sie an einer anderen Stelle, z. B. in Azure Storage oder in einer Datenbank.
• Denken Sie bei der Entwicklung an das Abskalieren. Es ist auch wichtig, dass Ihre Anwendung einfach nach unten skalieren kann. Es muss nicht nur elegant damit umgehen können, wenn dem Pool von Servern, die den Datenverkehr verarbeiten, mehr Instanzen hinzugefügt werden, sondern auch mit der abrupten Beendigung von Instanzen, wenn die Last abnimmt. Der Skalierungsaspekt nach unten wird häufig übersehen.

Entkopplung

Sie haben weitere virtuelle Computer mit Skalierungssätzen hinzugefügt. Das Aufskalieren ist die typische Reaktion auf eine Skalierungsanforderung. Sie können jedoch nur basierend auf einer einzelnen Metrik skalieren, und diese Reaktion ist möglicherweise nicht für alle Aufgaben relevant, die von Ihrem Produktdienst durchgeführt werden.

In unserem Szenario hat der Produktdienst eine Aufgabe: Wenn ein Produktbild hochgeladen wird, transkodiert es dieses Bild und speichert es in verschiedenen Größen für Miniaturansichten, Bilder im Katalog usw. Die Bildverarbeitung ist CPU-intensiv, aber die allgemeine Auslastung ist arbeitsspeicherintensiv.

Die Bildverarbeitung ist eine asynchrone Aufgabe, die in einen Hintergrundauftrag unterteilt werden kann. Dazu können Sie Ihren Bildverarbeitungsdienst über eine Warteschlange entkoppeln. Die Entkopplung ermöglicht es, beide Dienste unabhängig voneinander zu skalieren – einen nach Arbeitsspeicherbedarf (den Produktdienst) und den anderen nach CPU-Belastung oder sogar Warteschlangenlänge (den Bildverarbeitungsdienst). Zudem kann ein weiteres Skalierungsset diese Nachrichten entgegennehmen und die Bilder verarbeiten.

Skalieren mit Warteschlangen

Azure verfügt über zwei Arten von Warteschlangenangeboten:

• Azure Service Bus Warteschlangen Ein erweitertes Warteschlangenangebot, das Teil des umfassenderen Azure Service Bus Produkts ist und pub/sub und erweiterte Integrationsmuster bietet.
• Azure Storage Queues Eine einfache REST-basierte Warteschlangenschnittstelle, die auf Azure Storage basiert. Es bietet zuverlässiges, persistentes Messaging.

Ihre Anforderungen in diesem Szenario sind einfach, sodass Sie Azure Storage Warteschlangen verwenden können. Ihre Produktebene muss überhaupt nicht skaliert werden, da Sie diese Hintergrundaufgabe entkoppelt haben.

In-Memory-Caching

Eine weitere Möglichkeit zur Verbesserung der Leistung Ihrer Anwendung besteht darin, einen Speichercache zu implementieren.

Jetzt wissen Sie, dass die Leistung nicht exakt der Skalierbarkeit entspricht, aber durch die Verbesserung der Leistung Ihrer Anwendung können Sie die Auslastung anderer Ressourcen reduzieren. Diese Verbesserung bedeutet, dass Sie möglicherweise nicht so schnell skalieren müssen.

Azure Managed Redis (ehemals Azure Cache for Redis) ist ein verwaltetes Redis-Angebot. Redis können für viele Muster und Anwendungsfälle verwendet werden. Für Ihren Produktdienst in diesem Szenario würden Sie wahrscheinlich das Cache-Aside-Muster implementieren. In diesem Muster laden Sie Elemente aus der Datenbank nach Bedarf in den Cache, wodurch Ihre Anwendung leistungsfähiger wird und die Auslastung der Datenbank reduziert wird.

Redis kann auch als Messagingwarteschlange, zum Zwischenspeichern von Webinhalten oder zum Zwischenspeichern von Benutzersitzungen verwendet werden. Diese Art der Zwischenspeicherung eignet sich möglicherweise besser für andere Dienste im System wie den Einkaufswagendienst, in dem Sie Einkaufswagendaten pro Sitzung in Redis speichern können, anstatt ein Cookie zu verwenden.

Skalieren der Datenbank

Nachdem Sie Ihre Computeressourcen nun skalierbarer gestaltet haben, sehen Sie sich Ihre Datenbank an. In diesem Szenario verwenden Sie Azure SQL-Datenbank, ein verwaltetes SQL Server Angebot aus Azure.

Relationale Datenbanken sind schwieriger zu skalieren als nichtrelationale Datenbanken. Das erste, was Sie tun können, um die Datenbank zu skalieren, besteht darin, die Größe der Datenbank zu skalieren. Diese Größenänderung kann problemlos nur mit einem kurzen Verbindungsverlust erfolgen, entweder mithilfe eines einfachen API-Aufrufs in Azure SQL oder mithilfe eines Schiebereglers im Portal.

Wenn diese Größenanpassung Ihre Anforderungen nicht erfüllt, kann es je nach Eigenschaften des Datenverkehrs sinnvoll sein, die Lesevorgänge in der Datenbank aufzuskalieren. Auf diese Weise können Sie den Lesedatenverkehr an Ihr Lesereplikat weiterleiten.

Diese Änderung muss im Code implementiert werden. Sie geben die Routingabsicht an, indem Sie das Attribut ApplicationIntent in Ihrer Datenbank Verbindungszeichenfolge festlegen. Verwenden Sie ReadOnly, um eine Verbindung mit dem Replikat herzustellen, oder ReadWrite, um eine Verbindung mit dem Primärsystem herzustellen.

Der empfohlene Ansatz besteht darin, verwaltete Identitäten für die Authentifizierung zu verwenden und alle erforderlichen Konfigurationen in Azure Key Vault zu speichern:

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

Da diese Änderung im Code implementiert werden muss, ist sie möglicherweise keine geeignete Lösung für Ihre Situation. Was geschieht, wenn jeder einzelne Produktdienst die Möglichkeit zum Lesen und Schreiben benötigt?

In diesem Fall können Sie das Skalieren von Azure SQL-Datenbank mithilfe von Sharding betrachten.

Datenbank-Sharding

Wenn Ihre Datenbankressourcen nach der Hochskalierung oder dem Einsatz von Lesereplikaten immer noch nicht den Systemanforderungen entsprechen, ist die nächste Option Sharding.

Sharding ist ein Verfahren zum Verteilen großer Mengen identisch strukturierter Daten über viele unabhängige Datenbanken hinweg. Sharding kann aus diversen Gründen notwendig sein. Beispiel:

• Die Gesamtmenge der Daten ist zu groß, um in die Einschränkungen einer einzelnen Datenbank zu passen.
• Der Transaktionsdurchsatz der gesamten Workload überschreitet die Funktionen einer einzelnen Datenbank.
• Separate Mandanten müssen sich wegen der Compliance auf verschiedenen physischen Datenbanken befinden. (Bei dieser Anforderung geht es weniger um die Skalierung, aber es handelt sich um eine weitere Situation, in der Sharding verwendet wird.)

Ihre Anwendung fügt den relevanten Shard die relevanten Daten hinzu und macht Ihr System somit über die Einschränkungen der einzelnen Datenbank hinaus skalierbar.

Azure SQL bietet die Azure Elastic Database Tools. Diese Tools helfen Ihnen beim Erstellen, Verwalten und Abfragen von sharded SQL-Datenbanken von Ihrer Anwendungslogik aus in Azure.