Permettre à une entreprise de publicité télévisée de réduire les risques et d’améliorer la fiabilité grâce aux déploiements Canary

Introduction
Dans le paysage actuel du développement logiciel, en évolution rapide, il est crucial de garantir que les nouvelles fonctionnalités et mises à jour soient fournies de manière fiable et sans interruption. Les déploiements Canary, une stratégie essentielle au sein de la boîte à outils DevOps, offrent une méthode puissante pour atteindre cet objectif. L’un de ces grands voyages est l’histoire d’un Plateforme mondiale de gestion de la publicité client, une référence en matière de publicité et de télévisions connectées. Avec une plateforme de gestion de publicité TV connectée de pointe, ils avaient besoin d’un partenaire de confiance pour gérer leur processus de déploiement critique. Ce blog explore comment les déploiements Canary ont aidé le client, en garantissant une diffusion transparente des publicités et en améliorant l’efficacité et la fiabilité de leur pipeline de déploiement.

Qu’est-ce que le déploiement Canary ?
Les déploiements Canary sont une stratégie DevOps qui implique le déploiement d’une nouvelle version du logiciel auprès d’un petit sous-ensemble contrôlé d’utilisateurs avant une version à grande échelle. Cette approche permet aux équipes de surveiller l’impact des dernières modifications dans un environnement réel, d’identifier et de résoudre rapidement les problèmes et de minimiser les risques associés au déploiement.

Déploiement Canary

Exigences et cas d’utilisation

• Tests par rapport au trafic de production: Notre client avait besoin de tester différents scénarios sur une partie de son trafic de production sans perturber l’ensemble de l’environnement.
• Inclusion sélective des candidatures : Sachant que toutes les applications ne nécessitent pas un déploiement Canary, nous avons identifié les applications critiques pour cette implémentation. En nous concentrant sur l’essentiel, nous avons assuré un processus efficace.
• Équilibrer l’automatisation et l’intervention manuelle: Tout en visant une automatisation complète, nous avons assuré une configuration initiale gérable avec un chemin clair vers l’automatisation.
• Assurer une restauration fiable: Nous avons mis en œuvre un processus de restauration transparent pour revenir à l’état précédent si la version Canary rencontrait des problèmes ou échouait d’approbation.
• Compatibilité et coexistence: Les modifications apportées à l’application ont été conçues pour prendre en charge la version Canary exécutée parallèlement à la version actuelle, conformément aux meilleures pratiques pour les déploiements conteneurisés.

Stratégie de déploiement existante et ses défis

• Notre stratégie de déploiement existante reposait sur mise à jour continue fonctionnalité du service AWS ECS. Le nouveau code a été soumis à des tests rigoureux dans l’environnement de pré-production, où régression et tests unitaires ont été menés, complétés par des tests manuels de la part de l’équipe d’assurance qualité. Nous avons utilisé des artefacts et des images Docker construits dans un environnement de pré-production en production. Cependant, le déploiement du nouveau code directement en production présentait des risques importants malgré ces mesures.
  
  

  Déploiement de préprod existant

• Avec l’approche de mise à jour continue, tous les nouveaux conteneurs recevaient 100 % du trafic une fois déployés en production. Cette configuration ne laissait aucune place à l’erreur ; tout oubli ou défaut manqué lors des tests dans des environnements inférieurs pourrait entraîner des pannes soudaines de production.
• De plus, notre travail dépendait fortement de données en temps réel que les environnements de test ne pouvaient pas imiter. Des facteurs comme emplacements des utilisateurs, IPet le flux de messages échangés en temps réel étaient critiques et ne pouvaient pas être entièrement testés au préalable, ce qui nous exposait à des risques.
• Les méthodes de déploiement traditionnelles ont également eu du mal à suivre le rythme rapide de notre secteur, ne parvenant pas à gérer efficacement les pics de trafic soudains ou les problèmes inattendus. Si nous rencontrions des problèmes tels qu’une augmentation Erreurs 5xx, fuites de mémoireou Processeur élevé utilisation, nous avons été obligés de tout restaurer en production vers la version stable précédente, provoquant des perturbations et des pertes potentielles.
  
  

  Déploiement de production existant

• Conscients de ces lacunes, nous avons décidé de passer à un modèle de déploiement Canary. Cette approche nous a permis d’atténuer les risques en acheminant progressivement un petit pourcentage du trafic vers le nouveau code, nous permettant ainsi d’observer son comportement dans un contexte réel. Dans notre prochaine discussion sur la conception du déploiement Canary, nous examinerons comment cette stratégie a répondu à nos défis et assuré un processus de déploiement plus stable et plus fiable.

Conception de déploiement Canary
Intégration du pipeline Jenkins

• Nous avons ajouté 3 nouvelles étapes dans notre pipeline Jenkins dédiées aux déploiements Canary. Déploiement Canary, Approuver/Désapprouver Canary et Annulation des applications Canary.
• L’application Canary, nommée au format app1_canariréplique l’application non Canary application 1.
• Nous avons également configuré des groupes cibles d’équilibreurs de charge pour diriger 1% du trafic vers l’application Canary et 99% à l’application non canarie. Ces pourcentages sont gérés via Terraforme et peut être modifié d’un cas à l’autre.
  
  

  Stratégie de déploiement Canary

Mises à jour de la base de données Liquibase

• Avant de déployer le nouveau code, nous effectuons des mises à jour du schéma de base de données à l’aide de Liquibase.
• Liquibase est un outil de gestion des modifications de schéma de base de données open source. Il nous permet de définir les modifications de la base de données dans un format facile à suivre et à restaurer si nécessaire, garantissant ainsi la cohérence et la fiabilité du schéma de base de données lors des déploiements.

Déploiement Canary

• Le nouveau code est déployé sur l’application Canary, où le contrôle qualité le teste avec 1 % de trafic avant l’étape d’approbation.

Étape d’approbation

• L’équipe d’assurance qualité teste le déploiement Canary avec 1 % de trafic ; s’il est approuvé, le nouveau code est déployé sur le reste de l’application gérant 99 % du trafic.
  

  Étape d’approbation

Retour en arriere

1. Refus et restauration :
   • Si le contrôle qualité désapprouve le déploiement Canary, une restauration est déclenchée.
   • La restauration implique le rétablissement de l’application Canary et du schéma de base de données (à l’aide de Liquibase) vers la version stable précédente.
     
     

     retour en arriere

   • Ceci est réalisé en exécutant un dédié canariRollback Travail Jenkins qui automatise le processus de restauration.
     

     Stratégie de restauration

Surveillance

1. Journaux Kibana et tableaux de bord CloudWatch :
   • QA utilise les journaux Kibana pour surveiller les journaux d’applications en temps réel pendant le déploiement Canary.
   • Les tableaux de bord CloudWatch sont configurés pour suivre les métriques clés telles que Utilisation du processeur, utilisation de la mémoire, et Codes de réponse HTTP (5xx et 4xx.
     
     

     Tableau de bord Cloudwatch

2. Alarmes CloudWatch :
   • Des alarmes CloudWatch spécifiques sont configurées pour l’application Canary afin d’alerter l’équipe de toute anomalie ou problème.
   • Ces alarmes permettent d’identifier et de répondre rapidement aux problèmes potentiels pendant la phase canari.
3. Approbation pour le déploiement complet :
   • Après des tests et une surveillance approfondis, le contrôle qualité approuve le déploiement de Canary si tout semble bon. La nouvelle version du logiciel est désormais déployée sur l’ensemble de l’application.
   • Cela garantit que le logiciel mis à jour gère 100 % du trafic, offrant ainsi une transition transparente de Canary au déploiement complet.
     
     

     étape d’approbation

   • L’approbation finale saute l’étape de restauration de Canary et procède au déploiement du nouveau logiciel sur l’ensemble de l’application.

En intégrant les déploiements Canary dans notre pipeline Jenkins, nous pouvons garantir un déploiement plus sûr et plus contrôlé des nouvelles versions logicielles, avec la possibilité de revenir rapidement en arrière si des problèmes sont détectés.

Avantages commerciaux après le passage aux déploiements Canary

• Haute disponibilité et fiabilité maintenues en minimisant l’impact des problèmes potentiels.
• Offrez de meilleures expériences client grâce à des versions stables et bien testées.
• Efficacité opérationnelle: Déploiements plus fluides, moins stressants et restauration plus facile si nécessaire.
• Restez compétitif et innovant avec des mises à jour plus rapides et plus fréquentes.
• Améliorer la prise de décision avec des informations tirées des commentaires des utilisateurs du monde réel pendant les phases Canary.
• Tests en situation réelle: permet une détection précoce des problèmes à l’aide d’interactions réelles avec les utilisateurs.

Conclusion

La transition vers un modèle de déploiement Canary a été transformatrice pour notre client, réduisant considérablement les risques de déploiement en introduisant du nouveau code dans un petit pourcentage du trafic et en permettant une détection précoce des problèmes. À AU NOUVEAU, nous excellons dans la simplification des migrations vers le cloud AWS et dans la mise en œuvre de stratégies de déploiement avancées. Notre Architectes certifiés AWS et Ingénieurs DevOps s’engagent à vous faire économiser du temps et des ressources tout en améliorant l’efficacité et la fiabilité de votre entreprise. Restez à l’écoute pour plus d’informations et de développements alors que nous poursuivons notre voyage vers l’excellence du déploiement.