À propos de la topologie en nuage fiable et résiliente

L'architecture d'une application fiable dans le nuage est généralement différente d'une architecture d'application traditionnelle. Historiquement, vous avez peut-être acheté du matériel redondant haut de gamme pour réduire la probabilité de défaillance d'une plate-forme d'application complète, dans le nuage, il est important de reconnaître, dès le départ, que les défaillances se produiront. Au lieu d'essayer d'éviter complètement les défaillances, l'objectif est de minimiser les effets d'un seul composant défaillant (point de défaillance unique ou SPOF). Suivez ces meilleures pratiques pour intégrer la fiabilité à chaque étape de votre processus de conception.

Les applications fiables sont :

Résilientes et récupérées en douceur en cas de défaillance, elles continuent de fonctionner avec un minimum de temps d'arrêt et de pertes de données avant une récupération complète.
Haute disponibilité (HA) et exécution selon la conception dans un état sain sans temps d'arrêt important.
Protégé contre les défaillances de région grâce à une bonne conception de reprise 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 en nuage, utilisez les outils suivants pour améliorer 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 nuage et des besoins de l'entreprise.
Appliquer les meilleures pratiques architecturales.
Suivez les pratiques éprouvées, identifiez les points de défaillance possibles dans l'architecture et déterminez comment l'application réagira à la défaillance.
Effectuez des tests avec des simulations et des basculements forcés.
Simulez les défaillances, 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 automatisez dans la mesure du possible.
Surveiller l'état des applications.
Détectez les défaillances, surveillez les indicateurs des défaillances potentielles et évaluez l'état de vos applications.
Gérer les défaillances et les sinistres.
Déterminez quand un échec se produit et déterminez comment y remédier en fonction de 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 nuage et des besoins de l'entreprise.

Tenez compte des points suivants lors de l'identification de vos besoins d'affaires et faites correspondre votre plan de fiabilité à ceux-ci :

Identifier les charges de travail et leurs besoins
Une charge de travail est une fonction ou une tâche distincte qui est logiquement séparée des autres charges de travail, en termes de logique applicative et d'exigences de stockage de données. Chaque charge de travail a des exigences différentes en matière de disponibilité, d'extensibilité, de cohérence des données et de reprise 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 de mois, mais peut traiter l'échec à d'autres moments. Pour garantir la disponibilité, 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 les chemins critiques
Tous les composants de votre système ne sont peut-être pas aussi importants que les 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 si nécessaire. Déterminez où se trouvent ces composants et, inversement, où se trouvent les parties essentielles de votre charge de travail. Cela vous aidera à définir vos paramètres de disponibilité et de fiabilité et à planifier vos stratégies de récupération afin de hiérarchiser les composants d'importance la plus élevée.
Identifier les dépendances externes et l'effet d'une défaillance en aval
Si votre charge de travail dépend de services externes, une défaillance de ces dépendances peut avoir une incidence négative sur la disponibilité de la charge de travail. Mettre en œuvre des méthodes de découplage de l'intégration pour l'isoler contre les défaillances en aval.
Déterminer les exigences de disponibilité de la charge globale
La haute disponibilité est normalement définie en termes de temps d'activité. Une cible haute disponibilité de 99 % par exemple 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 (CNS) pour chacun de ses services, qui décrit les engagements d'Oracle en matière de temps de disponibilité et de connectivité à ces services. Vous devez les vérifier pour voir comment ils correspondent à vos besoins. Certains services sur OCI offrent des niveaux élevés de haute disponibilité intégrés, en particulier les services gérés Oracle tels que la base de données autonome. Pour vous assurer qu'une architecture d'application répond aux exigences de votre entreprise, définissez des CNS cibles pour chaque charge de travail, y compris les dépendances externes. Prendre en compte le coût et la complexité de la conformité aux exigences de disponibilité, en plus des dépendances d'application.
Établissez vos mesures de récupération - objectif de temps de récupération (ODR) et objectif de point de récupération (OPR)
L'ODR est le temps maximum acceptable pendant lequel une application peut être indisponible après un incident de sinistre.

L'OPR est la durée maximale de perte de données acceptable en cas de sinistre.

Pour obtenir 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 organisation.

Les sauvegardes incrémentielles pour le stockage fournissent une 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 politiques de sauvegarde prédéfinies d'Oracle pour le stockage de volumes par blocs OCI : Bronze, Argent et Or. Chaque politique de sauvegarde comprend des 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 un sinistre
Avoir des plans et des exigences de reprise après sinistre bien documentés est important, mais la nature chaotique d'un tel événement peut créer de la confusion. Comprendre ce qui constitue un sinistre pour votre entreprise, identifier les rôles clés qui seront nécessaires lors d'un sinistre et établir un plan de communication bien défini pour lancer une réponse aux sinistres.
Prendre en compte les coûts
D'un point de vue FinOps, examinez les implications financières des différentes stratégies de fiabilité. Cela vous aide à faire des choix éclairés sur vos exigences de disponibilité et de récupération.

Appliquer les meilleures pratiques architecturales

Lors de la conception de votre architecture, concentrez-vous sur la mise en œuvre de pratiques qui répondent aux besoins de votre entreprise, identifiez les points de défaillance et réduisez la portée des défaillances.

Tenez compte des meilleures pratiques suivantes :

Déterminer où les échecs peuvent survenir
Analysez votre architecture pour identifier les types de défaillance que votre application peut rencontrer, les effets potentiels de chacune d'elles et les stratégies de récupération possibles.
Déterminez le niveau de redondance requis, en fonction des exigences de haute disponibilité et de reprise après sinistre
Le niveau de redondance requis pour chaque charge de travail dépend des besoins et des facteurs de votre entreprise quant au coût global de votre application.
Conception pour l'évolutivité
Une application en nuage doit être en mesure de s'adapter pour tenir compte des changements dans l'utilisation. Commencez par des composants discrets et concevez l'application pour répondre automatiquement aux modifications de charge lorsque 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 répartir les demandes
L'équilibrage de la charge distribue les demandes de votre application aux instances de service saines en supprimant la rotation des instances non saines. L'externalisation des informations d'état rendra l'ajustement dorsal transparent pour l'utilisateur final. Si l'état est suivi dans la session, la persistance peut être nécessaire.
Établissez des exigences de disponibilité et de résilience dans votre conception
La résilience est la capacité d'un système à se remettre des échecs 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 la prévention des points de défaillance uniques et la décomposition des charges de travail par objectif de niveau de service. Utilisez les fonctions standard de votre couche de données, telles que la continuité des applications et les transactions asynchrones pour assurer à la fois disponibilité et résilience.
Mettre en oeuvre la récupération après sinistre
Concevez votre solution pour répondre aux exigences RTO et RPO identifiées. Assurez-vous de mettre en ligne tous les composants de votre solution de reprise après sinistre au sein de votre ODR. Protégez vos données afin de répondre à votre RPO. La façon dont vous stockez, sauvegardez et répliquez des données est essentielle.
- Sauvegardez vos données
  Même avec un environnement de reprise après sinistre entièrement répliqué, les sauvegardes régulières restent critiques. Sauvegardez et validez les données régulièrement, et assurez-vous qu'aucun compte utilisateur unique n'a accès aux données de production et de sauvegarde.
- Sélectionner des méthodes de réplication pour les données d'application
  Vos données d'application sont stockées dans différents magasins de données et peuvent avoir des exigences de disponibilité différentes. Évaluez 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 d'OPR.
- Comprendre les implications du basculement et son effet sur la préparation aux catastrophes
  Devrez-vous instancier une autre région pour la réplication afin de répondre aux exigences de vos charges de travail? Devrez-vous vous préoccuper de la cohérence des données lors du basculement?
- Documentez et testez vos processus de basculement et de restauration automatique
  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 précises et faciles à suivre.
- Assurez-vous que le plan de récupération de données répond à votre objectif de délai de récupération
  Assurez-vous que votre stratégie de sauvegarde et de réplication prévoit des temps de récupération des données qui répondent à votre objectif de point de reprise (RTO) et à votre objectif de point de reprise (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.

Tester périodiquement avec des simulations et des basculements forcés

Les tests de fiabilité nécessitent de mesurer le fonctionnement de la charge globale de bout en bout dans des conditions de défaillance qui ne se produisent que par intermittence.

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 des scénarios courants (y compris des combinaisons de pannes) et le temps de récupération.
Identifier les défaillances qui se produisent uniquement sous la charge
Tester la charge maximale, à l'aide de données de production ou de 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 exercices de récupération après sinistre
Mettez en place un plan de reprise après sinistre et testez-le périodiquement pour vous assurer qu'il fonctionne.
Effectuer des tests de basculement et de reprise après incident
Assurez-vous que les services dépendants de votre application basculent et basculent dans l'ordre approprié.
Exécuter les tests de simulation
Les tests de scénarios réels peuvent mettre en évidence les problèmes qui doivent être résolus. Les scénarios doivent être contrôlables et ne pas perturber l'entreprise. Informer la gestion des plans de test de simulation.
Sondes de santé de test
Configurer des sondes d'état pour les équilibreurs de charge et les gestionnaires du trafic afin de vérifier les composants système critiques. Testez-les pour vous assurer qu'ils répondent correctement.
Systèmes de surveillance des essais
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 les services de tierce partie dans les scénarios de test
Testez les points de défaillance possibles en raison d'une interruption de service de tierce partie, en plus de la récupération.
En savoir plus sur les 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 les applications de manière uniforme

Le déploiement comprend 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 devraient être éliminés, bien que cela puisse être acceptable dans des environnements inférieurs pour favoriser la vitesse et la flexibilité.
Tirer parti de l'automatisation pour tester le code avant le déploiement
Il est essentiel de tester les bogues, les vulnérabilités de sécurité, les fonctionnalités, les performances et les intégrations pour minimiser les problèmes détectés par les utilisateurs finaux. Les échecs de test doivent empêcher la libération du code en production.
Concevez votre processus de lancement pour maximiser la disponibilité
Si votre processus de version nécessite que les services soient hors ligne pendant le déploiement, votre application n'est pas disponible tant qu'elle n'est pas de nouveau en ligne. Tirer parti des fonctions de préparation et de production de la plate-forme. Si possible, lancez de nouveaux déploiements à un sous-ensemble d'utilisateurs pour surveiller les défaillances en début d'heure.
Disposer d'un plan de repositionnement pour le déploiement
Concevez un processus d'annulation pour revenir à une dernière version dont le fonctionnement a été vérifié et réduire les temps d'arrêt en cas d'échec du déploiement. L'automatisation du repositionnement en cas d'échec du déploiement peut éviter des temps d'arrêt inutiles.
Déploiements de journaux et de vérification
Si vous utilisez des techniques de déploiement par étapes, plusieurs versions de votre application sont en production. Mettre en œuvre une stratégie de journalisation robuste pour capturer autant d'informations spécifiques à la version que possible.
Documenter le processus de lancement de la demande
Définissez et documentez clairement votre processus de lancement et assurez-vous qu'il est disponible pour l'ensemble de l'équipe des opérations.

Surveiller l'état des applications

Mettez en œuvre 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.

Mettre en œuvre le traçage autour des appels de service
Les données de référence sur le rendement peuvent aider à fournir des données de tendance qui peuvent être utilisées pour identifier de manière proactive les problèmes de rendement avant qu'ils n'affectent les utilisateurs.
Mettre en œuvre des sondes de santé
Exécutez-les régulièrement depuis l'extérieur de l'application pour identifier la dégradation de l'état et des performances de l'application. Ces sondes devraient être plus que des tests de page statiques, elles devraient refléter la santé globale de l'application.
Vérifier les flux de travail longs
La détection précoce des problèmes peut réduire la nécessité d'annuler l'ensemble du flux de travail ou d'exécuter plusieurs transactions de compensation.
Tenir à jour le système, les applications et les journaux de vérification
Utilisez un service de journalisation centralisé pour stocker vos journaux.
Mettre en place un système d'alerte précoce
Identifier les indicateurs clés de rendement (ICR) de l'état d'une application, tels que les exceptions transitoires et la latence des appels à distance, et définir des valeurs de seuil appropriées pour chacun d'entre eux. Envoyer une alerte aux opérations lorsque la valeur de seuil est atteinte.
Former plusieurs opérateurs pour surveiller l'application et effectuer des étapes de récupération manuelle
Assurez-vous qu'il y a toujours au moins un opérateur formé actif.

Gérer les défaillances et les sinistres

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

Planifier la gestion des incidents
Définir 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.
Documentez et testez votre plan de récupération après sinistre
Écrivez un plan de reprise après sinistre qui reflète l'incidence des défaillances d'application sur l'entreprise. Automatisez autant que possible le processus de récupération et documentez toutes les étapes manuelles. Testez régulièrement votre processus de reprise 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 reprise après sinistre sont bien coordonnés et que les applications sont priorisées en fonction de la valeur commerciale.
Se préparer aux défaillances d'applications
Préparez-vous pour toute une série de défaillances, notamment celles qui sont traitées automatiquement, celles qui entraînent une réduction des fonctionnalités et celles qui entraînent l'indisponibilité de l'application. L'application doit informer les utilisateurs des problèmes temporaires.
Récupérer après une corruption de 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 corrompues à partir d'une sauvegarde.
récupérer après une panne de réseau
Vous pouvez utiliser les données mises en cache pour une exécution locale avec une fonctionnalité d'application réduite. Sinon, envisagez un temps d'arrêt de l'application ou un basculement vers une autre région. Stockez vos données dans un autre emplacement jusqu'à ce que la connectivité soit rétablie.
Récupérer après une défaillance de service dépendant
Déterminez quelles fonctionnalités sont encore disponibles et comment l'application doit réagir.
Récupérer après une interruption de service à l'échelle de la région
Les interruptions de service à l'échelle de la région sont rares, mais vous devriez avoir une stratégie pour y remédier, en particulier pour les applications critiques. Vous pouvez peut-être redéployer l'application dans une autre région ou redistribuer le trafic.
Apprendre des tests de récupération après sinistre et améliorer les processus
Assurez-vous que tous les problèmes rencontrés lors des tests de reprise après sinistre sont saisis et que les plans de correction de ces problèmes sont résolus lors de tests ou de basculements futurs.