Comment éviter une interruption imprévue lors d'une mise à niveau
Migrer ses systèmes métier vers le cloud présente de nombreux avantages. L'un des principaux atouts d'un service managé est qu'il évite d'avoir à maintenir le service sur une infrastructure existante avec ses ressources techniques en place et ses processus opérationnels établis. Vous bénéficiez du savoir-faire collectif et de l'expérience d'un service managé, en contrepartie d'un abonnement. Recourir à un service de gestion de base de données présente de multiples avantages : sécurité, allocation des ressources, intégration des fonctionnalités.
Cet article aborde une fonctionnalité disponible chez plusieurs fournisseurs cloud qui, en apparence, semble simplifier la maintenance courante. En réalité, elle peut coûter très cher : interruption critique et scénario de sinistre auquel vous n'êtes pas préparé, alors même que les ressources techniques et les compétences issues d'une implémentation auto-hébergée précédente ne sont plus disponibles.
Cette fonctionnalité, ce sont les mises à jour automatiques des versions mineures.
Pourquoi les mises à niveau produit sont-elles importantes ?
Chaque organisation dispose de processus et de contrôles qui lui sont propres, fruit de nombreuses années d'expérience, de produits et d'outils internes spécifiques à son activité. Ces processus peuvent être très robustes, simplement adéquats, voire fragiles. Recourir à un service managé peut donner un sentiment de stabilité et améliorer la capacité opérationnelle ; pour autant, cela ne supprime pas la nécessité de tester. Le cloud, les services managés, l'automatisation, l'IaC et les frameworks ne suppriment pas la nécessité d'une gestion rigoureuse des processus.
La base de données est un composant critique dans toute entreprise. Ce n'est pas le seul composant vital, mais l'absence d'une base de données fonctionnelle représente, dans bien des organisations, un risque aux conséquences majeures sur la capacité opérationnelle.
Tous les produits connaissent, au fil du temps, des dépréciations de fonctionnalités et de syntaxe, des notifications de fin de vie et des correctifs de sécurité. Ces évolutions exigent une maintenance continue de l'infrastructure qui supporte vos applications. Les mises à jour produit prennent la forme de mises à niveau mineures et de mises à jour majeures. Traitez-les sur un pied d'égalité en matière de risque métier.
Une mise à niveau mineure non testée peut faire tomber votre système de production.
La méthode de mise à niveau par défaut des services managés
De nombreux services proposés par les différents fournisseurs cloud offrent des outils et de l'automatisation pour gérer les tâches répétitives et fastidieuses, notamment les mises à niveau de versions mineures.
Voici un exemple avec AWS RDS. Lorsque vous créez une nouvelle base de données via la console AWS, plusieurs dizaines d'options de configuration vous sont présentées, mais pas toutes. Cliquez sur Configuration supplémentaire en bas de la page pour afficher l'ensemble des options disponibles.
Vous devez faire défiler jusqu'en bas de cette page pour trouver la section Maintenance, où l'option Activer la mise à niveau automatique des versions mineures est cochée par défaut.
Les limites de cette approche du service managé
Ce paramètre par défaut pose plusieurs problèmes fondamentaux :
- Les mises à niveau mineures sont appliquées lors de la fenêtre de maintenance hebdomadaire, à la discrétion d'AWS. Elles ne sont pas forcément déclenchées automatiquement à la prochaine fenêtre de maintenance et peuvent prendre plusieurs semaines avant de se produire.
- AWS ne fait pas de distinction entre un environnement de test et un environnement de production. Si plusieurs de vos environnements sont configurés pour se mettre à niveau automatiquement, ils peuvent tous être traités la même semaine, ou seulement certains.
- AWS ne privilégie pas les versions à support long terme (LTS) par rapport aux mises à niveau mineures. La documentation AWS RDS indique d'ailleurs : Nous recommandons de ne pas définir le paramètre AutoMinorVersionUpgrade sur true pour les versions LTS. Cela pourrait entraîner la mise à niveau de votre cluster DB vers une version non LTS.
- Lorsqu'une mise à niveau mineure se produit, AWS RDS ne crée pas de point de restauration permettant de revenir en arrière en cas de problème. Vous pouvez certes utiliser la restauration à un instant T, mais celle-ci ne ramènera pas la version actuellement en cours d'exécution à celle en place au moment du point de restauration.
- Les fenêtres de maintenance sont généralement planifiées aux heures de faible utilisation de votre système et coïncident le plus souvent avec une disponibilité minimale des ressources techniques. La durée d'exécution d'une mise à niveau imprévue va probablement allonger la durée de l'interruption.
Les versions mineures ne sont pas appliquées automatiquement à la prochaine fenêtre de maintenance.
Une mise à niveau de version mineure est aussi importante qu'une nouvelle release produit interne. Lorsque la majorité de vos ressources techniques sont indisponibles, déploieriez-vous automatiquement en production une nouvelle version produit interne non testée ?
Bonnes pratiques pour les mises à niveau de versions mineures
C'est très simple : tester et vérifier.
L'option Activer la mise à niveau automatique des versions mineures est pratique et réduit la dépendance à la maintenance régulière, mais elle entretient une certaine méconnaissance du contrôle de l'exécution et des options de récupération. La base de données est souvent un composant critique d'une stack technologique. Elle exige une surveillance constante, une gestion et une maintenance continues, au même titre que tout autre composant critique du système.
Le déploiement d'une nouvelle version mineure dans un environnement, quel qu'il soit, doit suivre un processus contrôlé et documenté. Cela passe par une progression à travers les différents environnements jusqu'à la production : dev, test, stage et prod, par exemple. Une mise à niveau doit être exécutée via l'automatisation et supervisée par un humain, même lorsqu'il s'agit de centaines ou de milliers de serveurs de bases de données. Les mises à niveau doivent être lancées lorsque les ressources sont disponibles en ligne, qu'il s'agisse des ressources opérationnelles qui gèrent l'infrastructure ou des Engineers capables d'intervenir si une opération inattendue ou non testée provoquait un incident.
Les étapes du processus de mise à niveau sont propres à chaque organisation. Ce processus doit toujours inclure un snapshot pré mise à niveau. De manière générale, les déploiements en production ne devraient avoir lieu qu'après un délai suffisant — quelques semaines, par exemple — après le déploiement et la validation dans d'autres environnements.
Une base de données de production ne devrait jamais être dans une version plus récente que celles utilisées dans un cycle de tests de release.
Il n'est pas conseillé d'exploiter votre base de données avec la version mineure la plus ancienne. Cela placerait la mise à niveau de version mineure en chemin critique, et AWS ne fournit pas de calendrier pour la dépréciation et la suppression. En règle générale, vous ne devriez pas non plus utiliser la version mineure la plus récente : la communauté n'a peut-être pas encore détecté les problèmes introduits dans cette dernière, et les ressources en ligne pour vous aider au triage peuvent être limitées.
La bonne pratique consiste à déployer chaque version mineure à un moment opportun pour l'activité, sans cumuler plusieurs versions mineures lors d'une même mise à niveau. Un déploiement vers la dernière version peut s'avérer nécessaire en raison d'un bug connu corrigé dans une nouvelle version : vous n'avez alors pas d'autre choix que de tester, vérifier et mettre à niveau en dehors d'une politique métier connue et documentée.
En résumé, soyez TOUJOURS proactif.
Identifier les mises à niveau de versions mineures
Ces derniers mois, AWS a introduit une nouvelle fonctionnalité qui expose les recommandations AWS via l'AWS CLI et la console. Jusqu'ici, déterminer la disponibilité de nouvelles versions exigeait un processus plus complexe : consultation des Release Notes, suivi des nouvelles versions disponibles, ou surveillance des événements d'autres environnements pour lesquels cette fonctionnalité aurait été activée.
Vous pouvez désormais obtenir cette information à l'aide de la commande describe-db-recommendations. REMARQUE : elle est disponible à partir de la version 2.15.3 de la CLI. Il faut lire le changelog ligne par ligne pour repérer cette mise à jour récente. Si vous ne mettez pas à jour votre CLI fréquemment, il vous faudra une version plus récente pour utiliser cette commande.
Sortie de describe-db-recommendations
$ aws rds describe-db-recommendations
{
"RecommendationId": "",
"TypeId": "config_recommendation::old_minor_version",
"Severity": "informational",
"ResourceArn": "arn:aws:rds:region:123456789:cluster:mydb",
"Status": "active",
"Detection": "**[resource-name]** is not running the latest minor DB engine version",
"Recommendation": "Upgrade to latest engine version",
"Description": "Your database resources aren't running the latest minor DB engine version. The latest minor version contains the latest security fixes and other improvements.",
"RecommendedActions": [\
{\
"ActionId": "",\
"Operation": "modifyDbCluster",\
"Parameters": [\
{\
"Key": "EngineVersion",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "DBClusterIdentifier",\
"Value": "mydb"\
}\
],\
"ApplyModes": [\
"immediately",\
"next-maintenance-window"\
],\
"Status": "ready",\
"ContextAttributes": [\
{\
"Key": "Recommended value",\
"Value": "8.0.mysql_aurora.3.04.2"\
},\
{\
"Key": "Current engine version",\
"Value": "8.0.mysql_aurora.3.04.1"\
}\
]\
}\
```\
### Sortie console AWS\
Dans la console AWS, sur le service RDS, les Recommandations apparaissent dans le menu de gauche. Par exemple :\
\
### **Liste des recommandations RDS**\
Depuis la liste des recommandations, vous verrez les serveurs accompagnés de la mention is not running the latest monitor DB engine version.\
\
### Plus d'informations sur une recommandation spécifique\
Vous pouvez également afficher davantage de détails sur la recommandation pour examiner la configuration complète de la ressource et accéder à la documentation associée.\
\
En conclusion\
En combinant ces informations avec une tâche planifiée régulièrement pour capturer et partager ces notifications, vous pourrez vous préparer sereinement à une mise à niveau de version mineure recommandée. Des étapes de validation supplémentaires et une procédure de récupération adaptées à vos exigences et ressources métier renforceront considérablement la confiance dans l'absence d'incidence sur la production lors des mises à niveau de versions mineures.\