Guide

Une application globale nécessite une faible latence et une haute disponibilité pour les utilisateurs du monde entier.

→Utiliser un Global HTTP(S) Load Balancer avec des backends multi-régions (MIGs/GKE), Cloud CDN pour le contenu statique et Cloud Armor pour la protection DDoS.

Pourquoi: Le Global Load Balancer fournit une adresse IP anycast unique qui achemine les utilisateurs vers le backend sain le plus proche. Le CDN met en cache le contenu en périphérie, réduisant la charge de l'origine et la latence.

Référence↗

Ingérer et traiter des données en temps réel et à haut débit provenant d'appareils IoT pour une analyse immédiate.

→Utiliser Pub/Sub pour l'ingestion de messages évolutive, un pipeline de streaming Dataflow pour le traitement en temps réel et la détection d'anomalies, et écrire les résultats dans BigQuery pour l'analyse.

Pourquoi: C'est le modèle serverless canonique pour les données en temps réel. Pub/Sub découple l'ingestion, Dataflow gère le traitement complexe avec l'auto-scaling, et BigQuery prend en charge les insertions en streaming pour l'analyse en temps réel.

Référence↗

Un backend de jeu doit stocker l'état des joueurs et les classements avec une latence de lecture inférieure à la milliseconde et un débit élevé.

→Utiliser Cloud Bigtable pour l'état du jeu/les classements et Memorystore (Redis) pour la mise en cache des sessions.

Pourquoi: Bigtable offre une latence de l'ordre de quelques millisecondes pour les lectures/écritures à haut débit, idéal pour les séries temporelles ou les grands ensembles de données analytiques. Memorystore offre une latence de l'ordre de la microseconde pour l'état des sessions.

Une application distribuée mondialement nécessite une base de données avec une forte cohérence transactionnelle et une scalabilité horizontale.

→Utiliser Cloud Spanner avec une configuration multi-régions.

Pourquoi: Spanner est le seul service qui offre des transactions globales, fortement cohérentes avec la sémantique SQL et une scalabilité horizontale. Cloud SQL nécessite un sharding manuel pour cette échelle.

Référence↗

Migrer une base de données Oracle ou PostgreSQL exigeante, sur site, nécessitant une haute disponibilité, des performances élevées et un refactoring minimal.

→Utiliser AlloyDB pour PostgreSQL.

Pourquoi: AlloyDB est une base de données entièrement gérée, compatible PostgreSQL, offrant des performances supérieures, une disponibilité de 99,99 % et des fonctionnalités de compatibilité Oracle, ce qui la rend idéale pour les migrations d'entreprise.

Référence↗

Connecter un centre de données sur site à GCP avec des exigences de connectivité cohérente, à faible latence (<10ms) et à haut débit (10+ Gbps).

→Utiliser Dedicated Interconnect avec des connexions redondantes.

Pourquoi: Dedicated Interconnect fournit une connexion physique privée, à haut débit et à faible latence. Cloud VPN fonctionne sur l'internet public et ne peut pas garantir les SLAs de latence ou de bande passante à ce niveau.

Référence↗

Concevoir un réseau pour plusieurs équipes/projets nécessitant une gestion réseau centralisée mais une propriété de projet décentralisée.

→Mettre en œuvre un modèle hub-and-spoke en utilisant un Shared VPC. L'équipe réseau centrale gère le projet hôte, et les équipes d'application utilisent des projets de service.

Pourquoi: Shared VPC permet un contrôle centralisé des ressources réseau (sous-réseaux, pare-feu) tout en déléguant la gestion des ressources dans les projets de service. C'est plus évolutif et sécurisé que le VPC peering.

Gérer les clusters Kubernetes de manière cohérente sur Google Cloud, AWS, Azure et les environnements sur site.

→Utiliser Anthos pour fournir un plan de contrôle unifié pour la gestion des clusters multi-cloud et hybrides, l'application des politiques et l'observabilité.

Pourquoi: Anthos étend GKE à d'autres environnements, permettant des opérations cohérentes et une gestion de la configuration basée sur GitOps (Config Management) sur l'ensemble de votre parc.

Une équipe de science des données doit entraîner des modèles ML complexes avec accélération GPU sans gérer l'infrastructure.

→Utiliser Vertex AI Training avec des conteneurs personnalisés et Vertex AI Experiments pour le suivi des itérations de modèles.

Pourquoi: Vertex AI fournit un service d'entraînement entièrement géré qui s'occupe du provisionnement de l'infrastructure, de la mise à l'échelle et de la gestion des GPU. Il s'intègre aux expérimentations pour suivre et comparer les performances des modèles.

Servir un grand modèle ML avec une faible latence et une haute disponibilité, capable d'auto-scaling.

→Utiliser Vertex AI Prediction avec un conteneur personnalisé, déployé sur un endpoint géré avec l'auto-scaling activé.

Pourquoi: Vertex AI Prediction est optimisé pour la diffusion de modèles à faible latence. Il gère l'auto-scaling, la répartition du trafic (pour les tests A/B) et la gestion de l'infrastructure, abstrayant la complexité pour les développeurs.

Un service Cloud Function ou Cloud Run doit se connecter de manière sécurisée à une instance Cloud SQL avec une adresse IP privée.

→Configurer un connecteur d'accès VPC Serverless pour relier l'environnement serverless à votre VPC.

Pourquoi: Le connecteur crée un tunnel dans votre VPC, permettant aux services serverless d'accéder aux ressources internes par leurs adresses IP privées sans les exposer à Internet.

Migrer une application avec état qui utilise un stockage de session local vers une plateforme sans état et auto-évolutive comme Cloud Run ou GKE.

→Externaliser l'état de session vers un magasin en mémoire géré comme Memorystore (Redis).

Pourquoi: Le calcul sans état nécessite que les données de session soient stockées en externe afin que toute instance puisse gérer toute requête utilisateur. Memorystore offre une solution partagée à faible latence pour cela.

Créer un pipeline de livraison continue géré pour promouvoir les releases à travers plusieurs environnements (staging, prod) avec des approbations.

→Utiliser Cloud Deploy pour définir un pipeline de livraison qui orchestre les déploiements vers les environnements cibles (GKE, Cloud Run) avec des portes d'approbation intégrées.

Pourquoi: Cloud Deploy est un service entièrement géré pour le CD, offrant la gestion des releases, l'auditabilité et les capacités de rollback automatisé sans la charge opérationnelle des outils auto-hébergés comme Spinnaker.

Déployer une application conteneurisée sur un cluster Kubernetes prêt pour la production avec une surcharge opérationnelle et de gestion minimale.

→Utiliser un cluster GKE Autopilot.

Pourquoi: Autopilot gère le plan de contrôle et les nœuds du cluster, y compris le provisionnement, la mise à l'échelle et le renforcement de la sécurité. Vous ne payez que pour les ressources de pod que vous demandez, simplifiant ainsi les opérations et la gestion des coûts.

Migrer progressivement une grande application monolithique vers une architecture de microservices avec un risque et un temps d'arrêt minimaux.

→Appliquer le modèle Strangler Fig. Placer un proxy devant le monolithe et rediriger progressivement le trafic pour des fonctionnalités spécifiques vers de nouveaux microservices au fur et à mesure qu'ils sont construits et validés.

Pourquoi: Ce modèle évite une réécriture "big bang" à haut risque en permettant une transition graduelle et contrôlée. Le monolithe est lentement "étranglé" à mesure que de nouveaux services prennent en charge ses fonctionnalités.

Migrer un grand nombre de VM sur site vers Google Cloud avec un temps d'arrêt minimal.

→Utiliser Migrate to Virtual Machines (anciennement Migrate for Compute Engine) pour effectuer une réplication continue au niveau des blocs depuis l'environnement sur site vers GCP, suivie d'une bascule rapide.

Pourquoi: Cet outil est conçu pour les migrations "lift-and-shift", minimisant le temps d'arrêt à quelques minutes en maintenant les VM source et cible synchronisées jusqu'à la bascule finale.

Une équipe adopte les principes SRE et doit établir ses SLOs initiaux.

→Définir d'abord des indicateurs de niveau de service (SLIs) centrés sur l'utilisateur (par exemple, disponibilité, latence). Analyser les données de performance historiques pour définir des objectifs de niveau de service (SLOs) initiaux réalistes.

Pourquoi: Les SLOs doivent être basés sur l'expérience utilisateur (SLIs) et être réalisables. Les définir en fonction des données historiques garantit que le budget d'erreur initial est réaliste et n'est pas immédiatement violé.

Automatiser la création de nouveaux projets GCP avec une configuration standardisée (APIs, IAM, réseau, sécurité).

→Utiliser un modèle de "Project Factory" avec un module Terraform, déclenché par Cloud Build. Utiliser Service Catalog pour fournir une interface en libre-service.

Pourquoi: Cela garantit que tous les nouveaux projets respectent les normes organisationnelles et les lignes de base de sécurité, réduisant l'effort manuel et la dérive de configuration. Cela permet une gouvernance à l'échelle.

Prévenir les modifications manuelles (dérive de configuration) de l'infrastructure gérée par Terraform.

→Utiliser un pipeline CI/CD (par exemple, Cloud Build) pour toutes les applications, le verrouillage de l'état Terraform (via le backend GCS), les stratégies d'organisation pour restreindre les actions de la console et la détection régulière de la dérive.

Pourquoi: Une approche multicouche est nécessaire. Le pipeline impose un chemin unique pour les changements, le verrouillage empêche les applications concurrentes, et les stratégies d'organisation fournissent un garde-fou préventif.

Gérer le code d'infrastructure (Terraform) pour plusieurs environnements (dev, staging, prod) avec des modules partagés mais des configurations différentes.

→Utiliser un ensemble unique de modules Terraform réutilisables et fournir des configurations spécifiques à l'environnement via des fichiers `.tfvars` ou des workspaces séparés.

Pourquoi: Cela suit le principe Don't Repeat Yourself (DRY). Les modules garantissent la cohérence, tandis que les fichiers de variables offrent la flexibilité d'adapter chaque environnement.

Mettre en œuvre un workflow GitOps pour déployer automatiquement les manifestes Kubernetes d'un dépôt Git vers les clusters GKE.

→Utiliser Anthos Config Management (ou Config Sync autonome) pour réconcilier continuellement l'état du cluster avec la configuration d'un dépôt Git.

Pourquoi: Config Sync fournit une solution GitOps entièrement gérée qui détecte et corrige la dérive de configuration, garantissant que le dépôt Git est la source unique de vérité pour l'état du cluster.

Référence↗

Mettre en œuvre un déploiement bleu-vert pour une application web avec zéro temps d'arrêt et une capacité de rollback instantanée.

→Utiliser deux Managed Instance Groups identiques (ou déploiements GKE) derrière un HTTP(S) Load Balancer. Effectuer la bascule en redirigeant le trafic dans le service backend du load balancer.

Pourquoi: La répartition du trafic au niveau du load balancer est instantanée et permet un rollback facile en basculant simplement le trafic vers le backend d'origine. C'est supérieur aux méthodes plus lentes basées sur DNS.

Stocker, gérer et auditer de manière sécurisée l'accès aux secrets comme les clés API et les mots de passe de bases de données pour les applications.

→Utiliser Secret Manager avec IAM pour le contrôle d'accès et Workload Identity pour l'authentification sans clé depuis GKE/Cloud Run.

Pourquoi: Secret Manager est un service géré et centralisé avec versioning, politiques de rotation et journalisation d'audit. L'utilisation de Workload Identity évite de gérer et de distribuer les clés de compte de service.

Référence↗

Empêcher l'accès ou la copie de données sensibles dans des services comme BigQuery et Cloud Storage vers des projets ou des emplacements non autorisés.

→Utiliser VPC Service Controls pour créer un périmètre de service autour des projets sensibles et restreindre le flux de données.

Pourquoi: VPC Service Controls agit comme un pare-feu pour les services gérés par Google, empêchant l'exfiltration de données au niveau de l'API. C'est une couche de défense en profondeur critique au-delà d'IAM et des pare-feu réseau.

Référence↗

Chiffrer les données au repos dans les services Google Cloud tout en conservant un contrôle total sur les clés de chiffrement.

→Utiliser des clés de chiffrement gérées par le client (CMEK), avec les clés stockées et gérées dans Cloud KMS.

Pourquoi: CMEK vous permet d'utiliser vos propres clés via Cloud KMS pour protéger les données dans d'autres services GCP. Vous contrôlez la rotation des clés et pouvez révoquer l'accès en désactivant la clé, offrant une effacement cryptographique.

Concevoir une architecture pour gérer les informations de santé protégées (PHI) en conformité avec HIPAA.

→Utiliser CMEK pour le contrôle du chiffrement, VPC Service Controls pour prévenir l'exfiltration, Assured Workloads pour les limites de conformité, Cloud Audit Logs et Access Transparency pour l'audit.

Pourquoi: HIPAA exige une combinaison de contrôles techniques. CMEK fournit le contrôle des clés, VPC-SC empêche les fuites de données, et une journalisation étendue (Audit Logs, Access Transparency) fournit l'auditabilité nécessaire.

Un pod GKE doit se connecter à une base de données Cloud SQL de manière sécurisée sans utiliser de mots de passe ni gérer les clés de compte de service.

→Utiliser Workload Identity pour lier un compte de service Kubernetes à un compte de service Google. Se connecter en utilisant le sidecar Cloud SQL Auth Proxy et l'authentification de base de données IAM.

Pourquoi: Ce modèle "sans mot de passe" est le plus sécurisé. Workload Identity fournit une authentification sans clé, l'Auth Proxy chiffre le trafic, et l'authentification IAM DB utilise IAM pour l'accès à la base de données au lieu de credentials statiques.

Appliquer une politique selon laquelle toutes les ressources cloud doivent être créées uniquement dans des régions géographiques spécifiques (par exemple, UE).

→Configurer une contrainte de stratégie d'organisation (`gcp.resourceLocations`) au niveau de l'organisation ou du dossier, en spécifiant les régions autorisées.

Pourquoi: C'est un contrôle préventif qui bloque la création de ressources non conformes au niveau de l'API. C'est la manière faisant autorité d'appliquer les politiques de résidence des données dans toute l'organisation.

S'assurer que seules des images conteneur fiables, scannées et autorisées sont déployées sur les clusters GKE de production.

→Utiliser Artifact Registry pour l'analyse des vulnérabilités et Binary Authorization pour appliquer les politiques de déploiement qui exigent des attestations valides (signatures).

Pourquoi: Cela crée une chaîne d'approvisionnement logicielle sécurisée. Artifact Registry recherche les vulnérabilités, et Binary Authorization agit comme un point d'application des politiques, vérifiant cryptographiquement qu'une image a passé tous les contrôles requis.

Référence↗

Fournir un accès sécurisé et contextuel aux applications web internes pour les employés à distance sans utiliser un VPN traditionnel.

→Utiliser BeyondCorp Enterprise avec Identity-Aware Proxy (IAP), Access Context Manager pour les politiques et Endpoint Verification pour la posture des appareils.

Pourquoi: Cela met en œuvre un modèle de confiance zéro où l'accès est accordé en fonction de l'identité de l'utilisateur et de la confiance de l'appareil, et non de l'emplacement réseau. IAP agit comme un proxy d'authentification pour chaque requête.

Une charge de travail réglementée exige que les clés de chiffrement soient stockées et traitées au sein d'un module de sécurité matérielle (HSM) certifié FIPS 140-2 Niveau 3.

→Utiliser Cloud KMS avec le niveau de protection `HSM` pour les clés.

Pourquoi: Cloud HSM est un service entièrement géré fournissant des HSM certifiés FIPS 140-2 Niveau 3. Les clés générées avec ce niveau de protection ne quittent jamais la limite du HSM en texte clair.

Découvrir et désidentifier automatiquement les données sensibles (comme les PII) dans Cloud Storage ou BigQuery.

→Utiliser Cloud Data Loss Prevention (DLP) pour rechercher les données sensibles et appliquer des techniques de désidentification comme le masquage, la tokenisation ou la rédaction.

Pourquoi: DLP fournit des détecteurs pré-construits et personnalisés pour un large éventail de types de données sensibles, permettant une protection des données automatisée et évolutive sans scripting personnalisé.

Permettre aux employés de plusieurs fournisseurs d'identité (par exemple, Okta, Azure AD) d'accéder aux ressources Google Cloud sans créer de comptes Google.

→Utiliser Workforce Identity Federation pour connecter les fournisseurs d'identité externes à Google Cloud IAM.

Pourquoi: Cela vous permet de tirer parti de vos systèmes d'identité existants comme source de vérité, évitant ainsi la nécessité de synchroniser les utilisateurs ou de gérer des identités Google séparées pour votre personnel.

Traiter des données hautement sensibles où les données doivent rester chiffrées même pendant leur utilisation (en mémoire).

→Utiliser des VM confidentielles.

Pourquoi: Confidential Computing chiffre les données pendant le traitement à l'aide de fonctionnalités matérielles dédiées (AMD SEV). Cela protège contre les attaques de récupération de mémoire et fournit une couche de sécurité supplémentaire pour les charges de travail sensibles.

Optimiser le coût et les performances de BigQuery pour un grand entrepôt de données.

→Mettre en œuvre le partitionnement par date et le clustering sur les colonnes fréquemment filtrées. Utiliser BI Engine pour les tableaux de bord et les vues matérialisées pour les agrégations courantes et coûteuses.

Pourquoi: Le partitionnement et le clustering sont fondamentaux pour réduire la quantité de données scannées par requête, ce qui diminue directement les coûts et améliore la vitesse. BI Engine et les vues matérialisées réduisent les calculs redondants.

Référence↗

Exécuter des tâches de traitement par lots à grande échelle et tolérantes aux pannes avec le coût de calcul le plus bas possible.

→Utiliser des Spot VMs dans un Managed Instance Group. S'assurer que l'application est tolérante aux pannes et peut gérer les préemptions.

Pourquoi: Les Spot VMs offrent jusqu'à 91 % d'économies par rapport aux instances à la demande. Elles sont idéales pour les charges de travail sans état et tolérantes aux pannes qui peuvent être arrêtées et redémarrées, comme de nombreuses tâches de traitement par lots.

Mettre en œuvre des pratiques FinOps pour offrir une visibilité des coûts et une responsabilisation aux différentes équipes ou départements.

→Utiliser une hiérarchie de ressources (dossiers par équipe), appliquer des libellés pour l'allocation des coûts, et exporter les données de facturation détaillées vers BigQuery pour l'analyse et la visualisation dans Looker Studio.

Pourquoi: Cette combinaison offre un moyen structuré d'organiser les ressources, de suivre les coûts de manière granulaire via des libellés, et de construire des tableaux de bord personnalisés, spécifiques aux équipes, pour le showback/chargeback.

Optimiser le coût et les performances du cluster GKE pour les applications à charge variable.

→Utiliser Horizontal Pod Autoscaler (HPA) pour mettre à l'échelle les pods en fonction des métriques, et Cluster Autoscaler pour ajouter/supprimer des nœuds au besoin.

Pourquoi: Cette approche d'auto-scaling à deux niveaux garantit que l'application (pods) et l'infrastructure (nœuds) s'adaptent en fonction de la demande, évitant le sur-provisionnement et garantissant les performances.

Un travail d'entraînement ML montre une faible utilisation du GPU (<30%), indiquant un goulot d'étranglement.

→Diagnostiquer et optimiser le pipeline d'entrée de données. Utiliser `tf.data` avec le préchargement et les lectures parallèles, ou Cloud Storage FUSE pour améliorer les performances E/S.

Pourquoi: La faible utilisation du GPU est presque toujours un goulot d'étranglement d'E/S de données. Le GPU est inactif en attendant le prochain lot de données. L'optimisation du chargement des données est la première étape pour améliorer l'efficacité de l'entraînement.

Réduire les coûts élevés de sortie réseau lors de la diffusion de données vers Internet ou entre les régions.

→Utiliser Cloud CDN pour mettre en cache le contenu statique. Pour le trafic inter-régions, utiliser le Standard Network Service Tier pour les charges de travail non sensibles à la latence.

Pourquoi: Le CDN sert les données depuis la périphérie, ce qui est moins cher que la sortie de l'origine. Le niveau Standard achemine le trafic via l'internet public au lieu du réseau premium de Google, offrant un coût inférieur pour le transfert de données en vrac.

Réduire les coûts des VM de développement et de test qui ne sont nécessaires que pendant les heures de bureau.

→Utiliser Cloud Scheduler pour déclencher des Cloud Functions qui démarrent et arrêtent automatiquement les instances selon un calendrier prédéfini.

Pourquoi: Ce modèle de "planification d'instances" automatise le processus d'arrêt des ressources lorsqu'elles ne sont pas utilisées, réduisant considérablement les coûts pour les environnements hors production.

Une application critique nécessite une base de données relationnelle avec basculement automatique en cas de défaillance zonale.

→Configurer l'instance Cloud SQL avec l'option Haute Disponibilité (HA).

Pourquoi: La configuration HA crée une instance de secours dans une zone différente avec réplication synchrone. En cas de défaillance de l'instance principale ou de la zone, le basculement est automatique et prend généralement moins de 60 secondes.

Détecter et récupérer automatiquement les instances Compute Engine non réactives ou défaillantes.

→Déployer des instances au sein d'un Managed Instance Group (MIG) et configurer l'auto-réparation avec une vérification de l'état basée sur l'application.

Pourquoi: L'auto-réparation MIG sonde activement l'application sur chaque instance. Si l'application échoue à sa vérification d'état, le MIG recrée automatiquement l'instance, assurant la fiabilité du service.

Concevoir un plan de reprise après sinistre avec un RTO de < 1 heure et un RPO de < 15 minutes.

→Mettre en œuvre un "warm standby" dans une région secondaire. Utiliser des répliques inter-régions Cloud SQL, Cloud Storage multi-régional et des modèles d'instances préconfigurés pour le calcul.

Pourquoi: Cette approche équilibre le coût et le temps de récupération. Les données sont répliquées de manière quasi synchrone pour atteindre le RPO, et une infrastructure minimale est en fonctionnement (warm) pour permettre une mise à l'échelle rapide afin d'atteindre le RTO.

Mettre en œuvre une observabilité complète pour une application de microservices afin de permettre un dépannage rapide.

→Utiliser la journalisation structurée avec des IDs de corrélation, Cloud Trace pour le traçage distribué, Cloud Monitoring pour les métriques, et Cloud Error Reporting pour le regroupement automatique des erreurs.

Pourquoi: Une combinaison de journaux, de traces et de métriques (les "trois piliers de l'observabilité") est essentielle. Les IDs de corrélation et le traçage distribué sont essentiels pour suivre une seule requête à travers plusieurs services.

Empêcher qu'une défaillance dans un microservice ne provoque une défaillance en cascade à travers toute l'application.

→Mettre en œuvre des modèles de résilience tels que les disjoncteurs (circuit breakers), les tentatives avec backoff exponentiel et les timeouts agressifs à chaque point de communication service-à-service.

Pourquoi: Ces modèles isolent les défaillances. Un disjoncteur arrête les appels vers un service défaillant, empêchant le service appelant d'épuiser ses ressources et de tomber en panne à son tour.

Mettre en œuvre les meilleures pratiques SRE pour réduire le risque de pannes de production causées par de nouveaux déploiements.

→Utiliser les déploiements canaries pour déployer progressivement les changements, les feature flags pour découpler le déploiement de la release, et des déclencheurs de rollback automatisés basés sur la surveillance des SLO.

Pourquoi: Ces pratiques limitent le "rayon d'impact" d'un mauvais déploiement. Les canaries exposent d'abord la nouvelle version à un petit sous-ensemble d'utilisateurs, et le rollback automatisé minimise le temps moyen de récupération (MTTR).

Utiliser les budgets d'erreur SRE pour équilibrer la vélocité des fonctionnalités et la fiabilité.

→Définir une politique de budget d'erreur : lorsque le budget est presque épuisé, geler les nouveaux déploiements de fonctionnalités et prioriser le travail qui améliore la fiabilité.

Pourquoi: Le budget d'erreur est un mécanisme basé sur les données pour prendre des décisions d'arbitrage. Il donne aux équipes la permission de prendre des risques lorsque le budget est sain et impose un focus sur la stabilité lorsqu'il ne l'est pas.

Une application distribuée mondialement utilisant Cloud Spanner subit une latence d'écriture élevée dans certaines régions.

→Analyser les schémas d'écriture de l'application et configurer la région leader de l'instance Spanner de manière à ce qu'elle soit géographiquement proche de la majorité des opérations d'écriture.

Pourquoi: Dans Spanner, toutes les écritures sont acheminées via la région leader pour garantir la cohérence. Placer la région leader à proximité de la source principale des écritures minimise la latence réseau pour ces transactions.