Vorbereiten

  • 5 Minuten

Sie fügen Ihre eigenen Erweiterungen zu einer bestehenden Architektur hinzu, die den Anforderungen an hohe Zuverlässigkeit des Unternehmens entspricht. Hier besprechen wir die Hintergrundinformationen, die Sie benötigen, um die Übungen erfolgreich zu absolvieren.

Problemkontext

Contoso Shoes muss für die nächste anspruchsvolle Produkteinführung bereit sein, von der ein erheblicher Anstieg des Datenverkehrs erwartet wird. In den letzten zwei Jahren gab es mehrere Vorfälle, die dazu führten, dass die Website bis zu einem halben Tag lang offline war. Das System wurde in der Entwicklungs-/Testumgebung nicht vollständig getestet, und einige Fehler haben sich in die Produktion eingeschlichen. Die Problembehandlung und -behebung nahm viel Zeit in Anspruch, da die Operatoren nicht in der Lage waren, die Grundursachen schnell zu identifizieren.

Es hat einige Herausforderungen gegeben, wenn bestimmte Komponenten nicht verfügbar waren. Die Vorgänge zur horizontalen Skalierung auf der Compute-Instanz wurden beeinträchtigt, als Azure Key Vault falsch konfiguriert war. Außerdem gibt es keine Strategien für regionale Ausfälle. Bei einem kürzlichen Vorfall ist die gesamte Region „Europa, Westen“ ausgefallen. Da die Workload nur in dieser Region ausgeführt wurde, musste das Unternehmen einen finanziellen Verlust hinnehmen, bis die Region wieder in Betrieb war.

Aktuelle Architektur

Damit Sie diese Herausforderung meistern können, müssen Sie die aktuelle Architektur von Contoso Shoe gut kennen. Konzentrieren wir uns auf die API-Ebene.

Diagramm der grundlegenden Architektur einer Webanwendung.

Komponenten

Alle Komponenten dieser Architektur werden in einer einzelnen Region bereitgestellt.

  • Die SKU „S2 Standard“ des Azure App Service-Plans stellt die Computeplattform bereit, auf der die App gehostet wird. Die automatische Skalierung ist aktiviert. In der Entwicklungsumgebung wird die SKU „Basic B1“ verwendet.

  • Azure App Service stellt die Anwendungsplattform bereit, die den API-Code in einem Container ausführt. Das Feature der App Service-Authentifizierung ist für die Autorisierung aktiviert.

  • Bereitstellungsslots ermöglichen Ihnen das Staging einer Bereitstellung und dann den Austausch durch die Produktionsbereitstellung. Sie werden nur in der Produktion verwendet.

  • Azure Container Registry speichert den containerisierten API-Code und wird durch CI/CD-Pipelines (Continuous Integration/Continuous Delivery) gepusht, die das Workloadteam erstellt und verwaltet. Die Containerregistrierung wird sowohl von Produktions- als auch von Entwicklungs-/Testumgebungen verwendet.

  • Azure Cosmos DB mit SQL-API speichert alle Zustände im Zusammenhang mit der Workload. Das Cosmos DB-Datenbankkonto besitzt eine einzelne Datenbank, die einige Container im Modell „Gemeinsam genutzter Durchsatz“ enthält. Das Azure Cosmos-Konto verwendet den serverlosen Kapazitätsmodus. Es gibt eine Instanz für die Produktionsumgebung und eine für die Entwicklungs-/Testumgebung.

  • Azure Key Vault speichert Geheimnisse, die für die API erforderlich sind, um einen HTTP POST-Aufruf an eine externe API von Drittanbietern als Teil eines Anforderungsablaufs zu tätigen. Die Anwendung greift auf die Geheimnisse über einen Key Vault-Verweis in der App-Konfiguration der Azure App Service-Instanz zu. Es gibt eine Key Vault-Instanz für die Produktionsumgebung und eine für die Entwicklungs-/Testumgebung.

  • Azure Log Analytics wird als einheitliche Senke verwendet, um Protokolle und Metriken für alle Azure Diagnostics-Einstellungen für alle in der Lösung festgelegten Komponenten zu speichern. Es gibt einen Arbeitsbereich für die Produktionsumgebung und einen für die Entwicklungs-/Testumgebung.

  • Azure Application Insights wird für die Erfassung von Telemetriedaten und Protokollen von der API verwendet. Application Insights verwendet den eigenständigen Modus und schreibt nicht in einen dedizierten Log Analytics-Arbeitsbereich. Die Produktionsumgebung und die Entwicklungs-/Testumgebung teilen sich keine gemeinsame Instanz.

  • Azure Pipelines wird für CI/CD verwendet, mit dem der Workload in Vorproduktions- und Produktionsumgebungen erstellt, getestet und bereitgestellt wird. Das Workloadteam verwaltet die Pipelines und auch die gesamte Infrastruktur in seiner Lösung. Bicep ist die Technologie der Wahl für Infrastructure-as-Code (IaC).

Entwurfsentscheidungen

In der Liste der Komponenten besteht der Bereitstellungsstempel aus Diensten, die an der Verarbeitung einer Anforderung beteiligt sind. Zu diesen Diensten gehören App Services, der API-Code und Cosmos DB. Der Stempel enthält auch nicht funktionale Komponenten: Key Vault und Container Registry. Die Anwendung ist von einem Drittanbieter-Framework für Leistung und Resilienz abhängig. Die systemseitig verwalteten Identitäten werden zwischen den Komponenten des Stempels verwendet.

Im Stempel wird App Services so konfiguriert, dass die Skalierung basierend auf der Auslastung automatisch erfolgt.

Für Produktion und Entwicklung/Test werden getrennte Umgebungen verwendet. Die Produktionsumgebung verwendet den die Standard-SKU des App Service-Plans. Das Unternehmen hat diese Entscheidung getroffen, um die Möglichkeit zu haben, die Anwendung vor der Bereitstellung in der Produktionsumgebung in einem Slot in einer Aufwärmphase vorzubereiten. In der Entwicklungs-/Testumgebung wird die Basic-SKU zur Kostenoptimierung verwendet. Beide Umgebungen verfügen über ihre eigenen Instanzen von Diensten. Die Umgebungen nutzen nur Container Registry gemeinsam.

Der containerisierte API-Code wird in einem einzelnen Containerimage geliefert, das in App Service ausgeführt wird. Die API verfügt über mehrere HTTP-Endpunkte, die von verschiedenen Front-Ends sowohl zum Lesen als auch zum Schreiben verwendet werden. Die Front-Ends sind nicht Teil dieses Moduls, sind jedoch im Gesamtbild für den unternehmenskritischen Status dieser Situation von Bedeutung. Der Code wurde mit Application Insights instrumentiert, um einige grundlegende Telemetriedaten zu erfassen. Das Team, das diesen Code entwickelt hat, verwaltet auch die CI/CD-Pipeline für das API-Containerimage und die CI/CD-Pipelines.

Kompromisse

Doch wie bei allem gibt es auch bei der aktuellen Architektur Kompromisse. Die geschäftlichen Anforderungen haben der Kostenoptimierung Vorrang vor Zuverlässigkeit und Betrieb gegeben. Um den Kostenrahmen einzuhalten, hat sich die Architektur nicht weiterentwickelt. Die Komponenten sind nicht in der Lage, die von der Plattform gebotene Zuverlässigkeit zu nutzen. Beispielsweise verhindert die Wahl der SKU für die Compute-Instanz, dass die Workload Verfügbarkeitszonen verwendet. Für die Telemetrie wird eine ältere Version von Application Insights verwendet, die nicht mit Log Analytics integriert ist.

Außerdem ist der Zugriff auf die Workload übermäßig weit verbreitet. Ohne Integration eines virtuellen Netzwerks können z. B. alle Azure-Dienste direkt über das öffentliche Internet erreicht werden.

Bei der Entwicklung der Lösung verwendete das App-Entwicklungsteam ein einzelnes Azure-Abonnement, in dem Entwicklung/Test und Produktion untergebracht waren, um die Tools für die DevOps-Teams zu vereinfachen. Aber die Produktionsressourcen und die Entwicklungs-/Testressourcen sind nicht vollständig voneinander getrennt. Einige Ressourcen werden von den beiden Umgebungen gemeinsam genutzt, obwohl sie ein von den restlichen Lösungen von Contoso Shoes isoliertes Abonnement erhalten haben.

Außerdem ist die Entwicklungs-/Testumgebung eine einzelne Umgebung, die von allen Mitgliedern des Entwicklungs- und QA-Teams freigegeben wird. Diese Entscheidung war angesichts der Größe der Teams gerechtfertigt, und die Koordination zwischen ihnen erforderte keinen höheren Grad an Isolation. Als sich das Team und die Lösung weiterentwickelten, führte die einzelne Entwicklungs-/Testumgebung zunehmend zu einer komplexen Integration, da die Lebenszyklen der Arbeitsstreams kollidierten. Der Churn und seine Auswirkungen auf die Zuverlässigkeit waren kostenintensiv.

Projektspezifikation

Das Unternehmen möchte die Architektur seiner Lösung um weitere Funktionen erweitern, damit sie in der Lage ist, die erwartete Zunahme der Last zu bewältigen. Hier sind die Geschäftsanforderungen:

  • Erstellen Sie die Fähigkeit, regionalen Ausfällen zu widerstehen, indem Sie die Architektur auf mehrere Regionen ausweiten.
  • Verbessern Sie das Kundenerlebnis, indem Sie Kunden in einer geografisch näher gelegenen Region schneller bedienen.
  • Richten Sie sich nach der Azure-Roadmap, und nutzen Sie die neuesten Zuverlässigkeitsfeatures der Azure-Dienste.
  • Erkennen Sie Probleme frühzeitig und deren kaskadenartige Auswirkungen auf das System, indem Sie ein umfassendes Integritätsmodell erstellen.

Diese Anforderungen sind nur die priorisierte Liste ihrer Verbesserungspläne. Das Anwendungsteam ist sich bewusst, dass alle Entwurfsbereiche berücksichtigt werden müssen, um die Zuverlässigkeit dieser Lösung auf ein unternehmenskritisches Niveau zu bringen. Seien Sie versichert, dass sie nicht aufhören werden, ihre Lösung und ihre Abläufe zu verbessern, nachdem Sie ihnen bei den Aspekten geholfen haben, die in den kommenden Übungen behandelt werden.

Willkommen im Team! Contoso Shoes freut sich auf Ihre Empfehlungen.

Setup

In diesem Challenge-Projekt schlüpfen Sie in die Rolle eines Architekten, der Contoso Shoes dabei hilft, ihre Zuverlässigkeitsziele zu erreichen, angefangen bei den priorisierten Elementen im vorherigen Abschnitt.

  • Wir empfehlen Ihnen, das Architekturdiagramm zur Visualisierung der Architektur zu verwenden.
  • Sie benötigen kein Azure-Abonnement für diese Herausforderung, wenn Sie mit den Diensten und ihren Features vertraut sind.