Le ZDD (Zero Downtime Deployment) est un pattern qui permet de réaliser des déploiement d’évolutions sans interruption de service. Il faut savoir que la tâche n’est pas toujours si simple à mettre en oeuvre.
Nous allons profiter de cet article pour voir le concept du ZDD (Zero Downtime Deployment) ; puis nous verrons les difficultés souvent rencontrées et les solutions associées lors de la mise en place de ce pattern.
Fonctionnement du ZDD (Zero Downtime Deployment)
Ce pattern utilise le concept très connu du blue green deployment que nous avons déjà vu dans le passé sur ce blog. Le concept est de lancer la nouvelle version en parallèle de la version en production et d’amener les utilisateurs peu à peu vers la nouvelle version.
En effet, nous avons vu ces schéma dernièrement dans nos derniers articles devops. L’objectif est de basculer de plus en plus d’utilisateurs vers la version N+1 jusqu’à ce qu’elle devienne la seule version utilisée par tous.
Nous allons voir que ce pattern très utile apporte également son lot de complications.
Des concepts pour tester les parties techniques et/ou les parties fonctionnelles utilisent d’ailleurs ce pattern :
Problématiques rencontrées en ZDD (Zero Downtime Deployment)
Sessions HTTP
Comme nous l’avions vu dans notre ancien article sur le blue green deployment, le problème le plus classique est la gestion des sessions. Comment faire migrer un utilisateur de N à N+1 sans que la personne soit déconnectée ?
Il existe deux méthodes classiques comme :
- mettre la session dans un cookie
- appeler un « dépôt » indépendant de type Memcache, Redis…
Dans ce cas les utilisateurs passeront du Blue au Green sans même s’en rendre compte. Cependant pour des raisons de sécurité de données, nous privilégions fortement la seconde option.
Si vous désirez que ce « dépôt » fasse parti du système blue green, il faudra alors utiliser une couche supplémentaire que nous verrons plus tard.
Modification de schéma de base de données
Nous allons pour le moment considérer que la base de données est sortie du système du blue green deployment. Nous verrons après, le problème quand la base de données fait parti de ce pattern.
Les nouveaux déploiements imposent parfois des modifications des modèles de données de nos bases SQL. Ces modifications vont devoir respecter deux règles essentielles :
- Les deux versions doivent fonctionner avec le modèle modifié
- Capacité de revenir à la version N (ancienne) en cas de constat négatif
Attention aux lock
Si cela implique des modifications, le fait d’avoir des bases de données partagées, amène le risque de blocage (LOCK) lors du changement de modèle de données. Renseignez-vous sur les bases de données que vous utilisez pour en savoir plus. Dans les clouds actuels, ce problème est plus rare.
Utilisez des outils disponibles qui permettent de limiter ce type de soucis et éviter les opérations « ALTER ». Privilégié toujours un ajout de champs.
Préparer ses scripts
Dans certains langages, il peut-être nécessaires de prévoir des scripts de mise à jour des modèles de données :
- script d’évolution du modèle : INSERT
- le script de rollback : DELETE
- script de fin de bascule : DELETE
Supprimer un champ ou une table
La suppression d’un champs ou d’une table est le cas le plus simple à prendre en charge. Nous effectuerons les suppressions nécessaires que lors du script de fin de bascule.
Ajouter un champ ou une table
L’ajout du champ ou d’une table se feront dans le script d’évolution.
Dans certains cas l’ajout de champ peut-être plus complexe. Par exemple, si nous voulons avoir plusieurs utilisateurs pour un même compte dans la nouvelle version alors que dans la version actuelle, chaque compte ne pouvait avoir qu’un seul utilisateur ; nous serions contraint de faire des modifications plus importantes.
Dans ce cas, les actions à réaliser seraient plus complexe (voire le schéma ci-dessous) :
- créer la nouvelle table dans le script d’évolution.
- ajouter 2 triggers pour remplir les deux champs à partir de chaque version dans le script d’évolution
- supprimer le champ devenant obsolète dans le script de fin de bascule.
- retirer les 2 triggers pour remplir les deux champs à partir de chaque version dans le script de fin de bascule.
- retirer les 2 triggers pour remplir les deux champs à partir de chaque version dans le script de rollback.
- supprimer la nouvelle table dans le script de rollback.
Le trigger permet de s’assurer de n’avoir aucune perte de données, peu importe la finalité du déploiement.
Les modifications de champs/tables
Bien que des outils existent pour limiter les risques de LOCK, je vous recommande cette méthode pour modifier des champs :
- ajouter un champ (non proche de l’ancien nom) lors du script d’évolution.
- ajouter 2 triggers pour remplir les deux champs à partir de chaque version dans le script d’évolution.
- supprimer l’ancien champ obsolète dans le script de fin de bascule.
- retirer les 2 triggers pour remplir les deux champs à partir de chaque version dans le script de fin de bascule.
- retirer les 2 triggers pour remplir les deux champs à partir de chaque version dans le script de rollback.
- supprimer le nouveau champ dans le script de rollback.
En effet, la technique est très proche au final de celle vue précédemment.
Certaines équipes vont privilégier de fonctionner avec des outils tel que RabbitMQ à la place des triggers ; cependant, cela amènera à d’autres travaux et d’autres complexités à analyser avant de se lancer dans ce type de technologies.
Les bases sont aussi dans le blue green deployment
Cette méthode est tout a fait possible mais votre code devra prendre en compte d’effectuer des opérations deux fois (sur les bases de données de la version N et de la version N+1).
Cependant si cela fonctionne très bien pour des applications à faible charge, cela peut vite amener un problème de performances quand l’application implique des opérations conséquentes.
Le ZDD (Zero Downtime Deployment), c’est pas si simple
Le pattern de ZDD (Zero Downtime Deployment) peut amener de nombreuses problématiques et amener a des choix importants dans l’architecture de vos applications.
Cependant ce pattern très populaire en devops permet de proposer des mises à jours sans interruption de service ; il permet également de bénéficier de pratiques très utiles pour assurer une meilleure qualité des livraisons réalisées.
Soyez le premier à commenter