Partager via


Fiabilité dans Azure Logic Apps

Cet article décrit la prise en charge de la fiabilité dans Azure Logic Apps, couvrant la résilience intrarégionale via des zones de disponibilité et des déploiements multirégions.

La résilience est une responsabilité partagée entre Microsoft et vous-même, donc cet article couvre également les moyens de vous permettant de créer une solution résiliente qui répond à vos besoins.

Les flux de travail d’application logique vous aident à intégrer et 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. Quand vous planifiez la résilience, veillez à ne pas prendre en compte que vos applications logiques, mais également ces ressources Azure que vous utilisez avec vos applications logiques :

Azure Logic Apps multilocataire gère automatiquement l’infrastructure de calcul et les ressources pour les flux de travail Consommation. Vous n’avez pas besoin de configurer ou de gérer des machines virtuelles. Les flux de travail Consommation partagent l’infrastructure de calcul entre de nombreux clients.

Azure Logic Apps à locataire unique exécute des flux de travail Standard sur des ressources de calcul dédiées, qui sont dédiées à vous et qui sont appelées plans. Chaque plan peut avoir plusieurs instances, et ces instances peuvent éventuellement être réparties entre plusieurs zones de disponibilité. Vos flux de travail s’exécutent sur des instances de votre plan.

Recommandations concernant le déploiement de production

Pour les flux de travail d’entreprise et sécurisés avec des exigences d’isolement ou de sécurité réseau, nous vous recommandons de créer et d’exécuter des flux de travail Standard dans Azure Logic Apps à locataire unique, plutôt que de consommer des flux de travail 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 à locataire unique, vous devez activer la redondance de zone pour répartir vos ressources d’application logique sur plusieurs zones de disponibilité.

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. Elles se corrigent d’elles-même après un court laps de temps. Il est important que vos applications gèrent 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 d’Azure lors de la communication avec les API, bases de données et autres composants hébergés dans le cloud. Pour en savoir plus sur la gestion des erreurs temporaires, consultez Recommandations pour la gestion des erreurs temporaires.

Dans Azure Logic Apps, de nombreux déclencheurs et actions prennent automatiquement en charge les stratégies de nouvelle tentative, qui retentent automatiquement les requêtes qui échouent en raison d’erreurs temporaires. Pour savoir comment modifier ou désactiver des stratégies de nouvelle tentative pour votre application logique, 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 plus d’informations sur la gestion des erreurs dans Azure Logic Apps, consultez Gérer les erreurs et les exceptions dans Azure Logic Apps.

Prise en charge des zones de disponibilité

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

Pour plus d’informations sur les zones de disponibilité dans Azure, consultez Que sont les zones de disponibilité ?.

Azure Logic Apps prend en charge la redondance de zone, qui répartit les ressources de calcul 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.

La redondance de zone est automatiquement activée pour les flux de travail d’application logique Consommation nouveaux et existants dans Azure Logic Apps multilocataire.

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 les environnements App Service v3 prennent en charge les zones de disponibilité, consultez Fiabilité dans App Service.

Régions prises en charge

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. Elle ne prend actuellement pas en charge les applications logiques redondantes interzone, car certains services de dépendance ne prennent pas encore en charge la redondance de zone.

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. Elle ne prend actuellement pas en charge les applications logiques redondantes interzone. Pour plus d’informations, consultez Fiabilité dans la Azure App Service.

Pour savoir quelles régions prennent en charge les zones de disponibilité pour App Service Environment v3, consultez Régions.

Spécifications

Vous devez déployer au moins trois instances de votre plan de service de flux de travail. Chaque instance correspond approximativement à une machine virtuelle. Pour distribuer ces instances (machines virtuelles) entre les zones de disponibilité, vous devez disposer d’un minimum de trois instances.

À propos de l’installation

Cost

Aucun coût supplémentaire ne s’applique à l’utilisation de la redondance de zone, qui est automatiquement activée pour les flux de travail Consommation nouveaux et existants dans Azure Logic Apps multilocataire.

Lorsque vous disposez de flux de travail 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é tant que vous avez trois instances ou plus du plan. Vous êtes facturé en fonction de la référence SKU de votre plan, de la capacité spécifiée et de toutes les instances pour lesquelles vous effectuez un scale-up ou un scale-down, en fonction de vos critères de mise à l’échelle automatique. Si vous activez les zones de disponibilité, mais que vous spécifiez une capacité de moins de trois instances, la plateforme applique les trois instances minimales et vous facture ces trois 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 un flux de travail avec redondance de zone.

    Pour activer la redondance de zone pour les flux de travail d’application logique Standard, consultez Activer la redondance de zone pour votre application logique.

  • Migration

    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ésactivez 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 à un échec de zone de disponibilité, envisagez de surapprovisionner la capacité de votre service. 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 connaître le nombre d’instances à surapprovisionner, il est important de savoir que la plateforme répartit les instances entre plusieurs zones. Vous devez prendre en compte au moins l’échec d’une zone.

Procédez comme suit pour déterminer le nombre total d’instances que vous devez approvisionner :

  1. Déterminez le nombre d’instances nécessaires à votre charge de travail maximale. Dans cet exemple, nous utilisons deux scénarios. L’un est avec 3 instances et l’autre est avec 4 instances.
  2. Récupérez le nombre d’instances en surapprovisionnement en multipliant le nombre d’instances de la charge de travail maximale par un facteur de [(zones/(zones-1)].
  3. Arrondissez le résultat au nombre entier supérieur le plus proche.

Remarque

Le tableau suivant suppose que vous utilisez trois zones de disponibilité. Si vous utilisez un autre nombre de zones de disponibilité, ajustez la formule en conséquence.

Nombre d’instances de la charge de travail maximale Facteur de [(zones/(zones-1)] Formule Instances à approvisionner (arrondi)
3 3/2 ou 1,5 (3 x 1,5 = 4,5) 5 instances
4 3/2 ou 1,5 (4 x 1.5 = 6) 6 instances

Routage du trafic entre les zones

Pendant les opérations normales, les appels de flux de travail peuvent utiliser des ressources de calcul dans l’une des zones de disponibilité de la région.

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é.

Expérience en cas de panne de zone

Détection et réponse : la plateforme Azure Logic Apps est responsable de la détection d’une panne dans une zone de disponibilité. Vous n’avez rien à faire pour lancer un basculement de zone.

Demandes actives : si une zone de disponibilité devient indisponible, les exécutions de flux de travail en cours qui s’exécutent sur une machine virtuelle dans la zone de disponibilité défectueuse sont arrêtées. La plateforme Azure Logic Apps 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.

Restauration automatique

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.

Test des défaillances de zone

La plateforme Azure Logic Apps gère le routage du trafic, le basculement et la restauration automatique 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 donc pas besoin de valider les processus d’échec de zone de disponibilité.

Prise en charge de plusieurs régions

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.

Autres approches multirégions

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 la documentation suivante :

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour Azure Logic Apps décrit la disponibilité attendue du service. Cet accord décrit également les conditions à respecter pour atteindre cette attente. Pour comprendre ces conditions, assurez-vous de passer en revue les contrats de niveau de service (SLA) pour les services en ligne.