Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье показано, как оценить затраты на план потребления Flex и устаревший план потребления.
Выберите вариант размещения, который наилучшим образом поддерживает функциональные возможности, производительность и стоимость для выполнения ваших функций. Для получения дополнительной информации см. Масштабирование и размещение Azure Functions.
В этой статье рассматриваются два плана потребления, так как выставление счетов в этих планах зависит от активных периодов выполнения внутри каждого экземпляра.
Обеспечивает быстрое горизонтальное масштабирование с гибкими параметрами вычислений, интеграцией виртуальной сети и полной поддержкой подключений с помощью проверки подлинности Microsoft Entra ID. В этом плане экземпляры динамически масштабируются на основе настроенного параллелизма каждого экземпляра, входящих событий и рабочих нагрузок для каждой функции для оптимальной эффективности. Flex Consumption — это рекомендуемый план для бессерверного размещения. Дополнительные сведения см. в разделе размещение по плану Flex Consumption для Azure Functions.
Durable Functions также могут выполняться в обоих этих тарифных планах. Дополнительные сведения о затратах при использовании Durable Functions см. в разделе Durable Functions выставление счетов.
Затраты на основе потребления
Способ вычисления затрат на основе потребления, включая бесплатные гранты, зависит от конкретного плана. Для получения самой актуальной информации о затратах и грантах см. страницу цен Azure Functions.
Существует два режима, с помощью которых затраты определяются при запуске приложений в плане потребления Flex. Каждый режим определяется для каждого экземпляра.
| Режим выставления счетов | Описание |
|---|---|
| По запросу | При выполнении в режиме по запросу плата взимается только за время выполнения кода функции на доступных экземплярах. В режиме спроса не требуется минимальное количество экземпляров. Счета выставляются за: • Общий объем памяти, выделенной по мере того как каждый экземпляр по запросу активно выполняет функции (в ГБ-секундах), минус бесплатный грант ГБ-секунд в месяц. • Общее количество выполнений, за вычетом бесплатной выделенной квоты (число выполнений) в месяц. |
| Всегда готов | Можно настроить один или несколько экземпляров, назначенных определенным типам триггеров (HTTP/Durable/Blob) и отдельным функциям, которые всегда доступны для обработки запросов. Если у вас включены какие-либо всегда готовые экземпляры, вам выставляется счет за: • Общий объем памяти, подготовленной во всех всегда готовых экземплярах, называемый базовым уровнем (в ГБ-секундах). • Общий объем памяти, предоставленной в течение времени, когда каждый всегда готовый экземпляр активно выполняет функции (в ГБ-секундах). • Общее количество выполнений. В автоматизированной выставке счетов нет бесплатных грантов. |
Для получения актуальных сведений о ценах на выполнение, всегда готовых базовых затратах и бесплатных грантах для выполнения по запросу см. на странице цен Azure Functions.
На этой схеме показано, как затраты по запросу определяются в этом плане:
В дополнение к времени выполнения при использовании одного или нескольких всегда готовых экземпляров вы платите более низкую базовую ставку для количества всегда готовых экземпляров, которые вы обслуживаете. Время выполнения для всегда готовых экземпляров может быть дешевле, чем время выполнения экземпляров с выполнением по запросу.
Внимание
В этой статье используются цены по запросу, которые помогут вам понять примеры вычислений. Всегда проверяйте текущие затраты на странице цен Azure Functions при оценке затрат при выполнении функций в плане потребления Flex.
Рассмотрим приложение-функцию, которое имеет только триггеры HTTP с этими основными фактами:
- Триггеры HTTP обрабатывают 40 постоянных запросов в секунду.
- Триггеры HTTP обрабатывают 10 одновременных запросов.
- Размер памяти экземпляра составляет 2048 МБ.
- Вы настраиваете отсутствие всегда готовых экземпляров, что означает, что приложение может масштабироваться до нуля.
В такой ситуации цены зависят от типа работы, выполняемой во время выполнения кода. Рассмотрим два сценария рабочей нагрузки:
Связанная с ЦП рабочая нагрузка. В рабочей нагрузке, привязанной к ЦП, нет преимуществ параллельной обработки нескольких запросов в одном экземпляре. Вам лучше распределять каждый запрос в свой экземпляр, чтобы запросы выполнялись как можно быстрее без конкуренции. В этом сценарии установите низкую конкуренцию триггера HTTP
1. С 10 одновременными запросами приложение масштабируется до устойчивого состояния примерно 10 экземпляров, и каждый экземпляр постоянно активно обрабатывает один запрос за раз.Так как размер каждого экземпляра составляет около 2 ГБ, потребление для одного постоянно активного экземпляра равно
2 GB * 3600 s = 7200 GB-s. Предположим, что скорость выполнения по запросу составляет 0,00026 ГБ (без каких-либо бесплатных грантов), стоимость становится$0.1872 USDв час на экземпляр. Так как приложение, привязанное к ЦП, масштабируется до 10 экземпляров, общая скорость почасового выполнения составляет$1.872 USD.Подобным образом, стоимость выполнения по запросу (без бесплатных грантов) за 40 запросов в секунду равна
40 * 3600 = 144,000или0.144 millionвыполнений в час. При условии, что ставка по запросу$0.40на миллион выполнений, общая почасовая стоимость выполнений составит0.144 * $0.40, что составляет$0.0576в час.В этом сценарии общая почасовая стоимость выполнения на условиях по требованию на 10 экземплярах составляет
$1.872 + $0.0576s = $1.9296 USD.Связанная с операцией ввода-вывода рабочая нагрузка. В рабочей нагрузке, связанной с операцией ввода-вывода, большая часть времени приложения тратится на ожидание входящего запроса, что может быть ограничено пропускной способностью сети или другими вышестоящими факторами. Из-за ограниченных входных данных код может обрабатывать несколько операций одновременно без негативных последствий. В этом сценарии предполагается, что можно обрабатывать все 10 одновременных запросов на одном экземпляре.
Поскольку расходы на потребление основаны только на памяти каждого активного экземпляра, расчет платы за потребление сводится просто к
2 GB * 3600 s = 7200 GB-s, что при предполагаемой скорости выполнения по запросу (без учета каких-либо бесплатных грантов) составляет$0.1872 USDв час для одного экземпляра.Как и в сценарии, связанном с ЦП, плата за выполнение запросов по требованию (без бесплатных квот) при 40 запросах в секунду равна
40 * 3600 = 144,000или 0,144 миллиона выполнений в час. В этом случае общая (бесплатная) почасовая стоимость выполнения0.144 * $0.40, которая составляет$0.0576в час.В этом сценарии общая почасовая стоимость выполнения по запросу одного экземпляра
$0.1872 + $0.0576 = $0.245 USD.
Поведение, влияющее на время выполнения
Следующее поведение функций может повлиять на время выполнения:
Триггеры и привязки: время, затраченное на чтение входных данных из и запись выходных данных в привязки функций , учитывается как время выполнения. Например, если функция использует выходную привязку для записи сообщения в очередь хранилища Azure, время выполнения включает время, затраченное на запись сообщения в очередь, которое включается в вычисление стоимости функции.
Асинхронное выполнение: время ожидания функции результатов асинхронного запроса (
awaitв C#) в качестве времени выполнения. Вычисление ГБ-с основано на времени начала и окончания функции и на использовании памяти за этот период. Что происходит с течением времени с точки зрения активности ЦП, не учитывается в вычислении. Вы можете сократить затраты во время асинхронных операций с помощью Durable Functions. Время, потраченное на ожидание в функциях оркестратора, не учитывается при расчете платы.
Просмотр и оценка затрат на основе метрик
В счете можно просмотреть данные, связанные с затратами, вместе с фактическими выставленными затратами. Однако эти данные счета — это ежемесячное агрегированное значение за прошедший период.
В этом разделе показано, как использовать метрики как на уровне приложения, так и на уровне выполнения функций, чтобы оценить затраты на запуск приложений функций.
Метрики уровня функционального приложения
Метрики уровня приложения, доступные приложению, зависят от типа используемого плана потребления.
Эти метрики Azure Monitor связаны с выставлением счетов за план потребления Flex:
| Единица измерения | Описание | Вычисление счётчика |
|---|---|---|
| Количество выполнения функции по запросу | Общее количество выполнений функций в экземплярах по запросу. |
OnDemandFunctionExecutionCount относится к счетчику итогов выполнения по запросу . |
| Счетчик выполнения функции в режиме "Всегда готов" | Общее количество выполнений функций в постоянно готовых экземплярах. |
AlwaysReadyFunctionExecutionCount относится к счетчику Всегда Готовых Итоговых Выполнений. |
| Единицы выполнения функции по запросу | Общее количество мб-миллисекунд от экземпляров по запросу во время активного выполнения функций. |
OnDemandFunctionExecutionUnits / 1,024,000 — это счетчик времени выполнения по запросу, измеряемый в ГБ-секундах. |
| Единицы выполнения функции Always Ready | Общее количество MB-миллисекунд из всегда готовых экземпляров в процессе активного выполнения функций. |
AlwaysReadyFunctionExecutionUnits / 1,024,000 — это счетчик времени выполнения Always Ready, измеряемый в гигабайт-секундах. |
| Всегда готовые подразделения | Общее количество мегабайт-миллисекунд всегда готовых экземпляров, назначенных приложению, вне зависимости от того, выполняются ли функции. |
AlwaysReadyUnits / 1,024,000 — это счетчик базового уровня Always Ready, в гигабайт-секундах. |
Дополнительные сведения см. в справочнике по данным мониторинга Azure Functions.
Чтобы лучше понять затраты на функции, используйте Azure Monitor для просмотра метрик, связанных с затратами, создаваемых приложениями-функциями. Вы можете просматривать метрики мониторинга с помощью одного из следующих средств:
Используйте обозреватель метрик Azure Monitor для просмотра данных, связанных с затратами, для приложений-функций плана Flex Consumption в графическом формате.
На портале Azure перейдите к функциональному приложению.
На левой панели прокрутите вниз до "Мониторинг " и выберите "Метрики".
В списке метрик выберите "Число выполнения функции по запросу " и "Сумма " для агрегирования. Этот параметр добавляет на диаграмму сумму счетчиков выполнения за выбранный период.
Выберите "Добавить метрики" и добавьте единицы выполнения функции по запросу, количество выполнений функции Always Ready, единицы выполнения функции Always Ready и единицы Always Ready на диаграмму.
Результирующая диаграмма содержит итоги для всех метрик выполнения потребления Flex в выбранном диапазоне времени, который в этом примере представляет собой настраиваемый диапазон времени.
Поскольку число единиц выполнения функции по запросу больше, чем число запросов на выполнение функции, и в приложении не было всегда готовых экземпляров, на диаграмме отображаются только единицы выполнения функции по запросу.
На этой диаграмме показана общая сумма 3,54 млрд On Demand Function Execution Units , потребляемых в течение 16-минутного периода, измеряемого в миллисекундах МБ. Чтобы преобразовать в ГБ-секунды, разделите на 1024 000. В этом примере приложение потребило 3,540,000,000 / 1,024,000 = 3,457.03 гигабайт-секунд. Это значение можно использовать и умножить на текущую цену времени выполнения по требованию на странице цен на функции, что даст вам стоимость этих 16 минут, если вы уже использовали любые бесплатные льготы времени выполнения. Вы можете использовать это же вычисление с метрикой Always Ready Execution Units и стоимостью измерителя выставления счетов за время выполнения Always Ready, а также с метрикой Always Ready Units и стоимостью измерителя выставления счетов за базовое значение Always Ready, для определения затрат в гигабайт-секундах для всегда готовых экземпляров.
Чтобы рассчитать затраты на общее количество выполнений по требованию, возьмите сумму количества выполнений функции по требованию за тот же период времени, преобразуйте её в миллионы, а затем умножьте на цену за общее количество выполнений по требованию на странице цен на функции. Например, 2,100 выполнений в приведенном выше примере равняется 0.0021 миллиону выполнений. Вы можете использовать это же вычисление с метрикой счетчика выполнения функции Always Ready и счетчиком выставления счетов Always Ready Total Executions, чтобы узнать затраты на выполнение, обрабатываемые всегда готовым экземпляром.
Метрики уровня функции
Использование памяти важно при оценке затрат на выполнение функции. Однако способ влияния использования памяти на затраты зависит от конкретного типа плана:
В рамках плана потребления Flex вы платите за время работы экземпляра на основе выбранного размера экземпляра, который имеет установленный предел памяти. Дополнительные сведения см. в разделе о выставлении счетов.
Включите Application Insights в вашем приложении функций, если это еще не сделано. Если эта интеграция включена, можно запросить эти данные телеметрии на портале.
Вы можете использовать обозреватель метрик Azure Monitor на портале Azure или REST API для получения данных метрик Azure Monitor.
Определение используемого объема памяти
В разделе Мониторингвыберите Журналы (Аналитика), затем скопируйте следующий запрос телеметрии и вставьте его в окно запроса, после чего нажмите Выполнить. Этот запрос возвращает общий объем использованной памяти для выбранного времени.
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
Результаты должны выглядеть, как показано ниже:
| Метка времени [UTC] | имя | значение |
|---|---|---|
| 12.09.2019, 01:05:14.947 утра | байты частного использования | 209 932 288 |
| 12.09.2019, 1:06:14.994 AM | байты частного использования | 212 189 184 |
| 12.09.2019, 01:06:30.010 | байты частного использования | 231 714 816 |
| 12.09.2019, 01:07:15.040 | байты частного использования | 210 591 744 |
| 12.09.2019, 01:12:16.285 | байты частного использования | 216 285 184 |
| 12.09.2019, 1:12:31.376 | байты частного использования | 235 806 720 |
Определение длительности
Azure Monitor отслеживает метрики на уровне ресурса, который для Функций является приложением-функцией. Интеграция Application Insights обеспечивает предоставление метрик для каждой функции. Ниже приведен пример запроса аналитики для получения средней длительности выполнения функции:
customMetrics
| where name contains "Duration"
| extend averageDuration = valueSum / valueCount
| summarize averageDurationMilliseconds=avg(averageDuration) by name
| имя | средняяДлительностьМиллисекунды |
|---|---|
| ТриггерОчереди СредняяДлительностьМс | 16.087 |
| ТриггерОчереди МаксимальнаяДлительностьМс | 90.249 |
| ТриггерОчереди МинПродолжительностьМс | 8.522 |
Другие связанные затраты
При оценке общей стоимости выполнения ваших функций в любой из планов, помните, что среда выполнения функций использует несколько других служб Azure, и каждой из них выставляется отдельный счет. При оценке цен на приложения-функции все триггеры и привязки, которые интегрируются с другими службами Azure, требуют создания и оплаты других служб.
Для функций, выполняемых в плане потребления, общая стоимость — это стоимость выполнения функций, а также стоимость пропускной способности и других служб.
При оценке общих затрат приложения-функции и связанных служб используйте калькулятор цен Azure.
| Связанные затраты | Описание |
|---|---|
| Учетная запись хранения | Каждое функциональное приложение требует наличия связанной учетной записи общего назначения Azure Storage, которая выставляется отдельно. Эта учетная запись используется внутренне средой выполнения Функций, но ее также можно использовать для триггеров и привязок хранилища. Если у вас нет учетной записи хранения, она будет создана для вас при создании приложения-функции. Дополнительную информацию см. в статье Требования учетных записей хранения. |
| Аналитика приложений | Функции Azure используют Application Insights для обеспечения высокопроизводительного мониторинга функциональных приложений. Хотя это и не является обязательным, следует включить интеграцию Application Insights. Включено бесплатное предоставление данных телеметрии за каждый месяц. Дополнительные сведения см. на странице цен Azure Monitor. |
| Пропускная способность сети | Вы можете нести расходы на передачу данных в зависимости от направления и сценария перемещения данных. Дополнительные сведения см. в разделе Тарифы на пропускную способность. |