Déploiements canary d’Amazon ECS - Amazon Elastic Container Service
Ressources impliquées dans un déploiement de CanaryConsidérationsComment fonctionnent les déploiements Canary

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Déploiements canary d’Amazon ECS

Les déploiements Canary acheminent d'abord un faible pourcentage du trafic vers la nouvelle version pour les tests initiaux, puis transfèrent immédiatement tout le trafic restant une fois la phase Canary terminée avec succès. Avec les déploiements Amazon ECS Canary, validez les nouvelles révisions de service avec le trafic utilisateur réel tout en minimisant l'exposition aux risques. Cette approche fournit un moyen contrôlé de déployer les modifications avec la possibilité de surveiller les performances et de revenir rapidement en arrière si des problèmes sont détectés.

Ressources impliquées dans un déploiement de Canary

Les ressources suivantes sont impliquées dans les déploiements d'Amazon ECS Canary :

  • Transfert de trafic : processus utilisé par Amazon ECS pour transférer le trafic de production. Pour les déploiements d'Amazon ECS Canary, le trafic est transféré en deux phases : d'abord pour atteindre le pourcentage Canary, puis pour terminer le déploiement.

  • Pourcentage Canary : pourcentage du trafic acheminé vers la nouvelle version pendant la période d'évaluation.

  • Durée de cuisson Canary : durée nécessaire pour surveiller la version Canary avant de procéder au déploiement complet.

  • Durée du déploiement : temps, en minutes, qu'Amazon ECS attend après avoir transféré tout le trafic de production vers la nouvelle révision du service, avant de mettre fin à l'ancienne révision du service. Il s'agit de la durée pendant laquelle les révisions des services bleu et vert sont exécutées simultanément après le déplacement du trafic de production.

  • Étapes du cycle de vie : une série d’événements au cours de l’opération de déploiement, tels que le « après transfert du trafic de production » :

  • Lifecycle Hook : fonction Lambda qui s'exécute à un stade spécifique du cycle de vie. Vous pouvez créer une fonction qui vérifie le déploiement.

  • Groupe cible : ressource ELB utilisée pour acheminer les demandes vers une ou plusieurs cibles enregistrées (par exemple, des EC2 instances). Lorsque vous créez un écouteur, vous spécifiez un groupe cible pour son action par défaut. Le trafic est transféré vers le groupe cible spécifié dans la règle de l'écouteur.

  • Écouteur : ressource ELB qui vérifie les demandes de connexion à l'aide du protocole et du port que vous configurez. Les règles que vous définissez pour un écouteur déterminent la manière dont Amazon ECS achemine les requêtes vers ses cibles enregistrées.

  • Règle : ressource ELB associée à un écouteur. Une règle définit la manière dont les requêtes sont acheminées et comprend une action, une condition et une priorité.

Considérations

Tenez compte des éléments suivants lors du choix d’un type de déploiement :

  • Utilisation des ressources : les déploiements Canary exécutent simultanément les ensembles de tâches d'origine et Canary pendant la période d'évaluation, ce qui augmente l'utilisation des ressources.

  • Volume de trafic : assurez-vous que le pourcentage Canary génère suffisamment de trafic pour une validation significative de la nouvelle version.

  • Supervision de la complexité : les déploiements Canary nécessitent de surveiller et de comparer simultanément les métriques entre deux versions différentes.

  • Vitesse de restauration : les déploiements Canary permettent une restauration rapide en transférant le trafic vers l'ensemble de tâches initial.

  • Atténuation des risques : les déploiements de Canary offrent une excellente atténuation des risques en limitant l'exposition à un faible pourcentage d'utilisateurs.

  • Durée de déploiement : les déploiements Canary incluent des périodes d'évaluation qui prolongent le temps de déploiement global tout en offrant des opportunités de validation.

Comment fonctionnent les déploiements Canary

Le processus de déploiement d'Amazon ECS Canary suit une approche structurée comportant six phases distinctes qui garantissent des mises à jour d'applications sûres et fiables. Chaque phase a un objectif spécifique en validant et en faisant passer votre application de la version actuelle (bleu) à la nouvelle version (vert).

  1. Phase de préparation : création de l’environnement vert à côté de l’environnement bleu existant.

  2. Phase de déploiement : déploiement de la nouvelle version du service dans un environnement vert. Amazon ECS lance de nouvelles tâches à l’aide de la révision de service mise à jour tandis que l’environnement bleu continue de desservir le trafic de production.

  3. Phase de test : validation de l’environnement vert à l’aide du routage du trafic de test. L’Application Load Balancer dirige les requêtes de test vers l’environnement vert tandis que le trafic de production reste en mode bleu.

  4. Phase de transfert du trafic Canary : transfert du pourcentage configuré du trafic vers la nouvelle révision du service écologique pendant la phase Canary, puis transfert de 100,0 % du trafic vers la révision du service vert

  5. Phase de surveillance : surveillance de l’état de l’application, des métriques de performance et des états d’alarme pendant la durée de l’intégration. Une opération de restauration est lancée lorsque des problèmes sont détectés.

  6. Phase d'achèvement : finalisez le déploiement en mettant fin à l'environnement bleu.

La phase de transfert de trafic de Canary suit les étapes suivantes :

  • Initiale : le déploiement commence lorsque 100 % du trafic est acheminé vers la version bleue (actuelle) du service. La version verte (nouvelle) du service reçoit du trafic de test mais aucun trafic de production au départ.

  • Transfert de trafic aux Canaries - Il s'agit d'une stratégie de transfert de trafic en deux étapes.

    • Étape 1 : 10,0 % vers le vert, 90 % vers le bleu

    • Étape 2 : 100,0 % vers le vert, 0,0 % vers le bleu

  • Temps de cuisson Canary : attend une durée configurable (temps de cuisson Canary) après Canary Traffic Shift pour permettre le suivi et la validation des performances de la nouvelle révision compte tenu de l'augmentation de la charge de trafic.

  • Lifecycle Hooks : les fonctions Lambda facultatives peuvent être exécutées à différentes étapes du cycle de vie au cours du déploiement pour effectuer une validation automatisée, une surveillance ou une logique personnalisée. Les fonctions Lambda ou les hooks de cycle de vie configurés pour PRODUCTION_TRAFFIC_SHIFT seront invoqués à chaque étape du transfert du trafic de production.

Étapes du cycle de vie du déploiement

Le processus de déploiement de Canary passe par différentes étapes du cycle de vie, chacune comportant des responsabilités et des points de contrôle de validation spécifiques. La compréhension de ces étapes vous permet de suivre la progression du déploiement et de résoudre les problèmes de manière efficace.

Chaque étape du cycle de vie peut durer jusqu'à 24 heures. De plus, chaque étape de transfert de trafic dans PRODUCTION_TRAFFIC_SHIFT peut durer jusqu'à 24 heures. Nous recommandons que la valeur reste inférieure à 24 heures. Cela est dû au fait que les processus asynchrones ont besoin de temps pour déclencher les hooks. Le système expire, échoue au déploiement, puis lance une restauration après une période de 24 heures.

CloudFormation les déploiements sont soumis à des restrictions de délai d'expiration supplémentaires. Bien que la limite de 24 heures reste en vigueur, elle CloudFormation impose une limite de 36 heures à l'ensemble du déploiement. CloudFormation échoue au déploiement, puis lance une annulation si le processus ne se termine pas dans les 36 heures.

Étapes du cycle de vie
Étapes du cycle de vie Description Support Lifecycle Hook
RECONCILE_SERVICE Cette étape ne se produit que lorsque vous démarrez un nouveau déploiement de service avec plus d’une révision de service dans un état ACTIF. Oui
PRE_SCALE_UP La révision de service verte n’a pas commencé. La révision de service bleue gère 100 % du trafic de production. Il n’y a aucun trafic de test. Oui
SCALE_UP Le moment où la révision de service verte augmente verticalement jusqu’à 100 % et lance de nouvelles tâches. La révision de service verte ne génère aucun trafic pour le moment. Non
POST_SCALE_UP La révision de service verte a commencé. La révision de service bleue gère 100 % du trafic de production. Il n’y a aucun trafic de test. Oui
TEST_TRAFFIC_SHIFT Les révisions de service bleues et vertes sont en cours. La révision de service bleue gère 100 % du trafic de production. La révision de service verte passe de 0 % à 100 % du trafic de test. Oui
POST_TEST_TRAFFIC_SHIFT Le transfert du trafic de test est terminé. La révision de service verte gère 100 % du trafic de test. Oui
PRODUCTION_TRAFFIC_SHIFT Le trafic de production de Canary est acheminé vers la révision verte et le hook du cycle de vie est invoqué avec un délai d'expiration de 24 heures. La deuxième étape fait passer le trafic de production restant à la révision verte. Oui
POST_PRODUCTION_TRAFFIC_SHIFT Le transfert du trafic de production est terminé. Oui
BAKE_TIME Durée pendant laquelle les révisions de service bleues et vertes sont exécutées simultanément. Non
CLEAN_UP La révision de service bleue a été complètement réduite à 0 tâches en cours d’exécution. Au terme de cette étape, la révision de service verte devient la révision de service de production. Non

Paramètres de configuration

Les déploiements Canary nécessitent les paramètres de configuration suivants :

  • Pourcentage Canary : pourcentage du trafic à acheminer vers la nouvelle révision du service pendant la phase Canary. Cela permet de tester avec un sous-ensemble contrôlé du trafic de production.

  • Temps de cuisson des canaris : temps d'attente pendant la phase canari avant de transférer le trafic restant vers la nouvelle révision du service. Cela laisse le temps de contrôler et de valider la nouvelle version.

Gestion du trafic

Les déploiements Canary utilisent des groupes cibles d'équilibreurs de charge pour gérer la distribution du trafic :

  • Groupe cible d'origine : contient les tâches de la version stable actuelle et reçoit la majorité du trafic.

  • Groupe cible Canary : contient les tâches de la nouvelle version et reçoit un faible pourcentage de trafic à des fins de test.

  • Routage pondéré : l'équilibreur de charge utilise des règles de routage pondérées pour répartir le trafic entre les groupes cibles en fonction du pourcentage Canary configuré.

Surveillance et validation

Les déploiements Canary efficaces reposent sur une surveillance complète :

  • Contrôles de santé - Les deux ensembles de tâches doivent passer des tests de santé avant de recevoir du trafic.

  • Comparaison des indicateurs : comparez les indicateurs de performance clés entre les versions d'origine et Canary, tels que le temps de réponse, le taux d'erreur et le débit.

  • Annulation automatique - Configurez les CloudWatch alarmes pour déclencher automatiquement la restauration si les performances de la version Canary sont dégradées.

  • Validation manuelle : utilisez la période d'évaluation pour examiner manuellement les journaux, les indicateurs et les commentaires des utilisateurs avant de continuer.

Bonnes pratiques pour les déploiements Canary

Suivez ces bonnes pratiques pour garantir le succès des déploiements Canary avec les services.

Choisissez les pourcentages de trafic appropriés

Tenez compte des facteurs suivants lors de la sélection des pourcentages de trafic Canary :

  • Commencez modestement : commencez par 5 à 10 % du trafic afin de minimiser l'impact en cas de problème.

  • Tenez compte de la criticité des applications : utilisez des pourcentages plus faibles pour les applications critiques et des pourcentages plus élevés pour les services moins critiques.

  • Tenez compte du volume de trafic - Assurez-vous que le pourcentage Canary génère suffisamment de trafic pour une validation significative.

Définissez des périodes d'évaluation appropriées

Configurez les périodes d'évaluation en fonction des considérations suivantes :

  • Prévoyez suffisamment de temps : définissez des périodes d'évaluation suffisamment longues pour recueillir des données de performance pertinentes, généralement de 10 à 30 minutes.

  • Tenez compte des modèles de trafic : tenez compte des modèles de trafic de votre application et des heures de pointe d'utilisation.

  • Équilibre entre rapidité et sécurité - Les périodes d'évaluation plus longues fournissent davantage de données mais ralentissent la vitesse de déploiement.

Mettre en œuvre une surveillance complète

Configurez la surveillance pour suivre les performances de déploiement de Canary :

  • Indicateurs clés : surveillez le temps de réponse, le taux d'erreur, le débit et l'utilisation des ressources pour les deux ensembles de tâches.

  • Annulation basée sur les alarmes : configurez les CloudWatch alarmes pour déclencher automatiquement l'annulation lorsque les métriques dépassent les seuils.

  • Analyse comparative - Configurez des tableaux de bord pour comparer les indicateurs entre les versions side-by-side d'origine et Canary.

  • Indicateurs commerciaux - Incluez des indicateurs spécifiques à l'entreprise, tels que les taux de conversion ou l'engagement des utilisateurs, ainsi que des indicateurs techniques.

Planifier des stratégies de réduction

Préparez-vous à d'éventuels scénarios de réduction grâce aux stratégies suivantes :

  • Annulation automatique : configurez des déclencheurs de restauration automatique en fonction des bilans de santé et des indicateurs de performance.

  • Procédures d'annulation manuelles - Documentez des procédures claires pour la restauration manuelle lorsque les déclencheurs automatisés ne détectent pas tous les problèmes.

  • Tests de rétrogradation : testez régulièrement les procédures de rétrogradation pour vous assurer qu'elles fonctionnent correctement en cas de besoin.

Validez minutieusement avant le déploiement

Assurez-vous d'une validation complète avant de procéder aux déploiements de Canary :

  • Tests de pré-déploiement : testez minutieusement les modifications dans les environnements de test avant le déploiement de Canary.

  • Configuration des contrôles de santé : assurez-vous que les contrôles de santé reflètent avec précision l'état de préparation et les fonctionnalités de l'application.

  • Validation des dépendances : vérifiez que les nouvelles versions sont compatibles avec les services en aval et en amont.

  • Cohérence des données : assurez-vous que les modifications du schéma de base de données et les migrations de données sont rétrocompatibles.

Coordonner l'implication de l'équipe

Garantissez une coordination efficace des équipes lors des déploiements Canary :

  • Fenêtres de déploiement : planifiez les déploiements de Canary pendant les heures ouvrables lorsque les équipes sont disponibles pour surveiller et répondre.

  • Canaux de communication - Établissez des canaux de communication clairs pour connaître l'état du déploiement et l'escalade des problèmes.

  • Attributions de rôles : définissez les rôles et les responsabilités en matière de surveillance, de prise de décision et d'exécution des annulations.