Ereignisbasierte Cloudautomatisierung

Die Automatisierung von Workflows und sich wiederholenden Aufgaben in der Cloud mithilfe serverloser Technologien kann die Produktivität des DevOps-Teams einer Organisation erheblich steigern. Ein serverloses Modell eignet sich am besten für Automatisierungsszenarien, die zu einem ereignisgesteuerten Ansatz passen.

Aufbau

Szenarien

Dieser Artikel veranschaulicht zwei wichtige Szenarios zur Cloudautomatisierung:

1. Tagging von Kostenstellen: Bei dieser Implementierung werden die Kostenstellen der einzelnen Azure-Ressourcen nachverfolgt. Der Azure Policy-Dienst versieht alle neuen Ressourcen in einer Gruppe mit einer standardmäßigen Kostenstellen-ID als Tag. Azure Event Grid überwacht Ereignisse zur Ressourcenerstellung und ruft dann eine Azure-Funktion auf. Die Funktion interagiert mit Microsoft Entra ID und überprüft die Kostenstellen-ID der neuen Ressource. Falls unterschiedlich, wird das Tag aktualisiert und eine E-Mail an den Ressourcenbesitzer gesendet. Die REST-Abfragen für Microsoft Entra ID werden aus Gründen der Einfachheit simuliert. Microsoft Entra ID kann auch in das Microsoft Graph PowerShell-Modul oder die Microsoft Authentication Library (MSAL) für Python integriert werden.

2. Drosselungsreaktion: In diesem Beispiel wird eine Azure Cosmos DB-Datenbank auf Drosselung überwacht. Azure Monitor-Warnungen werden ausgelöst, wenn Datenzugriffsanforderungen an Azure Cosmos DB die Kapazität in Anforderungseinheiten (Request Units, RUs) überschreiten. Eine Azure Monitor-Aktionsgruppe ist so konfiguriert, dass die Automatisierungsfunktion als Reaktion auf diese Warnungen aufgerufen wird. Die Funktion skaliert die RUs auf einen höheren Wert, wodurch die Kapazität erhöht wird und die Benachrichtigungen hingegen eingestellt werden.

Die Referenzimplementierung für Szenario 1 ist auf GitHub verfügbar.

Die Funktionen in diesen serverlosen Cloudautomatisierungsszenarios sind häufig in PowerShell und Python geschrieben, zwei der am weitesten verbreiteten Skriptsprachen, die im Bereich Systemautomatisierung zum Einsatz kommen. Sie werden in Azure CLI mithilfe von Azure Functions Core Tools bereitgestellt. Alternativ verwenden Sie das PowerShell-Cmdlet „Az.Functions“, um Azure Functions bereitzustellen und zu verwalten.

Workflow

Ereignisbasierte Automatisierungsszenarien werden am besten mithilfe von Azure Functions implementiert. Dabei werden diese allgemeinen Muster befolgt:

• Reagieren auf Ereignisse für Ressourcen. Dies sind Reaktionen auf Ereignisse wie das Anlegen, Löschen, Ändern usw. einer Azure-Ressource oder Ressourcengruppe. Dieses Muster verwendet Event Grid, um die Funktion für solche Ereignisse auszulösen. Das Szenario „Tagging von Kostenstellen“ ist ein Beispiel dieses Musters. Andere gängige Szenarien sind u. a.:

  • Gewähren des Zugriffs auf neu erstellte Ressourcengruppen für die DevOps-Teams
  • Senden einer Benachrichtigung an DevOps, wenn eine Ressource gelöscht wird
  • Reagieren auf Wartungsereignisse für Ressourcen wie virtuelle Azure-Computer (VMs)

• Geplante Aufgaben. Dies sind typischerweise Wartungsaufgaben, die mit timergesteuerten Funktionen ausgeführt werden. Beispiele dieses Musters:

  • Beenden einer Ressource in der Nacht und Neustarten am Morgen
  • Lesen von Blob Storage-Inhalten in regelmäßigen Abständen und Konvertieren in ein Azure Cosmos DB-Dokument
  • Regelmäßiges Prüfen auf nicht mehr verwendete Ressourcen und deren Entfernung
  • Automatisierte Sicherungen

• Verarbeiten von Azure-Warnungen. Dieses Muster nutzt die einfache Integration von Azure Monitor-Warnungen und -Aktionsgruppen in Azure Functions. Die Funktion ergreift in der Regel Abhilfemaßnahmen als Reaktion auf Metriken, Protokollanalysen und Warnungen, die sowohl von den Anwendungen als auch der Infrastruktur stammen. Das Drosselungsreaktionsszenario ist ein Beispiel dieses Musters. Andere gängige Szenarien sind u. a.:

  • Abschneiden der Tabelle, wenn die maximale Größe der SQL-Datenbank-Instanz erreicht wird
  • Neustarten eines Diensts auf einer VM, wenn er irrtümlich angehalten wurde
  • Senden von Benachrichtigungen, wenn eine Funktion fehlschlägt

• Orchestrieren mit externen Systemen. Dieses Muster ermöglicht die Integration in externe Systeme mithilfe von Logic Apps, um den Workflow zu orchestrieren. Logic Apps-Connectors können problemlos mit verschiedenen Diensten von Drittanbietern sowie mit Microsoft-Diensten wie Microsoft 365 integriert werden. Azure Functions-Instanzen können für die eigentliche Automatisierung verwendet werden. Das Szenario „Tagging von Kostenstellen“ veranschaulicht dieses Muster. Andere gängige Szenarien sind u. a.:

  • Überwachen von IT-Prozessen wie Änderungsanforderungen oder Genehmigungen
  • Senden einer E-Mail-Benachrichtigung nach Erledigung einer Automatisierungsaufgabe

• Verfügbarmachen als Webhook oder API. Automatisierungsaufgaben mit Azure Functions können in Anwendungen von Drittanbietern oder sogar in Befehlszeilentools integriert werden, indem die Funktion als Webhook/API mithilfe eines HTTP-Triggers verfügbar gemacht wird. Mehrere Authentifizierungsmethoden sind sowohl in PowerShell als auch in Python verfügbar, um den externen Zugriff auf die Funktion zu schützen. Die Automatisierung erfolgt als Reaktion auf die anwendungsspezifischen externen Ereignisse, z. B. die Integration in Power Apps oder GitHub. Zu den häufigen Szenarios gehören:

  • Auslösen der Automatisierung für einen ausgefallenen Dienst
  • Integrieren von Benutzern in die Ressourcen der Organisation

• Erstellen einer ChatOps-Schnittstelle: Dieses Muster ermöglicht Kunden die Erstellung einer chatbasierten Betriebsoberfläche sowie die Ausführung von Entwicklungs- und Betriebsfunktionen/-befehlen, die auf die Zusammenarbeit mit Menschen abgestimmt sind. Dieses Muster kann in Azure Bot Framework integriert werden und Microsoft Teams oder Slack-Befehle für die Bereitstellung, Überwachung, allgemeine Fragen und vieles mehr verwenden. Eine ChatOps-Oberfläche erstellt ein Echtzeitsystem für die Verwaltung von Produktionsincidents. Dabei werden die einzelnen Schritte automatisch im Chat dokumentiert. Weitere Informationen finden Sie unter Bessere DevOps-Prozesse mit ChatOps.

• Hybridautomatisierung: Dieses Muster nutzt Azure App Service-Hybridverbindungen, um eine Softwarekomponente auf dem lokalen Computer zu installieren. Diese Komponente ermöglicht den sicheren Zugriff auf Ressourcen auf diesem Computer. Die Verwaltung von Hybridumgebungen ist derzeit auf Windows-basierten Systemen mithilfe von PowerShell-Funktionen möglich. Zu den häufigen Szenarios gehören:

  • Verwalten lokaler Computer
  • Verwalten anderer Systeme (etwa einer lokalen SQL Server-Instanz) hinter der Firewall über einen Jumpserver

Komponenten

Die Architektur umfasst die folgenden Komponenten:

• Azure Functions. Azure Functions stellen die ereignisgesteuerten, serverlosen Computefunktionen in dieser Architektur zur Verfügung. Eine Funktion führt Automatisierungsaufgaben aus, wenn sie durch Ereignisse oder Warnungen ausgelöst wird. In zwei Szenarien wird eine Funktion mit einer HTTP-Anforderung aufgerufen. Die Komplexität des Codes sollte minimiert werden, indem die Funktion zustandslos und idempotent gestaltet wird.

  Mehrere Ausführungen einer idempotenten Funktion generieren die gleichen Ergebnisse. Um Idempotenz aufrechtzuerhalten, wird die Skalierung der Funktion im Drosselungsszenario einfach gehalten. Achten Sie bei der tatsächlichen Automatisierung darauf, dass das Hoch- oder Herunterskalieren entsprechend erfolgt. Lesen Sie die Informationen unter Optimieren der Leistung und Zuverlässigkeit von Azure Functions, um mehr über bewährte Methoden beim Schreiben Ihrer Funktionen zu erfahren.

• Azur Logic Apps. Mit Logic Apps lassen sich einfachere Aufgaben durchführen, die mit den integrierten Connectors mühelos implementiert werden können. Diese Aufgaben können von E-Mail-Benachrichtigungen bis zur Integration in externe Verwaltungsanwendungen reichen. Um zu erfahren, wie Logik-Apps mit Anwendungen von Drittanbietern eingesetzt werden können, lesen Sie Einfache Unternehmensintegration in Azure.

  Logic Apps bieten einen codelosen bzw. codearmen visuellen Designer und können in einigen Automatisierungsszenarien eigenständig verwendet werden. Lesen Sie diesen Vergleich zwischen Azure Functions und Azure Logic Apps, um zu erfahren, welcher Dienst für Ihr Szenario am besten geeignet ist.

• Event Grid. Event Grid bietet integrierte Unterstützung für Ereignisse anderer Azure-Dienste sowie für benutzerdefinierte Ereignisse (auch als benutzerdefinierte Themen bezeichnet). Betriebsereignisse, wie z. B. die Erstellung von Ressourcen, können mithilfe des in Event Grid integrierten Mechanismus einfach an die Automatisierungsfunktion weitergegeben werden.

  Event Grid vereinfacht die ereignisbasierte Automatisierung mit einem Veröffentlichen-Abonnieren-Modell, das eine zuverlässige Automatisierung für über HTTPS übermittelte Ereignisse ermöglicht.

• Azure Monitor: Azure Monitor-Warnungen dienen zur Überwachung auf kritische Zustände und können mithilfe von Azure Monitor-Aktionsgruppen korrigierend eingreifen. Diese Aktionsgruppen können problemlos in Azure Functions integriert werden. Dies ist nützlich, um alle Fehlerbedingungen in Ihrer Infrastruktur zu überwachen und zu beheben, wie z. B. Datenbankdrosselung.

• Automatisierungsaktion. Dieser umfassende Block stellt andere Dienste dar, mit denen Ihre Funktion interagieren kann, um die Automatisierungsfunktionalität bereitzustellen. Beispiel: Microsoft Entra ID zur Validierung von Tags im ersten Szenario oder eine bereitzustellende Datenbank im zweiten Szenario.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Resilienz

Azure-Funktionen

Behandeln von HTTP-Timeouts

Um HTTP-Timeouts bei einer längeren Automatisierungsaufgabe zu vermeiden, stellen Sie dieses Ereignis in einer Service Bus-Instanz in eine Warteschlange, und erledigen Sie die tatsächliche Automatisierung in einer anderen Funktion. Das Automatisierungsszenario der Drosselungsreaktion veranschaulicht dieses Muster, obwohl die tatsächliche Bereitstellung von RUs für Azure Cosmos DB schnell erfolgt.

Durable Functions, die den Status zwischen Aufrufen aufrechterhalten, sind eine Alternative zum vorherigen Ansatz. Durable Functions unterstützen nur bestimmte Sprachen.

Protokollieren von Fehlern

Als bewährte Methode sollte die Funktion alle Fehler bei der Ausführung von Automatisierungsaufgaben protokollieren. Dies ermöglicht eine ordnungsgemäße Behandlung der Fehlerbedingungen. Azure Functions unterstützt nativ die Integration in Application Insights als Telemetriesystem.

Parallelität

Überprüfen Sie die Anforderung an Parallelität für Ihre Automatisierungsfunktion. Die Parallelität wird durch Festlegen der Variablen maxConcurrentRequests in der Datei host.json eingeschränkt. Diese Einstellung beschränkt die Anzahl der gleichzeitigen Funktionsinstanzen, die in Ihrer Funktions-App ausgeführt werden. Da jede Instanz CPU und Arbeitsspeicher beansprucht, muss dieser Wert für CPU-intensive Vorgänge angepasst werden. Verringern Sie den Wert für maxConcurrentRequests, wenn Ihre Funktionsaufrufe zu langsam sind oder nicht abgeschlossen werden können. Ausführlichere Informationen finden Sie unter Konfigurieren des Host-Verhaltens zum besseren Verwalten der Parallelität.

Idempotenz

Stellen Sie sicher, dass Ihre Automatisierungsfunktion idempotent ist. Sowohl Azure Monitor als auch Event Grid können Warnungen oder Ereignisse ausgeben, die den Fortschritt anzeigen, z. B. dass das von Ihnen abonnierte Ereignis aufgelöst, ausgelöst, in Bearbeitung ist usw., dass Ihre Ressource bereitgestellt wird, erfolgreich erstellt wurde usw., oder sogar falsche Alarme aufgrund einer Fehlkonfiguration senden. Stellen Sie sicher, dass Ihre Funktion nur auf die relevanten Warnungen und Ereignisse reagiert und alle anderen ignoriert, damit falsche oder falsch konfigurierte Ereignisse nicht zu unerwünschten Ergebnissen führen. Weitere Informationen finden Sie unter Entwerfen von Azure Functions für identische Eingaben.

Event Grid

Wenn Event Grid in Ihrem Workflow verwendet wird, prüfen Sie, ob Ihr Szenario eine hohe Anzahl von Ereignissen erzeugen kann, die ausreichen, um das Raster zu überlasten. Siehe Event Grid – Übermittlung und Wiederholung von Nachrichten, um zu verstehen, wie Ereignisse behandelt werden, wenn die Zustellung nicht bestätigt wird, und Sie Ihre Logik entsprechend ändern. Der Kostenstellen-Workflow implementiert hierfür keine zusätzlichen Prüfungen, da er nur auf Ereignisse zur Ressourcenerstellung in einer Ressourcengruppe achtet. Bei der Überwachung von Ressourcen, die in einem gesamten Abonnement erstellt wurden, kann eine größere Anzahl von Ereignissen erzeugt werden, die eine resilientere Verarbeitung erfordern.

Azure Monitor

Wenn eine ausreichend große Anzahl von Warnungen generiert wird und die Automatisierung Azure-Ressourcen aktualisiert, werden ggf. Drosselungsgrenzwerte von Azure Resource Manager erreicht. Dies kann sich negativ auf die restliche Infrastruktur im jeweiligen Abonnement auswirken. Vermeiden Sie diese Situation, indem Sie die Häufigkeit von Warnungen begrenzen, die von Azure Monitor generiert werden. Außerdem können Sie die Warnungen begrenzen, die für einen bestimmten Fehler generiert werden. Weitere Informationen finden Sie in der Dokumentation zu Azure Monitor-Warnungen.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Steuern des Zugriffs auf die Funktion

Beschränken Sie den Zugriff auf eine durch HTTP ausgelöste Funktion, indem Sie die Autorisierungsebene festlegen. Bei anonymer Authentifizierung ist die Funktion mit einer URL wie http://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME> leicht zugänglich. Eine Authentifizierung auf Funktionsebene kann den HTTP-Endpunkt verschleiern, indem Funktionsschlüssel in der URL angefordert werden. Diese Ebene wird in der Datei function.json festgelegt:

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "Request",
      "methods": [
        "get",
        "post"
      ]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "Response"
    }
  ]
}

In der Produktionsumgebung können zusätzliche Strategien zum Schutz der Funktion erforderlich sein. In diesen Szenarios werden die Funktionen innerhalb der Azure-Plattform von anderen Azure-Diensten ausgeführt und nicht dem Internet zugänglich gemacht. Für Funktionen, auf die als Webhooks zugegriffen wird, ist die Funktionsautorisierung manchmal ausreichend.

Erwägen Sie das Hinzufügen von Sicherheitsebenen über die Funktionsauthentifizierung hinaus, wie z. B:

• Authentifizieren mit Clientzertifikaten
• Sicherstellen, dass der Aufrufer Teil des Verzeichnisses ist, das die Funktion hostet, oder Zugriff auf dieses Verzeichnis hat, indem die App Service-Authentifizierung aktiviert wird.

Authentifizierung auf Funktionsebene ist die einzige Option, die Azure Monitor-Aktionsgruppen, die Azure Functions verwenden, zur Verfügung steht.

Wenn die Funktion von einer Anwendung oder einem Dienst eines Drittanbieters aufgerufen werden muss, wird empfohlen, den Zugriff auf die Funktion mithilfe einer API Management-Ebene zu ermöglichen. Diese Ebene muss die Authentifizierung erzwingen. API Management hat einen in Azure Functions integrierten Verbrauchstarif, der Ihnen erlaubt, nur dann zu zahlen, wenn die API ausgeführt wird. Weitere Informationen finden Sie unter Erstellen und Verfügbarmachen von Funktionen mit OpenAPI.

Wenn der aufrufende Dienst Dienstendpunkte oder private Verbindungen unterstützt, können die folgenden kostenträchtigeren Optionen in Betracht gezogen werden:

• Verwenden eines dedizierten App Service-Plans, bei dem Sie die Funktionen in einem virtuellen Netzwerk sperren können, um den Zugriff darauf zu beschränken. Dies ist bei einem verbrauchsbasierten serverlosen Modell nicht möglich.
• Verwenden des Plans Azure Functions Premium, der ein dediziertes virtuelles Netzwerk enthält, das von Ihren Funktions-Apps genutzt werden kann.

Um Preise und Features dieser Optionen zu vergleichen, lesen Sie Skalierung und Hosting von Azure Functions.

Steuern, auf was die Funktion zugreifen kann

Verwaltete Identitäten für Azure-Ressourcen, ein Microsoft Entra-Feature, vereinfacht die Authentifizierung von und den Zugriff auf andere Azure-Ressourcen und -Dienste. Der Code muss die Anmeldeinformationen für die Authentifizierung nicht verwalten, da er von Microsoft Entra ID verwaltet wird.

Es gibt zwei Arten von verwalteten Identitäten:

• Vom System zugewiesene verwaltete Identitäten: Diese werden als Teil der Azure-Ressource erstellt und können nicht von mehreren Ressourcen gemeinsam genutzt werden. Sie werden gelöscht, sobald die Ressource gelöscht wird. Verwenden Sie diese für Szenarien, die eine einzelne Azure-Ressource umfassen oder unabhängige Identitäten benötigen. Beide Szenarien verwenden vom System zugewiesene Identitäten, da sie nur eine einzige Ressource aktualisieren. Verwaltete Identitäten sind nur erforderlich, um eine andere Ressource zu aktualisieren. Beispielsweise kann eine Funktion die Ressourcentags ohne eine verwaltete Identität lesen. Siehe diese Anweisungen, um Ihrer Funktion eine vom System zugewiesene Identität hinzuzufügen.

• Vom Benutzer zugewiesene verwaltete Identitäten: Diese werden als eigenständige Azure-Ressourcen erstellt. Sie können von mehreren Ressourcen gemeinsam genutzt und müssen explizit gelöscht werden, wenn sie nicht mehr benötigt werden. In diesen Anweisungen erfahren Sie, wie Sie Ihrer Funktion eine vom Benutzer zugewiesene Identität hinzufügen. Verwenden Sie diese für Szenarien:

  • die Zugriff auf mehrere Ressourcen benötigen, die eine einzelne Identität gemeinsam nutzen können, oder
  • die eine Vorautorisierung zum Schützen von Ressourcen während der Bereitstellung erfordern oder
  • bei denen Ressourcen häufig recycelt werden, die Berechtigungen aber konsistent bleiben müssen.

Nachdem die Identität der Azure-Funktion zugewiesen wurde, weisen Sie ihr eine Rolle mithilfe der rollenbasierten Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) zu, um auf die Ressourcen zuzugreifen. Um beispielsweise eine Ressource zu aktualisieren, muss die Rolle Mitwirkender der Identität der Funktion zugewiesen werden.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Verwenden Sie den Azure-Preisrechner, um die voraussichtlichen Kosten zu ermitteln. Nachfolgend finden Sie einige Überlegungen zum Senken von Kosten.

Azure Logic Apps

Logik-Apps verfügen über ein Modell mit nutzungsbasierter Bezahlung. Ausführungen von Triggern, Aktionen und Connectors werden jedes Mal gemessen, wenn eine Logik-App ausgeführt wird. Alle erfolgreichen und nicht erfolgreichen Aktionen, einschließlich Trigger, werden als Ausführungen angesehen.

Logik-Apps verfügen auch über ein Modell mit festen Preisen. Wenn Sie Logik-Apps ausführen müssen, die mit geschützten Ressourcen in einem virtuellen Azure-Netzwerk kommunizieren, können Sie sie in einer Integrationsdienstumgebung (Integration Service Environment, ISE) erstellen.

Weitere Informationen finden Sie unter Preismodell für Azure Logic Apps.

In dieser Architektur werden Logik-Apps für das Taggen von Kostenstellen verwendet, um den Workflow zu orchestrieren.

Es werden integrierte Connectors genutzt, um eine Verbindung mit Azure Functions herzustellen und eine E-Mail-Benachrichtigung zu senden, wenn eine Automatisierungsaufgabe abgeschlossen ist. Die Funktionen werden als Webhook/API mit einem HTTP-Trigger verfügbar gemacht. Logik-Apps werden nur ausgelöst, wenn eine HTTPS-Anforderung auftritt. Dies ist eine kostengünstige Methode im Vergleich zu einem Entwurf, bei dem von Funktionen fortlaufend Abfragen durchgeführt und bestimmte Kriterien überprüft werden. Jede Abrufanforderung wird als Aktion gemessen.

Weitere Informationen hierzu finden Sie unter Logic Apps – Preise.

Azure-Funktionen

Azure Functions ist in den folgenden drei Tarifen verfügbar.

• Verbrauchstarif: Dies ist der kostengünstigste, serverlose Tarif, bei dem Sie nur für den Zeitraum bezahlen, in dem Ihre Funktion ausgeführt wird. In diesem Tarif können Funktionen jeweils bis zu zehn Minuten lang ausgeführt werden.

• Premium-Tarif: Verwenden Sie den Azure Functions-Premium-Tarif für Automatisierungsszenarien mit zusätzlichen Anforderungen wie dedizierten virtuellen Netzwerken, längerer Ausführungsdauer usw. Diese Funktionen können bis zu eine Stunde lang ausgeführt werden und sollten für längere Automatisierungsaufgaben wie das Ausführen von Sicherungen, die Datenbankindizierung oder das Erstellen von Berichten ausgewählt werden.

• App Service-Plan. Für Hybridautomatisierungsszenarien, in denen Azure App Service-Hybridverbindungen genutzt werden, muss der App Service-Plan verwendet werden. Die in diesem Tarif erstellten Funktionen können ähnlich wie bei einer Web-App unbegrenzt ausgeführt werden.

In diesen Automatisierungsszenarios wird Azure Functions für bestimmte Aufgaben genutzt, z. B. Aktualisieren von Tags in Microsoft Entra ID oder Ändern der Azure Cosmos DB-Konfiguration durch das zentrale Hochskalieren der RUs auf einen höheren Wert. Der Verbrauchsplan ist für diesen Anwendungsfall geeignet, weil diese Aufgaben interaktiv und nicht zeitintensiv sind.

Azure Cosmos DB

Bei Azure Cosmos DB werden Kosten für den bereitgestellten Durchsatz und den genutzten Speicher pro Stunde berechnet. Der bereitgestellte Durchsatz wird in Anforderungseinheiten pro Sekunde (RU/s) ausgedrückt. Dies kann für gängige Datenbankvorgänge, z. B. Einfügungen und Lesevorgänge, genutzt werden. Der Speicher wird pro genutztem Gigabyte (GB) berechnet, das für Ihre gespeicherten Daten und den Index verwendet wird. Weitere Informationen finden Sie unter Azure Cosmos DB – Preismodell.

Bei dieser Architektur werden von Azure Monitor Warnungen ausgelöst, wenn die Datenzugriffsanforderungen für Azure Cosmos DB die Kapazität nach Anforderungseinheiten (RUs) überschreiten. Eine Azure Monitor-Aktionsgruppe ist so konfiguriert, dass als Reaktion auf diese Warnungen die Automatisierungsfunktion aufgerufen wird. Die Funktion skaliert die RUs auf einen höheren Wert. Auf diese Weise werden die Kosten gering gehalten, weil Sie nur für die Ressourcen zahlen, die von Ihren Workloads pro Stunde benötigt werden.

Verwenden Sie den Kapazitätsrechner von Azure Cosmos DB, um eine schnelle Schätzung der Workloadkosten zu erhalten.

Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Überlegungen zur Bereitstellung

Für kritische Automatisierungsworkflows, die das Verhalten Ihrer Anwendung verwalten, muss durch eine effiziente DevOps-Pipeline eine Bereitstellung ohne Ausfallzeiten erreicht werden. Weitere Informationen finden Sie unter Serverlose Back-End-Bereitstellung.

Wenn die Automatisierung mehrere Anwendungen abdeckt, bewahren Sie die von der Automatisierung benötigten Ressourcen in einer getrennten Ressourcengruppe auf. Eine einzelne Ressourcengruppe kann von Automatisierungs- und Anwendungsressourcen gemeinsam genutzt werden, wenn die Automatisierung sich auf eine einzige Anwendung bezieht.

Wenn der Workflow mehrere Automatisierungsfunktionen umfasst, gruppieren Sie die Funktionen, die ein Szenario abdecken, in einer einzigen Funktions-App. Weitere Informationen finden Sie unter Verwalten einer Funktions-App.

Wenn Sie Ihre Anwendung bereitstellen, müssen Sie sie überwachen. Sie können Application Insights verwenden, damit Entwickler die Leistung überwachen und Probleme erkennen können.

Weitere Informationen finden Sie im Microsoft Azure Well-Architected Framework unter Übersicht über die DevOps-Säule.

Imperative Aktionen für Azure-Ressourcen

In beiden oben genannten Szenarien bestand das Endergebnis in einer Änderung des Azure-Ressourcenzustands über eine direkte Azure Resource Manager-Interaktion. Obwohl dies das beabsichtigte Ergebnis war, sollten Sie die Auswirkungen berücksichtigen, die diese Vorgehensweise auf Ihre Umgebung haben kann, wenn die geänderten Ressourcen ursprünglich deklarativ bereitgestellt wurden, z. B. mittels Bicep- oder Terraform-Vorlagen. Sofern diese Änderungen nicht wieder in Ihre Quellvorlagen zurückrepliziert werden, könnten die durch diese Automatisierung vorgenommenen Änderungen von der nächste Verwendung dieser Vorlagen rückgängig gemacht werden. Berücksichtigen Sie die Auswirkungen der Mischung imperativer Änderungen an Azure-Ressourcen, die routinemäßig mittels Vorlagen bereitgestellt werden.

Bereitstellen dieses Szenarios

Informationen zum Bereitstellen des Kostenstellenszenarios finden Sie in den Bereitstellungsschritten auf GitHub.

Nächste Schritte

• Training: Einführung in Azure Functions
• Dokumentation: Einführung in Azure Functions
• Was ist Azure Event Grid?

Zugehörige Ressourcen

• Exemplarische Vorgehensweise mit Code: Serverlose Anwendung mit Azure Functions
• Architekturentwurf mit serverlosen Funktionen
• Referenzarchitekturen für serverlose Funktionen