Ce document du Google Cloud Well-Architected Framework : perspective FSI présente les principes et les recommandations pour concevoir, déployer et exploiter des charges de travail fiables du secteur des services financiers (FSI) dansGoogle Cloud. Ce document explique comment intégrer des pratiques de fiabilité avancées et l'observabilité dans vos plans architecturaux. Les recommandations de ce document sont conformes au pilier de fiabilité du framework Well-Architected.
Pour les institutions financières, une infrastructure fiable et résiliente est à la fois une nécessité commerciale et un impératif réglementaire. Pour garantir la fiabilité des charges de travail FSI dansGoogle Cloud , vous devez comprendre et atténuer les points de défaillance potentiels, déployer les ressources de manière redondante et planifier la récupération. La résilience opérationnelle est un résultat de la fiabilité. Il s'agit de la capacité à absorber les perturbations, à s'y adapter et à s'en remettre. La résilience opérationnelle aide les organisations du secteur des services financiers à répondre à des exigences réglementaires strictes. Cela permet également d'éviter de causer un préjudice intolérable aux clients.
Les composants clés de la fiabilité dans Google Cloud sont les régions, les zones et les différents niveaux d'emplacement des ressources cloud : zonal, régional, multirégional et mondial. Vous pouvez améliorer la disponibilité en utilisant des services gérés, en distribuant les ressources, en implémentant des modèles de haute disponibilité et en automatisant les processus.
Exigences réglementaires
Les institutions financières sont soumises à des mandats de fiabilité stricts par des organismes de réglementation tels que le Federal Reserve System aux États-Unis, l'Autorité bancaire européenne dans l'UE et la Prudential Regulation Authority au Royaume-Uni. À l'échelle mondiale, les autorités de régulation mettent l'accent sur la résilience opérationnelle, qui est essentielle pour la stabilité financière et la protection des consommateurs. La résilience opérationnelle est la capacité à résister aux perturbations, à se rétablir efficacement et à maintenir les services critiques. Cela nécessite une approche harmonisée pour gérer les risques technologiques et les dépendances vis-à-vis des tiers.
Les exigences réglementaires dans la plupart des juridictions présentent les thèmes communs suivants :
- Cybersécurité et résilience technologique : renforcement des défenses contre les cybermenaces et garantie de la résilience des systèmes informatiques.
- Gestion des risques tiers : gestion des risques associés à l'externalisation de services auprès de fournisseurs de technologies de l'information et de la communication (TIC).
- Continuité de l'activité et réponse aux incidents : planification solide pour maintenir les opérations critiques en cas de perturbation et pour assurer une reprise efficace.
- Protéger la stabilité financière : assurer la solidité et la stabilité du système financier au sens large.
Les recommandations de fiabilité de ce document sont associées aux principes de base suivants :
- Prioriser les déploiements multizones et multirégionaux
- Éliminer les points de défaillance uniques
- Comprendre et gérer la disponibilité globale
- Mettre en place une stratégie de reprise après sinistre robuste
- Exploiter les services gérés
- Automatiser les processus de provisionnement et de récupération de l'infrastructure
Prioriser les déploiements multizones et multirégionaux
Pour les applications de services financiers critiques, nous vous recommandons d'utiliser une topologie multirégionale répartie sur au moins deux régions et sur trois zones dans chaque région. Cette approche est importante pour la résilience face aux pannes de zones et de régions. Les réglementations prescrivent souvent cette approche, car si une défaillance se produit dans une zone ou une région, la plupart des juridictions considèrent qu'une perturbation grave dans une deuxième zone est une conséquence plausible. En effet, lorsqu'un emplacement échoue, l'autre emplacement peut recevoir une quantité exceptionnellement élevée de trafic supplémentaire.
Tenez compte des recommandations suivantes pour renforcer la résilience face aux pannes de zone et de région :
- Privilégiez les ressources dont la portée géographique est plus large. Dans la mesure du possible, utilisez des ressources régionales plutôt que zonales, et des ressources multirégionales ou mondiales plutôt que régionales. Cette approche permet d'éviter de restaurer des opérations à l'aide de sauvegardes.
- Dans chaque région, utilisez trois zones au lieu de deux. Pour gérer les basculements, surprovisionnez la capacité d'un tiers de plus que l'estimation.
- Minimisez les étapes de récupération manuelle en implémentant des déploiements actif-actif comme dans les exemples suivants :
- Les bases de données distribuées telles que Spanner offrent une redondance et une synchronisation intégrées dans toutes les régions.
- La fonctionnalité de haute disponibilité de Cloud SQL fournit une topologie quasi active-active, avec des instances répliquées en lecture seule dans toutes les zones. Il fournit un objectif de point de récupération (RPO) entre les régions proche de 0.
- Répartissez le trafic utilisateur entre les régions à l'aide de Cloud DNS et déployez un équilibreur de charge régional dans chaque région. Un équilibreur de charge mondial est une autre option que vous pouvez envisager en fonction de vos besoins et de la criticité. Pour en savoir plus, consultez Avantages et risques de l'équilibrage de charge global pour les déploiements multirégionaux.
- Pour stocker des données, utilisez des services multirégionaux tels que Spanner et Cloud Storage.
Éliminer les points de défaillance uniques
Répartissez les ressources sur différents emplacements et utilisez des ressources redondantes pour éviter qu'un point de défaillance unique (SPOF) n'affecte l'ensemble de la pile d'applications.
Tenez compte des recommandations suivantes pour éviter les points de défaillance uniques :
- Évitez de déployer un seul serveur d'applications ou une seule base de données.
- Assurez-vous que les VM défaillantes sont recréées automatiquement en utilisant des groupes d'instances gérés (MIG).
- Répartissez le trafic de manière uniforme entre les ressources disponibles en implémentant l'équilibrage de charge.
- Utilisez des configurations à haute disponibilité pour les bases de données telles que Cloud SQL.
- Améliorez la disponibilité des données en utilisant des disques persistants régionaux avec réplication synchrone.
Pour en savoir plus, consultez Concevoir une infrastructure fiable pour vos charges de travail dans Google Cloud.
Comprendre et gérer la disponibilité globale
Sachez que la disponibilité globale ou agrégée d'un système est affectée par la disponibilité de chaque niveau ou composant du système. Le nombre de niveaux d'une pile d'application présente une relation inverse avec la disponibilité globale de la pile. Tenez compte des recommandations suivantes pour gérer la disponibilité globale :
Calculez la disponibilité globale d'une pile à plusieurs niveaux à l'aide de la formule disponibilité_niveau1 × disponibilité_niveau2 × … × disponibilité_niveauN.
Le schéma suivant montre le calcul de la disponibilité globale pour un système multicouche composé de quatre services :
Dans le schéma précédent, le service de chaque niveau offre une disponibilité de 99,9 %, mais la disponibilité globale du système est inférieure, à 99,6 % (0,999 x 0,999 x 0,999 x 0,999). En général, la disponibilité globale d'une pile à plusieurs niveaux est inférieure à celle du niveau qui offre la plus faible disponibilité.
Dans la mesure du possible, choisissez la parallélisation plutôt que l'enchaînement. Avec les services parallélisés, la disponibilité de bout en bout est supérieure à celle de chaque service individuel.
Le schéma suivant montre deux services, A et B, déployés à l'aide des approches d'enchaînement et de parallélisation :
Dans les exemples précédents, les deux services ont un SLA de 99 %, ce qui entraîne la disponibilité globale suivante en fonction de l'approche d'implémentation :
- Les services en chaîne n'offrent qu'une disponibilité globale de 98 % (0,99 x 0,99).
- Les services parallélisés offrent une disponibilité globale plus élevée (99,99 %), car chaque service s'exécute indépendamment et les services individuels ne sont pas affectés par la disponibilité des autres services. La formule pour les services parallélisés agrégés est 1 − (1 − A) × (1 − B).
Choisissez des services Google Cloud avec des SLA de disponibilité qui peuvent vous aider à atteindre le niveau de disponibilité global requis pour votre pile d'applications.
Lorsque vous concevez votre architecture, tenez compte des compromis entre disponibilité, complexité opérationnelle, latence et coût. Augmenter le nombre de neuf de disponibilité coûte généralement plus cher, mais vous aide à respecter les exigences réglementaires.
Par exemple, une disponibilité de 99,9 % (trois neuf) signifie un temps d'arrêt potentiel de 86 secondes sur une période de 24 heures. En revanche, 99 % (deux neufs) signifie une indisponibilité de 864 secondes sur la même période, soit 10 fois plus d'indisponibilité qu'avec trois neufs de disponibilité.
Pour les services financiers critiques, les options d'architecture peuvent être limitées. Toutefois, il est essentiel d'identifier les exigences de disponibilité et de calculer précisément la disponibilité. Effectuer une telle évaluation vous aide à évaluer les implications de vos décisions de conception sur votre architecture et votre budget.
Mettre en œuvre une stratégie de reprise après sinistre efficace
Créez des plans bien définis pour différents scénarios de sinistre, y compris les pannes zonales et régionales. Une stratégie de reprise après sinistre (DR) bien définie vous permet de vous remettre d'une interruption et de reprendre vos opérations normales avec un impact minimal.
La reprise après sinistre et la haute disponibilité sont deux concepts différents. Avec les déploiements cloud, la reprise après sinistre s'applique généralement aux déploiements multirégionaux, et la haute disponibilité aux déploiements régionaux. Ces archétypes de déploiement sont compatibles avec différents mécanismes de réplication.
- HA : de nombreux services gérés fournissent par défaut une réplication synchrone entre les zones d'une même région. Ces services prennent en charge un objectif de temps de récupération (RTO) et un objectif de point de récupération (RPO) nuls ou presque nuls. Cette prise en charge vous permet de créer une topologie de déploiement actif-actif sans SPOF.
- Reprise après sinistre : pour les charges de travail déployées dans plusieurs régions, vous devez définir une stratégie de réplication si vous n'utilisez pas de services multirégionaux ou mondiaux. La stratégie de réplication est généralement asynchrone. Évaluez soigneusement l'impact de cette réplication sur le RTO et le RPO des applications critiques. Identifiez les opérations manuelles ou semi-automatiques nécessaires au basculement.
Pour les établissements financiers, votre choix de région de reprise après sinistre peut être limité par les réglementations sur la souveraineté et la résidence des données. Si vous avez besoin d'une topologie actif-actif dans deux régions, nous vous recommandons de choisir des services multirégionaux gérés, comme Spanner et Cloud Storage, en particulier lorsque la réplication des données est essentielle.
Tenez compte des recommandations suivantes :
- Utilisez des services de stockage multirégionaux gérés pour les données.
- Prenez des instantanés des données sur les disques persistants et stockez-les dans des emplacements multirégionaux.
- Lorsque vous utilisez des ressources régionales ou zonales, configurez la réplication des données dans d'autres régions.
- Validez l'efficacité de vos plans de reprise après sinistre en les testant régulièrement.
- Tenez compte du RTO et du RPO, et de leur corrélation avec la tolérance à l'impact stipulée par les réglementations financières dans votre juridiction.
Pour en savoir plus, consultez Concevoir une solution de reprise après sinistre pour les pannes d'infrastructure cloud.
Exploiter tout le potentiel des services gérés
Dans la mesure du possible, utilisez des services gérés pour profiter des fonctionnalités intégrées de sauvegarde, de haute disponibilité et d'évolutivité. Voici quelques recommandations pour utiliser les services gérés :
- Utilisez des services gérés dans Google Cloud. Ils offrent une haute disponibilité soutenue par des contrats de niveau de service. Ils proposent également des mécanismes de sauvegarde et des fonctionnalités de résilience intégrés.
- Pour la gestion des données, envisagez d'utiliser des services tels que Cloud SQL, Cloud Storage et Spanner.
- Pour l'hébergement de calcul et d'applications, envisagez d'utiliser des groupes d'instances gérés (MIG) Compute Engine et des clusters Google Kubernetes Engine (GKE). Les MIG régionaux et les clusters GKE régionaux sont résilients aux pannes zonales.
- Pour améliorer la résilience aux pannes régionales, utilisez des services multirégionaux gérés.
- Identifiez la nécessité de plans de sortie pour les services présentant des caractéristiques uniques et définissez les plans requis. Les organismes de réglementation financière tels que la FCA, la PRA et l'ABE exigent des entreprises qu'elles disposent de stratégies et de plans d'urgence pour la récupération des données et la continuité opérationnelle en cas de fin de la relation avec un fournisseur de services cloud. Les entreprises doivent évaluer la faisabilité de la sortie avant de conclure des contrats cloud et doivent conserver la possibilité de changer de fournisseur sans perturbation opérationnelle.
- Vérifiez que les services que vous choisissez permettent d'exporter des données dans un format ouvert tel que CSV, Parquet et Avro. Vérifiez si les services sont basés sur des technologies Open Source, comme la compatibilité de GKE avec le format OCI (Open Container Initiative) ou Cloud Composer basé sur Apache Airflow.
Automatiser les processus de provisionnement et de récupération de l'infrastructure
L'automatisation permet de réduire les erreurs humaines, ainsi que le temps et les ressources nécessaires pour répondre aux incidents. L'utilisation de l'automatisation peut aider à assurer une récupération plus rapide en cas d'échec et des résultats plus cohérents. Tenez compte des recommandations suivantes pour automatiser le provisionnement et la récupération des ressources :
- Réduisez les erreurs humaines en utilisant des outils d'infrastructure en tant que code (IaC) tels que Terraform.
- Réduisez l'intervention manuelle en automatisant les processus de basculement. Les réponses automatiques peuvent également contribuer à réduire l'impact des échecs. Par exemple, vous pouvez utiliser Eventarc ou Workflows pour déclencher automatiquement des actions correctives en réponse aux problèmes observés dans les journaux d'audit.
- Augmentez la capacité de vos ressources cloud lors du basculement à l'aide de l'autoscaling.
- Appliquez automatiquement des règles et des mesures de protection pour les exigences réglementaires dans votre topologie cloud lors du déploiement de services en adoptant l'ingénierie de plate-forme.