Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье показано, как оценить затраты на план потребления Flex и устаревший план потребления.
Выберите вариант размещения, который наилучшим образом поддерживает функциональные возможности, производительность и стоимость для выполнения ваших функций. Дополнительные сведения см. в статье о масштабировании и размещении функций Azure.
В этой статье рассматриваются два плана потребления, так как выставление счетов в этих планах зависит от активных периодов выполнения внутри каждого экземпляра.
Обеспечивает быстрое горизонтальное масштабирование с гибкими параметрами вычислений, интеграцией виртуальной сети и полной поддержкой подключений с помощью проверки подлинности идентификатора Microsoft Entra. В этом плане экземпляры динамически масштабируются на основе настроенного параллелизма каждого экземпляра, входящих событий и рабочих нагрузок для каждой функции для оптимальной эффективности. Flex Consumption — это рекомендуемый план для бессерверного размещения. Дополнительные сведения можно найти в статье Размещение плана Flex Consumption для функций Azure.
Устойчивые функции также может выполняться в обоих этих планах. Дополнительные сведения о затратах при использовании устойчивых функций см. в разделе выставления счетов за устойчивые функции.
Затраты на основе потребления
Способ вычисления затрат на основе потребления, включая бесплатные гранты, зависит от конкретного плана. Сведения о самых текущих затратах и предоставлении предоставления см. на странице цен на Функции Azure.
Существует два режима, с помощью которых затраты определяются при запуске приложений в плане потребления Flex. Каждый режим определяется на основе каждого экземпляра.
| Режим выставления счетов | Описание |
|---|---|
| По запросу | При выполнении в режиме спроса плата взимается только за время выполнения кода функции на доступных экземплярах. В режиме спроса не требуется минимальное количество экземпляров. Счета выставляются за: • Общий объем памяти, подготовленной в то время как каждый экземпляр по запросу активно выполняет функции (в ГБ-секундах), минус бесплатный грант ГБ в месяц. • Общее количество выполнений, минус бесплатное предоставление (число) выполнений в месяц. |
| Всегда готов | Можно настроить один или несколько экземпляров, назначенных определенным типам триггеров (HTTP/Durable/Blob) и отдельным функциям, которые всегда доступны для обработки запросов. Если у вас есть все готовые экземпляры, вам выставляются счета за: • Общий объем памяти, подготовленной во всех всегда готовых экземплярах, известных как базовый (в ГБ-секундах). • Общий объем памяти, подготовленной в течение каждого всегда готового экземпляра , активно выполняет функции (в ГБ-секундах). • Общее количество выполнений. В всегда готовых выставления счетов нет бесплатных грантов. |
Актуальные сведения о ценах на выполнение, всегда готовых базовых затрат и бесплатных грантах по запросу см. на странице Функции Azure цен.
На этой схеме показано, как затраты по запросу определяются в этом плане:
В дополнение к времени выполнения при использовании одного или нескольких всегда готовых экземпляров вы платите более низкую базовую ставку для количества всегда готовых экземпляров, которые вы обслуживаете. Время выполнения для всегда готовых экземпляров может быть дешевле, чем время выполнения экземпляров с выполнением по запросу.
Внимание
В этой статье используются цены по запросу, которые помогут вам понять примеры вычислений. Всегда проверяйте текущие затраты на странице цен на Azure Functions, оценивая возможные затраты при использовании плана Flexible Consumption для выполнения ваших функций.
Рассмотрим приложение-функцию, которое имеет только триггеры 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#) в качестве времени выполнения. Вычисление ГБ-с основано на времени начала и окончания функции и на использовании памяти за этот период. Что происходит с течением времени с точки зрения активности ЦП, не учитывается в вычислении. Вы можете сократить затраты во время асинхронных операций с помощью Устойчивые функции. Время, потраченное на ожидание в функциях оркестратора, не учитывается при вычислении времени выполнения.
Просмотр и оценка затрат на основе метрик
В счете можно просмотреть данные, связанные с затратами, вместе с фактическими выставленными затратами. Однако эти данные счета представляют собой ежемесячное агрегирование данных за время, за которое выставляется счет.
В этом разделе показано, как использовать метрики как на уровне приложения, так и на уровне выполнения функций, чтобы оценить затраты на запуск приложений функций.
Метрик уровня приложения-функции
Метрики уровня приложения, доступные приложению, зависят от типа используемого плана потребления.
Эти метрики 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.
Чтобы лучше понять затраты на функции, используйте Azure Monitor для просмотра метрик, связанных с затратами, создаваемых приложениями-функциями. Вы можете просматривать метрики мониторинга с помощью одного из следующих средств:
Используйте обозреватель метрик Azure Monitor для просмотра данных, связанных с затратами, для приложений-функций плана потребления Flex в графическом формате.
На портале 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 Monitor на портале Azure или интерфейсы REST API.
Определение используемого объема памяти
В разделе Мониторингвыберите Журналы (Аналитика), затем скопируйте следующий запрос телеметрии и вставьте его в окно запроса, после чего нажмите Выполнить. Этот запрос возвращает общий объем использованной памяти для выбранного времени.
performanceCounters
| where name == "Private Bytes"
| project timestamp, name, value
Результаты должны выглядеть, как показано ниже:
| Метка времени [UTC] | имя | значение |
|---|---|---|
| 12.09.2019, 1:05:14.947 | байт исключительного пользования | 209 932 288 |
| 12.09.2019, 1:06:14.994 | байт исключительного пользования | 212 189 184 |
| 12.09.2019, 1:06:30.010 | байт исключительного пользования | 231 714 816 |
| 12.09.2019, 1:07:15.040 | байт исключительного пользования | 210 591 744 |
| 12.09.2019, 1: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.
| Связанные затраты | Описание |
|---|---|
| Учетная запись хранения | Для каждого приложения-функции требуется связанная учетная запись хранения Azure общего назначения, которая оплачивается отдельно. Эта учетная запись используется внутри среды выполнения Функций Azure, но ее также можно использовать для триггеров и привязок службы хранилища. Если у вас нет учетной записи хранения, она будет создана для вас при создании приложения-функции. Дополнительную информацию см. в статье Требования учетных записей хранения. |
| Аналитика приложений | Функции Azure используют Application Insights для обеспечения высокопроизводительного мониторинга приложений-функций. Хотя это и не является обязательным, следует включить интеграцию Application Insights. Включено бесплатное предоставление данных телеметрии за каждый месяц. Дополнительные сведения см. на странице цен для Azure Monitor. |
| Пропускная способность сети | Вы можете нести расходы на передачу данных в зависимости от направления и сценария перемещения данных. Дополнительные сведения см. на странице Цены для пропускной способности. |