Limites et références de configuration pour Azure Logic Apps

Pour les workflows d’application logique Consommation, le même paramètre contrôle le nombre maximal de jours pendant lesquels un workflow peut s’exécuter et durant lesquels l’historique des exécutions peut être conservé dans le stockage.

• Dans Azure Logic Apps multilocataire, la limite par défaut de 90 jours est identique à la limite maximale. Vous pouvez uniquement réduire cette valeur.

Par exemple, supposons que vous réduisiez la limite de conservation de 90 à 30 jours. Une exécution datant de 60 jours est supprimée de l’historique des exécutions. Si vous augmentez la période de conservation de 30 à 60 jours, une exécution datant de 20 jours reste dans l’historique des exécutions pendant 40 jours supplémentaires.

Portail

1. À partir de la zone de recherche du portail Azure, ouvrez votre workflow d’application logique dans le concepteur.

2. Dans le menu de l’application logique, sélectionnez Paramètres de workflow.

3. Sous Options de runtime, dans la liste Conservation de l’historique des exécutions en jours, choisissez Personnalisée.

4. Faites glisser le curseur pour modifier le nombre de jours souhaité.

5. Lorsque vous avez terminé, dans la barre d’outils Paramètres du workflow, sélectionnez Enregistrer.

Modèle ARM

Si vous utilisez un modèle Azure Resource Manager, ce paramètre apparaît sous forme de propriété dans la définition de ressource de votre workflow, comme décrit dans Informations de référence sur le modèle de workflow 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}
         }
      }
   }
}

Pour les workflows d’application logique Standard, vous pouvez réduire ou augmenter la limite par défaut de 90 jours, mais vous devez ajouter les paramètres suivants et leurs valeurs à votre ressource ou projet d’application logique :

• Un paramètre d’application nommé Workflows.RuntimeConfiguration.RetentionInDays

• Un paramètre d’hôte nommé Runtime.FlowMaintenanceJob.RetentionCooldownInterval

Par défaut, le paramètre d’application nommé Workflows.RuntimeConfiguration.RetentionInDays est défini pour conserver 90 jours de données. Le paramètre d’hôte nommé Runtime.FlowMaintenanceJob.RetentionCooldownInterval est défini pour vérifier tous les 7 jours s’il y a des données anciennes à supprimer. Si vous conservez ces valeurs par défaut, vous pouvez voir jusqu’à 97 jours de données conservées. Par exemple, supposons qu’Azure Logic Apps lance une vérification le jour X et supprime les données datant de plus de 90 jours avant ce jour X, puis attende 7 jours avant d’effectuer une nouvelle vérification. Ce comportement entraîne un délai de conservation des données pouvant aller jusqu’à 97 jours avant que le travail ne s’exécute à nouveau. En revanche, si vous définissez l’intervalle à 1 jour, mais que vous laissez le nombre de jours de conservation des données à la valeur par défaut, le délai maximal avant la suppression des anciennes données est de 90+1 jours.

Portail

1. Effectuez ces étapes pour ajouter le paramètre d’application nommé Workflows.RuntimeConfiguration.RetentionInDays et définir sa valeur sur le nombre de jours pendant lesquels vous souhaitez conserver l’historique des exécutions de votre workflow.

2. Effectuez ces étapes pour ajouter le paramètre d’hôte nommé Runtime.FlowMaintenanceJob.RetentionCooldownInterval et définir sa valeur sur l’intervalle (en jours) entre la vérification et la suppression de l’historique des exécutions que vous ne souhaitez pas conserver.

Visual Studio Code

1. Effectuez ces étapes pour ajouter le paramètre d’application nommé Workflows.RuntimeConfiguration.RetentionInDays et définir sa valeur sur le nombre de jours pendant lesquels vous souhaitez conserver l’historique des exécutions de votre workflow.

2. Effectuez ces étapes pour ajouter le paramètre d’hôte nommé Runtime.FlowMaintenanceJob.RetentionCooldownInterval et définir sa valeur sur l’intervalle (en jours) entre la vérification et la suppression de l’historique des exécutions que vous ne souhaitez pas conserver.

Dans Azure Logic Apps à locataire unique, une ressource d’application logique standard utilise le stockage et le calcul comme ressources principales pour exécuter des flux de travail.

Stockage

Les flux de travail avec état dans Azure Logic Apps à locataire unique utilisent Stockage Table Azure pour le stockage de données persistant pendant l’exécution, Stockage Blob Azure pour gérer les historiques d’exécution des flux de travail et stockage File d’attente Azure à des fins de planification. Par exemple, un compte de stockage unique permet de gérer un nombre important de requêtes avec des taux allant jusqu’à 2 000 requêtes par partition et 20 000 requêtes par seconde au niveau du compte de stockage. Bien qu’un compte de stockage unique puisse gérer un débit raisonnablement élevé, au-delà de ces seuils, les taux de requête sont soumis à une limitation et vos flux de travail peuvent rencontrer une limitation au niveau de la partition ou une limitation au niveau du compte à mesure que le taux d’exécution du flux de travail augmente. Pour vous assurer que vos flux de travail fonctionnent en douceur, il est essentiel que vous compreniez les limitations possibles et les façons dont vous pouvez les traiter.

Pour plus d’informations sur la mise à l’échelle des cibles et des limitations pour les différents services Stockage Azure, consultez la documentation suivante :

• Cibles de mise à l’échelle pour le stockage table
• Cibles d’opération de données pour le stockage table
• Cibles de mise à l’échelle pour le stockage Blob
• Cibles de mise à l’échelle pour le stockage file d’attente

Mettre à l’échelle votre application logique pour les limitations de stockage

Les recommandations suivantes s’appliquent à la mise à l’échelle des flux de travail d’application logique Standard :

• Partagez la charge de travail entre plusieurs flux de travail.

  Azure Logic Apps à locataire unique réduit déjà la limitation au niveau de la partition en distribuant des transactions de stockage sur plusieurs partitions. Toutefois, pour améliorer la distribution et atténuer la limitation au niveau de la partition, distribuez la charge de travail sur plusieurs flux de travail, plutôt que de vous appuyer sur un seul flux de travail.

• Partagez la charge de travail entre plusieurs comptes de stockage.

  Si vos flux de travail nécessitent un débit élevé, vous pouvez augmenter considérablement le débit en répartissant la charge de travail sur plusieurs comptes de stockage, plutôt que de vous appuyer sur un seul compte de stockage. Vous pouvez configurer votre ressource d’application logique Standard pour utiliser jusqu’à 32 comptes de stockage comme limite. Pour déterminer le nombre de comptes de stockage dont vous avez besoin, utilisez l’orientation générale de la recherche d’environ 100 000 exécutions d’actions par minute, par compte de stockage. Bien que cette estimation fonctionne bien pour la plupart des scénarios, vous pouvez utiliser un nombre inférieur d’exécutions d’actions si vos actions de flux de travail sont lourdes, par exemple une action de requête qui traite des tableaux de données volumineux. Veillez à effectuer des tests de charge et à régler votre solution avant d’utiliser en production.

  Pour activer l’utilisation de plusieurs comptes de stockage, procédez comme suit avant de créer votre application logique Standard. Sinon, si vous modifiez les paramètres après la création, vous pouvez rencontrer une perte de données ou ne pas atteindre l’extensibilité nécessaire.

  1. Créez les comptes de stockage que vous souhaitez utiliser. Enregistrez le chaîne de connexion pour chaque compte de stockage.

  2. Recherchez et ouvrez votre application logique Standard, puis modifiez les paramètres d’hôte de votre application logique (fichier host.json) pour inclure l’objet suivantextensions, qui contient les objets et settings les workflow objets avec le paramètre Runtime.ScaleUnitsCount :

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

     L’exemple suivant spécifie 3 comme nombre de comptes de stockage :

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

  3. Modifiez les paramètres de configuration d’application de votre application logique (local.settings.json) pour ajouter un paramètre d’application nommé CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU0<storage-account-number>. ConnectionString et le compte de stockage correspondant chaîne de connexion à l’aide de la syntaxe suivante, où le premier numéro de compte de stockage est 00 jusqu’au nombre de comptes de stockage moins 1, par exemple :

     Nom du paramètre d’application	Valeur
     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

     Quand vous avez des informations sensibles, comme des chaînes de connexion qui incluent des noms d’utilisateur et des mots de passe, veillez à utiliser le flux d’authentification le plus sécurisé disponible. Par exemple, dans les workflows d’applications logiques Standard, les types de données sécurisés tels que securestring et secureobject ne sont pas pris en charge. Microsoft vous recommande d’authentifier l’accès aux ressources Azure avec une identité managée quand c’est possible et d’attribuer un rôle disposant du privilège minimum nécessaire.

     Si cette fonctionnalité n’est pas disponible, veillez à sécuriser les chaînes de connexion via d’autres mesures, comme Azure Key Vault, que vous pouvez utiliser avec des paramètres d’application. Vous pouvez ensuite référencer directement des chaînes sécurisées, telles que des chaînes de connexion et des clés. Comme pour les modèles ARM, où vous pouvez définir des variables d’environnement au moment du déploiement, vous pouvez définir des paramètres d’application dans la définition de workflow de votre application logique. Vous pouvez ensuite capturer des valeurs d’infrastructure générées dynamiquement, comme des points de terminaison de connexion, des chaînes de stockage, etc. Pour plus d’informations, consultez Types d’application pour la plateforme d’identités Microsoft.

  4. Dans les paramètres de configuration de l’application de votre application logique, mettez à jour la valeur du paramètre AzureWebJobsStorage avec la même chaîne de connexion dans le paramètre CloudStorageAccount.Workflows.ScaleUnitsDataStorage.CU00.ConnectionString.

Compute

Une application logique standard s’exécute à l’aide de l’un des plans de calcul disponibles, qui fournissent différents niveaux de processeur virtuel et de mémoire, ou à l’aide d’un environnement App Service v3, qui fournit plus d’options de calcul.

Azure Logic Apps à locataire unique est mis à l’échelle dynamiquement pour gérer efficacement les charges croissantes. Votre application logique utilise les facteurs principaux suivants pour déterminer s’il faut effectuer une mise à l’échelle.

• Déclencheur

  Pour déterminer les exigences de mise à l’échelle, le scaler analyse le déclencheur qui démarre chaque workflow dans votre application logique. Par exemple, pour un flux de travail avec un déclencheur Service Bus, si la longueur de la file d’attente augmente en continu, le scaler prend des mesures pour ajouter des instances de travail, ce qui permet de traiter davantage de messages. De même, pour un flux de travail avec un déclencheur de requête, si la latence de la requête connaît une tendance à la hausse, le scaler augmente le nombre d’instances de travail pour distribuer la charge de requête plus efficacement. Pour plus d’informations sur les instances de travail, consultez Azure Logic Apps (Standard) - Runtime Deep Dive.

• Délai d’exécution du travail de flux de travail

  Au moment de l’exécution, les actions de flux de travail sont divisées en travaux individuels mis en file d’attente pour l’exécution. Les répartiteurs de travaux interrogent régulièrement la file d’attente de travaux pour récupérer et exécuter ces travaux. Toutefois, si la capacité de calcul est insuffisante pour récupérer ces travaux, ils restent dans la file d’attente pendant plus longtemps, ce qui entraîne des retards d’exécution accrus. Le scaler surveille cette situation et prendre des décisions de mise à l’échelle pour maintenir les retards d’exécution sous contrôle. Pour plus d’informations sur la façon dont le runtime planifie et exécute des travaux, consultez Azure Logic Apps (Standard) - Runtime Deep Dive.

  Le scaler prend également en compte la configuration minimale et maximale du compteur d’instances de travail pour déterminer s’il faut prendre des décisions de mise à l’échelle, telles que l’ajout, la suppression ou la maintenance du nombre actuel d’instances de travail. En règle générale, le scaler prend ces décisions à intervalles d’environ 15 à 30 secondes. Prenons donc ce temps d’accélération et son impact sur la vitesse de mise à l’échelle de votre application logique pour gérer efficacement les pics de charge. Par exemple, si votre charge de travail nécessite une mise à l’échelle de votre application logique de seulement 1 instance de travail vers 100 instances de travail, la montée en puissance seule peut prendre 25 à 50 minutes. La mise à l’échelle d’Azure Logic Apps à locataire unique partage la même infrastructure de mise à l’échelle d’Azure Functions.

Configurer votre calcul d’application logique pour accélérer la mise à l’échelle

• Partagez la charge de travail entre plusieurs applications logiques.

  Chaque application logique peut être mise à l’échelle indépendamment, de sorte que la distribution de votre charge de travail sur plusieurs applications logiques peut accélérer considérablement la vitesse de mise à l’échelle. Par exemple, deux applications logiques peuvent être mises à l’échelle à deux fois le nombre d’instances de travail dans la même période qu’une application logique unique. En fractionnant votre charge de travail entre plusieurs applications, vous pouvez multiplier efficacement l’extensibilité et obtenir des résultats de mise à l’échelle plus rapides.

• Utilisez des instances prédéfinies.

  Si votre scénario nécessite une accélération plus rapide, envisagez d’utiliser des instances prédéfinies. Si vos pics de charge sont déterministes, vous pouvez utiliser une tâche d’automatisation pour ajuster ces instances préliminaires selon une planification. Pour plus d’informations, consultez Gérer les ressources Azure et surveiller les coûts en créant des tâches Automation (préversion).

Azure Logic Apps multilocataire a une limite par défaut sur le nombre d’actions qui s’exécutent toutes les 5 minutes. Pour élever la valeur par défaut à la valeur maximale, vous pouvez activer le mode débit élevé, qui est en préversion. Ou, distribuez la charge de travail entre plusieurs applications logiques et flux de travail, plutôt que de vous appuyer sur une application logique unique et un flux de travail.

Activer un débit élevé dans le portail

1. Sur le portail Azure, dans le menu de votre application logique, sélectionnez Paramètres, puis Paramètres de workflow.

2. Sous Options d’exécution>Débit élevé, activez le paramètre.

   

Activer un débit élevé dans un modèle Resource Manager

Pour activer ce paramètre dans un modèle ARM pour le déploiement de votre application logique, dans l’objet properties de la définition de ressource de votre application logique, ajoutez l’objet runtimeConfiguration avec la propriété operationOptions définie sur 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": {}
}

Pour plus d’informations sur la définition de ressource de votre application logique, consultez Présentation : Automatiser le déploiement pour le service Azure Logic Apps à l’aide de modèles Resource Manager.