View a markdown version of this page

Déploiements canary d’Amazon ECS - Amazon Elastic Container Service
Ressources impliquées dans le déploiement d'un canariConsidérationsComment fonctionnent les déploiements de 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 petit pourcentage du trafic vers la nouvelle révision pour les tests initiaux, puis transfèrent tout le trafic restant en une seule fois 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 un 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 le déploiement d'un canari

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

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

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

  • Durée de cuisson de Canary : durée de surveillance de la version Canary avant de procéder au déploiement complet.

  • Temps de préparation 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 de service, avant de mettre fin à l'ancienne révision de service. Il s'agit de la durée pendant laquelle les révisions de service en bleu et en 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 » :

  • Hook du cycle de vie : fonction Lambda ou point de pause à une étape spécifique du cycle de vie. Les hooks Lambda invoquent les fonctions Lambda que vous avez définies pour exécuter du code personnalisé. Les crochets de pause interrompent le déploiement et attendent que vous appeliez ContinueServiceDeployment pour continuer.

  • Groupe cible : ressource Elastic Load Balancing utilisée pour acheminer les requêtes vers une ou plusieurs cibles enregistrées (par exemple, des instances EC2). 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 : une ressource Elastic Load Balancing 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 Elastic Load Balancing 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 des ensembles de tâches d'origine et des ensembles de tâches Canary pendant la période d'évaluation, ce qui augmente l'utilisation des ressources.

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

  • Complexité de la surveillance : les déploiements de Canary nécessitent une surveillance et une comparaison simultanées des métriques entre deux versions différentes.

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

  • 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 du déploiement : les déploiements de Canary incluent des périodes d'évaluation qui prolongent la durée globale du déploiement tout en offrant des opportunités de validation.

Comment fonctionnent les déploiements de Canary

Le processus de déploiement d'Amazon ECS Canary suit une approche structurée en 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 des Canaries : transfert du pourcentage configuré du trafic vers la nouvelle révision du service vert pendant la phase canarienne, 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 des Canaries suit les étapes suivantes :

  • Initiale : le déploiement commence avec 100 % du trafic acheminé vers la version bleue (actuelle) du service. La (nouvelle) révision de service verte 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 % au vert, 90,0 % au bleu

    • Étape 2 : 100,0 % au vert, 0,0 % au bleu

  • Temps de cuisson des canaris - Attend pendant une durée configurable (temps de cuisson des canaris) après le changement de trafic des Canaries afin de permettre le suivi et la validation des performances de la nouvelle révision face à l'augmentation de la charge de trafic.

  • Hooks du cycle de vie : des fonctions Lambda facultatives ou des crochets de pause peuvent être configurés à différentes étapes du cycle de vie pendant le déploiement afin d'effectuer une validation, une surveillance ou une logique personnalisée automatisées. Les hooks sont configurés pour PRODUCTION_TRAFFIC_SHIFT ou PRE_PRODUCTION_TRAFFIC_SHIFT sont 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 et, en outre, chaque étape de changement 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 lors du déploiement, puis lance une restauration après qu'une étape ait atteint 24 heures.

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

Pour les crochets de pause, vous pouvez configurer le délai d'attente jusqu'à 20 160 minutes (14 jours). Le délai de déploiement global est de 30 jours.

É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 (Lambda uniquement)
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
CHANGEMENT_DE_CIRCULATION_PRÉPRODUCTION Se produit avant chaque étape de transfert du trafic de production. Pour les îles Canaries, cela se produit avant le changement de trafic des Canaries et avant le quart de trafic restant. Oui
PRODUCTION_TRAFFIC_SHIFT Le trafic de production de Canary est acheminé vers la version 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 (Lambda uniquement)
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 canarien : pourcentage du trafic à acheminer vers la nouvelle révision du service pendant la phase canarienne. Cela permet de réaliser des tests avec un sous-ensemble contrôlé du trafic de production.

  • Durée de cuisson des Canaries : durée d'attente pendant la phase canarienne avant de transférer le trafic restant vers la nouvelle révision du service. Cela laisse le temps de surveiller et de valider la nouvelle version.

Gestion du trafic

Les déploiements Canary utilisent des groupes cibles d'équilibrage 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 majeure partie du trafic.

  • Groupe cible Canary : contient les tâches de la nouvelle version et reçoit un faible pourcentage du trafic destiné aux tests.

  • 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 canarien configuré.

Surveillance et validation

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

  • Contrôles de santé : les deux ensembles de tâches doivent réussir des contrôles de santé avant de recevoir du trafic.

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

  • Annulation automatique : configurez CloudWatch des alarmes pour déclencher automatiquement une restauration si la version Canary affiche des performances dégradées.

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

Meilleures pratiques pour les déploiements de Canary

Suivez ces bonnes pratiques pour garantir la réussite des déploiements de services avec Canary.

Choisissez les pourcentages de trafic appropriés

Tenez compte des facteurs suivants lorsque vous sélectionnez les pourcentages de trafic des Canaries :

  • Commencez petit : commencez avec 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 canarien génère un trafic suffisant 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 significatives, généralement de 10 à 30 minutes.

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

  • Équilibrez vitesse et sécurité - Des 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.

  • Alarm-based rollback : configurez CloudWatch des alarmes pour déclencher automatiquement une annulation lorsque les métriques dépassent les seuils.

  • Analyse comparative - Configurez des tableaux de bord pour comparer les statistiques entre les versions originale et Canary côte à côte.

  • Indicateurs commerciaux : incluez des indicateurs spécifiques à l'entreprise, tels que les taux de conversion ou l'engagement des utilisateurs, aux côtés des indicateurs techniques.

Planifiez des stratégies de restauration

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

  • Annulation automatique : configurez des déclencheurs d'annulation automatiques en fonction des bilans de santé et des mesures de performance.

  • Procédures de restauration manuelle : documentez des procédures claires pour la restauration manuelle lorsque les déclencheurs automatiques ne permettent pas de détecter tous les problèmes.

  • Tests d'annulation : testez régulièrement les procédures d'annulation 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 :

  • Pre-deployment testing - Testez minutieusement les modifications apportées aux environnements de test avant le déploiement de Canary.

  • Configuration du bilan de santé : assurez-vous que les bilans 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 la participation de l'équipe

Assurez une coordination efficace de l'équipe lors des déploiements de Canary :

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

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

  • Attribution des 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 rétroactive.