Partager via

Fiabilité dans Azure Logic Apps

Azure Logic Apps vous permet d’intégrer et d’orchestrer plus facilement les données entre les applications, les services cloud et les systèmes locaux en réduisant la quantité de code que vous devez écrire.

Lorsque vous utilisez Azure, la fiabilité est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre les flux de travail d’application logique résilients à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il met également en évidence certaines informations clés sur le contrat de niveau de service Azure Logic Apps (SLA).

Recommandations de déploiement de production pour la fiabilité

Pour les charges de travail de production, nous vous recommandons de :

  • Pour les flux de travail d’entreprise et sécurisés avec des exigences d’isolation ou de sécurité réseau, créez et exécutez des flux de travail Standard dans Azure Logic Apps monolocataire, plutôt que des flux de travail consommation dans Azure Logic Apps multilocataire. Pour plus d’informations, consultez Créer et déployer dans différents environnements.
  • Pour les déploiements de production avec Azure Logic Apps monolocataire, activez la redondance de zone pour répartir vos ressources d’application logique sur plusieurs zones de disponibilité.

Vue d’ensemble de l’architecture de fiabilité

Cette section décrit certains des aspects importants du fonctionnement du service qui sont les plus pertinents du point de vue de la fiabilité. La section présente l’architecture logique, qui inclut certaines des ressources et fonctionnalités que vous déployez et utilisez. Il traite également de l’architecture physique, qui fournit des détails sur le fonctionnement du service sous les couvertures.

Architecture logique

La ressource principale que vous déployez est une application logique. Les applications logiques de consommation n’ont qu’un seul flux de travail, tandis que les applications logiques standard peuvent avoir plusieurs flux de travail. La plupart des flux de travail utilisent une ou plusieurs connexions pour accéder à d’autres applications, services et systèmes.

Si vous accédez aux données dans des systèmes locaux, vous pouvez déployer une passerelle de données locale. Chaque ressource de passerelle représente une installation de passerelle de données distincte sur un ordinateur local. Vous pouvez configurer une passerelle de données locale pour la haute disponibilité à l’aide de plusieurs ordinateurs. Pour en savoir plus, consultez Prise en charge de la haute disponibilité.

Lorsque vous utilisez Azure Logic Apps pour les scénarios d’intégration d’entreprise B2B (Business-to-Business), vous pouvez déployer des comptes d’intégration où vous définissez et stockez les artefacts utilisés par les flux de travail d’application logique.

Architecture physique

Pour les applications logiques consommation, Azure Logic Apps gère automatiquement l’infrastructure de calcul, le stockage d’état et d’autres ressources. Vous n’avez pas besoin de configurer ou de gérer des machines virtuelles. Les applications logiques de consommation partagent l’infrastructure de calcul entre de nombreux clients.

Pour les applications logiques standard, Azure Logic Apps utilise des ressources de calcul appelées Plans de service de flux de travail ou plans, qui sont dédiés à vous. Chaque plan peut avoir plusieurs instances, que vous pouvez éventuellement répartir entre plusieurs zones de disponibilité. Chaque instance est à peu près mappée à une machine virtuelle, mais vous ne voyez pas ces machines virtuelles et vous n’avez pas besoin de les configurer ou de les gérer directement. Vos workflows s’exécutent sur des instances de votre plan.

Les applications logiques standard nécessitent que vous configuriez le stockage pour conserver l’état des flux de travail à états. Pour plus d’informations, consultez Workflows avec et sans état.

Les applications logiques standard utilisent une infrastructure sous-jacente similaire à Azure Functions et Azure App Service. Toutefois, certaines différences existent dans la façon dont vous configurez des plans pour les applications logiques par rapport à d’autres services.

Pour plus d’informations, consultez Différences entre les applications logiques standard et les applications logiques consommation.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec toutes les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Dans Azure Logic Apps, de nombreux déclencheurs de flux de travail et actions prennent automatiquement en charge les stratégies de nouvelle tentative, qui réexécutent automatiquement les demandes qui échouent en raison d’erreurs temporaires. Pour plus d’informations sur la modification ou la désactivation des stratégies de nouvelle tentative, consultez Gérer les erreurs et les exceptions dans Azure Logic Apps.

Si une action échoue, vous pouvez personnaliser le comportement des actions suivantes. Vous pouvez également créer des étendues pour regrouper les actions associées susceptibles d’échouer ou de réussir ensemble.

Pour découvrir plus d’informations, consultez Gérer les erreurs et les exceptions dans Azure Logic Apps.

Résilience aux échecs de zone de disponibilité

Les zones de disponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Azure Logic Apps prend en charge la redondance de zone, qui répartit les ressources de calcul et l’état entre plusieurs zones de disponibilité. Lorsque vous distribuez des ressources de charge de travail d’application logique entre des zones de disponibilité, vous améliorez la résilience et la fiabilité de vos charges de travail d’application logique de production.

Les workflows d’application logique Consommation (nouveaux et existants) dans Azure Logic Apps mutualisé activent automatiquement la redondance de zone.

Azure Logic Apps prend en charge la redondance de zone, qui répartit les ressources de calcul entre plusieurs zones de disponibilité. Vous pouvez en option configurer la redondance de zone pour l’état dans lequel sont stockés vos flux de travail de l'application logique. Lorsque vous distribuez des ressources de charge de travail d’application logique entre des zones de disponibilité, vous améliorez la résilience et la fiabilité de vos charges de travail d’application logique de production.

Pour les flux de travail Standard avec l’option d’hébergement du plan de service de flux de travail dans Azure Logic Apps à locataire unique, vous pouvez éventuellement activer la redondance de zone.

Pour les flux de travail Standard avec l’option d’hébergement App Service Environment v3, vous pouvez éventuellement activer la redondance de zone. Pour plus d’informations sur la façon dont App Service Environment v3 prend en charge les zones de disponibilité, consultez Fiabilité dans App Service Environment.

Requirements

  • Prise en charge de la région : Les applications logiques de consommation déployées dans n’importe quelle région prenant en charge les zones de disponibilité sont automatiquement redondantes interzone. Japon Ouest est l’exception, qui ne prend actuellement pas en charge les applications logiques redondantes interzone, car certains services dépendants ne prennent pas encore en charge la redondance de zone.
  • Prise en charge de la région : Vous pouvez déployer des applications logiques standard redondantes interzone avec des plans de service de flux de travail dans n’importe quelle région prenant en charge les zones de disponibilité pour Azure App Service. Japon Ouest est l’exception, qui ne prend actuellement pas en charge les applications logiques redondantes interzone, car certains services dépendants ne prennent pas encore en charge la redondance de zone. Pour plus d’informations, consultez Fiabilité dans la Azure App Service.
  • Prise en charge des régions : pour voir quelles régions prennent en charge les zones de disponibilité pour App Service Environment v3, consultez Régions.
  • Nombre d’instances : vous devez déployer au moins deux instances de votre plan de service de flux de travail. Chaque instance correspond approximativement à une machine virtuelle. Par conséquent, pour distribuer ces instances (machines virtuelles) sur plusieurs zones de disponibilité, vous devez disposer de deux instances au minimum.

Considerations

Cost

Aucun coût supplémentaire ne s’applique à l’utilisation de la redondance de zone, qui est automatiquement activée pour les applications logiques de consommation nouvelles et existantes dans Azure Logic Apps multilocataire.

Lorsque vous disposez d’applications logiques standard avec le plan de service de flux de travail dans Azure Logic Apps à locataire unique, aucun coût supplémentaire ne s’applique à l’activation des zones de disponibilité si vous avez deux instances de plan ou plus. Vous êtes facturé en fonction de la référence SKU de votre plan, de la capacité spécifiée et des instances que vous ajustez en augmentant ou réduisant leur nombre, en fonction de vos critères de mise à l'échelle automatique. Si vous activez des zones de disponibilité, mais spécifiez moins de deux instances, la plateforme applique les deux instances minimales et vous facture ces deux instances.

App Service Environment v3 a un modèle de tarification spécifique pour la redondance de zone. Pour obtenir des informations de tarification pour App Service Environment v3, consultez Tarification.

Configurer la prise en charge des zones de disponibilité

Les flux de travail d’application logique de consommation prennent automatiquement en charge la redondance de zone, donc aucune configuration n’est requise.

  • Créez une application logique redondante interzone : pour activer la redondance de zone pour les applications logiques standard, consultez Activer la redondance de zone pour votre application logique.

  • Activer la redondance de zone sur une application logique existante : vous ne pouvez pas activer la redondance de zone après avoir créé un plan de service. Au lieu de cela, vous devez créer un plan avec la redondance de zone activée et supprimer l’ancien.

  • Désactiver la redondance de zone : vous ne pouvez pas désactiver la redondance de zone après avoir créé un plan de service de flux de travail. Au lieu de cela, vous devez créer un plan avec la redondance de zone désactivée et supprimer l’ancien.

Planification de capacité et gestion

Pour vous préparer à une défaillance de zone de disponibilité, envisagez de surprovisionner la capacité de votre plan. Le surapprovisionnement permet à la solution de tolérer un certain degré de perte de capacité et de continuer à fonctionner sans dégradation des performances. Pour plus d’informations, consultez Gérer la capacité avec le surapprovisionnement.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque les ressources d’application logique sont configurées pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

  • Routage du trafic entre les zones : pendant les opérations normales, les appels de flux de travail peuvent utiliser des ressources de calcul à partir de n’importe quelle zone de disponibilité de la région.

  • Réplication des données entre zones : pour les flux de travail avec état, l’état du flux de travail est répliqué de manière synchrone entre les zones de disponibilité à l’aide du stockage redondant interzone (ZRS).

  • Routage du trafic entre les zones : pendant les opérations normales, les appels de flux de travail sont répartis entre toutes vos instances de plan disponibles dans toutes les zones de disponibilité.

  • Réplication des données entre zones : pour les flux de travail avec état, l’état du flux de travail est stocké en fonction du stockage d’état que vous avez configuré. Lorsque vous utilisez Stockage Azure comme système de stockage externe, vous devez utiliser le stockage redondant interzone (ZRS), qui réplique de façon synchrone l’état du flux de travail entre les zones de disponibilité.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsqu’une panne de zone de disponibilité se produit pendant que les ressources d’application logique sont configurées pour la redondance de zone.

  • Détection et réponse : Azure Logic Apps est responsable de la détection d’un échec dans une zone de disponibilité. Vous n’avez rien à faire pour lancer un basculement de zone.
  • Notification : Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes Service Health pour vous avertir des problèmes.

  • Demandes actives : si une zone de disponibilité devient indisponible, Azure Logic Apps met fin à toutes les exécutions de flux de travail en cours qui s’exécutent sur une machine virtuelle dans la zone de disponibilité défectueuse. La plateforme reprend automatiquement le flux de travail sur une autre machine virtuelle dans une autre zone de disponibilité. En raison de ce comportement, les flux de travail actifs peuvent rencontrer des erreurs temporaires ou une latence plus élevée lorsque de nouvelles machines virtuelles sont ajoutées aux zones de disponibilité restantes.

  • Temps d’arrêt attendu : aucun temps d’arrêt n’est attendu dans Azure Logic Apps. Toutefois, si des dépendances existent sur d’autres services qui subissent un temps d’arrêt, votre application logique peut également être affectée.

  • Perte de données attendue : Aucune perte de données n’est attendue.

  • Réacheminement du trafic : le trafic entrant est automatiquement distribué à l’infrastructure dans des zones saines.
  • Comportements non liés à l'exécution : les flux de travail d'une application logique dans un plan redondant interzone continuent à fonctionner même si une zone de disponibilité rencontre une panne. Toutefois, il est possible que les comportements hors runtime soient toujours affectés pendant une panne de zone de disponibilité. Pour plus d’informations et pour obtenir la liste de ces comportements, consultez Fiabilité dans Azure App Service - Comportement lors d’une défaillance de zone.

Récupération de la zone

Lorsque la zone de disponibilité récupère, Azure Logic Apps crée automatiquement des instances dans la zone de disponibilité, supprime toutes les instances temporaires créées dans les autres zones de disponibilité et achemine le trafic entre vos instances normalement.

Tester les pannes de zone

Azure Logic Apps gère le routage du trafic, le basculement et la reprise pour les ressources d’application logique redondante interzone. Vous n’avez pas besoin de lancer quoi que ce soit. Cette fonctionnalité est entièrement gérée, vous n’avez ainsi pas besoin de valider la gestion des défaillances de zone de disponibilité.

Résilience aux défaillances à l’échelle de la région

Chaque application logique est déployée dans une seule région Azure. Si la région devient indisponible, votre application logique n’est pas disponible.

Solutions multirégions personnalisées pour la résilience

Pour une résilience plus élevée, vous pouvez déployer une application logique de secours ou de sauvegarde dans une région secondaire et basculer vers cette autre région si la région primaire n’est pas disponible. Pour activer cette fonctionnalité, procédez comme suit :

  • Déployez votre application logique dans les régions primaires et secondaires.
  • Reconfigurez les connexions aux ressources en fonction des besoins.
  • Configurez les stratégies d’équilibrage de charge et de basculement.
  • Planifiez la surveillance de l’intégrité de l’instance principale et lancez le basculement.

Pour plus d’informations sur les déploiements multirégions pour vos flux de travail d’application logique, consultez :

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour les services Azure décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les contrats SLA pour les services en ligne.

Contenu connexe

  • Last updated on