Abschätzen nutzungsbasierter Kosten

Es gibt zwei Modi, mit denen Ihre Kosten bestimmt werden, wenn Sie Ihre Apps im Flex-Verbrauchstarif ausführen. Jeder Modus wird pro Instanz bestimmt.

In diesem Diagramm wird dargestellt, wie die bedarfsorientierten Kosten in diesem Tarif bestimmt werden:

Zusätzlich zur Ausführungszeit wird Ihnen bei Verwendung einer oder mehrerer immer einsatzbereiter Instanzen auch ein niedrigerer Basistarif für die Anzahl der von Ihnen verwalteten, immer einsatzbereiten Instanzen abgerechnet. Die Ausführungszeit für immer einsatzbereite Instanzen ist möglicherweise günstiger als die Ausführungszeit für Instanzen mit bedarfsorientierter Ausführung.

Beachten Sie für die Beispiele in diesem Abschnitt die reduzierten Vorschaupreise in der Tabelle für die nutzungsbasierte Bezahlung in der Region „USA, Osten“.

Nehmen Sie als Beispiel eine Funktions-App, die nur aus HTTP-Triggern besteht, und die folgenden grundlegenden Fakten:

• HTTP-Trigger verarbeiten 40 konstante Anforderungen pro Sekunde.
• HTTP-Trigger verarbeiten 10 gleichzeitige Anforderungen.
• Die Einstellung für die Arbeitsspeichergröße der Instanz ist 2048 MB.
• Es wurden keine immer einsatzbereiten Instanzen konfiguriert. Das bedeutet, dass die App auf Null skaliert werden kann.

In einer solchen Situation hängen die Preise von der Art der Vorgänge ab, die während der Codeausführung durchgeführt werden. Sehen wir uns zwei Workloadszenarios an:

• CPU-gebundene Workload: In einer CPU-gebundenen Workload gibt es keinen Vorteil, wenn mehrere Anforderungen parallel in derselben Instanz verarbeitet werden. Es ist also besser, jede Anforderung auf ihre eigene Instanz zu verteilen, damit Anforderungen so schnell wie möglich ohne Konflikte abgeschlossen werden. In diesem Szenario sollten Sie eine niedrige HTTP-Trigger-Parallelität von 1 festlegen. Bei 10 gleichzeitigen Anforderungen skaliert die App auf einen stabilen Zustand von ca. 10 Instanzen und jede Instanz ist fortlaufend aktiv und verarbeitet jeweils eine Anforderung.

  Da jede Instanz ca. 2 GB groß ist, ist der Verbrauch für eine einzelne fortlaufend aktive Instanz 2 GB * 3600 s = 7200 GB-s. Beim angenommenen Tarif für die bedarfsorientierte Ausführung (ohne kostenlose Zuweisungen) sind das also $0.1152 USD pro Stunde und Instanz. Da die CPU-gebundene App auf 10 Instanzen skaliert wird, liegt der Gesamtstundensatz für die Ausführungszeit bei $1.152 USD.

  Ebenso entspricht die Gebühr pro bedarfsorientierter Ausführung (ohne kostenlose Zuweisungen) für 40 Anforderungen pro Sekunde 40 * 3600 = 144,000 oder 0,144 Millionen Ausführungen pro Stunde. Die Gesamtkosten (ohne Zuweisungen) für Ausführungen liegen dann bei 0.144 * $0.20, also $0.0288 pro Stunde.

  In diesem Szenario liegen die Gesamtkosten für die bedarfsorientierte Ausführung auf 10 Instanzen bei $1.152 + $0.0288 = $1.1808 USD.

• E/A-gebundene Workload: In einer E/A-gebundenen Workload wird die meiste Anwendungszeit auf eingehende Anforderungen gewartet. Dies kann durch den Netzwerkdurchsatz oder andere Upstreamfaktoren eingeschränkt werden. Aufgrund der eingeschränkten Eingaben kann der Code mehrere Vorgänge gleichzeitig ohne negative Auswirkungen verarbeiten. Gehen Sie in diesem Szenario davon aus, dass Sie alle 10 gleichzeitigen Anforderungen in derselben Instanz verarbeiten können.

  Da Nutzungsgebühren nur auf dem Arbeitsspeicher jeder aktiven Instanz basieren, wird die Nutzungsgebühr einfach wie folgt berechnet: 2 GB * 3600 s = 7200 GB-s. Beim angenommenen Tarif für bedarfsorientierte Ausführungen (ohne kostenlose Zuweisungen) ist die Gebühr für eine einzelne Instanz also $0.1152 USD pro Stunde.

  Genau wie im CPU-gebundenen Szenario entspricht die Gebühr pro bedarfsorientierter Ausführung (ohne kostenlose Zuweisungen) für 40 Anforderungen pro Sekunde 40 * 3600 = 144,000 oder 0,144 Millionen Ausführungen pro Stunde. Die Gesamtkosten (ohne Zuweisungen) für Ausführungen liegen dann bei 0.144 * $0.20, also $0.0288 pro Stunde.

  In diesem Szenario liegen die Gesamtkosten für die bedarfsorientierte Ausführung auf einer einzelnen Instanz bei $0.1152 + $0.0288 = $0.144 USD.

Die Ausführungskosten einer einzelnen Funktionsausführung werden in GB-Sekunden gemessen. Die Ausführungskosten werden berechnet, indem die Speichernutzung mit der Ausführungsdauer kombiniert wird. Eine Funktion, die länger ausgeführt wird, kostet mehr, ebenso wie eine Funktion, die mehr Arbeitsspeicher verbraucht.

Stellen Sie sich einen Fall vor, bei dem die von der Funktion verwendete Arbeitsspeichermenge konstant bleibt. In diesem Fall erfolgt die Berechnung der Kosten durch einfache Multiplikation. Nehmen wir beispielsweise an, dass ihre Funktion 0,5 GB für 3 Sekunden verbraucht hat. Dann betragen die Ausführungskosten 0.5GB * 3s = 1.5 GB-seconds.

Da sich die Speichernutzung im Laufe der Zeit ändert, ist die Berechnung im Wesentlichen das Integral der Arbeitsspeichernutzung im Lauf der Zeit. Das System führt diese Berechnung durch, indem die Speichernutzung des Prozesses (zusammen mit untergeordneten Prozessen) in regelmäßigen Abständen stichprobenhaft erfasst wird. Wie auf der Seite mit der Preisübersicht erwähnt, wird die Speichernutzung auf den nächstgelegenen 128-MB-Bucket aufgerundet. Wenn Ihr Prozess 160 MB verwendet, werden Ihnen 256 MB in Rechnung gestellt. Die Berechnung berücksichtigt dabei die Parallelität, bei der es sich um die gleichzeitige Ausführung mehrerer Funktionen im selben Prozess handelt.

Bei durch HTTP ausgelösten Funktionen werden Ihnen keine Ausführungen in Rechnung gestellt, wenn ein Fehler auftritt, bevor die Ausführung Ihres Funktionscodes beginnt. Dies bedeutet, dass 401-Antworten von der Plattform aufgrund der API-Schlüsselüberprüfung oder des Authentifizierungs-/Autorisierungsfeatures von App Service nicht auf Ihre Ausführungskosten angerechnet werden. Ebenso werden 5xx-Statuscodeantworten nicht gezählt, wenn diese auf der Plattform auftreten, bevor eine Funktion die Anforderung verarbeitet. Eine 5xx-Antwort, die nach dem Ausführungsbeginn Ihres Funktionscodes generiert wurde, wird dennoch als Ausführung gezählt, selbst wenn der Fehler nicht von Ihrem Funktionscode ausgelöst wird.

Verwenden Sie den Azure Monitor-Metrik-Explorer, um kostenbezogene Daten für Ihre Funktions-Apps im Verbrauchstarif in einem grafischen Format anzuzeigen.

1. Navigieren Sie im Azure-Portal zu Ihrer Funktions-App.

2. Scrollen Sie im linken Bereich nach unten zu Überwachung, , und wählen Sie die Option Metriken aus.

3. Wählen Sie in Metrik die Einträge Ausführungsanzahl für Funktion und Summe für Aggregation aus. Dadurch wird die Summe der Ausführungen während des gewählten Zeitraums dem Diagramm hinzugefügt.

   

4. Wählen Sie Metrik hinzufügen aus, und wiederholen Sie die Schritte 2–4, um dem Diagramm Ausführungseinheiten für Funktion hinzuzufügen.

Das resultierende Diagramm enthält die Summen für beide Ausführungsmetriken im ausgewählten Zeitraum, der in diesem Fall zwei Stunden beträgt.

Da die Anzahl der Ausführungseinheiten so viel höher ist, als die Ausführungen, zeigt das Diagramm nur die Ausführungseinheiten an.

Dieses Diagramm zeigt eine Gesamtzahl von 1,11 Mrd. Function Execution Units, die in einem Zeitraum von zwei Stunden verbraucht wurden, gemessen in MB-Millisekunden. Um den Wert in GB-Sekunden umzuwandeln, teilen Sie durch 1.024.000. In diesem Beispiel hat die Funktions-App 1110000000 / 1024000 = 1083.98 GB-Sekunden verbraucht. Sie können diesen Wert mit dem aktuellen Preis der Ausführungszeit auf der Seite mit den Preisen für Azure Functions multiplizieren, wodurch Sie die Kosten für diese zwei Stunden erhalten – vorausgesetzt, Sie haben bereits alle zugewiesenen kostenlosen Ausführungszeiten verbraucht.

Die Azure CLI enthält Befehle zum Abrufen von Metriken. Sie können die CLI aus einer lokalen Befehlsumgebung heraus oder direkt über das Portal mithilfe von Azure Cloud Shell verwenden. Beispielsweise gibt der folgende az monitor metrics list-Befehl stündlich Daten aus demselben zuvor verwendeten Zeitraum zurück.

Stellen Sie sicher, dass Sie <AZURE_SUBSCRIPTON_ID> durch Ihre Azure-Abonnement-ID ersetzen, wenn Sie den Befehl ausführen.

az monitor metrics list --resource /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption --metric FunctionExecutionUnits,FunctionExecutionCount --aggregation Total --interval PT1H --start-time 2019-09-11T21:46:00Z --end-time 2019-09-11T23:18:00Z

Dieser Befehl gibt eine JSON-Nutzlast zurück, die in etwa wie folgt aussieht:

{
  "cost": 0.0,
  "interval": "1:00:00",
  "namespace": "Microsoft.Web/sites",
  "resourceregion": "centralus",
  "timespan": "2019-09-11T21:46:00Z/2019-09-11T23:18:00Z",
  "value": [
    {
      "id": "/subscriptions/XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption/providers/Microsoft.Insights/metrics/FunctionExecutionUnits",
      "name": {
        "localizedValue": "Function Execution Units",
        "value": "FunctionExecutionUnits"
      },
      "resourceGroup": "metrics-testing-consumption",
      "timeseries": [
        {
          "data": [
            {
              "average": null,
              "count": null,
              "maximum": null,
              "minimum": null,
              "timeStamp": "2019-09-11T21:46:00+00:00",
              "total": 793294592.0
            },
            {
              "average": null,
              "count": null,
              "maximum": null,
              "minimum": null,
              "timeStamp": "2019-09-11T22:46:00+00:00",
              "total": 316576256.0
            }
          ],
          "metadatavalues": []
        }
      ],
      "type": "Microsoft.Insights/metrics",
      "unit": "Count"
    },
    {
      "id": "/subscriptions/XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption/providers/Microsoft.Insights/metrics/FunctionExecutionCount",
      "name": {
        "localizedValue": "Function Execution Count",
        "value": "FunctionExecutionCount"
      },
      "resourceGroup": "metrics-testing-consumption",
      "timeseries": [
        {
          "data": [
            {
              "average": null,
              "count": null,
              "maximum": null,
              "minimum": null,
              "timeStamp": "2019-09-11T21:46:00+00:00",
              "total": 33538.0
            },
            {
              "average": null,
              "count": null,
              "maximum": null,
              "minimum": null,
              "timeStamp": "2019-09-11T22:46:00+00:00",
              "total": 13040.0
            }
          ],
          "metadatavalues": []
        }
      ],
      "type": "Microsoft.Insights/metrics",
      "unit": "Count"
    }
  ]
}

Diese spezifische Antwort zeigt, dass die App von 2019-09-11T21:46 bis 2019-09-11T23:18 1.110.000.000 MB-Millisekunden (1.083,98 GB-Sekunden) verbraucht hat.

Azure PowerShell enthält Befehle zum Abrufen von Metriken. Sie können Azure PowerShell aus einer lokalen Befehlsumgebung heraus oder direkt über das Portal mithilfe von Azure Cloud Shell verwenden. Beispielsweise gibt der folgende Get-AzMetric-Befehl stündlich Daten aus demselben zuvor verwendeten Zeitraum zurück.

Stellen Sie sicher, dass Sie <AZURE_SUBSCRIPTON_ID> durch Ihre Azure-Abonnement-ID ersetzen, wenn Sie den Befehl ausführen.

Get-AzMetric -ResourceId /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption -MetricName  FunctionExecutionUnits,FunctionExecutionCount -AggregationType Total -TimeGrain 01:00:00 -StartTime 2019-09-11T21:46:00Z -EndTime 2019-09-11T23:18:00Z

Dieser Befehl gibt eine Ausgabe zurück, die in etwa wie folgt aussieht:

Id         : /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption/providers/Microsoft.Insights/metrics/FunctionExecutionUnits
Name       : 
                LocalizedValue : Function Execution Units
                Value          : FunctionExecutionUnits
             
Type       : Microsoft.Insights/metrics
Unit       : Count
Data       : {Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue, 
             Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue, 
             Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue, 
             Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue…}
Timeseries : {Microsoft.Azure.Management.Monitor.Models.TimeSeriesElement}

Id         : /subscriptions/<AZURE_SUBSCRIPTION_ID>/resourceGroups/metrics-testing-consumption/providers/Microsoft.Web/sites/metrics-testing-consumption/providers/Microsoft.Insights/metrics/FunctionExecutionCount
Name       : 
                LocalizedValue : Function Execution Count
                Value          : FunctionExecutionCount
             
Type       : Microsoft.Insights/metrics
Unit       : Count
Data       : {Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue, 
             Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue, 
             Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue, 
             Microsoft.Azure.Commands.Insights.OutputClasses.PSMetricValue…}
Timeseries : {Microsoft.Azure.Management.Monitor.Models.TimeSeriesElement}

Die Eigenschaft Data enthält die tatsächlichen Metrikwerte.