Справочник по ограничениям и конфигурации для Azure Logic Apps

Для рабочих процессов приложения логики потребления тот же параметр управляет максимальным количеством дней, которые может выполнять рабочий процесс и сохранять журнал выполнения в хранилище.

• В мультитенантных Azure Logic Apps ограничение по умолчанию 90 дней совпадает с максимальным ограничением. Это значение можно уменьшить.

• Хранение журнала выполнения всегда вычисляется с помощью времени начала выполнения и предельного срока хранения во время запуска, а не с текущим ограничением хранения.

Portal

1. В поле поиска на портале Azure откройте рабочий процесс приложения логики в конструкторе.

2. В меню приложения логики выберите параметры рабочего процесса.

3. В разделе "Параметры среды выполнения" в списке "Журнал выполнения" выберите "Настраиваемый".

4. Перетащите ползунок, чтобы изменить количество дней на нужное.

5. По завершении на панели инструментов параметров рабочего процесса нажмите кнопку "Сохранить".

ARM template

Если вы используете шаблон Azure Resource Manager, этот параметр отображается как свойство в определении ресурса вашего рабочего процесса, которое описано в Справочнике по шаблону рабочих процессов Microsoft.Logic:

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

Для рабочих процессов приложения логики уровня "Стандартный" можно уменьшить или увеличить ограничение по умолчанию на 90 дней, но необходимо добавить следующие параметры и их значения в ресурс приложения логики или проект:

• Параметр приложения с именем Workflows.RuntimeConfiguration.RetentionInDays

• Параметр узла с именем Runtime.FlowMaintenanceJob.RetentionCooldownInterval

По умолчанию для параметра приложения с именем Workflows.RuntimeConfiguration.RetentionInDays задано значение 90 дней данных. Параметр узла с именем Runtime.FlowMaintenanceJob.RetentionCooldownInterval устанавливается для проверки каждые 7 дней для удаления старых данных. Если вы оставляете эти значения по умолчанию, данные могут отображаться до 97 дней. Например, предположим, что Azure Logic Apps проверяет день X и удаляет данные старше дня X – 90 дней, а затем ожидает 7 дней, прежде чем выполняться снова. Такое поведение приводит к тому, что данные возрастом до 97 дней до выполнения задания снова. Однако если задать интервал 1 день, но оставьте дни хранения по умолчанию, максимальная задержка удаления старых данных составляет 90+1 дней.

Хранение журнала выполнения всегда вычисляется с помощью времени начала выполнения и предельного срока хранения во время запуска, а не с текущим ограничением хранения.

Portal

1. Выполните следующие действия, чтобы добавить параметр приложения с именем Workflows.RuntimeConfiguration.RetentionInDays и задать значение число дней, в течение которых требуется сохранить журнал выполнения рабочего процесса.

2. Выполните следующие действия, чтобы добавить параметр узла с именем Runtime.FlowMaintenanceJob.RetentionCooldownInterval, и задайте значение в качестве интервала между периодом между проверкой и удалением журнала выполнения, которые не нужно хранить.

Visual Studio Code

1. Выполните следующие действия, чтобы добавить параметр приложения с именем Workflows.RuntimeConfiguration.RetentionInDays и задать значение число дней, в течение которых требуется сохранить журнал выполнения рабочего процесса.

2. Выполните следующие действия, чтобы добавить параметр узла с именем Runtime.FlowMaintenanceJob.RetentionCooldownInterval, и задайте значение в качестве интервала между периодом между проверкой и удалением журнала выполнения, которые не нужно хранить.

В azure Logic Apps с одним клиентом ресурс приложения логики уровня "Стандартный" использует хранилище и вычисления в качестве основных ресурсов для выполнения рабочих процессов.

Storage

Рабочие процессы с отслеживанием состояния в azure Logic Apps с одним клиентом используют хранилище таблиц Azure для постоянного хранения данных во время выполнения, Хранилище BLOB-объектов Azure для обслуживания журналов выполнения рабочих процессов и хранилища очередей Azure для планирования. Например, одна учетная запись хранения позволяет обрабатывать значительное количество запросов с тарифами до 2000 запросов на секцию и 20 000 запросов в секунду на уровне учетной записи хранения. Хотя отдельная учетная запись хранения может обрабатывать достаточно высокую пропускную способность, помимо этих пороговых значений, скорость запросов зависит от регулирования, и рабочие процессы могут столкнуться с регулированием уровня секции или регулирования на уровне учетной записи по мере увеличения скорости выполнения рабочего процесса. Чтобы обеспечить плавность работы рабочих процессов, важно понимать возможные ограничения и способы их решения.

Дополнительные сведения о целевых объектах масштабирования и ограничениях для различных служб служба хранилища Azure см. в следующей документации:

• Целевые объекты масштабирования для хранилища таблиц
• Целевые объекты операций данных для хранилища таблиц
• Целевые объекты масштабирования для хранилища BLOB-объектов
• Целевые объекты масштабирования для хранилища очередей

Масштабирование приложения логики для ограничений хранилища

Следующие рекомендации применяются к рабочим процессам приложения логики уровня "Стандартный".

• Совместное использование рабочей нагрузки в нескольких рабочих процессах.

  Azure Logic Apps с одним клиентом уже сводит к минимуму регулирование на уровне секций путем распределения транзакций хранилища между несколькими секциями. Однако для улучшения распределения и устранения регулирования на уровне секций распределяйте рабочую нагрузку между несколькими рабочими процессами, а не полагаться на один рабочий процесс.

• Совместное использование рабочей нагрузки между несколькими учетными записями хранения.

  Если рабочие процессы требуют высокой пропускной способности, можно значительно увеличить пропускную способность, распределяя рабочую нагрузку по нескольким учетным записям хранения, а не полагаться на одну учетную запись хранения. Вы можете настроить ресурс приложения логики уровня "Стандартный" для использования до 32 учетных записей хранения в качестве ограничения. Чтобы определить количество необходимых учетных записей хранения, используйте общую инструкцию по поиску около 100 000 операций в минуту для каждой учетной записи хранения. Хотя эта оценка работает хорошо для большинства сценариев, можно использовать более низкое количество выполнений действий, если действия рабочего процесса являются вычислительными большими, например действие запроса, обрабатывающее большие массивы данных. Убедитесь, что вы выполняете нагрузочное тестирование и настраиваете решение перед использованием в рабочей среде.

  Чтобы включить использование нескольких учетных записей хранения, выполните следующие действия перед созданием приложения логики "Стандартный". В противном случае при изменении параметров после создания может возникнуть потеря данных или не достичь необходимой масштабируемости.

  1. Создайте учетные записи хранения, которые вы хотите использовать. Сохраните строка подключения для каждой учетной записи хранения.

  2. Найдите и откройте приложение логики уровня "Стандартный", а затем измените параметры узла приложения логики (host.json файл), чтобы включить следующий extensions объект, содержащий workflow и settings объекты с параметром Runtime.ScaleUnitsCount :

     "extensions": {
         "workflow": {
             "settings": {
                 "Runtime.ScaleUnitsCount": "<storage-accounts-number>"
             }
         }
     }
     

     В следующем примере указано 3 в качестве количества учетных записей хранения:

     {
         "version": "2.0",
         "extensionBundle": {
             "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
             "version": "[1.*, 2.0.0)"
         },
         "extensions": {
             "workflow": {
                 "settings": {
                     "Runtime.ScaleUnitsCount": "3"
                 }
             }
         }
     }
     

  3. Измените параметры конфигурации приложения логики (local.settings.json), чтобы добавить параметр приложения с именем CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0storage-account-number<.> ConnectionString и соответствующая учетная запись хранения строка подключения с помощью следующего синтаксиса, где первый номер учетной записи хранения составляет 00 до числа учетных записей хранения минус 1, например:

     Имя параметра приложения	Value
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString	<connection-string-1>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU01.ConnectionString	<connection-string-2>
     CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU02.ConnectionString	<connection-string-3>

     Important

     Если у вас есть конфиденциальная информация, например строка подключения, включающих имена пользователей и пароли, обязательно используйте самый безопасный поток проверки подлинности. Например, в рабочих процессах приложения логики "Стандартный" безопасные типы данных, например securestring и secureobjectне поддерживаются. Корпорация Майкрософт рекомендует пройти проверку подлинности доступа к ресурсам Azure с помощью управляемого удостоверения , если это возможно, и назначить роль с минимальными привилегиями.

     Если эта возможность недоступна, обязательно защитите строка подключения с помощью других мер, таких как Azure Key Vault, которые можно использовать с параметрами приложения. Потом можно напрямую ссылаться на такие защищенные строки, как строки подключения и ключи. Аналогично шаблонам ARM, где переменные среды определяют в процессе развертывания, настройки приложения можно задать в рамках определения рабочего процесса приложения логики. Затем можно захватывать динамически генерируемые значения инфраструктуры, такие как конечные точки подключения, строки хранения и другие. Дополнительные сведения см. в разделе "Типы приложений" для платформа удостоверений Майкрософт.

  4. В параметрах конфигурации приложения логики обновите значение параметра AzureWebJobsStorage с той же строкой подключения, которая находится в параметре CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString .

Compute

Приложение логики уровня "Стандартный" выполняется с помощью одного из доступных планов вычислений, которые предоставляют различные уровни виртуального ЦП и памяти или с помощью Среда службы приложений версии 3, которая предоставляет дополнительные возможности вычислений.

Azure Logic Apps с одним клиентом динамически масштабируется, чтобы эффективно обрабатывать увеличение нагрузки. Приложение логики использует следующие основные факторы, чтобы определить, следует ли масштабировать.

• Trigger

  Чтобы определить требования к масштабированию, масштабировщик анализирует триггер, который запускает каждый рабочий процесс в приложении логики. Например, для рабочего процесса с триггером служебная шина, если длина очереди постоянно растет, масштабировщик принимает меры для добавления рабочих экземпляров, что позволяет обрабатывать больше сообщений. Аналогичным образом, для рабочего процесса с триггером запроса, если задержка запроса испытывает восходящую тенденцию, масштабировщик увеличивает количество рабочих экземпляров для более эффективного распределения нагрузки запроса. Дополнительные сведения о рабочих экземплярах см. в статье Azure Logic Apps (цен. категория "Стандартный") — подробное изучение среды выполнения.

• Задержка выполнения задания рабочего процесса

  Во время выполнения действия рабочего процесса делятся на отдельные задания, которые помещаются в очередь для выполнения. Диспетчеры заданий регулярно опрашивать очередь заданий для получения и выполнения этих заданий. Однако если вычислительные ресурсы недостаточно для сбора этих заданий, они остаются в очереди в течение длительного времени, что приводит к увеличению задержек выполнения. Масштабировщик отслеживает эту ситуацию и принимает решения о масштабировании, чтобы сохранить задержки выполнения под контролем. Дополнительные сведения о расписании и выполнении заданий среды выполнения см. в статье Azure Logic Apps (стандартный) — глубокое изучение среды выполнения.

  Масштабировщик также рассматривает минимальную и максимальную конфигурацию счетчика рабочих экземпляров, чтобы определить, следует ли принимать решения по масштабированию, например добавлять, удалять или поддерживать текущее число рабочих экземпляров. Как правило, масштабировщик принимает эти решения через интервалы примерно в 15–30 секунд. Таким образом, рассмотрим это увеличение времени и его влияние на скорость масштабирования приложения логики, чтобы эффективно обрабатывать пиковые нагрузки. Например, если для рабочей нагрузки требуется масштабирование приложения логики с всего 1 экземпляра рабочей роли до 100 рабочих экземпляров, одно увеличение может занять 25–50 минут. Масштабирование Azure Logic Apps с одним клиентом использует одну и ту же Функции Azure инфраструктуру масштабирования.

Настройка вычислений приложения логики для ускорения масштабирования

• Совместное использование рабочей нагрузки в нескольких приложениях логики.

  Каждое приложение логики может масштабироваться независимо, поэтому распределение рабочей нагрузки в нескольких приложениях логики может значительно ускорить масштабирование. Например, два приложения логики могут масштабироваться до два раза больше числа рабочих экземпляров в одном и том же интервале времени, что и одно приложение логики. Разбив рабочую нагрузку между несколькими приложениями, вы можете эффективно умножить масштабируемость и ускорить масштабирование.

• Используйте предварительно подготовленные экземпляры.

  Если в вашем сценарии требуется более быстрое время увеличения, рассмотрите возможность использования предварительно подготовленных экземпляров. Если время пиковой нагрузки детерминировано, можно использовать задачу автоматизации, чтобы настроить эти предварительно подготовленные экземпляры по расписанию. Дополнительные сведения см. в статье "Управление ресурсами Azure" и мониторинг затрат путем создания задач автоматизации (предварительная версия).

Мультитенантное приложение Azure Logic Apps имеет ограничение по умолчанию на количество действий, выполняемых каждые 5 минут. Чтобы увеличить значение по умолчанию до максимального значения, можно включить режим высокой пропускной способности, который находится в предварительной версии. Или распределите рабочую нагрузку между несколькими приложениями логики и рабочими процессами, а не на основе одного приложения логики и рабочего процесса.

Включение высокой пропускной способности на портале

1. На портале Azure в меню приложения логики в разделе "Параметры" выберите параметры рабочего процесса.

2. В разделе параметров> среды выполнениявысокая пропускная способность измените значение "Вкл.".

   

Включение высокой пропускной способности в шаблоне Resource Manager

Чтобы включить этот параметр в шаблоне ARM для развертывания приложения логики, в propertiesобъекте для определения ресурса приложения логикиruntimeConfiguration добавьте объект со operationOptionsсвойством, имеющим значениеOptimizedForHighThroughput:

{
   <template-properties>
   "resources": [
      // Start logic app resource definition
      {
         "properties": {
            <logic-app-resource-definition-properties>,
            <logic-app-workflow-definition>,
            <more-logic-app-resource-definition-properties>,
            "runtimeConfiguration": {
               "operationOptions": "OptimizedForHighThroughput"
            }
         },
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {},
         "apiVersion": "2016-06-01",
         "dependsOn": [
         ]
      }
      // End logic app resource definition
   ],
   "outputs": {}
}

Дополнительные сведения об определении ресурсов приложения логики см. в разделе Обзор. Автоматизация развернутой службы для Azure Logic Apps с помощью шаблонов Azure Resource Manager.