Einfache Webanwendung

App Service
Key Vault
Monitor
SQL-Datenbank
Web Apps

Diese Referenzarchitektur veranschaulicht bewährte Verfahren für eine Webanwendung, die Azure App Service und Azure SQL-Datenbank verwendet.

Aufbau

Diagram showing the reference architecture for a basic web application in Azure.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Die Architektur umfasst die folgenden Komponenten:

App Service-Plan: Ein App Service-Plan dient zur Bereitstellung der verwalteten virtuellen Computer (VMs), auf denen Ihre App gehostet wird. Alle einem Plan zugeordneten Apps werden auf den gleichen VM-Instanzen ausgeführt.

App Service-App: Azure App Service ist eine umfassend verwaltete Plattform zum Erstellen und Bereitstellen von Cloudanwendungen.

Bereitstellungsslots: Ein Bereitstellungsslot ermöglicht Ihnen das Staging einer Bereitstellung und dann den Austausch durch die Produktionsbereitstellung. Auf diese Weise vermeiden Sie die direkte Bereitstellung in der Produktionsumgebung. Im Abschnitt Verwaltbarkeit finden Sie spezifische Empfehlungen.

IP-Adresse: Die App Service-App verfügt über eine öffentliche IP-Adresse und einen Domänennamen. Der Domänenname ist eine Unterdomäne von azurewebsites.net, z.B. contoso.azurewebsites.net.

Azure DNS: Azure DNS ist ein Hostingdienst für DNS-Domänen, der die Namensauflösung unter Verwendung der Microsoft Azure-Infrastruktur durchführt. Durch das Hosten Ihrer Domänen in Azure können Sie Ihre DNS-Einträge mithilfe der gleichen Anmeldeinformationen, APIs, Tools und Abrechnung wie für die anderen Azure-Dienste verwalten. Erstellen Sie zur Verwendung eines benutzerdefinierten Domänennamens (etwa contoso.com) DNS-Einträge, die der IP-Adresse den benutzerdefinierten Domänennamen zuordnen. Weitere Informationen finden Sie unter Konfigurieren eines benutzerdefinierten Domänennamens in Azure App Service.

Azure SQL-Datenbank: SQL-Datenbank ist ein Dienst mit einer relationalen Datenbank in der Cloud (Database-as-a-Service). SQL-Datenbank nutzt diese Codebasis gemeinsam mit der Microsoft SQL Server-Datenbank-Engine. Je nach Ihren Anwendungsanforderungen können Sie auch Azure Database for MySQL oder Azure Database for PostgreSQL verwenden. Hierbei handelt es sich um vollständig verwaltete Dienste, die auf den Open-Source-Datenbank-Engines für MySQL Server und Postgres basieren.

Komponenten

Referenzbereitstellung

Diese Architektur umfasst einen Azure App Service-Plan und eine leere Anwendung, Azure SQL-Datenbank, Azure Key Vault zum Speichern der Verbindungszeichenfolge für die Datenbank und Azure Monitor für die Protokollierung, Überwachung und Warnungsanzeige.

Verwenden Sie den folgenden Befehl, um eine Ressourcengruppe für die Bereitstellung zu erstellen. Klicken Sie auf die Schaltfläche Testen, um eine eingebettete Shell zu verwenden.

az group create --name basic-web-app --location eastus

Führen Sie den folgenden Befehl aus, um die Webanwendung und die unterstützende Infrastruktur bereitzustellen. Geben Sie nach entsprechender Aufforderung einen Benutzernamen und das Kennwort ein. Diese Werte werden für den Zugriff auf die Azure SQL-Datenbankinstanz verwendet.

az deployment group create --resource-group basic-web-app  \
    --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/basic-web-app/azuredeploy.json

Ausführliche Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den ARM-Vorlagen, die für die Bereitstellung dieser Lösung verwendet werden.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die Empfehlungen in diesem Abschnitt als Ausgangspunkt.

App Service-Plan

Verwenden Sie die Tarife Free und Shared (Vorschau) zum Testen, da die freigegebenen Ressourcen nicht aufskaliert werden können. Die beiden Tarife bieten unterschiedliche Optionen innerhalb Ihres Budgets. Führen Sie Ihre Produktionsworkloads in den Tarifen Basic, Standard und Premium aus, da die App auf dedizierten VM-Instanzen ausgeführt wird und über Ressourcen verfügt, die aufskaliert werden können. App Service-Pläne werden sekundengenau abgerechnet.

Weitere Informationen finden Sie unter Wie viel kostet mein App Service-Plan?.

Verwenden Sie den Standard- oder Premium-Tarif, weil dafür das Aufskalieren, die automatische Skalierung und SSL (Secure Sockets Layer) unterstützt werden. Alle Tarife unterstützen verschiedene Instanzgrößen, die sich anhand der Anzahl von Kernen und des Arbeitsspeichers unterscheiden. Sie können den Tarif oder die Instanzgröße nach der Erstellung eines Plans ändern. Weitere Informationen zu App Service-Plänen finden Sie unter App Service – Preise.

Die Instanzen im App Service-Plan werden Ihnen in Rechnung gestellt, auch wenn die App nicht ausgeführt wird. Achten Sie darauf, nicht verwendete Pläne (z.B. Testbereitstellungen) zu löschen.

SQL-Datenbank

Eine logische Servergruppe vereinfacht Verwaltungsaufgaben. Jede Datenbank innerhalb der Gruppe wird mit einer bestimmten Dienstebene bereitgestellt. Innerhalb jeder Gruppe können die Datenbanken keine Ressourcen gemeinsam nutzen. Es fallen keine Computekosten für den Server an, aber Sie müssen die Ebene für jede Datenbank festlegen. Daher wird aufgrund der dedizierten Ressourcen unter Umständen eine höhere Leistung erzielt, aber die Kosten können höher sein.

Verwenden Sie die V12-Version von SQL-Datenbank. SQL-Datenbank unterstützt die Dienstebenen „Basic“, „Standard“ und „Premium“ mit mehreren Leistungsebenen innerhalb der einzelnen Tarife, die in Datenbanktransaktionseinheiten (Database Transaction Units, DTUs) gemessen werden. Führen Sie Kapazitätsplanung durch, und wählen Sie einen Tarif und eine Leistungsstufe aus, die Ihren Anforderungen entsprechen.

Region

Stellen Sie den App Service-Plan und die SQL-Datenbank in der gleichen Region bereit, um die Netzwerklatenz zu minimieren. Wählen Sie grundsätzlich die Ihren Benutzern am nächsten gelegene Region aus.

Die Ressourcengruppe weist ebenfalls eine Region auf, die angibt, wo die Metadaten der Bereitstellung gespeichert werden. Implementieren Sie die Ressourcengruppe und ihre Ressourcen in der gleichen Region. Dies kann die Verfügbarkeit während der Bereitstellung verbessern.

Verwenden Sie den Preisrechner, um Ihre Kosten zu ermitteln.

Weitere Informationen finden Sie im Abschnitt zu Kosten im Microsoft Azure Well-Architected Framework.

Überlegungen

Skalierbarkeit

Ein großer Vorteil von Azure App Service ist die Möglichkeit, Ihre Anwendung abhängig von der Last zu skalieren. Hier sind einige Punkte aufgeführt, die beim Planen der Skalierung für Ihre Anwendung zu bedenken sind.

Skalieren der App Service-App

Es gibt zwei Möglichkeiten zum Skalieren einer App Service-App:

  • Hochskalieren, was die Änderung der Instanzgröße bedeutet. Die Instanzgröße bestimmt den Arbeitsspeicher, die Anzahl der Kerne und den Massenspeicher für die einzelnen VM-Instanzen. Das Hochskalieren kann manuell erfolgen, indem Sie die Instanzgröße oder den Plantarif ändern.

  • Aufskalieren, was das Hinzufügen von Instanzen zum Verarbeiten höherer Auslastungen bedeutet. Für jede Tarifebene gibt es eine Maximalanzahl Instanzen.

Sie können manuell aufskalieren, indem Sie die Instanzanzahl ändern, oder die automatische Skalierung verwenden, wenn Azure basierend auf einem Zeitplan bzw. auf Leistungsmetriken automatisch Instanzen hinzufügen oder entfernen soll. Die Skalierungsvorgänge dauern normalerweise nicht lange, sondern nur wenige Sekunden.

Um die automatische Skalierung zu aktivieren, erstellen Sie ein Profil für die automatische Skalierung, das die Minimal- und Maximalanzahl der Instanzen definiert. Profile können geplant werden. Beispielsweise können Sie separate Profile für Wochentage und Wochenenden erstellen. Optional enthält ein Profil Regeln dafür, wann Instanzen hinzugefügt oder entfernt werden sollen. (Beispiel: Zwei Instanzen hinzufügen, wenn die CPU-Auslastung fünf Minuten lang bei über 70 Prozent liegt.)

Empfehlungen zum Skalieren einer Web App:

  • Vermeiden Sie nach Möglichkeit das Hoch- und Herunterskalieren, da dies zu einem Neustart der Anwendung führen kann. Wählen Sie stattdessen einen Tarif und eine Größe aus, der bzw. die Ihre Leistungsanforderungen unter typischer Last erfüllt, und skalieren Sie die Instanzen auf, um Änderungen beim Datenverkehrsvolumen zu bewältigen.
  • Aktivieren Sie die automatische Skalierung. Wenn Ihre Anwendung eine vorhersehbare normale Arbeitsauslastung aufweist, erstellen Sie Profile, um die Instanzanzahl im Voraus zu planen. Wenn die Arbeitsauslastung nicht vorhersehbar ist, verwenden Sie regelbasierte automatische Skalierung, um auf Änderungen der Arbeitsauslastung beim Eintreten zu reagieren. Beide Ansätze können kombiniert werden.
  • Die CPU-Auslastung ist im Allgemeinen eine gute Metrik für Regeln zur automatischen Skalierung. Jedoch sollten Sie einen Auslastungstest Ihrer Anwendung durchführen, potenzielle Engpässe identifizieren und Regeln für die automatische Skalierung auf diesen Daten aufbauen.
  • Regeln für die automatische Skalierung beinhalten eine Abkühlphase. Hiermit wird die Warteperiode nach dem Abschluss einer Skalierungsaktion bezeichnet, bevor eine neue Skalierungsaktion gestartet wird. In der Abkühlphase stabilisiert sich das System, bevor eine erneute Skalierung erfolgt. Legen Sie eine kürzere Abkühlphase für das Hinzufügen von Instanzen und eine längere Abkühlphase für das Entfernen von Instanzen fest. Legen Sie beispielsweise 5 Minuten für das Hinzufügen einer Instanz aber 60 Minuten für das Entfernen einer Instanz fest. Es ist besser, bei hoher Auslastung schnell neue Instanzen hinzuzufügen, um den zusätzlichen Datenverkehr zu bewältigen, und das System dann nach und nach wieder herunterzuskalieren.

Skalierung einer SQL-Datenbank

Wenn Sie eine höhere Dienstebene oder Leistungsstufe für SQL-Datenbank benötigen, können Sie einzelne Datenbanken ohne Ausfallzeit der Anwendung hochskalieren. Weitere Informationen finden Sie unter Skalieren von Einzeldatenbankressourcen in Azure SQL-Datenbank.

Verfügbarkeit

Zum Entstehungszeitpunkt dieses Artikels beträgt der SLA-Prozentsatz (Vereinbarung zum Servicelevel) für App Service 99,95 % und für SQL-Datenbank 99,99 % für die Tarife Basic, Standard und Premium. Die App Service-SLA gilt sowohl für einzelne als auch für mehrere Instanzen.

Backups

Im Fall eines Datenverlusts stellt SQL-Datenbank Point-in-Time-Wiederherstellung und Geowiederherstellung bereit. Diese Funktionen sind in allen Tarifen verfügbar und automatisch aktiviert. Sie brauchen keine Sicherungen zu planen oder zu verwalten.

Weitere Informationen finden Sie unter Geschäftskontinuität für die Cloud und Notfallwiederherstellung für Datenbanken mit SQL-Datenbank.

App Service bietet eine Funktion zum Sichern und Wiederherstellen Ihrer Anwendungsdateien. Beachten Sie hierbei aber, dass in den gesicherten Dateien Anwendungseinstellungen als Klartext vorhanden sind, die Geheimnisse enthalten können, z. B. Verbindungszeichenfolgen. Vermeiden Sie die Verwendung der App Service-Sicherungsfunktion für die Sicherung Ihrer SQL-Datenbanken, da sie die Datenbank in eine SQL-BACPAC-Datei exportiert und dabei DTUs verbraucht. Verwenden Sie stattdessen die oben beschriebene SQL-Datenbank Point-in-Time-Wiederherstellung.

Verwaltbarkeit

Erstellen Sie separate Ressourcengruppen für Produktions-, Entwicklungs- und Testumgebungen. Dies erleichtert das Verwalten von Bereitstellungen, das Löschen von Testbereitstellungen und das Zuweisen von Zugriffsrechten.

Berücksichtigen Sie beim Zuweisen von Ressourcengruppen die folgenden Punkte:

  • Lebenszyklus. Platzieren Sie Ressourcen mit gleichem Lebenszyklus im Allgemeinen in der gleichen Ressourcengruppe.
  • Zugriff. Sie können Zugriffsrichtlinien mithilfe der rollenbasierten Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) auf die in einer Gruppe enthaltenen Ressourcen anwenden.
  • Abrechnung. Sie können die angefallenen Kosten für die Ressourcengruppe anzeigen.

Weitere Informationen finden Sie unter Übersicht über den Azure Resource Manager.

DevOps

Bei dieser Architektur verwenden Sie eine Azure Resource Manager-Vorlage, um die Azure-Ressourcen und die zugehörigen Abhängigkeiten bereitzustellen. Da es sich hierbei um eine einzelne Webanwendung handelt, sind alle Ressourcen in derselben grundlegenden Workload isoliert. Dies vereinfacht die Zuordnung der spezifischen Ressourcen der Workload zu einem Team, damit es alle Aspekte dieser Ressourcen separat verwalten kann. Diese Isolation ermöglicht dem DevOps-Team die Durchführung von Continuous Integration- und Continuous Delivery-Vorgängen (CI/CD). Außerdem können Sie verschiedene ARM-Vorlagen verwenden und in Azure DevOps Services integrieren, um in wenigen Minuten unterschiedliche Umgebungen bereitzustellen. Beispielsweise können Sie das Replizieren von produktionsähnlichen Szenarien oder Umgebungen für Auslastungstests bedarfsgesteuert durchführen, um Kosten zu sparen.

Stellen Sie mehrere Instanzen der Webanwendung bereit, damit keine Abhängigkeit von nur einer Instanz besteht, weil sonst ein Single Point of Failure entstehen kann. Darüber hinaus wird die Resilienz und Skalierbarkeit verbessert, wenn mehrere Instanzen bereitgestellt werden.

Bereitstellung

Die Bereitstellung umfasst zwei Schritte:

  1. Bereitstellen der Azure-Ressourcen. Wir empfehlen für diesen Schritt die Verwendung von Azure Resource Manager-Vorlagen. Mithilfe von Vorlagen können Bereitstellungen über PowerShell oder die Azure-Befehlszeilenschnittstelle einfacher automatisiert werden.
  2. Bereitstellen der Anwendung (Code, Binarys und Inhaltsdateien). Es gibt eine Reihe verschiedener Optionen, einschließlich der Bereitstellung aus einem lokalen Git-Repository, der Verwendung von Visual Studio oder Continuous Deployment aus einer cloudbasierten Quellcodeverwaltung. Weitere Informationen finden Sie unter Bereitstellen der App in Azure App Service.

Eine App Service-App weist immer einen Bereitstellungsslot mit dem Namen production auf, der die Produktions-Livewebsite darstellt. Wir empfehlen, zum Bereitstellen von Updates einen Stagingslot zu erstellen. Zu den Vorteilen beim Verwenden eines Stagingslots gehören:

  • Sie können überprüfen, ob die Bereitstellung erfolgreich war, bevor Sie sie in der Produktionsumgebung nutzen.
  • Das Bereitstellen in einem Stagingslot stellt sicher, dass alle Instanzen warmgelaufen sind, bevor sie in die Produktionsumgebung eingebracht werden. Viele Anwendungen weisen eine erhebliche Aufwärmdauer und Kaltstartzeit auf.

Ferner empfehlen wir die Erstellung eines dritten Slots zur Aufnahme der letzten als funktionierend bekannten Bereitstellung. Verschieben Sie nach dem Vertauschen von Staging- und Produktionsumgebung die bisherige Produktionsumgebung (die sich jetzt im Stagingslot befindet) in den Slot für die letzte als funktionierend bekannte Bereitstellung. Wenn Sie zu einem späteren Zeitpunkt ein Problem feststellen, können Sie auf diese Weise schnell zur letzten als funktionierend bekannten Version zurückkehren.

Swapping slots for production and staging deployments

Wenn Sie eine frühere Version wiederherstellen, achten Sie darauf, dass alle Änderungen am Datenbankschema abwärtskompatibel sind.

Verwenden Sie keine Slots in Ihrer Produktionsumgebung für Tests, da alle Apps in einem App Service-Plan die gleichen VM-Instanzen nutzen. Auslastungstests können z.B. den aktiven Produktionsstandort beeinträchtigen. Erstellen Sie stattdessen separate App Service-Pläne für die Produktion und für Tests. Indem Sie Testbereitstellungen in einen separaten Plan aufnehmen, isolieren Sie sie von der Produktionsversion.

Konfiguration

Speichern Sie die Konfigurationseinstellungen als App-Einstellungen. Definieren Sie die App-Einstellungen in Ihren Resource Manager-Vorlagen oder mit PowerShell. Zur Laufzeit stehen App-Einstellungen der Anwendung als Umgebungsvariablen zur Verfügung.

Checken Sie niemals Kennwörter, Zugriffsschlüssel oder Verbindungszeichenfolgen in die Quellcodeverwaltung ein. Übergeben Sie diese stattdessen als Parameter an ein Bereitstellungsskript, das diese Werte als Anwendungseinstellungen speichert.

Wenn Sie einen Bereitstellungsslot tauschen, werden die App-Einstellungen standardmäßig ebenfalls getauscht. Falls Sie unterschiedliche Einstellungen für Produktion und Staging benötigen, können Sie Anwendungseinstellungen erstellen, die fest bei einem Slot verbleiben und nicht getauscht werden.

Diagnose und Überwachung

Aktivieren Sie die Diagnoseprotokollierung, einschließlich Anwendungsprotokollierung und Webserverprotokollierung. Konfigurieren Sie für die Protokollierung die Verwendung von Azure Log Analytics. Detailliertere Anweisungen zur Protokollierung finden Sie unter Anleitung zur Überwachung und Diagnose.

Verwenden Sie einen Dienst wie New Relic oder Application Insights, um Leistung und Verhalten der Anwendung unter Last zu überwachen. Beachten Sie die Grenzwerte der Datenrate für Application Insights.

Führen Sie Auslastungstests mithilfe eines Tools wie Azure DevOps oder Visual Studio Team Foundation Server durch. Eine allgemeine Übersicht zur Leistungsanalyse in Cloudanwendungen finden Sie unter Einsteig in die Leistungsanalyse.

Tipps zur Problembehandlung bei der Anwendung:

Weitere Informationen finden Sie unter Azure Well-Architected Framework im Abschnitt zu DevOps.

Sicherheit

Dieser Abschnitt enthält Sicherheitshinweise, die für die in diesem Artikel beschriebenen Azure-Dienste spezifisch sind. Es handelt sich nicht um eine vollständige Liste der bewährten Sicherheitsmethoden. Weitere Sicherheitshinweise finden Sie unter Schützen einer App in Azure App Service.

SQL-Datenbanküberwachung

Die Überwachung kann Ihnen dabei helfen, die gesetzlichen Bestimmungen einzuhalten und Einblicke in Abweichungen und Unregelmäßigkeiten zu erhalten, die auf Geschäftsvorgänge oder mutmaßliche Sicherheitsverstöße hinweisen können. Weitere Informationen finden Sie unter Erste Schritte mit der Überwachung von SQL-Datenbanken.

Bereitstellungsslots

Jeder Bereitstellungsslot weist eine öffentliche IP-Adresse auf. Schützen Sie die nicht produktiven Slots mithilfe einer Azure Active Directory-Anmeldung, sodass nur Mitglieder Ihres Entwicklungs- und DevOps-Teams auf diese Endpunkte zugreifen können.

Protokollierung

Protokolle sollten niemals Benutzerkennwörter oder andere Informationen aufzeichnen, die für Identitätsdiebstähle verwendet werden können. Entfernen Sie diese Details aus den Daten, bevor Sie sie speichern.

SSL

Eine App Service-App umfasst ohne Zusatzkosten einen SSL-Endpunkt in einer Unterdomäne azurewebsites.net. Der SSL-Endpunkt schließt ein Platzhalterzertifikat für die *.azurewebsites.net-Domäne ein. Wenn Sie einen benutzerdefinierten Domänennamen verwenden, müssen Sie ein Zertifikat bereitstellen, das der benutzerdefinierten Domäne entspricht. Die einfachste Möglichkeit besteht darin, ein Zertifikat direkt über das Azure-Portal zu erwerben. Außerdem können Sie Zertifikate von anderen Zertifizierungsstellen importieren. Weitere Informationen finden Sie unter Kaufen und Konfigurieren eines SSL-Zertifikats für Ihren Azure App Service.

Als bewährte Sicherheitsmethode sollte Ihre Anwendung HTTPS durch Umleitung von HTTP-Anforderungen durchsetzen. Sie können dies innerhalb Ihrer Anwendung implementieren oder eine Regel zum Umschreiben von URL verwenden, wie unter Aktivieren von HTTPS für eine App in Azure App Service.

Authentifizierung

Wir empfehlen die Authentifizierung über einen Identitätsanbieter (IDP), wie etwa Azure AD, Facebook, Google oder Twitter. Verwenden Sie OAuth 2 oder OpenID Connect (OIDC) für den Authentifizierungsablauf. Azure AD bietet Funktionen zum Verwalten von Benutzern und Gruppen, Erstellen von Anwendungsrollen, Integrieren lokaler Identitäten und Nutzen von Back-End-Diensten, wie etwa Microsoft 365 und Skype for Business.

Vermeiden Sie die direkte Verwaltung von Benutzeranmeldungen und Anmeldeinformationen durch die Anwendung, da dadurch eine mögliche Angriffsfläche entsteht. Als Mindeststandard sollten eine E-Mail-Bestätigung, die Kennwortwiederherstellung und die mehrstufige Authentifizierung genutzt werden. Darüber hinaus sollte die Kennwortsicherheit überprüft werden und für die sichere Speicherung von Kennworthashes gesorgt sein. Die großen Identitätsanbieter übernehmen alle diese Dinge für Sie und überwachen und verbessern ihre Sicherheitsverfahren ständig.

Erwägen Sie den Einsatz von App Service-Authentifizierung zum Implementieren des OAuth/OIDC-Authentifizierungsablaufs. App Service-Authentifizierung bietet folgende Vorteile:

  • Einfach zu konfigurieren.
  • Für einfache Authentifizierungsszenarien ist kein Code erforderlich.
  • Unterstützt delegierte Autorisierung mithilfe von OAuth-Zugriffstoken, um Ressourcen im Benutzerauftrag zu nutzen.
  • Bietet einen integrierten Tokencache.

Einige Einschränkungen der App Service-Authentifizierung:

  • Eingeschränkte Anpassungsoptionen.
  • Die delegierte Autorisierung ist auf eine Back-End-Ressource pro Anmeldesitzung beschränkt.
  • Wenn Sie mehr als einen IDP verwenden, gibt es keinen integrierten Mechanismus für die Startbereichsermittlung.
  • In Szenarien mit mehreren Mandanten muss die Anwendung die Logik für die Überprüfung des Tokenbenutzers implementieren.

Nächste Schritte

Produktdokumentation:

Microsoft Learn-Module: