Ce document du framework d'architecture Google Cloud présente les bonnes pratiques à suivre pour exécuter votre service de manière fiable, par exemple pour déployer des mises à jour, exécuter des services dans des environnements de production et tester les défaillances. La conception d'une architecture fiable doit couvrir l'ensemble du cycle de vie de votre service, et pas seulement la conception logicielle.
Choisissez des noms appropriés pour les applications et les services.
Évitez d'utiliser des noms de code internes dans des fichiers de configuration de production, car ils peuvent prêter à confusion, en particulier pour les employés récents, ce qui peut augmenter la durée des interruptions (TTM, temps nécessaire à la résolution). Dans la mesure du possible, choisissez des noms propres pour l'ensemble de vos applications, services et ressources système critiques telles que les VM, les clusters et les instances de base de données, en fonction de leurs limites respectives de longueur de nom. Un nom adéquat décrit l'objectif de l'entité de façon précise, spécifique, unique et compréhensible pour tous ceux qui le voient. Un nom correct évite les acronymes, les noms de code, les abréviations et la terminologie potentiellement choquante, et ne crée pas de réponse publique négative, même s'il est publié en externe.
Mettre en œuvre des déploiements progressifs avec des tests en version Canary
Les modifications globales instantanées apportées aux binaires ou à la configuration des services sont fondamentalement risquées. Déployez les nouvelles versions des exécutables et les modifications de configuration de manière incrémentielle. Commencez avec un petit champ d'application, tel que quelques instances de VM dans une zone, puis développez progressivement le champ d'application. Effectuez un rollback rapide si la modification ne fonctionne pas comme prévu ou a un impact négatif sur les utilisateurs à n'importe quelle étape du déploiement. Votre objectif consiste à identifier et à résoudre les bugs lorsqu'ils n'affectent qu'une petite partie du trafic utilisateur, avant de déployer cette modification à l'échelle mondiale.
Configurez un système de tests Canary qui tient compte des modifications apportées aux services et effectue une comparaison A/B des métriques des serveurs modifiés avec les serveurs restants. Le système doit signaler tout comportement inattendu ou anormal. Si la modification ne fonctionne pas comme prévu, le système de tests Canary doit automatiquement interrompre les déploiements. Les problèmes peuvent être clairs, tels que des erreurs utilisateur, ou subtils, comme une augmentation de l'utilisation du processeur ou de la mémoire.
Il est préférable d'arrêter et de revenir à la première anomalie et de diagnostiquer les problèmes sans la pression de temps d'une panne. Une fois que la modification a réussi les tests en version Canary, propagez-la progressivement à des champs d'applications plus larges, par exemple vers une zone complète, puis vers une deuxième zone. Ainsi, le système modifié a le temps de traiter progressivement des volumes de trafic utilisateur plus importants afin d'exposer les bugs latents.
Pour en savoir plus, consultez la page Stratégies de déploiement et de test des applications.
Diffuser le trafic pour les promotions et les lancements planifiés
Vous pouvez avoir des événements promotionnels, tels que des ventes qui commencent à une heure précise, et encourager de nombreux utilisateurs à se connecter au service simultanément. Si tel est le cas, concevez le code client de façon à répartir le trafic sur quelques secondes. Utilisez des délais aléatoires avant de lancer des requêtes.
Vous pouvez également préchauffer le système. Lorsque vous préchauffez le système, vous lui envoyez le trafic utilisateur que vous attendez afin de vous assurer qu'il fonctionne comme prévu. Cela permet d'éviter les pics de trafic instantanés susceptibles d'entraîner le plantage de vos serveurs à l'heure de début programmée.
Automatiser la création, le test et le déploiement
Éliminez les opérations manuelles liées à votre processus de publication à l'aide de pipelines d'intégration continue et de livraison continue (CI/CD). Effectuez un déploiement et des tests d'intégration automatisés. Par exemple, créez un processus CI/CD moderne avec GKE.
Pour en savoir plus, consultez les sections Intégration continue, Livraison continue, Automatisation des tests et Automatisation du déploiement.
Se protéger contre les erreurs d'opérateur
Concevez vos outils opérationnels de manière à rejeter les configurations potentiellement non valides. Détectez et déclenchez une alerte lorsqu'une version de configuration est vide, partielle ou tronquée, corrompue, logiquement incorrecte ou inattendue, ou non reçue dans le délai attendu. Les outils doivent également rejeter les versions de configuration qui diffèrent trop de la version précédente.
Interdisez les modifications ou les commandes dont le champ d'application est trop large et potentiellement destructrices. Ces commandes générales peuvent être "Révoquer les autorisations de tous les utilisateurs", "Redémarrer toutes les VM de cette région" ou "Reformater tous les disques de cette zone". Ces modifications ne doivent être appliquées que si l'opérateur ajoute des options de ligne de commande de remplacement d'urgence ou des paramètres d'option lors du déploiement de la configuration.
Les outils doivent afficher l'ampleur des répercussions des commandes risquées, telles que le nombre de VM ayant un impact sur les modifications, et nécessiter une confirmation explicite de l'opérateur avant de poursuivre. Vous pouvez également utiliser des fonctionnalités pour verrouiller les ressources critiques et empêcher leur suppression accidentelle ou non autorisée, telles que les verrous des règles de conservation Cloud Storage.
Tester la reprise après échec
Testez régulièrement vos procédures opérationnelles afin de récupérer des défaillances de votre service. Sans tests réguliers, vos procédures peuvent ne pas fonctionner lorsque vous en avez besoin en cas de défaillance réelle. Les éléments à tester régulièrement incluent le basculement régional, l'annulation d'une version et la restauration des données à partir de sauvegardes.
Effectuer des tests de reprise après sinistre
Comme pour les tests de reprise après échec, n'attendez pas qu'un sinistre se produise. Testez et vérifiez régulièrement vos procédures et processus de reprise après sinistre.
Vous pouvez créer une architecture système pour fournir une haute disponibilité. Cette architecture ne chevauche pas entièrement la reprise après sinistre, mais il est souvent nécessaire de prendre en compte la haute disponibilité lorsque vous pensez aux valeurs d'objectif de temps de récupération (RTO) et d'objectif de point de récupération (RPO).
La haute disponibilité vous aide à atteindre ou à dépasser un niveau de performances opérationnelles convenu, tel que le temps d'activité. Lorsque vous exécutez des charges de travail de production sur Google Cloud, vous pouvez déployer une instance de secours passive ou active dans une deuxième région. Avec cette architecture, l'application continue de fournir le service depuis la région non affectée en cas de sinistre dans la région principale. Pour en savoir plus, consultez la page Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud.
Pratiquer l'ingénierie du chaos
Envisagez d'utiliser l'ingénierie du chaos dans vos pratiques de test. Intégrez les défaillances réelles dans différents composants des systèmes de production en charge dans un environnement sécurisé. Cette approche permet de garantir qu'il n'y a pas d'impact global sur le système, car votre service gère correctement les défaillances à chaque niveau.
Les défaillances que vous injectez dans le système peuvent inclure des tâches de plantage, des erreurs et des délais avant expiration sur les RPC, ou des réductions de la disponibilité des ressources. Utilisez l'injection de pannes aléatoires pour tester les défaillances intermittentes (flapping) dans les dépendances de service. Ces comportements sont difficiles à détecter et à atténuer en production.
L'ingénierie du chaos garantit que les résultats de ces tests sont minimisés et contenus. Traitez ces tests comme des pratiques pour les pannes réelles et utilisez toutes les informations collectées pour améliorer votre réponse aux pannes.
Étape suivante
- Créez des alertes efficaces (document suivant de cette série).
Découvrez d'autres catégories du framework d'architecture, telles que la conception du système, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.