A propos des meilleures pratiques pour la conception de topologies cloud fiables et résilientes

L'architecture d'une application fiable dans le cloud est généralement différente d'une architecture d'application traditionnelle. Bien qu'historiquement vous ayez peut-être acheté du matériel redondant haut de gamme pour minimiser les risques de défaillance de l'ensemble d'une plate-forme d'application, dans le cloud, il est important de reconnaître à l'avance que des pannes se produiront. Au lieu d'essayer d'empêcher complètement les pannes, l'objectif est de minimiser les effets d'un seul composant défaillant (point de panne unique ou SPOF). Suivez ces meilleures pratiques pour intégrer la fiabilité à chaque étape de votre processus de conception.

Les applications fiables sont les suivantes :

Résilientes et récupérées grâce aux pannes, elles continuent de fonctionner avec un temps d'arrêt minimal et une perte de données avant une récupération complète.
Haute disponibilité et exécution dans un état sain sans temps d'arrêt significatif.
Protection contre les pannes de région grâce à une bonne conception de récupération après sinistre.

Comprendre comment ces éléments fonctionnent ensemble et comment ils affectent les coûts est essentiel pour créer une application fiable. Il peut vous aider à déterminer le temps d'arrêt acceptable, le coût potentiel pour votre entreprise et les fonctions nécessaires lors d'une récupération.

Architecte pour la fiabilité

Lors de la création d'une application cloud, utilisez les éléments suivants pour renforcer la fiabilité.

Définissez les exigences.
Définissez vos exigences en matière de disponibilité et de récupération en fonction des charges de travail que vous apportez au cloud et des besoins de votre entreprise.
Appliquer les meilleures pratiques en matière d'architecture.
Suivez les pratiques éprouvées, identifiez les points de défaillance possibles dans l'architecture et déterminez comment l'application répondra aux défaillances.
Effectuer des tests avec des simulations et des basculements forcés.
Simulez les pannes, déclenchez les basculements forcés et testez la détection et la récupération de ces défaillances.
Déployez les applications de manière cohérente.
Mise en production à l'aide de processus fiables et reproductibles et automatisation dans la mesure du possible.
Surveiller l'état des applications.
Détectez les pannes, surveillez les indicateurs de pannes potentielles et évaluez l'état de vos applications.
Gérer les pannes et les sinistres.
Identifiez le moment où une défaillance se produit et déterminez comment y remédier en fonction des stratégies établies.

Définir les exigences

Définissez vos exigences en matière de disponibilité et de récupération en fonction des charges de travail que vous apportez au cloud et des besoins de votre entreprise.

Tenez compte des points suivants lors de l'identification des besoins de votre entreprise et adaptez-leur votre plan de fiabilité :

Identifier les charges de travail et leurs exigences
Une charge globale est une fonction ou une tâche distincte qui est logiquement séparée des autres charges globales, en termes de logique métier et de besoins de stockage de données. Chaque charge de travail a des exigences différentes en matière de disponibilité, d'évolutivité, de cohérence des données et de récupération après sinistre.
Déterminer les modèles d'utilisation
La façon dont une application est utilisée joue un rôle dans les exigences. Identifier les différences dans les exigences pendant les périodes critiques et non critiques. Par exemple, une application traitant le traitement de fin de mois ne peut pas échouer pendant la fin du mois, mais peut gérer l'échec à d'autres moments. Pour garantir le temps d'activité, des composants ou une redondance supplémentaires peuvent être ajoutés pendant les périodes critiques et supprimés lorsqu'ils n'ajoutent plus de valeur.
Identifier les composants et chemins critiques
Tous les composants de votre système peuvent ne pas être aussi importants que d'autres. Par exemple, vous pouvez avoir un composant facultatif qui ajoute une valeur incrémentielle, mais que la charge globale peut s'exécuter sans le cas échéant. Comprenez où se trouvent ces composants et, inversement, où se trouvent les parties critiques de votre charge de travail. Cela vous aidera à définir vos indicateurs de disponibilité et de fiabilité et à planifier vos stratégies de récupération afin de hiérarchiser les composants d'importance maximale.
Identifier les dépendances externes et l'effet d'une défaillance en aval
Si votre charge globale dépend de services externes, une défaillance de ces dépendances peut avoir un impact négatif sur la disponibilité de la charge globale. Implémenter des méthodes de découplage de l'intégration pour isoler les défaillances en aval.
Déterminer les exigences de disponibilité de la charge de travail
La haute disponibilité (HA) est normalement définie en termes de temps de disponibilité cible. Par exemple, une cible HA de 99 % signifie qu'une ressource particulière peut être indisponible pendant 3,65 jours par an. Oracle Cloud Infrastructure (OCI) est conçu pour vous fournir un environnement hautement disponible. OCI publie un contrat de niveau de service (SLA) pour chacun de ses services, qui décrit les engagements d'Oracle en matière de disponibilité et de connectivité à ces services. Vous devez les examiner pour voir comment ils correspondent à vos exigences. Certains services sur OCI disposent de niveaux élevés de haute disponibilité intégrés, en particulier les services gérés par Oracle tels que la base de données autonome. Pour vous assurer qu'une architecture d'application répond aux besoins de votre entreprise, définissez des contrats de niveau de service cible pour chaque charge de travail, y compris les dépendances externes. Prendre en compte le coût et la complexité du respect des exigences de disponibilité, en plus des dépendances d'application.
Etablissez vos mesures de récupération — objectif de temps de récupération (RTO) et objectif de point de récupération (RPO)
RTO est la durée maximale acceptable pendant laquelle une application peut être indisponible après un incident de sinistre.

Le RPO correspond à la durée maximale de perte de données acceptable lors d'un sinistre.

Pour dériver ces valeurs, effectuez une évaluation des risques et assurez-vous de comprendre le coût et le risque de temps d'arrêt ou de perte de données dans votre entreprise.

Les sauvegardes incrémentielles pour le stockage assurent la sécurité contre la perte de données via des points de récupération. La période entre chaque sauvegarde limite la quantité maximale de données perdues après la restauration à partir d'une sauvegarde.

Par exemple, envisagez d'utiliser l'une des stratégies de sauvegarde prédéfinies d'Oracle pour le stockage OCI Block Volumes : Bronze, Silver et Gold. Chaque stratégie de sauvegarde est composée de programmations avec une fréquence de sauvegarde incrémentielle définie, par exemple mensuelle, hebdomadaire ou quotidienne, et une période de conservation définie.
Définir une catastrophe
Il est important de disposer de plans et d'exigences de reprise après sinistre bien documentés, mais la nature chaotique d'un tel événement peut créer de la confusion. Comprenez ce qui constitue une catastrophe pour votre entreprise, identifiez les rôles clés qui seront nécessaires pendant une catastrophe et établissez un plan de communication bien défini pour initier une intervention en cas de catastrophe.
Prendre en compte les coûts
D'un point de vue FinOps, examinez les incidences financières des différentes stratégies de fiabilité. Cela vous aide à faire des choix éclairés concernant vos exigences en matière de disponibilité et de récupération.

Appliquer les meilleures pratiques en matière d'architecture

Lors de la conception de votre architecture, concentrez-vous sur l'implémentation de pratiques qui répondent aux besoins de votre entreprise, identifient les points de défaillance et minimisent la portée des défaillances.

Tenez compte des meilleures pratiques suivantes :

Déterminer où les pannes peuvent survenir
Analysez votre architecture pour identifier les types d'échec que votre application peut rencontrer, les effets potentiels de chacun et les stratégies de récupération possibles.
Déterminer le niveau de redondance requis, en fonction des exigences de haute disponibilité et de récupération après sinistre
Le niveau de redondance requis pour chaque charge de travail dépend des besoins et des facteurs de votre entreprise dans le coût global de votre application.
Conception pour l'évolutivité
Une application cloud doit pouvoir évoluer pour s'adapter aux changements d'utilisation. Commencez par des composants distincts et concevez l'application pour qu'elle réponde automatiquement aux modifications de charge chaque fois que cela est possible. Gardez à l'esprit les limites de mise à l'échelle pendant la conception afin que vous puissiez vous développer facilement à l'avenir.
Utiliser l'équilibrage de la charge pour distribuer les demandes
L'équilibrage de la charge distribue les demandes de votre application aux instances de service en bon état en supprimant les instances en mauvais état de la rotation. L'externalisation des informations d'état rendra le redimensionnement du back-end transparent pour l'utilisateur final. Si l'état est suivi dans la session, l'adhésion peut être nécessaire.
Intégrez les exigences de disponibilité et de résilience dans votre conception
La résilience est la capacité d'un système à récupérer des défaillances et à continuer à fonctionner. La disponibilité est la proportion de temps pendant lequel votre système est fonctionnel et fonctionnel. Mettez en œuvre les meilleures pratiques de haute disponibilité, telles que l'évitement des points de défaillance uniques et la décomposition des charges de travail par objectif de niveau de service. Utiliser les fonctionnalités standard de votre couche de données, telles que la continuité des applications et les transactions asynchrones pour garantir à la fois disponibilité et résilience.
Implémenter la récupération après sinistre
Concevez votre solution pour répondre aux exigences RTO et RPO identifiées. Assurez-vous que vous pouvez mettre en ligne tous les composants de votre solution de récupération après sinistre dans votre RTO. Protégez vos données afin de répondre à votre RPO. La manière dont vous stockez, sauvegardez et répliquez les données est essentielle.
- Sauvegardez vos données
  Même dans un environnement de récupération après sinistre entièrement répliqué, les sauvegardes régulières restent essentielles. Sauvegardez et validez régulièrement les données, et assurez-vous qu'aucun compte utilisateur n'a accès aux données de production et de sauvegarde.
- Choisir des méthodes de réplication pour les données d'application
  Les données d'application sont stockées dans différents magasins de données et peuvent avoir des exigences de disponibilité différentes. Evaluez les méthodes et les emplacements de réplication pour chaque type de magasin de données afin de vous assurer qu'ils répondent à vos exigences en matière de haute disponibilité et de RPO.
- Comprendre les implications d'un basculement et son effet sur la préparation aux catastrophes
  Devez-vous instancier une autre région pour la réplication afin de répondre aux exigences de vos charges globales ? Devez-vous vous soucier de la cohérence des données lors du rétablissement ?
- Documenter et tester vos processus de basculement et de rétablissement
  Documentez clairement les instructions pour basculer vers un nouveau magasin de données et testez-les régulièrement pour vous assurer qu'elles sont exactes et faciles à suivre.
- Assurez-vous que votre plan de récupération de données respecte votre RTO
  Assurez-vous que votre stratégie de sauvegarde et de réplication prévoit des temps de récupération des données qui correspondent à votre RTO ainsi qu'à votre RPO. Prenez en compte tous les types de données que votre application utilise, y compris les données de référence, les fichiers et les bases de données.

Effectuer des tests périodiques avec des simulations et des basculements forcés

Les tests de fiabilité nécessitent de mesurer les performances de la charge de travail de bout en bout dans des conditions de défaillance qui ne se produisent que de manière intermittente.

Tester les scénarios d'échec courants en déclenchant des échecs réels ou en les simulant
Utilisez les tests d'injection de pannes pour tester les scénarios courants (y compris les combinaisons de pannes) et le temps de récupération.
Identifier les défaillances qui se produisent uniquement en cas de charge
Testez la charge maximale, en utilisant des données de production ou des données synthétiques aussi proches que possible des données de production, pour voir comment l'application se comporte dans des conditions réelles.
Exécuter des analyses de récupération après sinistre
Mettez en place un plan de récupération après sinistre et testez-le régulièrement pour vous assurer qu'il fonctionne.
Effectuer des tests de basculement et de rétablissement
Assurez-vous que les services dépendants de votre application basculent et rétablissent dans le bon ordre.
Exécuter des tests de simulation
Tester des scénarios réels peut mettre en évidence les problèmes à résoudre. Les scénarios doivent être contrôlables et ne pas perturber l'entreprise. Informer la gestion des plans de test de simulation.
Tester les sondes d'intégrité
Configurez des sondes d'intégrité pour les équilibreurs de charge et les gestionnaires de trafic afin de vérifier les composants système critiques. Testez-les pour vous assurer qu'ils répondent correctement.
Tester les systèmes de surveillance
Assurez-vous que les systèmes de surveillance signalent de manière fiable des informations critiques et des données précises pour aider à identifier les défaillances potentielles.
Inclure des services tiers dans les scénarios de test
Testez les points de défaillance possibles en raison d'une interruption de service tierce, en plus de la récupération.
Apprendre des problèmes rencontrés lors des tests
Si les tests révèlent des problèmes ou des lacunes, assurez-vous qu'ils sont identifiés et corrigés en ajoutant une surveillance supplémentaire ou en ajustant les processus opérationnels.

Déployer des applications de façon cohérente

Le déploiement inclut le provisionnement des services et des ressources Oracle Cloud Infrastructure (OCI), le déploiement du code d'application et l'application des paramètres de configuration. Une mise à jour peut impliquer les trois tâches ou un sous-ensemble d'entre elles.

Automatisez votre processus de déploiement d'applications
Automatisez autant de processus que possible. Si possible, les déploiements manuels en production doivent être éliminés, bien que cela puisse être acceptable dans les environnements inférieurs pour favoriser la vitesse et la flexibilité.
Tirez parti de l'automatisation pour tester votre code avant le déploiement
Les tests de bugs, de vulnérabilités de sécurité, de fonctionnalités, de performances et d'intégrations sont essentiels pour minimiser les problèmes détectés par les utilisateurs finaux. Les échecs de test doivent empêcher la mise en production du code.
Concevez votre processus de publication pour maximiser la disponibilité
Si votre processus de publication nécessite que les services soient mis hors ligne pendant le déploiement, votre application n'est pas disponible tant qu'elle n'est pas remise en ligne. Tirer parti des fonctionnalités de préparation et de production de la plate-forme. Si possible, publiez de nouveaux déploiements vers un sous-ensemble d'utilisateurs afin de surveiller les pannes en début d'heure.
disposer d'un plan d'annulation pour le déploiement
Concevez un processus d'annulation pour revenir à une dernière version correcte connue et réduire les temps d'arrêt en cas d'échec d'un déploiement. L'automatisation de l'annulation en cas d'échec du déploiement peut empêcher un temps d'inactivité inutile.
Déploiements de journaux et d'audit
Si vous utilisez des techniques de déploiement intermédiaire, plusieurs versions de votre application sont exécutées en production. Implémentez une stratégie de journalisation robuste pour capturer autant d'informations spécifiques à la version que possible.
Documenter le processus de lancement de candidature
Définissez et documentez clairement votre processus de publication, et assurez-vous qu'il est disponible pour toute l'équipe opérationnelle.

Surveiller l'état des applications

Implémentez les meilleures pratiques en matière de surveillance et d'alertes dans votre application afin de détecter les défaillances et d'alerter un opérateur pour les corriger.

Implémenter le suivi des appels de service
Les données de performance de référence peuvent aider à fournir des données de tendance qui peuvent être utilisées pour identifier de manière proactive les problèmes de performance avant qu'ils n'affectent les utilisateurs.
Implémenter des sondes d'intégrité
Exécutez-les régulièrement à partir de l'extérieur de l'application pour identifier la dégradation de l'état et des performances de l'application. Ces sondes doivent être plus que de simples tests de page statiques, elles doivent refléter l'intégrité globale de l'application.
Vérifier les workflows à longue exécution
La détection précoce des problèmes peut réduire la nécessité d'annuler l'intégralité du workflow ou d'exécuter plusieurs transactions de compensation.
Maintenance des journaux système, d'application et d'audit
Utilisez un service de journalisation centralisé pour stocker vos journaux.
Configurer un système d'alerte rapide
Identifiez les indicateurs clés de performance (KPI) de l'état d'une application, tels que les exceptions transitoires et la latence des appels distants, et définissez des valeurs de seuil appropriées pour chacune d'elles. Envoyer une alerte aux opérations lorsque la valeur de seuil est atteinte.
Former plusieurs opérateurs à la surveillance de l'application et à l'exécution des étapes de récupération manuelle
Assurez-vous qu'au moins un opérateur formé est toujours actif.

Gérer les échecs et les catastrophes

Créez un plan de récupération et assurez-vous qu'il couvre la restauration des données, les pannes réseau, les pannes de service dépendantes et les perturbations de service à l'échelle de la région. Tenez compte de vos machines virtuelles, de votre stockage, de vos bases de données et d'autres services OCI dans votre stratégie de récupération.

Planifier la gestion des incidents
Définissez des rôles et des responsabilités clairs pour la gestion des incidents afin de maintenir le fonctionnement des services ou de les restaurer le plus rapidement possible.
Documentation et test de votre plan de récupération après sinistre
Ecrivez un plan de récupération après sinistre qui reflète l'impact commercial des pannes d'application. Automatisez le processus de récupération autant que possible et documentez les étapes manuelles. Testez régulièrement votre processus de récupération après sinistre pour valider et améliorer le plan.
Comprendre les rôles clés nécessaires à la coordination de la récupération après sinistre
Assurez-vous que les efforts de récupération après sinistre sont bien coordonnés et que les applications sont hiérarchisées en fonction de la valeur commerciale.
Préparation à la défaillance des applications
Préparez-vous à une série de pannes, y compris les pannes gérées automatiquement, celles qui entraînent une réduction des fonctionnalités et celles qui rendent l'application indisponible. L'application doit informer les utilisateurs des problèmes temporaires.
Récupération suite à une altération des données
Si une défaillance se produit dans un magasin de données, vérifiez les incohérences de données lorsque le magasin redevient disponible, en particulier si les données ont été répliquées. Restaurez les données endommagées à partir d'une sauvegarde.
Récupération après une panne réseau
Vous pouvez peut-être utiliser des données mises en cache pour une exécution locale avec des fonctionnalités d'application réduites. Sinon, envisagez un temps d'inactivité de l'application ou basculez vers une autre région. Stockez vos données dans un autre emplacement jusqu'à ce que la connectivité soit restaurée.
Récupération suite à la panne d'un service dépendant
Déterminez quelles fonctionnalités sont encore disponibles et comment l'application doit répondre.
Récupération suite à une interruption de service dans toute une région
Les interruptions de service à l'échelle de la région sont rares, mais vous devez avoir une stratégie pour y remédier, en particulier pour les applications critiques. Vous pouvez redéployer l'application vers une autre région ou redistribuer le trafic.
En savoir plus sur les tests DR et améliorer les processus
Assurez-vous que tous les problèmes rencontrés lors des tests DR sont capturés et que les plans de résolution de ces problèmes sont résolus lors de tests ou de basculements futurs.