Fiabilité dans les applications de conteneur Azure

Azure Container Apps est un service d’hébergement de conteneurs serverless entièrement managé pour le déploiement de microservices et d’applications conteneurisées.

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 Container Apps résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité, les pannes de région et la maintenance du service. Il décrit également comment utiliser des sauvegardes pour récupérer à partir d’autres types de problèmes et met en évidence des informations clés sur le contrat de niveau de service Container Apps (SLA).

Recommandations concernant le déploiement de production

Pour savoir comment déployer Container Apps pour prendre en charge les exigences de fiabilité de votre solution et comment la fiabilité affecte d’autres aspects de votre architecture, consultez les meilleures pratiques d’architecture pour Container Apps dans Azure Well-Architected Framework.

Vue d’ensemble de l’architecture de fiabilité

Lorsque vous utilisez Container Apps, vous déployez un environnement qui sert d’unité de déploiement de base et définit une limite sécurisée autour d’un groupe d’applications conteneur. L’environnement est l’endroit où vous configurez les paramètres principaux, notamment la prise en charge de la zone de disponibilité et la configuration réseau. Les deux types d'environnements sont les environnements de profils de charge de travail et les environnements uniquement de consommation. Pour plus d’informations, consultez Les structures de calcul et de facturation dans Container Apps.

Vous pouvez déployer plusieurs applications dans un seul environnement. Chaque application exécute un ou plusieurs conteneurs. Un environnement peut également exécuter un ou plusieurs travaux, qui représentent des tâches non interactives. Pour plus d’informations, consultez Conteneurs dans Container Apps et Travaux dans Container Apps.

Chaque application a un ou plusieurs réplicas, qui représentent les instances en cours d’exécution de l’application. Vous pouvez contrôler la mise à l’échelle de votre application, y compris le nombre minimal et maximal de réplicas et la façon dont l’application ajoute et supprime dynamiquement des réplicas. Le planificateur de plateforme garantit une distribution optimale entre les hôtes physiques tout en répondant à vos exigences minimales en matière de nombre de réplicas. Pour des informations supplémentaires, consultez Définir des règles de mise à l'échelle dans Container Apps.

Container Apps prend en charge la fiabilité de vos applications à l’aide de différentes fonctionnalités :

• Surveillance automatique de l'intégrité : le contrôleur d'entrée intégré équilibre automatiquement la charge du trafic entre les répliques saines. Si une réplique échoue aux contrôles d’intégrité ou si son infrastructure sous-jacente n’est plus disponible pendant une période prolongée, le service redémarre automatiquement les conteneurs en échec ou crée des répliques de remplacement. Il redirige aussi le trafic loin des répliques non saines et gère les nouvelles tentatives de mise en réseau dans le cluster. Ce processus de récupération automatique ne nécessite aucune intervention du client et gère votre nombre de réplicas spécifié. Pour plus d’informations, veuillez consulter la section Sondes d’intégrité.

• Résilience des applications via Dapr : Container Apps fournit une intégration étroite avec Dapr, qui est une infrastructure qui prend en charge les microservices de niveau production et les applications conteneurisées. Dapr inclut des fonctionnalités qui aident à améliorer la résilience, notamment la gestion des défaillances dans d’autres services. Pour plus d’informations, consultez Microservices avec des applications conteneurisées.

• Résilience de l’infrastructure pour les composants système : Cette résilience inclut le plan de contrôle, les contrôleurs d’entrée et le runtime de conteneur. Dans les régions qui ont des zones de disponibilité, Container Apps fournit une redondance zonale. Pour plus d’informations, consultez Résilience aux échecs de zone de disponibilité.

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.

Container Apps gère automatiquement de nombreuses erreurs temporaires par le biais de ses mécanismes de reprise automatique au niveau de la plateforme et de la surveillance de l’état de santé. Pour vous assurer que vos applications sont résilientes aux erreurs temporaires, effectuez les actions suivantes :

• Configurez des sondes d’intégrité qui permettent à la plateforme de détecter et de répondre aux conditions d’échec spécifiques à l’application. Définissez les seuils d’échec appropriés et les valeurs de délai d’expiration en fonction des caractéristiques de démarrage de votre application. Par exemple, pour prévenir des redémarrages anticipés des conteneurs lors de problèmes temporaires, utilisez un seuil d'échec de 3 avec une période de 10 secondes pour les sondes de vivacité. Pour plus d’informations, veuillez consulter la section Sondes d’intégrité.

• Utilisez les stratégies de résilience de la découverte des services (version préliminaire) pour prévenir, détecter et récupérer de manière proactive les échecs des demandes de service. Par exemple, lorsque vous utilisez une stratégie de résilience, chaque demande entrante à l’application peut automatiquement être retentée en cas d’erreur temporaire qui empêche l’application de répondre. Pour plus d’informations, consultez Résilience de la découverte de services (préversion).

• Implémentez une logique de nouvelle tentative dans vos applications pour les appels de service externes, les connexions de base de données et les demandes d’API.

  Si votre application utilise Dapr pour s’intégrer aux services cloud, utilisez la robustesse des composants Dapr (préversion) pour configurer les réessais, les délais d’attente et les disjoncteurs.

  Pour les autres dépendances, votre application doit gérer les erreurs temporaires. Utilisez des stratégies d’interruption exponentielle et des modèles de disjoncteur lors de l’appel de services externes pour empêcher les défaillances en cascade pendant les interruptions de service en aval. Les fonctionnalités intégrées de découverte de service et d’équilibrage de charge Container Apps acheminent automatiquement le trafic loin des instances défaillantes, mais vos stratégies de nouvelle tentative au niveau de l’application garantissent une gestion appropriée des problèmes temporaires avant que les contrôles d’intégrité au niveau de la plateforme déclenchent le redémarrage du conteneur.

• Concevoir des tâches conçues pour résister aux erreurs temporaires, y compris les échecs lors de l’exécution des tâches ou dans celles de leurs dépendances. Concevez vos travaux de manière à reprendre le travail s’ils sont redémarrés, ou optez pour une conception idempotente afin qu’ils puissent être réexécutés en toute sécurité.

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.

Lorsque vous créez un environnement Container Apps, vous pouvez activer la redondance de zone pour distribuer l’infrastructure sous-jacente sur plusieurs zones de disponibilité dans la région Azure choisie. Container Apps programme automatiquement les réplicas de vos applications entre les zones. Cette distribution se produit de manière transparente, ce qui signifie que vous n'avez pas besoin de spécifier l'emplacement des zones pour les répliques individuelles.

La redondance de zone améliore la résilience de votre application aux défaillances au niveau de la zone en vous assurant que les réplicas de votre application conteneur sont répartis entre plusieurs zones.

Le diagramme suivant illustre une application conteneurisée redondante par zone bénéficiant de trois répliques. Chaque réplica s’exécute dans une zone de disponibilité distincte.

Spécifications

• Vérifiez la prise en charge des régions. La redondance de zone est disponible dans toutes les régions qui prennent en charge les Container Apps et les zones de disponibilité.

  Pour voir quelles régions prennent en charge les zones de disponibilité, consultez les régions Azure avec prise en charge des zones de disponibilité.

  Pour voir quelles régions prennent en charge Container Apps, consultez la disponibilité des produits par région.

• Utilisez des profils de charge de travail. La redondance de zone s'applique à tous les plans d'applications Container Apps, y compris les profils de charge de travail à la consommation et dédiés.

• Activez la redondance de zone pendant la création de l’environnement. Ce paramètre ne peut pas être modifié une fois l’environnement créé.

• Déployez un environnement Container Apps dans un réseau virtuel. Le réseau virtuel doit se trouver dans une région qui prend en charge les zones de disponibilité. Vérifiez que le réseau virtuel dispose d’un sous-réseau de taille adéquate. Les environnements à la consommation uniquement requièrent un sous-réseau avec une plage CIDR (Classless Inter-Domain Routing) /23 ou supérieure, et les environnements de profils de charge de travail nécessitent une plage CIDR /27 ou supérieure.

• Définissez votre nombre minimal de réplicas sur au moins deux pour garantir la distribution entre plusieurs zones de disponibilité. Envisagez de définir un nombre minimal de réplicas plus élevé si l’une des conditions suivantes s’applique :

  • Votre charge maximale attendue nécessite plus de deux répliques.

  • Vous devez être résilient à plusieurs pannes de zone simultanées.

  • Vous souhaitez limiter autant que possible le temps d'attente pour la création de nouveaux réplicas dans d'autres zones lors d'une panne de zone.

Coûts

Vous n’entraînez pas de frais supplémentaires au-delà de la tarification standard de Container Apps lorsque vous activez la redondance de zone. Vous payez les mêmes tarifs pour les ressources de calcul, les requêtes et les secondes vCore, que la redondance de zone soit activée ou non. Pour plus d’informations, consultez la tarification de Container Apps et la facturation de Container Apps.

Configurez la prise en charge des zones de disponibilité

• Créez un environnement Container Apps avec redondance de zones. Pour obtenir des instructions de déploiement qui couvrent le portail Azure, Azure CLI et Azure PowerShell, consultez Créer une application conteneur redondante interzone.

• Migrez vers un déploiement redondant par zone. Vous ne pouvez pas activer la redondance de zone sur un environnement Container Apps existant. Pour mettre à niveau des environnements existants qui ne sont pas redondants interzone, créez un environnement avec la redondance de zone activée dans une région prise en charge. Redéployez ensuite vos applications conteneur.

• Désactivez la redondance de zone. La redondance de zone ne peut pas être désactivée après son activation lors de la création de l’environnement. Si vous avez besoin d’un déploiement non redondant interzone, vous devez créer un environnement sans activer l’option de redondance de zone ou déployer dans une région qui ne prend pas en charge les zones de disponibilité.

• Vérifiez la redondance de zone. Vous pouvez utiliser le portail Azure, Azure CLI et Azure PowerShell pour vérifier l’état de redondance de zone de votre environnement.

Planification de capacité et gestion

Si une zone de disponibilité devient indisponible, la plateforme Container Apps s'appuie sur vos règles de mise à l'échelle pour déterminer le moment opportun pour remplacer d'éventuels réplicas perdus dans cette zone. Il est important de configurer correctement vos règles de mise à l’échelle afin que le planificateur puisse prendre des décisions de planification appropriées.

Pour configurer correctement vos règles de mise à l’échelle, suivez ces principes :

• Définissez un nombre minimal de réplicas que votre application peut tolérer. Le remplacement des réplicas perdus peut prendre peu de temps, car la plateforme doit détecter que les anciens réplicas sont disparus. Les nouvelles répliques doivent ensuite démarrer et renvoyer un statut de sonde de disponibilité sain avant de pouvoir traiter les requêtes entrantes. Si aucune période avec un nombre de réplicas inférieur au minimum spécifié n'est tolérable, envisagez un surapprovisionnement afin de préserver les performances de votre application même si une zone devient indisponible.

• Définissez les demandes de ressources et les limites pour aider le planificateur Container Apps à prendre des décisions de placement optimales entre les zones. Les besoins en ressources sous-spécifiés peuvent entraîner des défaillances de distribution ou de placement inégales pendant une charge élevée.

Pour plus d’informations sur les options de configuration, consultez Définir des règles de mise à l’échelle.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qui doit être attendu lorsque les ressources Container Apps sont configurées pour la redondance de zone et que toutes les zones de disponibilité sont opérationnelles.

• Routage du trafic entre les zones : avec les Container Apps redondantes par zone, la plateforme fonctionne selon un modèle actif-actif dans lequel plusieurs répliques traitent simultanément le trafic. Le contrôleur d'entrée répartit les requêtes entrantes entre tous les réplicas sains, sans tenir compte de leur zone, et applique par défaut un équilibrage de type tourniquet (round robin). Chaque zone traite les requêtes indépendamment, et la plateforme ne hiérarchise aucune zone spécifique pour la distribution du trafic. Les sondes de santé proviennent de toutes les zones pour garantir une évaluation précise de l’intégrité de chaque réplicas à partir de plusieurs perspectives.

• Réplication des données entre les zones : Container Apps ne réplique pas les données d’application entre les zones, car elles sont conçues pour les charges de travail sans état. Toutes les données que votre application conserve dans un stockage éphémère,, y compris dans un stockage au niveau du conteneur et au niveau du réplica, sont supprimées lorsque le conteneur ou le réplica est arrêté.

  Pour les besoins en données avec état, montez un partage de fichiers Azure Files configuré pour un stockage redondant interzone, ou utilisez d’autres services Azure tels qu’Azure Cosmos DB ou Azure SQL Database qui fournissent leurs propres fonctionnalités de réplication interzone.

  La plateforme réplique uniquement les métadonnées du plan de contrôle, notamment les configurations de votre application, les règles de mise à l’échelle et les secrets entre les zones pour la haute disponibilité. Les images de conteneur sont extraites de votre registre de conteneurs dans chaque zone selon les besoins lorsque des réplicas sont créés.

Comportement lors d’une défaillance de zone

Cette section décrit ce qui doit être attendu lorsque les ressources Container Apps sont configurées pour la redondance de zone et qu’il existe une panne de zone de disponibilité.

• Détection et réponse : Azure détecte automatiquement les défaillances de zone. Container Apps cesse immédiatement de planifier de nouveaux réplicas dans la zone défaillante et commence à redistribuer le trafic vers des réplicas sains dans les zones restantes. La plateforme gère automatiquement toutes les opérations de basculement sans nécessiter votre intervention.

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

  Vous pouvez également surveiller l’intégrité de vos applications via des métriques Container Apps dans Azure Monitor. Configurez les alertes sur les baisses de nombre de réplicas et les taux d’échec de demande pour recevoir une notification immédiate lorsque des problèmes liés à la zone se produisent.

• Demandes actives : les requêtes en cours vers les réplicas de la zone défaillante peuvent être abandonnées ou rencontrer des délais d'attente ou des erreurs de connexion. Toutes les exécutions de travaux qui s’exécutent dans la zone affectée sont abandonnées et sont marquées comme ayant échoué.

• Perte de données attendue : Aucune perte de données ne se produit au niveau de la plateforme Container Apps, car le service est conçu pour les charges de travail sans état. Toutes les données stockées dans un stockage éphémère dans la zone de disponibilité sont perdues lorsque le réplica est arrêté et le stockage éphémère ne doit être utilisé que pour les données temporaires.

• Temps d’arrêt attendu : Les applications connaissent un temps d'arrêt minimal, voire inexistant, pendant les défaillances de zone. L’impact réel dépend des paramètres de sonde de santé de votre application et du nombre de copies dans des zones saines. Assurez-vous que les clients suivent des instructions de gestion des erreurs temporaires pour réduire les effets.

  Tous les travaux qui s’exécutent dans la zone affectée sont abandonnés et sont marqués comme ayant échoué. Si vous avez besoin d'une tâche pour être résistante à une panne de zone, configurez les reprises ou le parallélisme afin que la tâche exécute plusieurs instances de la même opération. Pour plus d’informations, consultez Configuration avancée des travaux.

• Réacheminement du trafic : les sondes d'intégrité du contrôleur d'entrée détectent rapidement les réplicas inaccessibles et les suppriment du pool d'équilibrage de charge. Selon la configuration de la sonde d’intégrité de votre application, ce processus de basculement se produit généralement en environ 30 secondes. Le trafic entrant ultérieur est distribué sur les réplicas sains restants. Cette redirection de trafic se produit de manière transparente vers les clients, qui continuent d’utiliser la même URL d’application.

  Si l’affinité de session est activée et qu’une zone tombe en panne, les clients qui ont été précédemment routés vers des réplicas de cette zone sont routés vers de nouveaux réplicas, car les réplicas précédents ne sont plus disponibles. Tout état associé aux réplicas précédents est perdu.

  Aucune nouvelle instance de travaux ne sera démarrée dans la zone défectueuse.

• Gestion des instances : De nouvelles instances de réplica peuvent être créées dans des zones saines si vos règles de mise à l’échelle automatique se déclenchent en fonction d’une charge accrue.

Récupération de la zone

Lorsqu'une zone de disponibilité se remet d'une défaillance, Container Apps réintègre automatiquement la zone dans le service actif sans nécessiter votre intervention. Les sondes d'intégrité de la plateforme détectent le moment où l'infrastructure de la zone rétablie redevient disponible et Container Apps commence à planifier de nouveaux réplicas dans cette zone conformément à votre configuration de mise à l'échelle. Les réplicas existants dans les zones opérationnelles continuent de traiter le trafic pendant la phase de réintégration, ce qui permet d'éviter toute interruption de service.

Container Apps rééquilibre progressivement la distribution des réplicas dans toutes les zones disponibles dans le cadre des opérations de mise à l’échelle normales. Ce rééquilibrage automatique intervient lors de la création de réplicas provoquée par des événements de mise à l'échelle ou lors du remplacement de réplicas non sains. La plateforme ne force pas la redistribution immédiate des réplicas sains existants, ce qui empêche les redémarrages inutiles du conteneur et maintient la stabilité de l’application pendant la récupération.

Tester les pannes de zone

La plateforme Container Apps gère le routage du trafic, le basculement et la restauration pour les applications conteneur. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

Pour valider la résilience de votre application aux défaillances de zone, simuler des interruptions au niveau de la zone au niveau de l’application à l’aide d’approches de test contrôlées. Arrêtez ou supprimez les réplicas de zones particulières en réduisant la taille de votre application, et observez la manière dont les réplicas restants prennent en charge l'augmentation de la charge. Surveillez les métriques clés pendant les tests de résilience, notamment le nombre de réplicas, les taux de réussite des demandes, les temps de réponse et le comportement de mise à l’échelle automatique. Assurez-vous que votre nombre minimal de répliques assure la disponibilité du service lorsque les répliques sont supprimées, et vérifiez que vos règles de mise à l’échelle sont capables de gérer la charge accrue sur les répliques restantes. Testez vos configurations de sondes de santé en provoquant délibérément des défaillances des points de terminaison de santé afin de confirmer que la plateforme retire les instances non saines de la rotation pendant les délais prévus.

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

Container Apps est un service à région unique. Si la région devient indisponible, votre environnement et vos applications ne sont pas disponibles.

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

Pour réduire le risque d’une défaillance à une seule région affectant votre application, vous pouvez déployer des environnements dans plusieurs régions. Les étapes suivantes aident à renforcer la résilience :

• Déployez vos applications dans des environnements dans chaque région. Chaque environnement nécessite sa propre configuration de réseau virtuel et les exigences de sous-réseau s’appliquent indépendamment à chaque déploiement régional. Vos images conteneur doivent être disponibles à partir de toutes les régions, que vous pouvez obtenir à l’aide d’Azure Container Registry avec la géoréplication activée.

• Configurez les stratégies d’équilibrage de charge et de basculement à l’aide d’un service tel qu’Azure Front Door ou Azure Traffic Manager.

• Répliquez vos données entre les régions afin de pouvoir récupérer votre dernier état d’application.

Sauvegarde et restauration

Container Apps ne fournit pas de fonctionnalités de sauvegarde intégrées pour vos applications ou données. En tant que plateforme d’hébergement de conteneur sans état, Container Apps s’attend à ce que les applications gèrent leurs propres stratégies de persistance et de récupération des données via des services externes. Vos conteneurs d’applications et leurs systèmes de fichiers locaux sont éphémères, et toutes les données stockées localement sont perdues lorsque les réplicas redémarrent ou se déplacent.

Résilience pendant les mises à jour d’application

Utilisez la gestion des révisions pour déployer des mises à jour sur votre application sans temps d’arrêt. Vous pouvez créer de nouvelles révisions avec des images conteneur mises à jour et effectuer un basculement à l’aide d’une stratégie de déploiement bleu-vert ou déplacer progressivement le trafic à l’aide de règles de fractionnement du trafic. Pendant les mises à jour d’application, la plateforme conserve le nombre minimal de réplicas en créant de nouveaux conteneurs avant de les désaffecter, ce qui permet d’éviter les interruptions de service.

Pour plus d’informations, consultez Mettre à jour et déployer des modifications dans Container Apps.

Résilience à la maintenance du service

Container Apps effectue une maintenance automatique de la plateforme pour appliquer des mises à jour de sécurité, déployer de nouvelles fonctionnalités et améliorer la fiabilité du service. La plateforme utilise les mises à jour propagées entre les domaines d’erreur et les zones de disponibilité pour réduire l’interruption des applications en cours d’exécution. Pendant les fenêtres de maintenance, vos conteneurs continuent à s’exécuter sans interruption, car les mises à jour sont appliquées à l’infrastructure sous-jacente en phases.

Vous pouvez spécifier vos propres fenêtres de maintenance, qui sont des périodes pendant lesquelles vous souhaitez effectuer la maintenance sur vos applications. N’oubliez pas que les mises à jour critiques peuvent se produire en dehors de vos fenêtres de maintenance. Pour plus d’informations, consultez La maintenance planifiée de Container Apps.

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.

Le contrat SLA de disponibilité pour Container Apps est basé sur les règles de mise à l’échelle que vous définissez sur vos applications.

Contenu connexe

• Vue d’ensemble de Container Apps
• Sondes de santé dans Container Apps
• Mise à l’échelle automatique dans Container Apps
• Observabilité dans Container Apps
• Documentation sur la fiabilité d'Azure
• Conseils de fiabilité du cadre Well-Architected