Skalierbare Anwendungen machen
- 8 Minuten
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:
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 können auf VMs oder App Service ausgeführt werden. Sie verwenden 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 einer VM 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 einzigen Azure SQL-Datenbank verbunden ist. Sie müssen diesen virtuellen Computer zum Skalieren aktivieren. Dazu können Sie Skalierungssätze für virtuelle Azure-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 unabhängige eigenständige Rechenzentren in einer Azure-Region sind. Mit AZ-Unterstützung können Sie Ihre virtuellen Computer über mehrere AZs verteilen, wodurch Ihre Anwendung zuverlässiger ist 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 das Azure-Anwendungsgateway für die erweiterte Verteilung von L7-Datenverkehr und SSL-Terminierung.
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 Produktservice einen Job. Es nimmt ein Produktbild und lädt dann dieses Bild hoch. Es transcodiert 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 Queues 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 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 können 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 die Azure SQL-Datenbank, bei der es sich um ein verwaltetes SQL Server-Angebot von Azure handelt.
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 ganz einfach mit einer durchschnittlichen Downtime von weniger als vier Sekunden durchgeführt werden. 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 Datenverkehrsmerkmalen geeignet sein, die Lesevorgänge in die Datenbank zu skalieren. Auf diese Weise können Sie den Lesedatenverkehr an Ihr Lesereplikat weiterleiten.
Hinweis
Wenn Sie die Stufe "Premium" oder "Business Critical" verwenden, ist Azure SQL standardmäßig "Read Scale Out" aktiviert. Sie kann nicht auf basis- oder Standardebenen aktiviert werden.
Diese Änderung muss im Code implementiert werden. Gehen Sie dazu wie folgt vor:
#Azure SQL Connection String
#Master Connection String
ApplicationIntent=ReadWrite
#Read Replica Connection String
ApplicationIntent=ReadOnly
#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;
Aktualisieren Sie das ApplicationIntent Attribut in Ihrer Datenbankverbindungszeichenfolge, um anzugeben, mit welchem Server Sie eine Verbindung herstellen möchten. Verwenden Sie ReadOnly, wenn Sie eine Verbindung mit dem Replikat herstellen möchten, oder ReadWrite, wenn Sie eine Verbindung mit dem Master herstellen möchten.
Da dieser Befehl im Code implementiert werden muss, ist er 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 SQL DB mithilfe von Sharding untersuchen.
Datenbank-Sharding
Wenn die Datenbankressourcen nach dem Hochskalieren oder der Implementierung von Lesereplikaten die Anforderungen Ihres Systems weiterhin nicht erfüllen, ist die nächste Option das 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. Mit diesen Tools können Sie partitionierte (sharded) SQL-Datenbanken in Azure aus Ihrer Anwendungslogik erstellen, verwalten und abfragen.