估算基于消耗的成本

项目
12/20/2024

本文介绍如何估算弹性消耗和消耗托管计划的计划成本。

Azure Functions 目前为函数应用提供了以下不同的托管选项，每个选项都有自己的托管计划定价模型：

规划	说明
弹性消耗计划	需要为运行函数的实例以及任何始终就绪的实例的执行时间付费。系统会根据传入事件数动态添加和删除实例。这是建议的动态缩放计划，它还支持虚拟网络集成。
高级	提供与“消耗”计划相同的功能和缩放机制，但具有增强的性能和虚拟网络访问权限。成本取决于所选的定价层。若要了解详细信息，请参阅 Azure Functions 高级计划。
专用（应用服务）（基本或更高层）	需要在专用 VM 或隔离的环境中运行、自定义映像，或想要使用超额的应用服务计划容量时。使用常规应用服务计划计费。成本取决于所选的定价层。

| 消耗计划 | 只根据函数应用的运行时间收费。此计划包括基于订阅的免费授予。|

你应该始终选择最支持函数执行的功能、性能和成本要求的选项。若要了解更多信息，请参阅 Azure Functions 的缩放和托管。

本文重点介绍弹性消耗和消耗计划，因为在这些计划中，计费取决于每个实例内的活动执行周期。

Durable Functions 还可以在这两个计划中运行。若要详细了解使用 Durable Functions 时的成本注意事项，请参阅 Durable Functions 计费。

基于消耗的成本

基于消耗的成本（包括免费给予）的计算方式视具体计划而定。有关最新的成本和给予信息，请参阅 Azure Functions 定价页。

Flex 消耗计划
消耗计划

在弹性消耗计划中运行应用程序时，可通过两种模式确定成本。每个模式基于每个实例确定。

计费模式	说明
按需	在按需模式下运行时，仅对函数代码在可用实例上执行的时间付费。在按需模式下，不需要最小实例计数。系统会针对以下内容计费： • 当每个按需实例主动执行函数（以 GB 秒为单位）时，预配的总内存量减去每月 GB-s 的免费额度。 • 执行的总数减去每月执行的免费额度（数量）。
始终就绪	可以配置一个或多个实例，将它们分配给特定触发器类 (HTTP/Durable/Blob) 和单独的函数，这些实例始终可用于处理请求。启用任何始终就绪的实例后，系统会针对以下内容计费： • 在所有始终就绪实例（称为基线，以 GB-秒为单位）中预配的总内存量。 • 每个始终就绪实例主动执行函数（以 GB-秒为单位）期间预配的总内存量。 • 总执行次数。在始终就绪的计费模式中，不存在免费赠予。

计费模式

说明

按需

在按需模式下运行时，仅对函数代码在可用实例上执行的时间付费。在按需模式下，不需要最小实例计数。系统会针对以下内容计费：

• 当每个按需实例主动执行函数（以 GB 秒为单位）时，预配的总内存量减去每月 GB-s 的免费额度。
• 执行的总数减去每月执行的免费额度（数量）。

始终就绪

可以配置一个或多个实例，将它们分配给特定触发器类 (HTTP/Durable/Blob) 和单独的函数，这些实例始终可用于处理请求。启用任何始终就绪的实例后，系统会针对以下内容计费：

• 在所有始终就绪实例（称为基线，以 GB-秒为单位）中预配的总内存量。
• 每个始终就绪实例主动执行函数（以 GB-秒为单位）期间预配的总内存量。
• 总执行次数。

在始终就绪的计费模式中，不存在免费赠予。

下图表示如何在此计划中确定按需成本：

基于负载（实例计数）和时间的弹性消耗计划按需成本图。

除了执行时间外，在使用一个或多个始终就绪实例时，还会按较低的基线费率对维护的始终就绪实例数进行计费。就执行时间的价格而言，与按需执行的实例相比，始终就绪的实例可能更划算。

重要

在本文中，按需定价用于帮助了解示例计算。在估算在弹性消耗计划中运行函数时可能产生的成本时，请务必在 Azure Functions 定价页面中查看当前成本。

假设有一个仅由 HTTP 触发器组成的函数应用程序，并具有以下基本事实：

HTTP 触发器每秒处理 40 个常量请求。
HTTP 触发器处理 10 个并发请求。
实例内存大小设置为 2048 MB。
没有配置始终就绪的实例，这意味着应用程序可以扩展到零。

在这种情况下，定价更多地取决于代码执行期间完成的工作类型。让我们看看两个工作负载方案：

CPU 密集型工作负载：在 CPU 密集型工作负载中，在同一实例中并行处理多个请求没有任何优势。这意味着你最好将每个请求分发到其自己的实例，以便请求尽快完成而不会发生争用。在此方案中，应该将 HTTP 触发器并发设置为 1。对于 10 个并发请求，应用可缩放到大约 10 个实例的稳定状态，并且每个实例都持续活动，一次处理一个请求。

由于每个实例的大小约为 2 GB，因此单个连续活动实例的消耗为 2 GB * 3600 s = 7200 GB-s，按照假定的按需执行速率（不应用任何免费赠予）为每个实例每小时 $0.1152 USD。由于 CPU 密集型应用程序扩展到 10 个实例，因此执行时间的总小时速率为 $1.152 USD。

同样，每秒 40 个请求的按需每次执行费用（没有任何免费授权）等于 40 * 3600 = 144,000，也就是每小时 14.4 万次执行。那么每小时执行的总成本（无赠予）为 0.144 * $0.20，即每小时 $0.0288。

在此方案中，按需运行 10 个实例的每小时总成本为 $1.152 + $0.0288 = $1.1808 USD。
IO 密集型工作负载：在 IO 密集型工作负载中，大部分应用程序时间都花在等待传入请求上，这可能受到网络吞吐量或其他上游因素的限制。由于输入有限，代码可以同时处理多个操作，而不会产生负面影响。在此方案中，假设可以在同一实例上处理所有 10 个并发请求。

由于消耗费用仅基于每个活动实例的内存，因此计算出的消耗费用仅为 2 GB * 3600 s = 7200 GB-s，在假定的按需执行速率（不应用任何免费赠款）下，该消耗费用为单个实例每小时 $0.1152 USD。

与 CPU 密集型方案一样，每秒 40 个请求的按需执行费用（没有任何免费授予）等于 40 * 3600 = 144,000，也就是每小时 14.4 万次执行。在这种情况下，每小时执行的总（无赠予）成本为 0.144 * $0.20，即每小时 $0.0288。

在此场景中，在单个实例上按需运行的总每小时成本为 $0.1152 + $0.0288 = $0.144 USD。

单个函数执行的执行成本以“GB 秒”来度量。执行成本是通过将其内存用量与执行时间相结合计算得出的。函数的运行时间越长，其成本越高；同理，函数消耗的内存越多，其成本越高。

假设函数使用的内存量保持恒定。在这种情况下，进行简单的相乘即可计算成本。例如，假设函数运行了 3 秒，消耗了 0.5 GB。那么，执行成本为 0.5GB * 3s = 1.5 GB-seconds。

由于内存用量会不断变化，计算结果实质上是不同时间的内存用量的积分。进行这种计算时，系统会按固定的时间间隔对进程（及其子进程）的内存用量采样。如定价页中所述，内存用量将向上舍入到最近似的 128-MB 桶。如果进程使用 160 MB，则你需要按 256 MB 的用量付费。计算中会考虑并发性，即，同一进程中的多个并发函数执行。

注意

尽管执行成本中不直接考虑 CPU 用量，但如果该用量会影响函数的执行时间，则也会影响成本。

对于 HTTP 触发的函数，在函数代码开始执行之前发生错误时，不会收取执行费用。这意味着由于 API 密钥验证或应用服务身份验证/授权功能，来自平台的 401 响应不会计入你的执行成本。同样，在函数处理请求之前，平台中出现的 5xx 状态代码响应不会被计算在内。在函数代码开始执行后，平台生成的 5xx 响应仍算作一次执行，即使函数代码未引发错误。

在估算任何计划中运行函数的总体成本时，请记住，函数运行时将使用其他多个 Azure 服务，而每个服务单独计费。估算函数应用的定价时，对于与其他 Azure 服务集成的任何触发器和绑定，需要创建这些附加的服务并为其付费。

对于在消耗计划中运行的函数，总成本是函数的执行成本加上带宽和附加服务的成本。

估算函数应用和相关服务的总体成本时，请使用 Azure 定价计算器。

相关成本	描述
存储帐户	需要为每个函数应用提供一个关联的常规用途 Azure 存储帐户，该帐户单独计费。函数运行时在内部使用此帐户，但你也可以将其用于存储触发器和绑定。如果你没有存储帐户，系统会在创建函数应用时创建一个存储帐户。有关详细信息，请参阅存储帐户要求。
Application Insights	函数依靠 Application Insights 为函数应用提供高性能的监视体验。虽然未强制要求，但你应启用 Application Insights 集成。每月会免费授予遥测数据。要了解详细信息，请参阅 Azure Monitor 定价页。
网络带宽	根据数据移动的方向和方案，可能会产生数据传输费用。有关详细信息，请参阅带宽定价详细信息。

影响执行时间的行为

函数的以下行为可能会影响执行时间：

触发器和绑定：从函数绑定读取输入以及向其写入输出所花费的时间计为执行时间。例如，如果函数使用某个输出绑定将消息写入 Azure 存储队列，则执行时间包括将该消息写入该队列所花费的时间，而函数成本计算包括该写入时间。
异步执行：函数等待异步请求（在 C# 中为 await）结果的时间计为执行时间。 “GB 秒”计算基于函数的开始和结束时间，以及该时间段内的内存用量。计算中不考虑该时间段内发生的 CPU 活动。可能也可以使用 Durable Functions 来降低异步操作期间产生的成本。业务流程协调程序函数中的等待时间不产生费用。

函数应用级指标

若要更好地了解函数的成本，可以使用 Azure Monitor 查看函数应用当前生成的成本相关指标。

使用 Azure Monitor 指标资源管理器可以图形格式查看消耗计划函数应用的成本相关数据。

在 Azure 门户中，导航到你的函数应用。
在左侧面板中，向下滚动至“监视”，然后选择“指标” 。
在“指标”中，为“聚合”选择“函数执行计数”和“求和”。这会在图表中将所选时间段内的执行计数之和相加。
选择“添加指标”并重复步骤 2-4，将“函数执行单位”添加到图表中。

生成的图表包含所选时间范围内（在本例中为 2 小时）两个执行指标的总和。

函数执行计数和执行单位图表

由于执行单位数远远大于执行计数，因此图表只显示执行单位。

此图显示两小时时间段内总共消耗了 11.1 亿个 Function Execution Units（以“MB 毫秒”度量）。若要转换为 GB 秒，请除以 1024000。在此示例中，函数应用消耗了 1110000000 / 1024000 = 1083.98 GB 秒。可以将此值乘以 Functions 定价页上执行时间的当前价格，从而得出这两个小时的成本（假设已用完了所有免费授予的执行时间）。

Azure CLI 提供了用于检索指标的命令。可以从本地命令环境使用 CLI。例如，以下 az monitor metrics list 命令返回以前使用的同一时间段内的每小时数据。

请务必将 <AZURE_SUBSCRIPTON_ID> 替换为运行该命令的 Azure 订阅 ID。

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

此命令返回类似于以下示例的 JSON 有效负载：

{
  "cost": 0.0,
  "interval": "1:00:00",
  "namespace": "Microsoft.Web/sites",
  "resourceregion": "chinanorth2",
  "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"
    }
  ]
}

此特定响应显示，从 2019-09-11T21:46 到 2019-09-11T23:18，应用消耗了 1110000000 MB 毫秒（1083.98 GB 秒）。

Azure PowerShell 提供了用于检索指标的命令。可以从本地命令环境使用 Azure PowerShell。例如，以下 Get-AzMetric 命令返回以前使用的同一时间段内的每小时数据。

请务必将 <AZURE_SUBSCRIPTON_ID> 替换为运行该命令的 Azure 订阅 ID。

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

此命令返回类似于以下示例的输出：

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}

Data 属性包含实际指标值。

函数级指标

函数执行单位是执行时间与内存用量的组合，因此很难使用此指标来了解内存用量。目前无法通过 Azure Monitor 获取内存数据这一指标。但是，如果要优化应用的内存用量，可以使用 Application Insights 收集的性能计数器数据。

如果尚未执行此操作，你可以在函数应用中启用 Application Insights。启用此集成后，你可以在门户中查询此遥测数据。

可以使用 Azure 门户中的 Azure Monitor 指标资源管理器或使用 REST API 来获取 Monitor 指标数据。

确定内存用量

在“监视”下选择“日志(分析)”，复制以下遥测查询并将其粘贴到查询窗口中，然后选择“运行”。此查询返回每个采样时间的总内存用量。

performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value

结果类似于以下示例：

timestamp [UTC]	name	值
9/12/2019, 1:05:14.947 AM	专用字节数	209,932,288
9/12/2019, 1:06:14.994 AM	专用字节数	212,189,184
9/12/2019, 1:06:30.010 AM	专用字节数	231,714,816
9/12/2019, 1:07:15.040 AM	专用字节数	210,591,744
9/12/2019, 1:12:16.285 AM	专用字节数	216,285,184
9/12/2019, 1:12:31.376 AM	专用字节数	235,806,720

确定持续时间

Azure Monitor 可跟踪资源级指标，对于函数来说，就是跟踪函数应用指标。 Application Insights 集成会发出每个函数的指标。下面是一个示例分析查询，可用于获取函数的平均持续时间：

customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name

name	averageDurationMilliseconds
QueueTrigger AvgDurationMs	16.087
QueueTrigger MaxDurationMs	90.249
QueueTrigger MinDurationMs	8.522

后续步骤

详细了解监视函数应用

通过