Minimaler Speicher – Feed ändern, um Daten zu replizieren

Azure Front Door

Azure App Service

Azure-Funktionen

Azure Cosmos DB

Azure Table Storage

In diesem Artikel wird eine Hochverfügbarkeitslösung für eine Webanwendung vorgestellt, die große Datenmengen verwaltet, auf die innerhalb eines bestimmten Zeitraums zugegriffen werden muss. Die Lösung verwendet Azure Cosmos DB als primären Datenspeicher und verwendet den Azure Cosmos DB Änderungsfeed, um Daten in kostengünstigen sekundären Speicher zu replizieren. Nach dem angegebenen Zeitraum verwendet die Lösung Azure Functions, um die Daten aus Azure Cosmos DB zu löschen. Die Daten im sekundären Speicher bleiben für die Überwachung und Analyse durch andere Lösungen länger verfügbar. Die Lösung repliziert Daten in verschiedene Datendienste, die eine hohe Haltbarkeit bieten.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Datenfluss

Der folgende Datenfluss entspricht dem vorherigen Diagramm:

Der Client authentifiziert sich mithilfe von Microsoft Entra ID und erhält Zugriff auf Webanwendungen, die auf Azure App Service gehostet werden.
Azure Front Door, bei dem es sich um einen Firewall- und Layer-7-Lastenausgleich handelt, wechselt den Benutzerdatenverkehr in den Standbybereich, wenn ein regionaler Ausfall auftritt.
Azure App Service hostet Websites und Web-APIs mit REST-Unterstützung. Browserclients führen asynchrone JavaScript- und XML-Anwendungen aus, die die APIs verwenden.
Web-APIs übertragen die Verantwortung für die Ausführung von Hintergrundaufgaben an in Functions gehosteten Code. Die Aufgaben sind in Warteschlangen des Azure Queue Storage eingereiht.
Die Nachrichten in der Warteschlange lösen die Funktionen aus, die die Hintergrundaufgaben ausführen.
Azure Managed Redis cacht Datenbankdaten für die Funktionen. Die Lösung entlädt Datenbanklesevorgänge für langsam ändernde Daten und beschleunigt die Funktions-Apps und Web-Apps mithilfe des Caches.
Azure Cosmos DB enthält kürzlich generierte Daten.
Azure Cosmos DB gibt einen Änderungsfeed aus, der zum Replizieren von Änderungen verwendet werden kann.
Eine Funktions-App liest den Änderungsfeed und repliziert die Änderungen in Azure Table Storage-Tabellen. Eine andere Funktions-App entfernt in regelmäßigen Abständen abgelaufene Daten aus Azure Cosmos DB.
Table Storage bietet kostengünstigen Speicher.

Komponenten

Microsoft Entra ID ist ein Identitäts- und Zugriffsverwaltungsdienst, der mit einem lokalen Verzeichnis synchronisiert werden kann. In dieser Architektur authentifiziert sie Benutzer und gewährt Zugriff auf Webanwendungen, die auf App Service gehostet werden.
Azure Front Door ist ein sicheres Netzwerk für die Inhaltsübermittlung und ein Lastenausgleich. In dieser Architektur beschleunigt sie die Inhaltsbereitstellung, bietet Failoverfunktionen und schützt Apps vor Cyberbedrohungen.
App Service ist ein vollständig verwalteter Dienst, den Entwickler zum Erstellen, Bereitstellen, Hosten und Skalieren von Web-Apps verwenden. Sie können Apps mithilfe von .NET, Node.js, Java, Python oder PHP erstellen. Die Apps können in Containern oder unter Windows oder Linux ausgeführt werden. In dieser Architektur hosten App Service die Webschnittstelle und REST-APIs für die Anwendung. Weitere Informationen zu Web-APIs finden Sie unter RESTful Web-API-Design.
Funktionen stellen eine Umgebung bereit, um kleine Codeteile auszuführen, die als Funktionen bezeichnet werden, ohne eine Anwendungsinfrastruktur einrichten zu müssen. Sie können damit Massendaten verarbeiten, Systeme integrieren, mit IoT-Geräten arbeiten und einfache APIs und Microservices erstellen. Sie können Microservices verwenden, um Server zu erstellen, die eine Verbindung mit Azure Diensten herstellen und immer auf dem neuesten Stand bleiben. In dieser Architektur führt Functions Hintergrundaufgaben wie Datenreplikation und das Löschen abgelaufener Datensätze aus.
Azure Storage ist eine Reihe skalierbarer und sicherer Clouddienste für Daten, Apps und Workloads. In dieser Architektur bietet Storage Warteschlangenspeicher für Aufgabennachrichten und Tabellenspeicher für kostengünstige replizierte Datenspeicher.
- Azure Queue Storage stellt einfache, kostengünstige und stabile Nachrichtenwarteschlangen für große Workloads zur Verfügung. Diese Architektur verwendet Warteschlangenspeicher für Aufgabennachrichten.
- Table Storage ist ein NoSQL-Schlüssel-Wert-Speicher für die schnelle Entwicklungsarbeit, der massive halbstrukturierte Datasets verwendet. Die Tabellen sind schemalos und passen sich nach Bedarf an. Der Zugriff ist für viele Anwendungen schnell und kostengünstig. Diese Architektur verwendet Tabellenspeicher zum Speichern einer synchronisierten und umstrukturierten Kopie der Daten in Azure Cosmos DB.
Azure Managed Redis ist ein vollständig verwalteter Speicherzwischenspeicherungsdienst und Nachrichtenbroker für Daten und Zustandsfreigabe zwischen Computeressourcen. Um die Leistung von OLTP-Anwendungen mit hohem Durchsatz zu verbessern, konzipieren Sie sie so, dass sie mithilfe eines In-Memory-Datenspeichers wie Azure Managed Redis skalieren. In dieser Architektur beschleunigt Azure Managed Redis den Zugriff auf häufig verwendete Daten, wodurch die Leistung für Funktions-Apps und Web-Apps verbessert wird.
Azure Cosmos DB ist eine global verteilte Multimodelldatenbank, die Ihre Lösungen für den elastisch und unabhängigen Skalierungsdurchsatz und -speicher in einer beliebigen Anzahl geografischer Regionen bereitstellt. Sie bietet Durchsatz-, Latenz-, Verfügbarkeits- und Konsistenzgarantien mit umfassenden Vereinbarungen auf Serviceebene. In dieser Architektur speichert Azure Cosmos DB aktuelle Daten und stellt einen Änderungsfeed bereit, den Sie verwenden können, um Aktualisierungen in Table Storage zu replizieren.

Alternativen

Azure Traffic Manager leitet auf der Grundlage der von Ihnen gewählten Routingmethoden für Datenverkehr eingehende DNS-Anforderungen über die globalen Azure-Regionen hinweg weiter. Er bietet darüber hinaus automatisches Failover und leistungsorientiertes Routing.
Azure Container Apps ist ein vollständig verwalteter, serverloser Containerdienst, den Entwickler zum Erstellen und Bereitstellen moderner Apps im großen Maßstab verwenden.
Azure Kubernetes Service (AKS) ist ein vollständig verwalteter Kubernetes-Dienst für containerisierte Anwendungsbereitstellung und -verwaltung. Sie können sie verwenden, um eine Microservices-Architektur mit Komponenten zu implementieren, die unabhängig und bei Bedarf skaliert werden.
Azure Container Instances führt Aufgaben ohne Infrastrukturverwaltung aus. Es ist während der Entwicklung und zum Ausführen ungeplanter Aufgaben nützlich.
Azure Service Bus ist ein zuverlässiger Cloudmessagingdienst für einfache Hybridintegrationen. Er kann in dieser Architektur anstelle von Queue Storage verwendet werden. Weitere Informationen finden sie unter Storage-Warteschlangen und Service Bus-Warteschlangen – Vergleich und Gegenüberstellung.

Szenariodetails

Diese Lösung speichert große Mengen von Webanwendungsdaten in Azure Cosmos DB. Web-Apps, die massive Datenmengen verarbeiten, verwenden Azure Cosmos DB, um Durchsatz und Speicher elastisch und unabhängig zu skalieren.

Wenn Änderungen an der Datenbank vorgenommen werden, wird der Azure Cosmos DB Änderungsfeed an einen ereignisgesteuerten Funktionstrigger gesendet. Eine Funktion wird dann ausgeführt und repliziert die Änderungen zu Table Storage-Tabellen, die eine kostengünstige Speicherlösung bieten. Sie können auch eine breitere nachgelagerte Datenverschiebung koordinieren, indem Sie Azure Data Factory Pipelines oder Fabric Data Factory verwenden, um Daten in Analysezonen zu landen.

Die Web-App benötigt die Daten nur für einen begrenzten Zeitraum. Diese Lösung führt in regelmäßigen Abständen abgelaufene Daten aus Azure Cosmos DB aus, wodurch die Kosten reduziert werden. Sie können Funktionen bei Bedarf auslösen oder die Ausführung zu bestimmten Zeiten planen.

Mögliche Anwendungsfälle

Diese Lösung eignet sich für jede Anwendung, die:

eine große Menge an Daten verwendet.
Erfordert, dass Daten in einem bestimmten Zeitrahmen verfügbar sind.
Daten verwendet, die ablaufen.

Beispiele hierfür sind Apps, die für Folgendes verwendet werden:

Personalisieren Sie die Kundenerfahrung und fördern Sie das Engagement mithilfe von Livedatenfeeds und Sensoren an physischen Standorten.
Nachverfolgen des Ausgaben- und Einkaufsverhaltens von Kunden.
Verfolgen Sie Fahrzeugflotten und verbessern Sie Effizienz und Sicherheit mithilfe von Fahrzeugstandort-, Leistungs- und Fahrerverhaltensdaten.
Wettervorhersage.
Überwachen und Verwalten von Verkehrssystemen.
Analysieren Sie IoT-Produktionsdaten.
Überwachen sie Smart Meter-Daten.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Zuverlässigkeit

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Der Azure Cosmos DB-Änderungsfeed garantiert eine Zustellung mindestens einmal. Entwerfen Sie Ihre Replikationsfunktion so, dass sie idempotent ist, sodass doppelte Ereignisse keine inkonsistenten Daten im Tabellenspeicher generieren.
Azure Front Door bietet automatisches regionales Failover. Wenn die primäre Region nicht verfügbar ist, wird der Datenverkehr ohne manuelles Eingreifen an den Standbybereich weitergeleitet.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

Der wesentliche Kostenvorteil ergibt sich aus der Verschiebung abgelaufener Daten aus Azure Cosmos DB, das pro Anforderungseinheit (RU) abgerechnet wird, in Table Storage, das pro Transaktion und pro gespeichertem GB abgerechnet wird. Dieser Vorgang ist billiger für selten aufgerufene Daten.
Wenn Ihre Workload über vorhersehbare Durchsatzanforderungen verfügt, sollten Sie reserved capacity für Azure Cosmos DB in Betracht ziehen.
Verwenden Sie den Änderungsfeed für die Replikation. Diese Methode reduziert die Codewartung im Vergleich zur Replikation in der Kernanwendung.
Diese Lösung verursacht zusätzliche Kosten für Sekundärspeicher sowie für die Funktionen, die die Datenreplikation und den Ablauf von Daten verwalten.

Betriebliche Effizienz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie in der Prüfliste für das Design Review von Operational Excellence.

Sie müssen vorhandene Daten migrieren. Der Migrationsprozess erfordert Ad-hoc-Skripts oder Routinen, um alte Daten in Speicherkonten zu kopieren. Wenn Sie die Daten migrieren, verwenden Sie Zeitstempel und Kopierkennzeichnungen, um den Migrationsfortschritt nachzuverfolgen.
Ignorieren Sie Löschfeeds, die von Ihren Funktionen generiert werden, wenn sie Einträge aus Azure Cosmos DB löschen. Dieser Ansatz verhindert, dass Einträge aus Azure sekundären Tabellenspeicher entfernt werden.

Leistungseffizienz

Leistungseffizienz bezieht sich auf die Fähigkeit Ihrer Arbeitslast, effizient auf die Anforderungen der Benutzer zu skalieren. Weitere Informationen finden Sie in der Checkliste zur Entwurfsüberprüfung für die Leistungseffizienz.

Die Latenz der Änderungsfeedverarbeitung wirkt sich auf die schnelle Verfügbarkeit von Daten im Tabellenspeicher aus. Um Ihre Latenzanforderungen zu erfüllen, skalieren Sie den Funktions-App-Plan und die Batcheinstellungen.
Um hot partitions zu vermeiden, wählen Sie einen Azure Cosmos DB Partitionsschlüssel aus, der den Schreibdurchsatz gleichmäßig über logische Partitionen verteilt.
Azure Managed Redis reduziert den Lesedruck auf Azure Cosmos DB für langsam ändernde Daten, wodurch die Latenz und der RU-Verbrauch verringert werden.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Nabil Siddiqui | Cloud Solution Architect – Digitale und Anwendungsinnovationen

Andere Mitwirkende:

Filipe Moreira | Cloud-Lösungsarchitekt

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Feedback

War diese Seite hilfreich?