Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Nachdem Sie nun einige wichtige Plattformunterschiede zwischen AWS und Azure verstanden haben, die für diese Workload relevant sind, befassen Sie sich im Folgende mit der Workflowarchitektur und deren Anpassung für die Arbeit in AKS.
AWS-Workloadarchitektur
Die AWS-Workload ist ein einfaches Beispiel für das Entwurfsmuster mit konkurrierenden Consumern. Die AWS-Implementierung ist eine Referenzarchitektur für die Verwaltung von Skalierung und Kosten für ereignisgesteuerte Workflows mit Kubernetes, Kubernetes Event-driven Autocaling (KEDA) und Karpenter.
Eine Producer-App generiert Ladevorgänge durch das Senden von Nachrichten an eine Warteschlange, und eine Consumer-App, die in einem Kubernetes-Pod ausgeführt wird, verarbeitet die Nachrichten und schreibt die Ergebnisse in eine Datenbank. KEDA verwaltet die automatische Skalierung von Pods über eine deklarative Bindung an die Producerwarteschlange, während Karpenter die automatische Skalierung der Knoten mit gerade ausreichenden Computeressourcen verwaltet, um die Kosten zu optimieren. Für die Authentifizierung bei der Warteschlange und der Datenbank wird die auf OAuth basierende Volumenprojektion für Dienstkontotoken verwendet.
Die Workload besteht aus einem AWS EKS-Cluster zum Orchestrieren der Consumer, die Nachrichten aus Amazon Simple Queue Service (SQS) lesen und verarbeitete Nachrichten in einer Amazon DynamoDB-Tabelle speichern. Eine Producer-App generiert Nachrichten und reiht sie in die Amazon SQS-Warteschlange ein. KEDA und Karpenter skalieren die Anzahl der EKS-Knoten und -Pods für die Consumer dynamisch.
Das folgende Diagramm zeigt die Architektur der EDW-Workload in AWS:
Zuordnen von AWS-Diensten zu Azure-Diensten
Um die AWS-Workload in Azure mit minimalen Änderungen neu zu erstellen, verwenden Sie für jeden AWS-Dienst einen äquivalenten Azure-Dienst und verwenden ähnliche Authentifizierungsmethoden wie im Original. In diesem Beispiel sind die erweiterten Features von Azure Service Bus oder Azure Event Hubs nicht erforderlich. Stattdessen können Sie Azure Queue Storage verwenden, um Aufgaben in eine Warteschlange einzureihen, und Azure Table Storage, um die Ergebnisse zu speichern.
In der folgenden Tabelle sind die Dienstzuordnungen zusammengefasst:
| Dienstzuordnung | AWS-Dienst | Azure-Dienst |
|---|---|---|
| Queuing | Simple Queue Service | Azure Queue Storage |
| Persistenz | DynamoDB (NoSQL) | Azure Table Storage |
| Orchestrierung | Elastic Kubernetes Service (EKS) | Azure Kubernetes Service (AKS) |
| Identität | AWS IAM | Microsoft Entra |
Azure Workloadarchitektur
Das folgende Diagramm zeigt die Architektur der Azure EDW-Workload mit der AWS-zu-Azure-Dienstzuordnung:
Computeoptionen
Abhängig von den Überlegungen zu Kosten und Resilienz für mögliche Knotenentfernungen können Sie verschiedenen Computetypen auswählen.
In AWS können Sie zwischen On-Demand-Compute (teurer, aber keine Risiko der Entfernung) oder Spotinstanzen (günstiger, aber mit Risiko einer Entfernung) auswählen. In AKS können Sie abhängig von den Anforderungen Ihrer Workload einen On-Demand-Knotenpool oder einen Spotknotenpool auswählen.
Nächste Schritte
Beitragende
Microsoft pflegt diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben:
- Ken Kilty | Principal TPM
- Russell de Pina | Principal TPM
- Jenny Hayes | Senior Content Developer
- Carol Smith | Senior Content Developer
- Erin Schaffer | Content Developer 2