你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn 。
估算基于消耗的成本
本文内容
本文介绍如何估算消耗和弹性消耗托管计划的计划成本。
Azure Functions 目前为函数应用提供了四个不同的托管计划,每个计划都有其自己的定价模型:
计划
说明
消耗
只根据函数应用的运行时间收费。 此计划包括基于订阅的免费授予 。
弹性消耗计划
需要为运行函数的实例以及任何始终就绪 的实例的执行时间付费。 系统会根据传入事件数动态添加和删除实例。 还支持虚拟网络集成。
高级
提供与“消耗”计划相同的功能和缩放机制,但具有增强的性能和虚拟网络访问权限。 成本取决于所选的定价层。 若要了解详细信息,请参阅 Azure Functions 高级计划 。
专用(应用服务) (基本或更高层)
需要在专用 VM 或隔离的环境中运行、自定义映像,或想要使用超额的应用服务计划容量时。 使用常规应用服务计划计费 。 成本取决于所选的定价层。
应该始终选择最符合函数执行的功能、性能和成本要求的计划。 若要了解更多信息,请参阅 Azure Functions 的缩放和托管 。
本文重点介绍消耗和弹性消耗计划,因为在这些计划中,计费取决于每个实例内的活动执行周期。
Durable Functions 还可以在这两个计划中运行。 若要详细了解使用 Durable Functions 时的成本注意事项,请参阅 Durable Functions 计费 。
基于消耗的成本
基于消耗的成本(包括免费给予)的计算方式视具体计划而定。 有关最新的成本和给予信息,请参阅 Azure Functions 定价页 。
单个函数执行的执行成本以“GB 秒”来度量。 执行成本是通过将其内存用量与执行时间相结合计算得出的。 函数的运行时间越长,其成本越高;同理,函数消耗的内存越多,其成本越高。
假设函数使用的内存量保持恒定。 在这种情况下,进行简单的相乘即可计算成本。 例如,假设函数运行了 3 秒,消耗了 0.5 GB。 那么,执行成本为 0.5GB * 3s = 1.5 GB-seconds
。
由于内存用量会不断变化,计算结果实质上是不同时间的内存用量的积分。 进行这种计算时,系统会按固定的时间间隔对进程(及其子进程)的内存用量采样。 如定价页 中所述,内存用量将向上舍入到最近似的 128-MB 桶。 如果进程使用 160 MB,则你需要按 256 MB 的用量付费。 计算中会考虑并发性,即,同一进程中的多个并发函数执行。
注意
尽管执行成本中不直接考虑 CPU 用量,但如果该用量会影响函数的执行时间,则也会影响成本。
对于 HTTP 触发的函数,在函数代码开始执行之前发生错误时,不会收取执行费用。 这意味着由于 API 密钥验证或应用服务身份验证/授权功能,来自平台的 401 响应不会计入你的执行成本。 同样,在函数处理请求之前,平台中出现的 5xx 状态代码响应不会被计算在内。 在函数代码开始执行后,平台生成的 5xx 响应仍算作一次执行,即使函数代码未引发错误。
在弹性消耗计划中运行应用程序时,可通过两种模式确定成本。 每个模式基于每个实例确定。
计费模式
说明
按需
在按需 模式下运行时,仅对函数代码在可用实例上执行的时间付费。 在按需模式下,不需要最小实例计数。 系统会针对以下内容计费: • 当每个按需实例主动 执行函数(以 GB 秒为单位)时,预配的总内存量减去每月 GB-s 的免费额度。 • 执行的总数减去每月执行的免费额度(数量)。
始终就绪
可以配置一个或多个实例,将它们分配给特定触发器类 (HTTP/Durable/Blob) 和单独的函数,这些实例始终可用于处理请求。 启用任何始终就绪的实例后,系统会针对以下内容计费: • 在所有始终就绪实例(称为基线 ,以 GB-秒为单位)中预配的总内存量。 • 每个始终就绪实例主动 执行函数(以 GB-秒为单位)期间预配的总内存量。 • 总执行次数。 在始终就绪的计费模式中,不存在免费赠予。
下图表示如何在此计划中确定按需成本:
除了执行时间外,在使用一个或多个始终就绪实例时,还会按较低的基线费率对维护的始终就绪实例数进行计费。 就执行时间的价格而言,与按需执行的实例相比,始终就绪的实例可能更划算。
对于本节中的示例,请考虑此表中美国东部即用即付的折扣预览定价。
模式
计量
免费每月赠予
消耗率
点播
执行时间 (GB-s)
100,000
$0.000016
/GB
点播
执行(次数)
250,000
$0.20
/百万次执行
始终就绪
基线(空闲)时间 (GB-s)
-
$0.000004
/GB
始终就绪
执行时间 (GB-s)
-
$0.000009
/GB
始终就绪
执行(次数)
-
$0.20
/百万次执行
假设有一个仅由 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
。
在估算任何计划中运行函数的总体成本时,请记住,函数运行时将使用其他多个 Azure 服务,而每个服务单独计费。 估算函数应用的定价时,对于与其他 Azure 服务集成的任何触发器和绑定,需要创建这些附加的服务并为其付费。
对于在消耗计划中运行的函数,总成本是函数的执行成本加上带宽和附加服务的成本。
估算函数应用和相关服务的总体成本时,请使用 Azure 定价计算器 。
影响执行时间的行为
函数的以下行为可能会影响执行时间:
触发器和绑定 :从函数绑定 读取输入以及向其写入输出所花费的时间计为执行时间。 例如,如果函数使用某个输出绑定将消息写入 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,也可以直接从门户中使用 Azure Cloud Shell 。 例如,以下 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": "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"
}
]
}
此特定响应显示,从 2019-09-11T21:46
到 2019-09-11T23:18
,应用消耗了 1110000000 MB 毫秒(1083.98 GB 秒)。
Azure PowerShell 提供了用于检索指标的命令。 可以从本地命令环境中使用 Azure PowerShell,也可以直接从门户中使用 Azure Cloud Shell 。 例如,以下 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
后续步骤