Измерение использования, выставление счетов и цены для Azure Logic Apps
Область применения: Azure Logic Apps (Потребление + Стандартный)
Azure Logic Apps помогает создать и запускать автоматизированные рабочие процессы интеграции, которые могут горизонтально уменьшить масштаб в облаке. В этой статье описывается, как работают измерение использования, выставление счетов и модели ценообразования для Azure Logic Apps и связанных ресурсов. Дополнительные сведения о конкретных тарифах, планировании затрат или различных средах размещения см. в следующих статьях.
- Тарифы Azure Logic Apps
- Планирование затрат и управление затратами для Azure Logic Apps
- Однотенантное и мультитенантное
Потребление (мультитенантное)
В мультитенантных Azure Logic Apps приложение логики и его рабочий процесс соответствуют плану потребления для ценообразования и выставления счетов. Такие приложения логики создаются различными способами, например при выборе типа ресурса приложение логики (версия потребления), использовании расширения Azure Logic Apps (версия потребления) в Visual Studio Code или создании задач автоматизации.
В следующей таблице показано, как модель потребления обрабатывает измерение и выставление счетов для следующих компонентов при использовании с приложением логики и рабочим процессом в мультитенантных Azure Logic Apps:
| Компонент | Измерение и выставление счетов |
|---|---|
| Операции с триггерами и действия | Модель потребления включает в себя изначальное количество бесплатных встроенных операций в каждой подписке Azure, которое может запустить рабочий процесс. После превышения этого количества к каждому выполнению применяется измерение, а выставление счетов осуществляется по ценам на действия для плана потребления. Для операций другого типа, таких как управляемые соединители, выставление счетов осуществляется по модели ценообразования для соединителей Стандартный или Enterprise в рамках плана потребления. Дополнительные сведения см. в статье Операции с триггерами и действиями в модели на основе потребления. |
| Операции с хранилищем | Измерение применяется только к потреблению хранилища, связанного с хранением данных, например при сохранении входных и выходных данных журнала выполнения рабочего процесса. Выставление счетов осуществляется по плану ценообразования для хранения данных на основе потребления. Дополнительные сведения см. в разделе Операции с хранилищем. |
| Учетные записи службы интеграции | Измерение применяется в зависимости от типа учетной записи интеграции, которую вы создали и используете в приложении логики. Выставление счетов следует ценам на учетную запись интеграции. Дополнительные сведения см. в разделе Учетные записи интеграции. |
Операции с триггерами и действиями в модели потребления
За исключением изначального количества бесплатных встроенных операций для каждой подписки Azure, которое может запустить рабочий процесс, в модели потребления измерение и выставление счетов для операций осуществляется на основе каждого выполнения, независимо от того, удается ли запустить общий рабочий процесс, завершить его выполнение или даже создать экземпляр. Операция обычно выполняется один раз, если только для нее не включены повторные попытки. В свою очередь, выполнение обычно совершает только один вызов, за исключением случаев, когда операция поддерживает и позволяет выполнять разделение на блоки или разбиение на страницы для получения больших объемов данных. Если включено разделение на блоки или разбиение на страницы, выполнение операции может совершить несколько вызовов.
В модели потребления измерение и выставление счетов для операций осуществляется за каждое выполнение, а не за каждый вызов. Например, предположим, что рабочий процесс начинается с триггера опроса, который получает записи путем регулярного выполнения исходящих вызовов к конечной точке. Исходящий звонок измеряется и оплачивается как одно выполнение независимо от того, срабатывает ли триггер или нет, например, когда триггер проверяет конечную точку, но не находит никаких данных или событий. Состояние триггера определяет, будет ли создан и запущен экземпляр рабочего процесса. Теперь предположим, что операция также поддерживает и включает разделение на блоки или разбиение на страницы. Если операция должна выполнить 10 вызовов, чтобы завершить получение всех данных, для целей измерения и выставления счетов операция по-прежнему считается за одно выполнение, несмотря на совершение нескольких вызовов.
Примечание.
По умолчанию триггеры, возвращающие массив, имеют параметр Split On , который уже включен. Этот параметр приводит к событию триггера, которое можно просмотреть в журнале триггеров и экземпляр рабочего процесса для каждого элемента массива. Все экземпляры рабочих процессов выполняются параллельно, чтобы элементы массива обрабатывались одновременно. Выставление счетов применяется ко всем событиям триггера, если состояние триггера выполнено успешно или пропущено. Триггеры по-прежнему оплачиваются даже в сценариях, когда триггеры не создают экземпляр и запускают рабочий процесс, но состояние триггера успешно выполнено, не удалось или пропущено.
В следующей таблице показано, как модель потребления обрабатывает измерение и выставление счетов для этих типов операций при использовании с приложением логики и рабочим процессом в мультитенантных Azure Logic Apps:
| Тип операции | Description | Измерение и выставление счетов |
|---|---|---|
| Встроены | Эти операции выполняются непосредственно и изначально в среде выполнения Azure Logic Apps. В конструкторе эти операции помечены как встроенные. Например, триггеры HTTP и Request являются встроенными триггерами. Действие HTTP и действие ответа являются встроенными действиями. К другим встроенным операциям относятся действия по управлению рабочими процессами, такие как циклы и условия, операции с данными, пакетные операции и др. |
Модель потребления включает в себя изначальное количество бесплатных встроенных операций в каждой подписке Azure, которое может запустить рабочий процесс. После превышения этого количества для выполнения встроенных операций используются цены на действия. Примечание. Некоторые операции управляемого соединителя также доступны в виде встроенных операций, которые включены в число изначальных бесплатных операций. За исключением изначальных бесплатных операций, выставление счетов осуществляется с использованием цен на действия, а не цен на соединители категории Стандартный или Enterprise. |
| Управляемый соединитель | Эти операции выполняются в Azure отдельно. В конструкторе эти операции помечены как Стандартный или Enterprise. | Для выполнения этих операций используются цены на соединители категории Стандартный или Enterprise. Примечание. Для выполнения операций предварительной версии корпоративного соединителя используются цены на соединители категории Стандартный. |
| Настраиваемый соединитель | Эти операции выполняются в Azure отдельно. В конструкторе эти операции помечены как пользовательские. Ограничения количества соединителей, пропускной способности и времени ожидания см. в разделе Ограничения пользовательских соединителей в Azure Logic Apps. | Для выполнения этих операций используются цены на соединители категории Стандартный. |
Дополнительные сведения о том, как модель потребления работает с операциями, выполняемыми внутри других операций, таких как циклы, обработка нескольких элементов, например массивов, и политики повторов, см. в статье Поведение других операций.
Советы по оценке затрат для модели потребления
Чтобы упростить процесс более точной оценки затрат на использование, выполните проверку следующих советов:
Рассмотрите возможное количество сообщений или событий, которые могут поступать в любой конкретный день, а не берите за базу вычислений только интервал опроса.
Когда событие или сообщение соответствует критериям, большая часть триггеров немедленно пытается считать его, как и все ожидающие события и сообщения, которые соответствуют критериям. Такое поведение означает, что даже если выбрать более длительный интервал опроса, триггеры срабатывают на основе количества ожидающих сообщений или событий, которые соответствуют критериям для запуска рабочих процессов. Триггеры, которые следуют этому поведению, включают Служебная шина Azure и Центры событий Azure.
Например, предположим, что был настроен триггер, который проверяет конечную точку каждый день. Когда этот триггер проверяет конечную точку и обнаруживает 15 событий, которые соответствуют критериям, он срабатывает и выполняет соответствующий рабочий процесс 15 раз. Оценка единиц измерения службы Logic Apps производится по всем действиям, выполняемым этими 15 рабочими процессами, включая запросы триггеров.
Стандартный (один клиент)
В Azure Logic Apps с одним клиентом для приложения логики и его рабочего процесса используется план ценообразования и выставления счетов Стандартный. Такие приложения логики создаются различными способами, например при выборе типа ресурса приложение логики (стандартный) или использовании расширения Azure Logic Apps (неизменяемости) в Visual Studio Code. Эта модель ценообразования требует, чтобы приложения логики использовали план размещения и ценовую категорию. Отличие от плана потребления состоит в том, что плата взимается за зарезервированную емкость и выделенные ресурсы независимо от того, используются они или нет.
При создании или развертывании приложений логики с типом ресурса Logic App (Standard) и выборе любого региона Azure для развертывания вы также выберете план размещения "Стандартный рабочий процесс". Однако если выбрать существующий ресурс Среда службы приложений версии 3 для расположения развертывания, необходимо выбрать Служба приложений план.
Внимание
Следующие планы и ресурсы больше не доступны или поддерживаются в общедоступном выпуске рабочих процессов приложения логики уровня "Стандартный" в однотенантных azure Logic Apps: план "Функции Премиум", Среда службы приложений версии 1 и Среда службы приложений версии 2. План Служба приложений доступен и поддерживается только с Среда службы приложений версии 3 (ASE версии 3).
В следующей таблице представлены общие сведения о том, как модель стандартной версии обрабатывает измерение и выставление счетов для следующих компонентов при использовании с приложением логики и рабочим процессом Azure Logic Apps с одним клиентом.
| Компонент | Измерение и выставление счетов |
|---|---|
| Виртуальный ЦП и память | Модель стандартной версии требуется, чтобы приложение логики использовало план размещения и ценовую категорию рабочего процесса Стандартный, что определяет уровни ресурсов и тарифы, которые применяются к емкости вычислительных ресурсов и объему памяти. Дополнительные сведения см. в статье Ценовые категории в модели стандартной версии. |
| Операции с триггерами и действия | Модель стандартной версии включает в себя неограниченное количество бесплатных встроенных операций, которое может запустить рабочий процесс. Если рабочий процесс использует какие-либо операции управляемого соединителя, измерение применяется к каждому вызову, в то время как выставление счетов осуществляется по той же модели ценообразования для соединителей Стандартный и Enterprise, что и при использовании плана на основе потребления. Дополнительные сведения см. в статье Операции с триггерами и действиями в модели стандартной версии. |
| Операции с хранилищем | Измерение применяется к любым операциям с хранилищем, выполняемым Azure Logic Apps. Например, операции с хранилищем выполняются, когда служба сохраняет входные и выходные данные из журнала выполнения рабочего процесса. Выставление счетов осуществляется на основе выбранной ценовой категории. Дополнительные сведения см. в разделе Операции с хранилищем. |
| Учетные записи службы интеграции | Если вы создаете учетную запись интеграции для использования приложением логики, измерение зависит от типа создаваемой учетной записи интеграции. Выставление счетов осуществляется на основе модели ценообразования для учетной записи интеграции. Дополнительные сведения см. в разделе Учетные записи интеграции. |
Ценовые категории в модели стандартной версии
Ценовая категория, выбранная для измерения и выставления счетов для ресурса Приложения логики (стандартный), включает определенные объемы вычислений в виртуальных ЦП и ресурсах памяти. При выборе Среда службы приложений версии 3 в качестве расположения развертывания и плана Служба приложений, в частности ценовой категории "Изолированный план службы версии 2", взимается плата за экземпляры, используемые планом Служба приложений и для выполнения рабочих процессов приложения логики. Больше ни за что плата не взимается. Дополнительные сведения см. в разделе Служба приложений План — ценовые категории "Изолированный план службы версии 2".
Если выбрать план размещения "Стандартный рабочий процесс" , можно выбрать один из следующих уровней:
| Ценовая категория | Виртуальный ЦП | Память (ГБ) |
|---|---|---|
| WS1 | 1 | 3.5 |
| WS2 | 2 | 7 |
| WS3 | 4 | 14 |
Внимание
Следующий пример предназначен только для иллюстрации. В этом примере представлены примерные цены, которые показывают, как работает ценовая категория. Конкретные цены на виртуальные ЦП и память на основе определенных регионов, где доступна Azure Logic Apps, см. в плане "Стандартный" для выбранного региона на странице цен Azure Logic Apps.
Предположим, что в примере региона для следующих ресурсов заданы следующие почасовые тарифы.
| Ресурс | Почасовой тариф (пример региона) |
|---|---|
| Виртуальные ЦП | 0,192 долл. за виртуальный ЦП |
| Память | 0,0137 долл. США за 1 ГБ |
В следующем примере рассчитывается приблизительный месячный тариф.
<Месячный тариф> = 730 часов (в месяц) * [(<кол-во виртуальных ЦП> * <почасовой тариф на виртуальный ЦП>) + (<кол-во ГБ памяти> * <почасовой тариф на ГБ памяти>)]
С учетом информации, приведенной выше, в следующей таблице показан примерный месячный тариф для каждой ценовой категории и ресурсов, включенных в эту ценовую категорию.
| Ценовая категория | Виртуальный ЦП | Память (ГБ) | Месячный тариф (пример региона) |
|---|---|---|---|
| WS1 | 1 | 3.5 | 175,16 долл. |
| WS2 | 2 | 7 | 350,33 долл. |
| WS3 | 4 | 14 | 700,65 долл. |
Операции с триггерами и действиями в модели стандартной версии
За исключением неограниченного количества бесплатных встроенных операций, которое может запустить рабочий процесс, в модели стандартной версии измерение и выставление счетов для операций осуществляется на основе каждого вызова, независимо от того, удается ли запустить общий рабочий процесс, завершить его выполнение или даже создать экземпляр. Операция обычно выполняется один раз, если только для нее не включены повторные попытки. В свою очередь, выполнение обычно совершает только один вызов, за исключением случаев, когда операция поддерживает и позволяет выполнять разделение на блоки или разбиение на страницы для получения больших объемов данных. Если включено разделение на блоки или разбиение на страницы, выполнение операции может совершить несколько вызовов. В модели стандартной версии измерение и выставление счетов для операций осуществляется за каждый вызов, а не за каждое выполнение.
Например, предположим, что рабочий процесс начинается с триггера опроса, который получает записи путем регулярного выполнения исходящих вызовов к конечной точке. Измерение и выставление счетов осуществляется для исходящего вызова, независимо от того, срабатывает ли триггер или пропускается. Состояние триггера определяет, будет ли создан и запущен экземпляр рабочего процесса. Теперь предположим, что операция также поддерживает и включает разделение на блоки или разбиение на страницы. Если операция должна выполнить 10 вызовов, чтобы завершить получение всех данных, измерение и выставление счетов для операции осуществляется на основе вызова.
В следующей таблице представлены общие сведения о том, как модель стандартной версии обрабатывает измерение и выставление счетов для типов операций при использовании с приложением логики и рабочим процессом Azure Logic Apps с одним клиентом.
| Тип операции | Description | Измерение и выставление счетов |
|---|---|---|
| Встроены | Эти операции выполняются непосредственно и изначально в среде выполнения Azure Logic Apps. В конструкторе эти операции можно найти в коллекции соединителей в разделе "Среда выполнения>в приложении". Например, триггеры HTTP и Request являются встроенными триггерами. Действие HTTP и действие ответа являются встроенными действиями. К другим встроенным операциям относятся действия по управлению рабочими процессами, такие как циклы и условия, операции с данными, пакетные операции и др. |
Стандартная модель включает неограниченное количество бесплатных встроенных операций. Примечание. Некоторые операции управляемого соединителя также доступны в виде встроенных операций. Несмотря на то что встроенные операции являются бесплатными, в стандартной модели для операций с управляемым соединителем измерение и выставление счетов по-прежнему осуществляется с использованием той же модели ценообразования для соединителей категории Стандартный или Enterprise, что и в модели на основе потребления. |
| Управляемый соединитель | Эти операции выполняются отдельно в общей глобальной среде Azure. В конструкторе эти операции можно найти в коллекции соединителей в разделе "Общие сведения о среде выполнения>". | В стандартной модели для операций с управляемым соединителем измерение и выставление счетов осуществляется с использованием той же модели ценообразования для соединителей категории Стандартный или Enterprise, что и в модели на основе потребления. Примечание. Для операций предварительной версии корпоративного соединителя используются цены на соединители категории Стандартный. |
| Настраиваемый соединитель | В настоящее время в рабочих процессах приложения логики на основе одного клиента можно создавать и использовать только пользовательские операции с соединителем. | Стандартная модель включает неограниченное количество бесплатных встроенных операций. Ограничения пропускной способности и времени ожидания см. в разделе Ограничения пользовательских соединителей в Azure Logic Apps. |
Дополнительные сведения о том, как стандартная модель работает с операциями, выполняемыми внутри других операций, таких как циклы, обработка нескольких элементов, например массивов, и политики повторов, см. в статье Поведение других операций.
Поведение других операций
В следующей таблице показано, как модели потребления и стандартные модели обрабатывают операции, выполняемые внутри других операций, таких как циклы, обработка нескольких элементов, таких как массивы, и политики повторных попыток:
| Операция | Description | Потребление | Стандартные |
|---|---|---|---|
| Действия цикла | Действие цикла, такого как цикл For each или Until, может включать другие действия, выполняемые во время каждого тела цикла. | За исключением изначального количества включенных встроенных операций, действие цикла и каждое действие в цикле измеряются при каждом выполнении тела цикла. Если действие обрабатывает какие-либо элементы в коллекции, например список или массив, количество элементов также используется при расчете измерения. Давайте для примера рассмотрим цикл For each, который обрабатывает список. Служба умножает число элементов списка на число действий в цикле, а также добавляет действие запуска цикла. Таким образом, вычисление для 10-элементного списка имеет значение (10 * 1) + 1, что дает результаты в виде 11 выполнений действий. Цены основаны на типе операций: встроенный, стандартный или Enterprise. |
За исключением включенных встроенных операций, все аналогично модели на основе потребления. |
| Политики повторных попыток | Для поддерживаемых операций можно реализовать базовую обработку исключений и ошибок, настроив политику повтора. | За исключением изначального числа встроенных операций, первоначальное выполнение и каждое повторное выполнение измеряются. Например, действие, выполняемое с 5 повторными попытками, измеряется и оплачивается как 6 выполнений. Цены основаны на типе операций: встроенный, стандартный или Enterprise. |
За исключением включенных встроенных операций, все аналогично модели на основе потребления. |
Операции с хранилищем
Azure Logic Apps использует службу хранилища Azure для выполнения любых необходимых транзакций с хранилищем, таких как использование очередей для планирования операций с триггером или использование таблиц и больших двоичных объектов для хранения состояний рабочих процессов. В зависимости от операций, выполняемых в рабочем процессе, затраты на хранение различаются, поскольку разные сочетания триггеров, действий и полезных данных требуют разных операций и условий хранения. Служба также сохраняет входные и выходные данные журнала выполнения рабочего процесса с учетом предельного срока хранения журнала выполнения ресурса приложения логики. Вы можете управлять этим предельным сроком хранения на уровне ресурсов приложения логики, а не на уровне рабочего процесса.
В следующей таблице приведены сведения о том, как модели потребления и стандартные модели обрабатывают измерение и выставление счетов для операций хранения:
| Модель | Description | Измерение и выставление счетов |
|---|---|---|
| Потребление (мультитенантное) | Ресурсы службы хранилища и использование присоединяются к ресурсу приложения логики. | Измерение показателей и выставление счетов применяются только к потреблению хранилища с целью хранения данных и осуществляются в соответствии с планом на основе потребления с ценами на хранение данных. |
| Стандартный (один клиент) | Вы можете использовать собственную учетную запись хранения Azure, что повышает контроль и гибкость при использовании данных рабочего процесса. | Измерение показателей и выставление счетов осуществляются по модели ценообразования для службы хранилища Azure. Затраты на хранение приводятся отдельным списком при выставлении счетов в накладной Azure. Совет. Чтобы получить представление о количестве операций с хранилищем, которые может запустить рабочий процесс, и о затратах на них, попробуйте использовать Калькулятор Logic Apps службы хранилища Azure. Выберите пример рабочего процесса или используйте существующее определение рабочего процесса. При первом вычислении оценивается количество операций с хранилищем в рабочем процессе. Затем эти цифры можно использовать для оценки возможных затрат с помощью Калькулятора цен Azure. Дополнительные сведения см. в статье Оценка потребностей в хранилище и затрат на рабочие процессы в Azure Logic Apps при одном клиенте. |
Дополнительные сведения см. в следующей документации:
Локальный шлюз данных
Локальный шлюз данных — это отдельный ресурс, который создается для того, чтобы рабочие процессы приложения логики могли получать доступ к локальным данным с помощью конкретных соединителей, поддерживаемых шлюзом. Ресурс шлюза не требует затрат, однако за операции, выполняемые через шлюз, взимается плата на основе цен и модели выставления счетов, используемой приложением логики.
Учетные записи службы интеграции
Учетная запись интеграции — это отдельный ресурс Azure, который создается в качестве контейнера для определения и хранения артефактов "бизнес — бизнес" (B2B), таких как торговые партнеры, соглашения, схемы, карты и т. д. После создания учетной записи и определения артефактов свяжите учетную запись с приложением логики, чтобы использовать эти артефакты и различные операции B2B в рабочих процессах для изучения, сборки и тестирования решений интеграции, использующих возможности EDI и XML-обработки.
В следующей таблице приведены сведения о том, как модели потребления и стандартные модели обрабатывают измерение и выставление счетов для учетных записей интеграции.
| Модель | Измерение и выставление счетов |
|---|---|
| Потребление (мультитенантное) | Измерение показателей и выставление счетов используют цены на учетную запись интеграции в зависимости от используемого уровня учетной записи. |
| Стандартный (один клиент) | Измерение показателей и выставление счетов используют цены на учетную запись интеграции в зависимости от используемого уровня учетной записи. |
Дополнительные сведения см. в следующей документации:
- Создание учетных записей интеграции и управление ими
- Ограничения учетной записи интеграции в Azure Logic Apps
Другие элементы, для которых не измеряются показатели и не осуществляется выставление счетов
Во всех моделях ценообразования не измеряются показатели и не осуществляется выставление счетов за следующие элементы.
- Действия, которые не были выполнены из-за того, что рабочий процесс остановился до его завершения
- Отключенные приложения логики или рабочие процессы, так как они не могут создавать новые экземпляры, пока они отключены.