Framework d'architecture Google Cloud

Last reviewed 2023-11-09 UTC

Vous pouvez imprimer cette page ou l'enregistrer au format PDF à l'aide de la fonction d'impression de votre navigateur et sélectionner l'option Enregistrer en tant que PDF. Pour la version standard de cette page, revenez au framework d'architecture.

Le framework d'architecture Google Cloud fournit des recommandations et des bonnes pratiques pour aider les architectes, développeurs, administrateurs et autres professionnels du cloud à concevoir et à exploiter une topologie cloud sécurisée, efficace, résiliente, performante et rentable. Le framework d'architecture Google Cloud est notre version d'un framework bien conçu.

Une équipe pluridisciplinaire d'experts Google valide les recommandations de conception et les bonnes pratiques qui composent ce framework d'architecture. L'équipe organise le framework d'architecture pour refléter les capacités croissantes de Google Cloud, les bonnes pratiques du secteur, les connaissances de la communauté et les retours de nos clients. Pour obtenir un récapitulatif des modifications importantes, consultez la section Nouveautés.

Les conseils de conception du framework d'architecture s'appliquent aux applications conçues pour le cloud ainsi qu'aux charges de travail migrées depuis une infrastructure sur site vers Google Cloud, aux déploiements cloud hybrides et aux environnements multicloud.

Le framework d'architecture Google Cloud est organisé en six catégories (également appelées piliers), comme le montre le schéma suivant :

Conception du système

Cette catégorie est la base du framework d'architecture Google Cloud. Définissez l'architecture, les composants, les modules, les interfaces et les données nécessaires pour répondre aux exigences de configuration cloud et découvrez les produits et fonctionnalités Google Cloud compatibles avec cette conception de système.

Excellence opérationnelle

Déployez, exploitez, surveillez et gérez efficacement vos charges de travail dans le cloud.

Sécurité, confidentialité et conformité

Optimisez la sécurité de vos données et de vos charges de travail dans le cloud et adaptez votre conception pour garantir la confidentialité et la conformité eu égard aux normes et exigences réglementaires.

Fiabilité

Concevez et exécutez des charges de travail résilientes et hautement disponibles dans le cloud.

Optimisation des coûts

Optimisez la valeur commerciale de votre investissement dans Google Cloud.

Optimisation des performances

Concevez et ajustez vos ressources cloud pour obtenir des performances optimales.

Pour afficher les résumés des produits Google Cloud et leur relation les uns avec les autres, consultez les produits, fonctionnalités et services Google Cloud en quatre mots maximum.

Framework d'architecture Google Cloud : conception du système

La conception du système est la catégorie de base du framework d'architecture Google Cloud. Dans cette catégorie, vous trouverez des recommandations de conception, ainsi que des bonnes pratiques et des principes à suivre pour vous aider à définir l'architecture, les composants, les modules, les interfaces et les données sur une plate-forme cloud qui répondent aux exigences de votre système. Vous découvrirez également les produits et fonctionnalités Google Cloud compatibles avec la conception du système.

Les documents de la catégorie "Conception du système" supposent que vous comprenez les principes de base de la conception du système. Dans ces documents, nous ne partons pas du principe que vous connaissez les concepts du cloud et les produits Google Cloud.

Pour les scénarios complexes de migration et de déploiement dans le cloud, nous vous recommandons d'utiliser les services de conseil Google Cloud. Nos consultants s'appuient sur nos bonnes pratiques et nos principes à suivre pour vous aider à réussir votre transition vers le cloud. Google Cloud dispose également d'un solide écosystème de partenaires, allant des intégrateurs de systèmes mondiaux de grande taille à des partenaires spécialisés dans un domaine particulier comme le machine learning. Nous vous recommandons de faire appel à des partenaires Google Cloud pour accélérer votre transformation numérique et améliorer vos résultats commerciaux.

Remarque : Avant de modifier votre environnement de production, nous vous recommandons de tester de nouvelles fonctionnalités ou de les concevoir dans un environnement de bac à sable.

Dans la catégorie de conception du système du framework d'architecture, vous allez apprendre à effectuer les opérations suivantes :

• Appliquer les principes de base de conception du système
• Sélectionnez des régions géographiques pour prendre en charge vos applications métier.
• Gérer les ressources cloud
• Choisir et gérer les ressources de calcul
• Concevoir votre infrastructure réseau
• Sélectionner et mettre en œuvre une stratégie de stockage
• Optimiser votre base de données
• Analyser vos données
• Implémenter le machine learning
• Concevez vos charges de travail cloud pour le développement durable.

Principes de base de la conception système

Ce document du framework d'architecture de Google Cloud décrit les principes de base de la conception système. Une conception système robuste est sécurisée, fiable, évolutive et indépendante. Vous pouvez ainsi apporter des modifications itératives et réversibles sans provoquer d'interruption du système, réduire les risques potentiels et améliorer l'efficacité opérationnelle. Nous vous recommandons de suivre quatre principes fondamentaux afin de tendre vers une conception système robuste.

Tout documenter

Lorsque vous commencez à déplacer vos charges de travail vers le cloud ou à créer vos applications, le manque de documentation du système constitue un obstacle majeur. La documentation est particulièrement importante pour visualiser correctement l'architecture de vos déploiements actuels.

Une architecture cloud correctement documentée établit un langage commun et des normes, qui permettent aux équipes pluridisciplinaires de communiquer et de collaborer efficacement. Il fournit également les informations nécessaires pour identifier et orienter les futures décisions de conception. Afin d'étayer le contexte des décisions spécifiques à la conception, la documentation doit être rédigée à l'aide de vos propres cas d'utilisation.

Au fil du temps, vos décisions de conception évolueront et changeront. L'historique des modifications fournit le contexte nécessaire à vos équipes pour aligner les initiatives, éviter la duplication et mesurer efficacement les changements de performances au fil du temps. Les journaux des modifications sont particulièrement utiles lorsque vous intégrez un nouvel architecte cloud qui ne connaît pas encore la conception, la stratégie ou l'historique actuels de votre système.

Simplifier la conception et utiliser des services entièrement gérés

La simplicité est cruciale pour la conception du système. Si votre architecture est si complexe qu'elle est difficile à comprendre, il sera difficile de la mettre en œuvre et de la gérer au fil du temps. Dans la mesure du possible, utilisez des services entièrement gérés pour réduire les risques, le temps et les efforts de gestion et de maintenance des systèmes de référence.

Si vous exécutez déjà vos charges de travail en production, testez-les avec des services gérés pour voir comment ils peuvent contribuer à réduire les complexités opérationnelles. Si vous développez de nouvelles charges de travail, commencez simplement, établissez un produit minimum viable (MVP) et résistez à l'envie de surcharger. Vous pouvez identifier les cas d'utilisation exceptionnels, effectuer des itérations et améliorer vos systèmes de manière incrémentielle.

Découpler votre architecture

Le découplage est une technique permettant de séparer vos applications et composants de services en composants plus petits pouvant fonctionner indépendamment. Par exemple, vous pouvez diviser une pile d'applications monolithiques en composants de service distincts. Dans une architecture découplée, une application peut exécuter ses fonctions indépendamment, quelles que soient les différentes dépendances.

Une architecture découplée vous permet d'effectuer les opérations suivantes :

• Appliquer des mises à niveau indépendantes.
• Appliquer des contrôles de sécurité spécifiques.
• Définissez des objectifs de fiabilité pour chaque sous-système.
• Surveiller l'état.
• Contrôlez de manière précise les performances et les paramètres de coût.

Vous pouvez commencer le découplage au début de la phase de conception ou l'intégrer dans les mises à niveau de votre système lors de la mise à l'échelle.

Utiliser une architecture sans état

Une architecture sans état peut augmenter à la fois la fiabilité et l'évolutivité de vos applications.

Les applications avec état s'appuient sur diverses dépendances pour effectuer des tâches, telles que des données mises en cache localement. Les applications avec état nécessitent souvent des mécanismes supplémentaires pour capturer la progression et redémarrer correctement. Les applications sans état peuvent effectuer des tâches sans dépendances locales importantes à l'aide d'espace de stockage partagé ou de services mis en cache. Une architecture sans état permet à vos applications de s'adapter rapidement avec des dépendances de démarrage minimales. Les applications peuvent supporter des redémarrages forcés, réduire les temps d'arrêt et offrir de meilleures performances aux utilisateurs finaux.

La catégorie "Conception du système" décrit les recommandations permettant de rendre vos applications sans état ou d'utiliser des fonctionnalités cloud natives pour améliorer la capture de l'état de la machine pour vos applications avec état.

Étapes suivantes

• Sélectionnez des régions géographiques pour prendre en charge vos applications métier.
• Gérer les ressources cloud
• Choisir et gérer les ressources de calcul
• Concevoir votre infrastructure réseau
• Sélectionner et mettre en œuvre une stratégie de stockage
• Optimiser votre base de données
• Analyser vos données
• Implémenter le machine learning
• Concevez vos charges de travail cloud pour le développement durable.

Choisir des archétypes de déploiement Google Cloud

Ce document du framework d'architecture Google Cloud décrit six archétypes de déploiement¹ : zonal, régional, multirégional, mondial, hybride et multicloud, que vous pouvez choisir pour créer des architectures pour vos charges de travail cloud en fonction de vos exigences en termes de disponibilité, de coût, de performances et d'efficacité opérationnelle.

Qu'est-ce qu'un archétype de déploiement ?

Un archétype de déploiement est un modèle abstrait, indépendant du fournisseur, qui vous permet de créer des architectures de déploiement spécifiques aux applications et répondant à vos exigences commerciales et techniques. Chaque archétype de déploiement spécifie une combinaison de domaines de défaillance dans lesquels une application peut s'exécuter. Ces domaines de défaillance peuvent correspondre à une ou plusieurs zones ou régions Google Cloud et peuvent s'étendre pour inclure vos centres de données sur site ou vos domaines de défaillance dans d'autres fournisseurs de services cloud.

Le schéma suivant illustre six applications déployées dans Google Cloud. Chaque application utilise un archétype de déploiement répondant à ses exigences spécifiques.

Comme le montre le schéma précédent, dans une architecture qui utilise l'archétype de déploiement hybride ou multicloud, la topologie cloud est basée sur l'un des archétypes de base : zonal, régional, multirégional ou mondial. Dans ce sens, les archétypes de déploiement hybrides et multicloud peuvent être considérés comme des archétypes de déploiement composites qui incluent l'un des archétypes de base.

Remarque : Les archétypes de déploiement sont différents des champs d'application d'emplacement. Le champ d'application d'emplacement d'une ressource Google Cloud définit sa limite de disponibilité. Par exemple, le champ d'application de l'emplacement d'une VM Compute Engine est zonal. Cela signifie que si la zone Google Cloud dans laquelle une VM est provisionnée subit une panne, la disponibilité de la VM est affectée. Toutefois, en répartissant les VM sur plusieurs zones, vous pouvez créer une architecture haute disponibilité basée sur l'archétype de déploiement régional.

Le choix d'un archétype de déploiement permet de simplifier les décisions suivantes concernant les produits et fonctionnalités Google Cloud que vous devez utiliser. Par exemple, pour une application conteneurisée haute disponibilité, si vous choisissez l'archétype de déploiement régional, les clusters Google Kubernetes Engine (GKE) régionaux sont plus appropriés que les clusters GKE zonaux.

Lorsque vous choisissez un archétype de déploiement pour une application, vous devez prendre en compte les compromis entre des facteurs tels que la disponibilité, les coûts et la complexité opérationnelle. Par exemple, si une application sert des utilisateurs dans plusieurs pays et nécessite une haute disponibilité, vous pouvez choisir l'archétype de déploiement multirégional. Toutefois, pour une application interne utilisée par les employés dans une seule zone géographique, vous pouvez privilégier le coût par rapport à la disponibilité et, par conséquent, choisir l'archétype de déploiement régional.

Présentation des archétypes de déploiement

Les onglets suivants fournissent des définitions pour les archétypes de déploiement ainsi qu'un résumé des cas d'utilisation et des considérations de conception pour chacun.

Zonal

Votre application s'exécute dans une seule zone Google Cloud, comme illustré dans le schéma suivant :

Cas d'utilisation	Environnements de développement et de test. Applications qui n'ont pas besoin de haute disponibilité. Mise en réseau à faible latence entre les composants d'application. Migration de charges de travail courantes. Applications utilisant des logiciels sous licence.
Considérations de conception	Temps d'arrêt en cas de panne zonale. Pour assurer la continuité des activités, vous pouvez provisionner une instance répliquée passive de l'application dans une autre zone de la même région. En cas de panne zonale, vous pouvez restaurer l'application en production à l'aide de l'instance répliquée passive.
Informations complémentaires	Consultez les sections suivantes : Archétype de déploiement zonal Analyse comparative de tous les archétypes de déploiement

Régional

Votre application s'exécute indépendamment dans au moins deux zones d'une même région Google Cloud, comme indiqué dans le diagramme suivant :

Cas d'utilisation	Applications haute disponibilité pour les utilisateurs dans une zone géographique. Respect des exigences de résidence et de souveraineté des données.
Considérations de conception	Temps d'arrêt en cas de panne régionale. Pour assurer la continuité des activités, vous pouvez sauvegarder l'application et les données dans une autre région. En cas de panne régionale, vous pouvez utiliser les sauvegardes de l'autre région pour restaurer l'application en production. Coûts et efforts pour provisionner et gérer les ressources redondantes.
Informations complémentaires	Consultez les sections suivantes : Archétype de déploiement régional Analyse comparative de tous les archétypes de déploiement

Multirégional

Votre application s'exécute indépendamment dans plusieurs zones dans au moins deux régions Google Cloud. Vous pouvez utiliser des règles de routage DNS pour acheminer le trafic entrant vers les équilibreurs de charge régionaux. Les équilibreurs de charge régionaux distribuent ensuite le trafic vers les instances répliquées zonales de l'application, comme illustré dans le schéma suivant :

Cas d'utilisation	Application haute disponibilité avec des utilisateurs dispersés géographiquement. Applications qui nécessitent une faible latence de l'utilisateur final. Conformité avec les exigences de résidence et de souveraineté des données grâce à une règle de routage DNS géolocalisée.
Considérations de conception	Coût du transfert et de la réplication de données interrégionaux. Complexité opérationnelle.
Informations complémentaires	Consultez les sections suivantes : Archétype de déploiement multirégional Analyse comparative de tous les archétypes de déploiement

Monde

Votre application s'exécute dans les régions Google Cloud à travers le monde, sous la forme d'une pile distribuée à l'échelle mondiale (non consciente de l'emplacement) ou de piles régionalement isolées. Un équilibreur de charge anycast mondial répartit le trafic dans la région la plus proche de l'utilisateur. D'autres composants de la pile d'applications peuvent également être mondiaux, tels que la base de données, le cache et le magasin d'objets.

Le schéma suivant illustre la variante distribuée à l'échelle mondiale de l'archétype de déploiement mondial. Un équilibreur de charge anycast mondial transfère les requêtes vers une pile d'applications distribuée sur plusieurs régions et utilisant une base de données répliquée à l'échelle mondiale.

Le schéma suivant illustre une variante de l'archétype de déploiement mondial avec des piles d'applications isolées au niveau régional. Un équilibreur de charge anycast mondial transfère les requêtes vers une pile d'applications dans l'une des régions. Toutes les piles d'applications utilisent une base de données répliquée à l'échelle mondiale.

Cas d'utilisation	Des applications haute disponibilité servant des utilisateurs répartis dans le monde entier. Possibilité d'optimiser les coûts et de simplifier les opérations en utilisant des ressources mondiales au lieu de plusieurs instances de ressources régionales.
Considérations de conception	Coûts liés au transfert et à la réplication de données interrégionaux.
Informations complémentaires	Consultez les sections suivantes : Archétype de déploiement mondial Analyse comparative de tous les archétypes de déploiement

Hybride

Certaines parties de votre application sont déployées dans Google Cloud, tandis que d'autres s'exécutent sur site, comme indiqué dans le schéma suivant. La topologie dans Google Cloud peut utiliser l'archétype de déploiement zonal, régional, multirégional ou mondial.

Cas d'utilisation	Site de reprise après sinistre (DR) pour les charges de travail sur site. Développement sur site pour les applications cloud. Migration progressive vers le cloud pour les anciennes applications. Améliorer les applications sur site grâce à des fonctionnalités cloud.
Considérations de conception	Effort de configuration et complexité opérationnelle. Coût des ressources redondantes.
Informations complémentaires	Consultez les sections suivantes : Archétype de déploiement hybride Analyse comparative de tous les archétypes de déploiement

Multicloud

Certaines parties de votre application sont déployées dans Google Cloud et d'autres sur d'autres plates-formes cloud, comme illustré dans le schéma suivant. La topologie de chaque plate-forme cloud peut utiliser l'archétype de déploiement zonal, régional, multirégional ou mondial.

Cas d'utilisation	Google Cloud comme site principal et autre cloud comme site de reprise après sinistre Amélioration des applications avec les fonctionnalités avancées de Google Cloud.
Considérations de conception	Effort de configuration et complexité opérationnelle. Coût des ressources redondantes et du trafic réseau sur plusieurs clouds.
Informations complémentaires	Consultez les sections suivantes : Archétype de déploiement multicloud Analyse comparative de tous les archétypes de déploiement

Choisir des zones géographiques et des régions

Le présent document du framework d'architecture Google Cloud décrit les bonnes pratiques à adopter pour déployer votre système en fonction de critères géographiques. Vous apprendrez à choisir des zones géographiques et des régions optimales en fonction de la disponibilité et de la proximité, ainsi qu'à assurer la conformité, optimiser les coûts et mettre en œuvre l'équilibrage de charge.

Lorsque vous sélectionnez une ou plusieurs régions pour vos applications métier, vous prenez en compte des critères tels que la disponibilité du service, la latence de l'utilisateur final, la latence des applications, le coût, ainsi que les exigences réglementaires ou de développement durable. Pour prendre en charge les priorités et les politiques de votre entreprise, équilibrez ces différentes exigences et identifiez les meilleurs compromis. Par exemple, la région la plus adaptée en termes de conformité n'est peut-être pas la région la plus rentable ou qui présente l'empreinte carbone la plus basse.

Déployer dans plusieurs régions

Les régions correspondent à des espaces géographiques indépendants qui sont constitués de zones. Les zones servent au déploiement des ressources Google Cloud dans une région. Chaque zone représente un domaine de défaillance unique au sein d'une région.

Pour vous protéger contre les temps d'arrêt attendus (y compris la maintenance) et inattendus (en cas d'incident par exemple), nous vous recommandons de déployer des applications tolérantes aux pannes et à haute disponibilité, c'est-à-dire des applications déployées dans plusieurs zones situées dans une ou plusieurs régions. Pour en savoir plus, consultez les pages Zones géographiques et régions, Remarques relatives au déploiement d'applications et Bonnes pratiques pour la sélection des régions Compute Engine.

Les déploiements multizones peuvent offrir une résilience si les déploiements multirégionaux sont limités en raison de problématiques de coût ou d'autres facteurs. Cette approche est particulièrement utile pour éviter les pannes zonales ou régionales, et pour gérer les problématiques de reprise après sinistre ou de continuité des activités. Pour plus d'informations, consultez la section Concevoir des solutions évolutives et à haute disponibilité.

Choisir les régions en fonction de leur proximité géographique

La latence affecte l'expérience utilisateur et les coûts associés à la diffusion pour les utilisateurs externes. Pour minimiser la latence lors de la diffusion de trafic vers des utilisateurs externes, sélectionnez une région ou un ensemble de régions géographiquement proches de vos utilisateurs et où vos services peuvent être exécutés de manière conforme. Pour en savoir plus, consultez la section Emplacements Cloud et le Centre de ressources pour la conformité.

Sélectionner les régions en fonction des services disponibles

Sélectionnez une région en fonction des services dont votre entreprise a besoin. La plupart des services sont disponibles dans toutes les régions. Certains services spécifiques à l'entreprise peuvent n'être disponibles que dans un sous-ensemble de régions lors de leur publication initiale. Pour vérifier le choix de région, consultez la section Emplacements Cloud.

Choisir des régions pour garantir la conformité

Sélectionnez une région ou un ensemble de régions spécifiques pour répondre aux exigences réglementaires ou de conformité qui nécessitent d'utiliser certaines zones géographiques, comme le Règlement général sur la protection des données (RGPD) ou la résidence des données. Pour en savoir plus sur la conception de systèmes sécurisés, consultez les pages Offres de conformité et Résidence des données, transparence opérationnelle et vie privée pour les clients européens sur Google Cloud.

Comparer les tarifs des ressources principales

Les régions offrent des tarifs différents pour les mêmes services. Pour identifier une région économique, comparez les tarifs des principales ressources que vous prévoyez d'utiliser. Les considérations relatives aux coûts varient en fonction des exigences de sauvegarde et des ressources utilisées (calcul, mise en réseau et stockage de données). Pour en savoir plus, consultez la page Catégorie d'optimisation des coûts.

Desservir des utilisateurs dans le monde entier grâce à Cloud Load Balancing

Pour améliorer l'expérience utilisateur lorsque vous diffusez des données dans le monde entier, utilisez Cloud Load Balancing pour fournir une adresse IP unique qui pointe vers votre application. Pour en savoir plus sur la conception de systèmes fiables, consultez la page Framework d'architecture Google Cloud : Fiabilité.

Utiliser l'outil de sélection de région de Google Cloud pour favoriser le développement durable

Google présente un bilan carbone neutre depuis 2007 et s'engage à ne plus émettre aucun carbone d'ici 2030. Pour sélectionner une région en fonction de son empreinte carbone, utilisez l'outil de sélection de région de Google Cloud. Pour en savoir plus sur la conception de solutions durables, consultez la page Cloud et le développement durable.

Étape suivante

Apprenez à gérer vos ressources cloud à l'aide de Resource Manager, de la hiérarchie des ressources Google Cloud et du service de règles d'administration.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Gérer les ressources cloud

Ce document du framework d'architecture Google Cloud décrit les bonnes pratiques à suivre pour organiser et gérer vos ressources dans Google Cloud.

Hiérarchie des ressources

Les ressources Google Cloud sont organisées de façon hiérarchique dans des organisations, dossiers et projets. Cette hiérarchie vous permet de gérer les aspects communs de vos ressources, tels que le contrôle des accès, les paramètres de configuration et les règles. Pour connaître les bonnes pratiques de conception de la hiérarchie de vos ressources cloud, consultez la page Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud.

Libellés et tags de ressources

Cette section présente les bonnes pratiques pour organiser les ressources Google Cloud à l'aide de libellés et de tags.

Utiliser une structure de dossiers simple

Les dossiers vous permettent de regrouper n'importe quelle combinaison de projets et de sous-dossiers. Créez une structure de dossiers simple pour organiser vos ressources Google Cloud. Vous pouvez ajouter d'autres niveaux selon vos besoins pour définir une hiérarchie de ressources qui réponde aux besoins de votre entreprise. La structure des dossiers est flexible et extensible. Pour en savoir plus, consultez la page Créer et gérer des dossiers.

Utiliser des dossiers et des projets pour refléter les règles de gouvernance des données

Utilisez des dossiers, des sous-dossiers et des projets pour séparer les ressources les unes des autres afin de refléter les règles de gouvernance des données de votre organisation. Par exemple, vous pouvez utiliser une combinaison de dossiers et de projets pour séparer le service financier, les ressources humaines et l'ingénierie.

Utilisez des projets pour regrouper des ressources partageant la même limite de confiance. Par exemple, les ressources d'un même produit ou d'un même microservice peuvent appartenir au même projet. Pour plus d'informations, consultez la section Choisir une hiérarchie de ressources pour votre zone de destination Google Cloud.

Utilisez des tags et des étiquettes dès le début de votre projet

Utilisez des libellés et tags lorsque vous commencez à utiliser les produits Google Cloud, même si vous n'en avez pas besoin immédiatement. L'ajout ultérieur de libellés et de tags peut nécessiter un effort manuel difficile et potentiellement source d'erreurs.

Un tag permettent d'autoriser ou de refuser des règles de manière conditionnelle selon qu'une ressource possède un tag spécifique ou non. Un libellé est une paire clé/valeur qui vous permet d'organiser plus efficacement vos instances Google Cloud. Pour en savoir plus sur les libellés, consultez les exigences relatives aux libellés, une liste de services compatibles avec les libellés et les formats de libellés.

Resource Manager fournit des libellés et tags pour vous aider à gérer les ressources, à allouer et générer des rapports sur les coûts, et à attribuer des stratégies à différentes ressources pour un contrôle d'accès précis. Par exemple, vous pouvez utiliser des libellés et des tags pour appliquer un contrôle d'accès et des principes de gestion précis à différents services et ressources locataires. Pour en savoir plus sur les libellés de VM et les tags réseau, consultez la section Relation entre les libellés de VM et les tags réseau.

Vous pouvez utiliser des libellés à plusieurs fins, y compris les suivantes :

• Gestion de la facturation des ressources : les libellés sont disponibles dans le système de facturation, ce qui vous permet de séparer les coûts par libellé. Par exemple, vous pouvez ajouter des libellés aux différents centres de coûts ou budgets.
• Regroupement des ressources par caractéristiques similaires ou par relation : vous pouvez utiliser des libellés pour séparer différentes étapes du cycle de vie de l'application ou différents environnements. Par exemple, vous pouvez ajouter des libellés aux environnements de production, de développement et de test.

Attribuer des libellés pour la création de rapports sur les coûts et la facturation

Pour bénéficier de rapports de coûts et de facturation précis basés sur des attributs en dehors de vos structures de création de rapports intégrées (par type de projet ou de produit par exemple), attribuez des libellés aux ressources. Les libellés peuvent vous aider à attribuer la consommation à des centres de coûts, des services, des projets spécifiques ou des mécanismes de recharge interne. Pour en savoir plus, consultez la section Catégorie d'optimisation des coûts.

Éviter de créer un grand nombre de libellés

Évitez de créer un grand nombre de libellés. Nous vous recommandons de créer les libellés principalement au niveau du projet, et d'éviter de les créer à des niveaux inférieures à celui de l'équipe. La création de libellés trop précis peut entraîner du bruit dans vos analyses. Pour en savoir plus sur les cas d'utilisation courants des libellés, consultez la section Utilisations courantes des libellés.

Éviter d'ajouter des informations sensibles aux libellés

Les libellés ne sont pas conçus pour gérer des informations sensibles. N'incluez pas d'informations sensibles dans les libellés, ce qui inclut les informations pouvant être personnellement identifiables, telles que le nom ou le titre d'une personne.

Anonymiser les informations dans les noms de projet.

Appliquez un modèle de dénomination de projet tel que COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME, où les espaces réservés sont uniques et ne dévoilent pas les noms de sociétés ou d'applications. N'incluez pas d'attributs susceptibles de changer à l'avenir, comme un nom d'équipe ou une technologie.

Appliquer des tags représentant les dimensions métier

Vous pouvez appliquer des tags pour modéliser d'autres aspects commerciaux tels que la structure organisationnelle, les régions, les types de charge de travail ou les centres de coûts. Pour en savoir plus sur les tags, consultez les pages Présentation des tags, Héritage des tags et Créer et gérer des tags. Pour apprendre à utiliser les tags avec les règles, consultez la page Règles et tags. Pour découvrir comment gérer les contrôles d'accès à l'aide de tags, consultez la section Tags et contrôle des accès.

Règles d'administration

Cette section présente les bonnes pratiques pour configurer des règles de gouvernance sur les ressources Google Cloud dans toute la hiérarchie des ressources cloud.

Établir des conventions de nommage de projet

Établissez une convention de nommage de projet standardisée, par exemple SYSTEM_NAME-ENVIRONMENT (dev, test, uat, stage, prod).

Les noms de projet ne doivent pas comporter plus de 30 caractères.

Bien que vous puissiez appliquer un préfixe tel que COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG, les noms de projet peuvent devenir obsolètes lorsque les entreprises subissent des réorganisations. Envisagez de déplacer les noms identifiables des noms de projets vers les libellés de projet.

Automatiser la création de projet

Pour créer des projets pour la production et les entreprises de grande envergure, utilisez un processus automatisé tel queDeployment Manager ou le module Terraform de la fabrique de projets Google Cloud. Ces outils permettent d'exécuter les opérations suivantes :

• Créer automatiquement des environnements de développement, de test et de production ou des projets disposant d'autorisations appropriées.
• Configurer la journalisation et la surveillance

Le module Terraform de la fabrique de projets Google Cloud vous aide à automatiser la création de projets Google Cloud. Dans les grandes entreprises, nous vous recommandons d'examiner et d'approuver les projets avant de les créer dans Google Cloud. Ce processus permet de s'assurer que :

• Les coûts peuvent bien être attribués. Pour en savoir plus, consultez la section Catégorie d'optimisation des coûts.
• Les approbations sont en place pour les importations de données.
• Les exigences réglementaires ou de conformité sont satisfaites.

Lorsque vous automatisez la création et la gestion des projets et ressources Google Cloud, vous bénéficiez d'un niveau cohérent de reproductibilité et de testabilité. Gérer la configuration sous forme de code vous permet de gérer les versions et le cycle de vie de la configuration ainsi que les artefacts logiciels. L'automatisation vous permet d'intégrer les bonnes pratiques comme les conventions de nommage cohérentes et l'étiquetage de ressources. À mesure que vos exigences évoluent, l'automatisation simplifie la refactorisation des projets.

Auditer régulièrement vos systèmes

Pour vous assurer que les demandes de nouveaux projets peuvent être auditées et approuvées, intégrez le système de gestion des demandes de votre entreprise ou un système autonome fournissant des audits.

Configurer les projets de manière cohérente

Configurez les projets pour répondre aux besoins de votre entreprise de manière cohérente. Tenez compte des points suivants lorsque vous configurez des projets :

• ID du projet et conventions de nommage
• Association de comptes de facturation
• Configuration de la mise en réseau
• API et services activés
• Configuration des accès à Compute Engine
• Exportation des journaux et rapports d'utilisation
• Privilège de suppression de projets

Dissocier et isoler des charges de travail ou des environnements

Les quotas et les limites sont appliqués au niveau du projet. Pour gérer les quotas et les limites, dissociez et isolez les charges de travail ou les environnements au niveau du projet. Pour en savoir plus, consultez la section Les quotas et leur utilisation.

Le découplage des environnements est différent des exigences de classification des données. La séparation des données de l'infrastructure peut être coûteuse et complexe à mettre en œuvre. Par conséquent, nous vous recommandons de mettre en œuvre la classification des données en fonction des exigences de sensibilité et de conformité.

Appliquer l'isolation de la facturation

Appliquez l'isolation de la facturation pour prendre en charge différents comptes de facturation et avoir une visibilité sur les coûts par charge de travail et par environnement. Pour en savoir plus, consultez les pages Créer, modifier ou fermer un compte de facturation Cloud en libre-service et Activer, désactiver ou modifier la facturation pour un projet.

Pour minimiser la complexité administrative, utilisez des contrôles de gestion d'accès précis pour les environnements critiques au niveau du projet, ou pour les charges de travail réparties sur plusieurs projets. Lorsque vous organisez le contrôle des accès pour les applications de production critiques, vous vous assurez que les charges de travail sont sécurisées et gérées efficacement.

Utiliser le service de règles d'administration pour contrôler les ressources

L'APIService de règles d'administration offre aux administrateurs de règles un contrôle centralisé et automatisé des ressources cloud de votre organisation afin qu'ils puissent configurer des contraintes sur l'ensemble de la hiérarchie de ressources. Pour en savoir plus, consultez la section Ajouter un administrateur de règles d'administration.

Utiliser le service de règles d'administration pour se conformer aux réglementations

Pour répondre aux exigences de conformité, utilisez le Service de règles d'administration afin appliquer les exigences de conformité relatives au partage et à l'accès aux ressources. Par exemple, vous pouvez limiter le partage avec des parties externes ou déterminer où déployer les ressources cloud. Voici d'autres scénarios de conformité :

• Centraliser le contrôle pour configurer des restrictions qui définissent la façon dont les ressources de votre organisation peuvent être utilisées.
• Définir et mettre en place des règles visant à aider vos équipes de développement à respecter les limites de conformité.
• Aider les propriétaires de projet et leurs équipes à apporter des modifications au système tout en maintenant la conformité réglementaire et en minimisant les préoccupations liées au non-respect des règles de conformité.

Limiter le partage des ressources en fonction du domaine

Une règle d'administration de partage restreint vous permet d'empêcher le partage des ressources Google Cloud avec des identités en dehors de votre organisation. Pour en savoir plus, consultez les pages Restreindre les identités par domaine et Contraintes liées aux règles d'administration.

Désactiver la création de comptes de service et de clés

Pour améliorer la sécurité, limitez l'utilisation des comptes de service Cloud IAM (Cloud Identity and Access Management) et des clés correspondantes. Pour en savoir plus, consultez la page Restreindre l'utilisation des comptes de service.

Limiter l'emplacement physique des nouvelles ressources

Limitez l'emplacement physique des ressources nouvellement créées en restreignant les emplacements des ressources. Pour afficher la liste des contraintes vous permettant de contrôler les ressources de votre organisation, consultez la page Contraintes liées au service de règles d'administration.

Étape suivante

Découvrez comment choisir et gérer les ressources de calcul, y compris :

• Approche de migration de calcul.

• Concevoir des charges de travail et faire évoluer vos charges de travail.

• Gérer les opérations.

• Gérer les migrations de VM.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Choisir et gérer les ressources de calcul

Ce document du framework d'architecture Google Cloud décrit les bonnes pratiques à adopter pour déployer votre système en fonction de ses besoins en calcul. Vous apprendrez à choisir une plate-forme de calcul et une approche de migration, à concevoir et faire évoluer des charges de travail, ainsi qu'à gérer les opérations et les migrations de VM.

Le calcul est au cœur de nombreuses charges de travail, qu'il s'agisse de l'exécution d'une logique métier personnalisée ou de l'application d'algorithmes de calcul complexes à des ensembles de données. La plupart des solutions utilisent des ressources de calcul sous une forme quelconque. Il est donc essentiel de sélectionner les ressources de calcul appropriées pour les besoins de votre application.

Google Cloud propose plusieurs options d'utilisation du temps sur un processeur. Les options sont basées sur les types de processeur, les performances et la manière dont le code est programmé pour s'exécuter, y compris la facturation de l'utilisation.

Les options de calcul de Google Cloud sont les suivantes :

• Machines virtuelles (VM) avec avantages spécifiques au cloud, tels que la migration à chaud
• Répartir les conteneurs sur des machines de cluster pouvant partager des processeurs
• Des fonctions et approches sans serveur, où l'utilisation du temps CPU peut être mesurée pour le travail effectué lors d'une seule requête HTTP.

Choisir des ressources de calcul

Cette section présente les bonnes pratiques pour choisir et migrer vers une plate-forme de calcul.

Choisir une plate-forme de calcul

Lorsque vous choisissez une plate-forme de calcul pour votre charge de travail, tenez compte des exigences techniques de la charge de travail, des processus d'automatisation du cycle de vie, de la régionalisation et de la sécurité.

Évaluez la nature de l'utilisation du processeur par votre application et l'ensemble du système, y compris la façon dont votre code est empaqueté, déployé, distribué et appelé. Bien que certains scénarios puissent être compatibles avec plusieurs options de plate-forme, une charge de travail portable doit être capable et performante sur toute une gamme d'options de calcul.

Le tableau suivant présente les services de calcul Google Cloud recommandés pour divers cas d'utilisation :

Plate-forme de calcul	Cas d'utilisation	Produits recommandés
Solutions sans serveur	Déployez votre première application. Concentrez-vous sur le développement de l'application et sur le développement de la logique.	Cloud Run : intégrez votre logique métier dans des conteneurs grâce à cette option sans serveur entièrement gérée. Cloud Run est conçu pour les charges de travail exigeantes en calculs, mais pas toujours activées. Effectuez un scaling économique de 0 (aucun trafic) et définissez le processeur et la mémoire RAM de vos tâches et services. Il vous suffit de déployer une seule commande, et Google provisionne automatiquement la quantité adéquate de ressources. Cloud Functions : séparez votre code en éléments flexibles de logique métier sans vous soucier de l'infrastructure d'équilibrage de charge, de mise à jour, d'authentification ou de scaling.
Kubernetes	Créez des architectures de microservices complexes nécessitant des services supplémentaires tels qu'Istio pour gérer le contrôle du maillage de services.	Google Kubernetes Engine : moteur d'orchestration de conteneurs Open Source qui automatise le déploiement, le scaling et la gestion des applications conteneurisées.
Machines virtuelles (VM)	Créez et exécuter des VM à partir de familles de VM prédéfinies et personnalisables qui répondent à vos exigences d'application et de charge de travail, ainsi qu'à des logiciels et services tiers.	Compute Engine : ajoutez des unités de traitement graphique (GPU) aux instances de VM. Vous pouvez utiliser ces GPU pour accélérer des charges de travail spécifiques sur vos instances, telles que le machine learning et le traitement des données. Pour sélectionner les types de machines appropriés en fonction de vos besoins, consultez la section Recommandations pour les familles de machines.

Pour en savoir plus, consultez la page Choisir des options de calcul.

Choisir une approche de migration des ressources de calcul

Si vous migrez vos applications existantes depuis un autre cloud ou depuis un environnement sur site, utilisez l'un des produits Google Cloud suivants pour vous aider à optimiser les performances, le scaling, les coûts et la sécurité.

Objectif de migration	Cas d'utilisation	Produit recommandé
Migration Lift and Shift	Migrez ou étendez vos charges de travail VMware vers Google Cloud en quelques minutes.	Google Cloud VMware Engine
Migration Lift and Shift	Migrez vos applications basées sur des VM vers Compute Engine.	Migrate to Virtual Machines
Conversion en conteneurs	Modernisez vos applications traditionnelles en conteneurs intégrés sur Google Kubernetes Engine.	Migrate to Containers

Pour savoir comment migrer vos charges de travail en alignant vos équipes internes, consultez les sections Cycle de vie de migration des VM et Créer un programme de migration à grande échelle avec Google Cloud.

Concevoir des charges de travail

Cette section présente les bonnes pratiques relatives à la conception de charges de travail compatibles avec votre système.

Évaluer les options sans serveur pour une logique simple

La logique simple est un type de calcul qui ne nécessite pas de matériel spécialisé ni de types de machines tels que les machines optimisées pour le processeur. Avant d'investir dans des implémentations Google Kubernetes Engine (GKE) ou Compute Engine pour éliminer les coûts opérationnels et optimiser les coûts et les performances, évaluer des options sans serveur pour une logique légère.

Dissocier vos applications pour qu'elles soient sans état

Si possible, dissociez vos applications de sorte qu'elles soient sans état afin de maximiser l'utilisation des options d'informatique sans serveur. Cette approche vous permet d'utiliser des offres de calcul gérées, de faire évoluer les applications en fonction de la demande et d'optimiser les coûts et les performances. Pour en savoir plus sur le découplage de votre application en vue de sa conception à des fins d'évolutivité et de haute disponibilité, consultez la page Concevoir une application évolutive et à haute disponibilité.

Utiliser la logique de mise en cache lorsque vous dissociez des architectures

Si votre application est conçue avec état, utilisez la logique de mise en cache pour dissocier et rendre votre charge de travail évolutive. Pour en savoir plus, consultez les bonnes pratiques de la base de données.

Faciliter les mises à niveau à l'aide des migrations à chaud

Pour faciliter les mises à niveau de maintenance Google, utilisez la migration à chaud en définissant des règles de disponibilité des instances. Pour en savoir plus, consultez la section Définir les règles de maintenance de l'hôte de VM.

Scaling des charges de travail

Cette section présente les bonnes pratiques pour le scaling des charges de travail afin qu'elles soient compatibles avec votre système.

Utiliser des scripts de démarrage et d'arrêt

Pour les applications avec état, utilisez des scripts de démarrage et d'arrêt si possible pour démarrer et arrêter l'état de votre application en douceur. Le démarrage progressif se produit lorsqu'un ordinateur est activé par une fonction logicielle et que le système d'exploitation est autorisé à effectuer ses tâches de démarrage et d'ouverture de connexion en toute sécurité.

Les démarrages et les arrêts progressifs sont importants, car les applications avec état dépendent de la disponibilité immédiate des données proches du calcul, généralement sur des disques locaux ou persistants, ou dans la mémoire RAM. Pour éviter d'exécuter les données d'application depuis le début à chaque démarrage, utilisez un script de démarrage pour actualiser les dernières données enregistrées et exécuter le processus à l'emplacement où il s'est précédemment arrêté. Pour enregistrer l'état de la mémoire de l'application afin d'éviter toute perte de progression lors de l'arrêt, utilisez un script d'arrêt. Par exemple, utilisez un script d'arrêt lorsqu'une VM est programmée pour s'arrêter en raison d'une réduction de la capacité ou d'événements de maintenance de Google.

Utiliser des MIG pour assurer la gestion des VM

Lorsque vous utilisez des VM Compute Engine, les groupes d'instances gérés sont compatibles avec des fonctionnalités telles que l'autoréparation, l'équilibrage de charge, l'autoscaling, la mise à jour automatique et les charges de travail avec état. Vous pouvez créer des MIG régionaux ou zonaux en fonction de vos objectifs de disponibilité. Vous pouvez utiliser des MIG pour les charges de travail de diffusion ou par lot sans état, ainsi que pour les applications avec état qui doivent conserver l'état unique de chaque VM.

Utiliser des autoscalers de pods pour faire évoluer vos charges de travail GKE

Utilisez des autoscalers de pod verticaux et horizontaux pour adapter vos charges de travail, et utilisez le provisionnement automatique des nœuds pour adapter les ressources de calcul sous-jacentes.

Distribuer le trafic de l'application

Pour faire évoluer vos applications à l'échelle mondiale, utilisez Cloud Load Balancing pour distribuer vos instances d'application sur plusieurs régions ou zones. Les équilibreurs de charge optimisent le routage des paquets depuis les réseaux périphériques Google Cloud vers la zone la plus proche, ce qui augmente l'efficacité du trafic de diffusion et réduit les coûts de diffusion. Afin d'optimiser la latence pour l'utilisateur final, utilisez Cloud CDN pour mettre en cache le contenu statique dans la mesure du possible.

Automatiser la création et la gestion de ressources de calcul

Réduisez les erreurs causées par l'homme dans votre environnement de production en automatisant la création et la gestion des calculs.

Gérer les opérations

Cette section présente les bonnes pratiques en matière de gestion d'opérations pour votre système.

Utiliser des images publiques fournies par Google

Utilisez des images publiques fournies par Google Cloud. Les images publiques Google Cloud sont régulièrement mises à jour. Pour en savoir plus, consultez la liste des images publiques disponibles sur Compute Engine.

Vous pouvez également créer vos propres images avec des configurations et des paramètres spécifiques. Dans la mesure du possible, automatisez et centralisez la création d'images dans un projet distinct que vous pouvez partager avec des utilisateurs autorisés de votre organisation. La création et la sélection d'une image personnalisée dans un projet distinct vous permettent de mettre à jour, d'appliquer un correctif et de créer une VM à l'aide de vos propres configurations. Vous pouvez ensuite partager l'image de VM sélectionnée avec les projets pertinents.

Utiliser des instantanés pour les sauvegardes d'instances

Les instantanés vous permettent de créer des sauvegardes pour vos instances. Les instantanés sont particulièrement utiles pour les applications avec état, qui ne sont pas suffisamment flexibles pour maintenir leur état ou enregistrer leur progression en cas d'arrêts brusques. Si vous utilisez fréquemment des instantanés pour créer des instances, vous pouvez optimiser votre processus de sauvegarde en créant une image de base à partir de cet instantané.

Utiliser une image de machine pour activer la création d'instances de VM

Bien qu'un instantané capture uniquement une image des données dans une machine, une image système capture les configurations et les paramètres de la machine, en plus des données. Utilisez une image système pour stocker la totalité des configurations, métadonnées, autorisations et données d'un ou de plusieurs disques nécessaires à la création d'une instance de VM.

Lorsque vous créez une machine à partir d'un instantané, vous devez configurer les paramètres de l'instance sur les nouvelles instances de VM, ce qui nécessite beaucoup de travail. L'utilisation d'images système vous permet de copier ces paramètres connus sur de nouvelles machines, ce qui réduit les frais généraux. Pour en savoir plus, consultez la section Quand utiliser une image de machine.

Capacité, réservations et isolation

Cette section présente les bonnes pratiques en matière de gestion de la capacité, des réservations et de l'isolation pour assurer la compatibilité avec votre système.

Réduire les coûts à l'aide des remises sur engagement d'utilisation

Vous pouvez réduire vos coûts de dépenses opérationnelles (OPEX) pour les charges de travail qui sont toujours activées à l'aide de remises sur engagement d'utilisation. Pour en savoir plus, consultez la section Catégorie d'optimisation des coûts.

Choisir des types de machines pour soutenir les coûts et les performances

Google Cloud propose des types de machines qui vous permettent de choisir des calculs en fonction des paramètres de coût et de performances. Vous pouvez choisir une offre à faible performance pour optimiser les coûts ou choisir une option de calcul hautes performances à un coût plus élevé. Pour en savoir plus, consultez la section Catégorie d'optimisation des coûts.

Utiliser des nœuds à locataire unique pour répondre aux besoins de conformité

Les nœuds à locataire unique sont des serveurs physiques Compute Engine dédiés exclusivement à l'hébergement des VM de votre projet. Les nœuds à locataire unique peuvent vous aider à répondre aux exigences de conformité concernant l'isolation physique, y compris :

• Veillez à séparer physiquement les VM des VM d'autres projets.
• Regroupez vos VM sur le même matériel hôte.
• Isolez les charges de travail de traitement des paiements.

Pour en savoir plus, consultez la page Nœuds à locataire unique.

Utiliser des réservations pour garantir la disponibilité des ressources

Google Cloud vous permet de définir des réservations pour vos charges de travail afin de vous assurer que ces ressources sont toujours disponibles. La création de réservations est gratuite, mais vous payez pour les ressources réservées, même si vous ne les utilisez pas. Pour en savoir plus, consultez la section Consommation et gestion des réservations.

Migration de VM

Cette section présente les bonnes pratiques pour la migration des VM afin de prendre en charge votre système.

Évaluer les outils de migration intégrés

Évaluez les outils de migration intégrés pour transférer vos charges de travail depuis un autre cloud ou depuis un environnement sur site. Pour en savoir plus, consultez la page Migration vers Google Cloud. Google Cloud propose des outils et des services pour vous aider à migrer vos charges de travail, et à optimiser les coûts et les performances. Pour obtenir une évaluation gratuite des coûts de migration en fonction de votre environnement informatique actuel, consultez la page Programme de migration rapide de Google Cloud.

Utiliser l'importation de disques virtuels pour les systèmes d'exploitation personnalisés

Pour importer des systèmes d'exploitation compatibles, consultez la section Importer des disques virtuels. Les nœuds à locataire unique peuvent vous aider à répondre aux exigences de votre propre matériel concernant les licences par cœur ou par processeur. Pour en savoir plus, consultez la page Utiliser vos propres licences (Bring Your Own License).

Recommandations

Pour appliquer les conseils du framework d'architecture à votre propre environnement, nous vous recommandons de procéder comme suit :

• Consultez les offres Google Cloud Marketplace pour évaluer si votre application est répertoriée sous un fournisseur accepté. Google Cloud est compatible avec l'exécution de divers systèmes Open Source et divers logiciels tiers.

• Envisagez d'utiliser Migrate to Containers and GKE pour extraire et empaqueter votre application basée sur une VM en tant qu'application conteneurisée s'exécutant sur GKE.

• Utilisez Compute Engine pour exécuter vos applications sur Google Cloud. Si d'anciennes dépendances s'exécutent dans une application basée sur des VM, vérifiez si elles répondent aux exigences de votre fournisseur.

• Évaluez l'utilisation d'un équilibreur de charge réseau passthrough interne Google Cloud pour faire évoluer la capacité de votre architecture dissociée. Pour en savoir plus, consultez la page Présentation de l'équilibreur de charge réseau interne à stratégie directe.

• Évaluez vos options pour passer des cas d'utilisation traditionnels sur site tels que l'utilisation du proxy haute disponibilité. Pour plus d'informations, consultez la page Bonnes pratiques pour les adresses IP flottantes.

• Utilisez VM Manager pour gérer les systèmes d'exploitation de vos grands parcs de VM exécutant Windows ou Linux sur Compute Engine, et appliquer des règles de configuration cohérentes.

• Envisagez d'utiliser GKE Autopilot et de laisser Google SRE gérer entièrement vos clusters.

• Utilisez Policy Controller et Config Sync pour gérer les règles et la configuration sur vos clusters GKE.

• Garantir la disponibilité et l'évolutivité des machines dans des régions et des zones spécifiques Google Cloud peut évoluer pour répondre à vos besoins de calcul. Toutefois, si vous avez besoin d'un grand nombre de types de machines spécifiques dans une région ou une zone spécifique, rapprochez-vous des équipes de votre compte pour garantir la disponibilité. Pour en savoir plus, consultez la section Réservations pour Compute Engine.

Étape suivante

Découvrez les principes de conception de réseaux, y compris les suivants :

• Concevez des architectures de VPC de charge de travail.

• Concevez une connectivité inter-VPC.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Concevoir votre infrastructure réseau

Le présent document du framework d'architecture Google Cloud présente les bonnes pratiques pour déployer votre système en fonction de la conception réseau. Vous apprendrez à choisir et à mettre en œuvre un cloud privé virtuel (VPC), ainsi qu'à tester et gérer la sécurité du réseau.

Principes de base

La conception de la mise en réseau est essentielle à la conception d'un système réussi, car elle vous aide à optimiser les performances et à sécuriser les communications des applications avec des services internes et externes. Lorsque vous choisissez des services de mise en réseau, il est important d'évaluer les besoins de vos applications et de prévoir comment elles vont communiquer entre elles. Par exemple, bien que certains composants nécessitent des services mondiaux, d'autres doivent être géolocalisés dans une région spécifique.

Le réseau privé de Google connecte nos sites régionaux à plus de 100 points de présence du réseau mondial. Google Cloud exploite des technologies de réseau défini par logiciel et des systèmes distribués pour héberger et diffuser vos services dans le monde entier. Le principal composant Google pour la mise en réseau au sein de Google Cloud est le VPC mondial. Le VPC utilise le réseau haut débit mondial de Google pour relier vos applications entre différentes régions tout en garantissant la confidentialité et la fiabilité. Google garantit la diffusion de votre contenu à haut débit grâce à des technologies telles que la bande passante de goulot d'étranglement et le délai de propagation aller-retour (BBR).

Le développement de votre conception de mise en réseau cloud comprend les étapes suivantes :

1. Concevoir l'architecture VPC des charges de travail. Commencez par identifier le nombre de projets Google Cloud et de réseaux VPC dont vous aurez besoin.
2. Ajouter la connectivité inter-VPC Déterminez comment les charges de travail se connectent à d'autres charges de travail situées dans d'autres réseaux VPC.
3. Concevoir une connectivité réseau hybride. Déterminez la manière dont vos VPC de charge de travail se connectent aux environnements sur site ou à d'autres environnements cloud.

Lorsque vous concevez votre réseau Google Cloud, tenez compte des points suivants :

• Un VPC fournit un environnement de mise en réseau privé dans le cloud pour l'interconnexion des services via Compute Engine, Google Kubernetes Engine (GKE) et les Solutions d'informatique sans serveur. Vous pouvez également utiliser un VPC pour accéder en mode privé à des services gérés par Google tels que Cloud Storage, BigQuery et Cloud SQL.
• Les réseaux VPC, y compris leurs routes et règles de pare-feu associées, sont des ressources globales. Ils ne sont associés à aucune région ou zone particulière.
• Les sous-réseaux sont des ressources régionales. Les instances de VM Compute Engine déployées dans différentes zones d'une même région cloud peuvent utiliser des adresses IP du même sous-réseau.
• Le trafic à destination et en provenance des instances peut être contrôlé à l'aide de règles de pare-feu VPC.
• L'administration réseau peut être sécurisée à l'aide de rôles Identity and Access Management (IAM).
• Les réseaux VPC peuvent être connectés en toute sécurité dans des environnements hybrides à l'aide de Cloud VPN ou de Cloud Interconnect.

Pour afficher la liste complète des spécifications VPC, consultez la section Spécifications.

Architecture du VPC de charge de travail

Cette section présente les bonnes pratiques pour concevoir des architectures de VPC de charge de travail adaptées avec votre système.

Se pencher tôt sur la conception des réseaux VPC

Veillez à aborder la conception des réseaux VPC au début du processus de conception de votre infrastructure Google Cloud. Les choix de conception à l'échelle de l'organisation sont souvent difficiles à modifier plus tard dans le processus. Pour plus d'informations, consultez les pages Bonnes pratiques et architectures de référence pour la conception de VPC et Choisir la conception de réseau pour votre zone de destination Google Cloud.

Commencer avec un seul réseau VPC

Pour de nombreux cas d'utilisation incluant des ressources qui ont des exigences communes, un seul réseau VPC fournit toutes les fonctionnalités dont vous avez besoin. Les réseaux VPC uniques sont faciles à créer, à gérer et à comprendre. Pour en savoir plus, consultez la section Spécifications du réseau VPC.

Simplifier la topologie du réseau VPC

Pour garantir une architecture facile à gérer, fiable et bien comprise, assurez-vous d'utiliser une conception de topologie réseau VPC aussi simple que possible.

Utiliser des réseaux VPC en mode personnalisé

Pour vous assurer que la mise en réseau Google Cloud s'intègre parfaitement à vos systèmes réseau existants, nous vous recommandons d'utiliser le mode personnalisé lorsque vous créez des réseaux VPC. Le mode personnalisé vous aide à intégrer la mise en réseau Google Cloud aux schémas d'adresses IP existants et vous permet de contrôler les régions cloud à inclure dans le VPC. Pour en savoir plus, consultez la page VPC.

Connectivité inter-VPC

Cette section présente les bonnes pratiques pour concevoir une connectivité inter-VPC adaptée à votre système.

Choisir une méthode de connexion VPC

Si vous décidez de mettre en œuvre plusieurs réseaux VPC, vous devez les connecter. Les réseaux VPC sont des espaces locataires isolés au sein du réseau défini par logiciel (SDN) Andromeda de Google. Les réseaux VPC peuvent communiquer entre eux de plusieurs façons. Choisissez la manière dont vous connectez votre réseau en fonction de vos exigences en matière de bande passante, de latence et de contrat de niveau de service (SLA). Pour en savoir plus sur les options de connexion, consultez la page Choisir la méthode de connexion VPC qui répond à vos besoins en termes de coûts, de performances et de sécurité.

Administrez plusieurs groupes de travail à l'aide d'un VPC partagé

Pour les organisations comprenant plusieurs équipes, le VPC partagé constitue un outil efficace pour étendre la simplicité architecturale d'un seul réseau VPC à plusieurs groupes de travail.

Utiliser des conventions de nommage simples

Choisissez des conventions de nommage simples, intuitives et cohérentes. Cela permet aux administrateurs et aux utilisateurs de comprendre l'objectif de chaque ressource, son emplacement et sa différence par rapport aux autres ressources.

Utiliser des tests de connectivité pour vérifier la sécurité du réseau

Dans le contexte de la sécurité réseau, vous pouvez effectuer des tests de connectivité pour vérifier que le trafic que vous souhaitez empêcher entre deux points de terminaison est bien bloqué. Pour vérifier que le trafic est bloqué et pourquoi il l'est, mettez en œuvre un test entre deux points de terminaison et évaluez les résultats. Par exemple, vous pouvez tester une fonctionnalité VPC qui vous permet de définir des règles pour bloquer le trafic. Pour en savoir plus, consultez la présentation des tests de connectivité.

Utiliser Private Service Connect pour créer des points de terminaison privés

Pour créer des points de terminaison privés vous permettant d'accéder aux services Google avec votre propre schéma d'adresses IP, utilisez Private Service Connect. Vous pouvez accéder aux points de terminaison privés depuis votre VPC et par l'intermédiaire d'une connectivité hybride qui se termine dans votre VPC.

Sécuriser et limiter la connectivité externe

Limitez l'accès Internet aux seules ressources qui en ont besoin. De plus, les ressources disposant uniquement d'une adresse IP interne privée peuvent toujours accéder à de nombreux services et API Google via l'accès privé à Google.

Surveiller vos réseaux cloud à l'aide de Network Intelligence Center

Network Intelligence Center fournit une vue complète de vos réseaux Google Cloud dans toutes les régions. Il vous aide à identifier les modèles de trafic et les modes d'accès susceptibles de présenter des risques opérationnels ou de sécurité.

Étapes suivantes

Découvrez les bonnes pratiques de gestion du stockage, dont celles ci-dessous :

• Choisir un type de stockage.
• Choisir les modèles d'accès au stockage et les types de charges de travail.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Choisir et mettre en œuvre une stratégie de stockage

Ce document du framework d'architecture Google Cloud décrit les bonnes pratiques à adopter pour déployer votre système en fonction de l'espace de stockage nécessaire. Apprenez à choisir une stratégie de stockage et à gérer le stockage, les modèles d'accès et les charges de travail.

Pour faciliter l'échange de données, ainsi que la sauvegarde et le stockage sécurisés des données, les organisations doivent choisir un plan de stockage basé sur la charge de travail, le nombre d'opérations d'entrée/sortie par seconde (IOPS), la latence, la fréquence de récupération, l'emplacement, la capacité et le format (bloc, fichier et objet).

Cloud Storage fournit des services de stockage d'objets fiables et sécurisés qui incluent les éléments suivants :

• Des options de redondance intégrées pour protéger vos données contre les pannes matérielles et en garantir la disponibilité lors de la maintenance de centre de données.
• Des options de transfert de données incluant celles ci-dessous :
  • Service de transfert de stockage
  • Transfer Appliance
  • Service de transfert de données BigQuery
  • Migration vers Google Cloud : transférer vos ensembles de données volumineux
• Des classes de stockage compatibles avec vos charges de travail.
• Des sommes de contrôle calculées pour toutes les opérations Cloud Storage qui permettent à Google de vérifier les lectures et les écritures.

Dans Google Cloud, les IOPS évoluent en fonction de votre espace de stockage provisionné. Les types d'espaces de stockage tels que Persistent Disk nécessitent une réplication et une sauvegarde manuelles, car ils sont zonaux ou régionaux. En revanche, le stockage d'objets est hautement disponible et réplique automatiquement les données dans une ou plusieurs régions.

Type de stockage

Cette section présente les bonnes pratiques pour choisir un type de stockage adapté à votre système.

Évaluer les options en matière de besoins de stockage hautes performances

Évaluez les disques persistants ou les disques durs SSD locaux pour les applications de calcul nécessitant un stockage hautes performances. Cloud Storage est un magasin d'objets immuable avec gestion des versions. L'utilisation de Cloud Storage avec Cloud CDN permet d'optimiser les coûts, en particulier pour les objets statiques fréquemment consultés.

Filestore accepte les applications multiécriture qui nécessitent un espace partagé hautes performances. Filestore est également compatible avec les applications anciennes et modernes qui doivent effectuer des opérations de fichiers de type POSIX via des montages Network File System (NFS).

Cloud Storage est compatible avec des cas d'utilisation tels que la création de lacs de données et le traitement des exigences d'archivage. Pour votre choix de classe Cloud Storage, il est important de faire un compromis en fonction des coûts d'accès et de récupération, en particulier lorsque vous configurez des règles de conservation. Pour en savoir plus, consultez la page Concevoir une stratégie de stockage optimale pour votre charge de travail cloud.

Par défaut, toutes les options de stockage sont chiffrées au repos et en transit à l'aide de clés gérées par Google. Pour les types de stockage tels que Persistent Disk et Cloud Storage, vous pouvez fournir votre propre clé ou gérer les clés dans Cloud Key Management Service (Cloud KMS). Pensez bien à élaborer une stratégie de gestion des clés avant d'utiliser ces solutions sur les données de production.

Choisir les services Google Cloud adaptés pour prendre en charge la conception du stockage

Pour en savoir plus sur les services Google Cloud compatibles avec la conception du stockage, consultez le tableau suivant :

Service Google Cloud	Description
Cloud Storage	Permet de stocker et de récupérer autant de données que vous le souhaitez, à tout moment et à l'échelle mondiale. Cloud Storage est un outil polyvalent, qui permet par exemple de diffuser le contenu d'un site Web, d'archiver des données ou encore d'assurer la reprise après sinistre. Vous pouvez également vous en servir pour distribuer des objets de données volumineux à vos utilisateurs par téléchargement direct. Pour en savoir plus, consultez les ressources suivantes : Bonnes pratiques Cloud Storage Emplacement des buckets Classes de stockage Cloud Storage FUSE
Persistent Disk	Un service de stockage de blocs à hautes performances pour Google Cloud. Persistent Disk fournit un espace de stockage SSD et HDD que vous pouvez associer à des instances exécutées dans Compute Engine ou Google Kubernetes Engine (GKE). Les disques régionaux fournissent un stockage durable et une réplication durables des données entre deux zones de la même région. Si vous avez besoin d'IOPS plus élevés et d'une faible latence, Google Cloud propose Filestore. Les disques SSD locaux sont rattachés physiquement au serveur qui héberge votre instance de machine virtuelle. Vous pouvez utiliser des disques SSD locaux en tant qu'espace disque temporaire.
Filestore	Un service géré de stockage de fichiers destiné aux applications qui requièrent une interface de système de fichiers ainsi qu'un système de fichiers partagé pour les données. Filestore fournit aux utilisateurs une expérience fluide pour mettre en place un stockage réseau (NAS) géré avec leurs instances Compute Engine et GKE.
Cloud Storage for Firebase	Conçu pour les développeurs d'applications qui doivent stocker et diffuser du contenu généré par les utilisateurs, comme des photos ou des vidéos. Tous vos fichiers sont stockés dans des buckets Cloud Storage et sont donc accessibles depuis Firebase et Google Cloud.

Choisir une stratégie de stockage

Pour choisir une stratégie de stockage répondant aux exigences de votre application, utilisez le tableau suivant :

Cas d'utilisation	Recommandations
Vous souhaitez stocker des données à grande échelle au prix le plus bas, et les performances d'accès ne sont pas un problème.	Cloud Storage
Vous exécutez des applications de calcul qui nécessitent un stockage immédiat. Pour en savoir plus, consultez la page Optimiser les performances des disques persistants et des disques SSD locaux.	Persistent Disk ou SSD local
Vous exécutez des charges de travail hautes performances qui nécessitent un accès en lecture et en écriture à un espace partagé.	Filestore
Vous avez un ou plusieurs cas d'utilisation de calcul hautes performances (HPC) ou à haut débit (HTC).	Utiliser des clusters pour les calculs techniques à grande échelle dans le cloud

Choisir le stockage actif ou le stockage d'archives en fonction des besoins d'accès

Une classe de stockage est un élément de métadonnées utilisé par chaque objet. Pour les données diffusées à un débit élevé avec une haute disponibilité, utilisez la classe Stockage standard. Pour les données rarement consultées et tolérant une disponibilité légèrement inférieure, utilisez la classe Stockage Nearline, Stockage Coldline ou Stockage Archive. Pour en savoir plus sur les coûts liés au choix d'une classe de stockage, consultez la section Tarifs de Cloud Storage.

Évaluer les besoins en termes d'emplacement de stockage et de protection des données pour Cloud Storage

Pour un bucket Cloud Storage situé dans une région, les données qu'il contient sont automatiquement répliquées sur toutes les zones de la région. La réplication des données sur plusieurs zones protège les données en cas de défaillance d'une zone dans une région.

Cloud Storage propose également des emplacements redondants entre les régions, ce qui signifie que les données sont répliquées dans plusieurs centres de données distincts géographiquement. Pour en savoir plus, consultez la page Emplacement des buckets.

Utiliser Cloud CDN pour améliorer la diffusion d'objets statiques

Pour optimiser le coût de récupération des objets et minimiser la latence d'accès, utilisez Cloud CDN. Cloud CDN utilise l'équilibreur de charge d'application externe Cloud Load Balancing pour assurer le routage, la vérification d'état et la compatibilité avec les adresses IP Anycast. Pour plus d'informations, consultez la page Configurer Cloud CDN avec des buckets Cloud.

Modèle d'accès au stockage et type de charge de travail

Cette section présente les bonnes pratiques pour choisir des modèles d'accès au stockage et des types de charges de travail adaptés à votre système.

Utiliser Persistent Disk pour bénéficier d'un accès au stockage hautes performances

Les modèles d'accès aux données dépendent de la manière dont vous concevez les performances du système. Cloud Storage fournit un stockage évolutif, mais ce n'est pas un choix idéal pour exécuter des charges de travail de calcul lourdes qui nécessitent un accès à haut débit à de grandes quantités de données. Pour un accès au stockage à hautes performances, utilisez Persistent Disk.

Utiliser un intervalle exponentiel entre les tentatives lors de la mise en œuvre d'une logique de nouvelle tentative

Utilisez un intervalle exponentiel entre les tentatives lors de la mise en œuvre d'une logique de nouvelle tentative pour gérer les erreurs 5XX, 408 et 429. Chaque bucket Cloud Storage est provisionné avec une capacité d'E/S initiale. Pour en savoir plus, consultez la page Consignes relatives aux taux de demandes et à la distribution des accès. Planifiez une augmentation progressive des requêtes de nouvelle tentative.

Gestion de l'espace de stockage

Cette section présente les bonnes pratiques en matière de gestion du stockage pour optimiser votre système.

Attribuer des noms uniques à chaque bucket

Attribuez un nom unique à chaque bucket sur l'ensemble de l'espace de noms Cloud Storage. N'incluez jamais d'informations sensibles dans un nom de bucket. Choisissez des noms de buckets et d'objets difficiles à deviner. Pour en savoir plus, consultez les consignes de dénomination des buckets et les consignes de dénomination des objets.

Préserver la confidentialité des buckets Cloud Storage

Sauf raison commerciale pertinente, assurez-vous que votre bucket Cloud Storage n'est pas accessible de manière anonyme ou publiquement. Pour en savoir plus, consultez la page Présentation du contrôle des accès.

Attribuer des noms d'objet aléatoires pour répartir la charge uniformément

Attribuez des noms d'objet aléatoires pour optimiser les performances et éviter le hotspotting. Dans la mesure du possible, utilisez un préfixe aléatoire pour les objets. Pour plus d'informations, consultez la section Utiliser une convention de dénomination qui répartit la charge uniformément entre les plages de clés.

Utiliser la protection contre l'accès public

Pour empêcher l'accès au niveau de l'organisation, du dossier, du projet ou du bucket, utilisez la protection contre l'accès public. Pour en savoir plus, consultez la page Utiliser la protection contre l'accès public.

Étape suivante

Découvrez les services de base de données Google Cloud et les bonnes pratiques associées :

• Choisir et migrer vos bases de données.
• Gérer le chiffrement des bases de données.
• Gérer la mise en réseau et l'accès aux bases de données.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Optimiser votre base de données

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques pour déployer votre système en fonction de la conception de base de données. Vous apprendrez à concevoir, migrer et faire évoluer des bases de données, à chiffrer les informations de base de données, à gérer les licences et à surveiller les événements.

Principaux services

Ce document de la catégorie de conception système "Framework d'architecture" fournit les bonnes pratiques à suivre pour divers services de base de données Google Cloud. Le tableau suivant offre une vue d'ensemble de ces services :

Service Google Cloud	Description
Cloud SQL	Un service de base de données entièrement géré qui vous permet de configurer, de maintenir, de gérer et d'administrer vos bases de données relationnelles utilisant Cloud SQL pour PostgreSQL, Cloud SQL pour MySQL et Cloud SQL pour SQL Server. Cloud SQL offre de hautes performances et une excellente évolutivité. Hébergé sur Google Cloud, Cloud SQL fournit une infrastructure de base de données pour les applications exécutées n'importe où.
Bigtable	Une table pouvant s'adapter à des milliards de lignes et des milliers de colonnes, vous permettant ainsi de stocker jusqu'à plusieurs pétaoctets de données. Une seule valeur, dite "clé de ligne", est indexée dans chaque ligne. Utilisez Bigtable pour stocker de très grandes quantités de données à clé unique avec une latence très faible. Cet outil permet de lire et d'écrire à haut débit et à faible latence, et constitue une source de données pour les opérations MapReduce.
Spanner	Un service de base de données d'entreprise évolutif, distribué à l'échelle mondiale et conçu pour le cloud, qui inclut une structure de base de données relationnelle et une évolutivité horizontale non relationnelle. Cette combinaison offre des transactions hautes performances et une cohérence forte entre les lignes, les régions et les continents. Spanner fournit une une disponibilité exceptionnelle de 99,999 % dans le cadre du contrat de niveau de service, et ce sans aucun temps d'arrêt planifié et avec un niveau de sécurité adapté aux entreprises.
Memorystore	Un service Redis entièrement géré pour Google Cloud. Les applications exécutées sur Google Cloud peuvent augmenter leurs performances en utilisant le service Redis hautement disponible, évolutif et sécurisé, sans avoir à gérer de déploiements Redis complexes.
Firestore	Une base de données de documents NoSQL conçue pour le scaling automatique, les hautes performances et le développement d'applications. Bien que l'interface Firestore présente de nombreuses fonctionnalités identiques aux bases de données traditionnelles, il s'agit d'une base de données NoSQL qui décrit les relations entre les objets de données d'une manière différente.
Firebase Realtime Database	Une base de données hébergée dans le cloud. Firebase stocke les données au format JSON et les synchronise en temps réel avec chaque client connecté. Lorsque vous créez des applications multiplates-formes avec nos SDK Google, iOS, Android et JavaScript, tous vos clients partagent une instance de base de données en temps réel et reçoivent automatiquement les mises à jour avec les données les plus récentes.
Bases de données Open Source	Les partenaires Google proposent différentes bases de données Open Source dont MongoDB, MariaDB et Redis.
AlloyDB pour PostgreSQL	Service de base de données entièrement géré compatible avec PostgreSQL pour vos charges de travail d'entreprise les plus exigeantes. Offre des performances jusqu'à quatre fois plus rapides pour les charges de travail transactionnelles et des requêtes d'analyse jusqu'à 100 fois plus rapides que PostgreSQL standard. AlloyDB pour PostgreSQL simplifie la gestion avec des systèmes automatisés basés sur le machine learning.

Choix de la base de données

Cette section présente les bonnes pratiques pour choisir une base de données pour votre système.

Utiliser un service de base de données géré

Évaluez les services de base de données gérés de Google Cloud avant d'installer votre propre base de données ou cluster de base de données. L'installation de votre propre base de données implique une surcharge de maintenance (installation de correctifs et de mises à jour par exemple) ainsi que la gestion d'activités opérationnelles quotidiennes (surveillance et exécution de sauvegardes par exemple).

Utilisez des exigences fonctionnelles et non fonctionnelles pour les applications afin de faciliter le choix de base de données. Pensez aux problématiques d'accès à faible latence, de traitement des données de séries temporelles, de reprise après sinistre et de synchronisation des clients mobiles.

Pour migrer des bases de données, utilisez l'un des produits décrits dans le tableau suivant :

Produit de migration de bases de données	Description
Cloud SQL	Un service régional qui accepte les instances dupliquées avec accès en lecture dans les régions distantes, les lectures à faible latence et la reprise après sinistre.
Spanner	Cloud Spanner est une offre multirégionale qui fournit une cohérence externe, une réplication globale et un contrat de niveau de service (SLA) haute disponibilité.
Bigtable	Un service de base de données NoSQL entièrement géré et évolutif pour les charges de travail analytiques et opérationnelles d'envergure, offrant une disponibilité allant jusqu'à 99,999 %.
Memorystore	Un service de base de données entièrement géré qui fournit une version gérée de deux solutions de mise en cache Open Source largement utilisées : Redis et Memcached.
Firebase Realtime Database	Firebase Realtime Database est une base de données NoSQL hébergée dans le cloud qui vous permet de stocker et de synchroniser des données en temps réel entre vos comptes utilisateur.
Firestore	Une base de données de documents NoSQL conçue pour le scaling automatique, les hautes performances et le confort de développement des applications.
Open Source	Autres options de bases de données dont MongoDB et MariaDB.

Migrer des bases de données

Pour vous assurer que les utilisateurs ne subissent aucune interruption d'application lorsque vous migrez des charges de travail existantes vers Google Cloud, il est important de choisir des technologies de base de données répondant à vos besoins. Pour plus d'informations sur les options et les bonnes pratiques de migration de bases de données, consultez les pages Solutions de migration de bases de données et Bonnes pratiques pour des migrations de bases de données homogènes.

La planification d'une migration de bases de données comprend les éléments suivants :

• Évaluation et découverte de la base de données actuelle.
• Définition des critères de réussite de la migration.
• Configuration de l'environnement de migration et de la base de données cible.
• Création du schéma dans la base de données cible.
• Migration des données vers la base de données cible.
• Validation de la migration pour vérifier que toutes les données sont correctement migrées et présentes dans la base de données.
• Création d'une stratégie de rollback.

Choisir une stratégie de migration

Le choix d'une base de données cible appropriée est l'une des clés de la réussite d'une migration. Le tableau suivant présente les options de migration pour certains cas d'utilisation :

Cas d'utilisation	Recommandation
Nouveau développement dans Google Cloud	Sélectionnez l'une des bases de données gérées conçues pour le cloud (Cloud SQL, Spanner, Bigtable ou Firestore) afin de répondre aux besoins de votre cas d'utilisation.
Migration Lift and Shift	Choisissez un service de base de données géré compatible, tel que Cloud SQL, MySQL ou PostgreSQL.
Votre application nécessite un accès précis à une base de données qui n'est pas compatible avec Cloud SQL.	Exécutez votre base de données sur des VM Compute Engine.

Utiliser Memorystore pour la couche de base de données de mise en cache

Memorystore est une base de données Redis et Memcached entièrement gérée qui offre une latence inférieure à la milliseconde. Memorystore est entièrement compatible avec les systèmes Open Source Redis et Memcached. Si vous utilisez ces bases de données de mise en cache dans vos applications, vous pouvez utiliser Memorystore sans modifier le code de ces applications.

Utiliser un serveur sur solution Bare Metal pour exécuter une base de données Oracle

Si vos charges de travail nécessitent une base de données Oracle, utilisez les serveurs sur solution Bare Metal fournis par Google Cloud. Cette approche s'intègre à une stratégie de migration Lift and Shift.

Si vous souhaitez déplacer votre charge de travail vers Google Cloud et commencer le processus de modernisation une fois que votre charge de travail de référence fonctionne, envisagez d'utiliser des options de base de données gérées telles queSpanner ,Bigtable etFirestore.

Les bases de données conçues pour le cloud sont des bases de données gérées modernes qui sont conçues de bas en haut sur l'infrastructure cloud. Ces bases de données offrent des fonctionnalités par défaut uniques, telles que l'évolutivité et la haute disponibilité, qui sont difficiles à obtenir en exécutant votre propre solution de base de données.

Moderniser votre base de données

Planifiez votre stratégie de base de données dès le début du processus de conception du système, que vous souhaitiez concevoir une nouvelle application ou migrer une base de données existante vers le cloud. Google Cloud fournit des options de bases de données gérées pour les bases de données Open Source telles que Cloud SQL pour MySQL et Cloud SQL pour PostgreSQL. Nous vous recommandons d'exploiter la migration comme une opportunité de moderniser votre base de données et de la préparer à répondre aux futurs besoins de l'entreprise.

Utiliser des bases de données fixes avec des applications prêtes à l'emploi

Les applications commerciales prêtes à l'emploi (COTS) nécessitent un type de base de données et une configuration fixes. L'approche Lift and Shift est généralement l'approche de migration la plus appropriée pour les applications COTS.

Vérifier les compétences de votre équipe en matière de migration de bases de données

Choisissez l'approche de migration de base de données cloud en fonction des capacités et des compétences de votre équipe. Utilisez Google Cloud Partner Advantage pour trouver un partenaire qui vous aidera tout au long de votre migration.

Concevoir votre base de données pour répondre aux exigences en matière de haute disponibilité et de reprise après sinistre

Lorsque vous concevez vos bases de données pour répondre aux exigences de haute disponibilité et de reprise après sinistre, évaluez les compromis entre fiabilité et coût. Les services de base de données conçus pour le cloud créent plusieurs copies de vos données dans une ou plusieurs régions, en fonction de la base de données et de la configuration.

Certains services Google Cloud proposent des variantes multirégionales, par exemple BigQuery et Spanner. Pour plus de résilience contre les défaillances régionales, utilisez ces services multirégionaux dans la mesure du possible.

Si vous concevez votre base de données sur des VM Compute Engine au lieu d'utiliser des bases de données gérées sur Google Cloud, veillez à exécuter plusieurs copies de vos bases de données. Pour plus d'informations, consultez la section Concevoir des solutions évolutives et à haute disponibilité dans la catégorie "Fiabilité".

Spécifier des régions cloud pour la résidence des données

La résidence des données décrit l'emplacement physique de vos données au repos. Envisagez de choisir des régions cloud spécifiques pour déployer vos bases de données en fonction de vos exigences de résidence des données.

Si vous déployez vos bases de données dans plusieurs régions, il peut y avoir une réplication des données entre ces régions selon la configuration utilisée. Sélectionnez la configuration qui conserve vos données au repos dans les régions souhaitées. Certaines bases de données telles que Spanner proposent une réplication multirégionale par défaut. Vous pouvez également appliquer la résidence des données en définissant une règle d'administration qui inclut les contraintes d'emplacements de ressources. Pour en savoir plus, consultez la section Restreindre les emplacements de ressources.

Inclure la reprise après sinistre dans la conception de résidence des données

Incluez l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) dans vos plans de résidence des données, et réfléchissez au compromis à faire entre les valeurs RTO/RPO et les coûts de la solution de reprise après sinistre. Des valeurs RTO/RPO plus faibles entraînent des coûts plus élevés. Si vous souhaitez que votre système soit rétabli plus rapidement après une interruption, son coût d'exécution sera plus élevé. Tenez également compte de la satisfaction des clients dans votre approche de reprise après sinistre, pour vous assurer que vos investissements en fiabilité sont appropriés. Pour en savoir plus, consultez les sections La fiabilité à 100% est la mauvaise cible et Guide de planification de reprise après sinistre.

Rendre votre base de données conforme à Google Cloud

Lorsque vous choisissez une base de données pour votre charge de travail, assurez-vous que le service sélectionné répond aux critères de conformité pour la région géographique dans laquelle vous travaillez et où vos données sont physiquement stockées. Pour en savoir plus sur les certifications et les normes de conformité Google, consultez la section Offres de conformité.

Chiffrement

Cette section présente les bonnes pratiques permettant d'identifier les exigences de chiffrement et de choisir une stratégie de clé de chiffrement adaptée à votre système.

Déterminer les exigences de chiffrement

Vos exigences de chiffrement dépendent de plusieurs facteurs, tels que les règles de sécurité de l'entreprise et les exigences de conformité. Toutes les données stockées dans Google Cloud sont chiffrées au repos par défaut et sans aucune action requise de votre part à l'aide de l'algorithme AES256. Pour plus d'informations, consultez la section Chiffrement au repos dans Google Cloud.

Choisir une stratégie de clé de chiffrement

Décidez si vous souhaitez gérer les clés de chiffrement vous-même ou si vous souhaitez utiliser un service géré. Google Cloud est compatible avec ces deux scénarios. Si vous souhaitez qu'un service entièrement géré gère vos clés de chiffrement sur Google Cloud, choisissez Cloud Key Management Service (Cloud KMS). Si vous souhaitez gérer vos clés de chiffrement afin de mieux contrôler le cycle de vie des clés, utilisez les clés de chiffrement gérées par le client (CMEK).

Pour créer et gérer vos clés de chiffrement en dehors de Google Cloud, choisissez l'une des options suivantes :

• Si vous utilisez une solution partenaire pour gérer vos clés, utilisez Cloud External Key Manager.
• Si vous gérez vos clés sur site et que vous souhaitez les utiliser pour chiffrer les données sur Google Cloud, importez-les dans Cloud KMS en tant que clés KMS ou clés HSM (Hardware Key Module). Utilisez ces clés pour chiffrer vos données sur Google Cloud.

Conception et scaling de bases de données

Cette section présente les bonnes pratiques relatives à la conception et au scaling d'une base de données pour votre système.

Évaluer les besoins en scaling à l'aide des métriques de surveillance

Utilisez les métriques des outils de surveillance existants et des environnements pour mieux comprendre les exigences de taille et de scaling de base de données, par exemple avec les stratégies de redimensionnement et de scaling de votre instance de base de données.

Pour les nouvelles conceptions de base de données, déterminez les chiffres de scaling sur la base des modèles de charge et de trafic attendus en provenance de l'application de diffusion. Pour en savoir plus, consultez les pages Surveiller les instances Cloud SQL, Surveiller avec Cloud Monitoring et Surveiller une instance.

Mise en réseau et accès

Cette section présente les bonnes pratiques de gestion de la mise en réseau et de l'accès pour votre système.

Exécuter des bases de données dans un réseau privé

Exécutez vos bases de données dans votre réseau privé et n'accordez un accès restreint qu'aux clients qui ont besoin d'interagir avec la base de données. Vous pouvez créer des instances Cloud SQL dans un VPC. Google Cloud fournit également des bases de données VPC Service Controls pour Cloud SQL, Spanner et Bigtable afin de garantir que l'accès à ces ressources est limité aux clients au sein des réseaux VPC autorisés.

Accorder des droits minimaux aux utilisateurs

La gestion de l'authentification et des accès (IAM) contrôle l'accès aux services Google Cloud, ce qui inclut les services de base de données. Pour réduire le risque d'accès non autorisé, accordez le moins de privilèges possible à vos utilisateurs. Pour un accès au niveau de l'application à vos bases de données, utilisez des comptes de service disposant des privilèges minimum requis.

Automatisation et redimensionnement

Cette section présente les bonnes pratiques relatives à l'automatisation et au redimensionnement pour votre système.

Définir les instances de base de données sous forme de code

L'un des avantages de la migration vers Google Cloud est la possibilité d'automatiser votre infrastructure ainsi que d'autres aspects de votre charge de travail tels que les couches de calcul et de base de données. Google Deployment Manager et les outils tiers tels que Terraform Cloud vous permettent de définir vos instances de base de données sous forme de code, ce qui vous permet d'appliquer une approche cohérente et reproductible pour la création et à la mise à jour de vos bases de données.

Utiliser Liquibase pour le contrôle des versions de votre base de données

Les services de base de données Google tels que Cloud SQL et Spanner sont compatibles avec Liquibase, un outil de contrôle des versions Open Source pour les bases de données. Liquibase vous aide à suivre les modifications de schéma de votre base de données, à effectuer un rollback des modifications de schéma et à effectuer des migrations reproductibles.

Tester et paramétrer la base de données pour assurer sa compatibilité

Effectuez des tests de charge sur votre instance de base de données et ajustez les réglages en fonction des résultats des tests pour répondre aux exigences de votre application. Déterminez l'échelle initiale de votre base de données en testant des indicateurs clés de performance (KPI) ou en utilisant des KPI de surveillance dérivés de votre base de données actuelle.

Lorsque vous créez des instances de base de données, commencez par une taille basée sur les résultats des tests ou sur l'historique des métriques de surveillance. Testez vos instances de base de données avec la charge attendue dans le cloud. Ensuite, ajustez le paramétrage des instances jusqu'à obtenir les résultats souhaités pour la charge attendue sur vos instances de base de données.

Choisir la base de données adaptée à vos exigences de scaling

Le scaling des bases de données est différent du scaling des composants de la couche de calcul. Les bases de données ont un état. Lorsqu'une instance de votre base de données n'est pas en mesure de gérer la charge, il faut envisager une stratégie appropriée pour le scaling de vos instances de base de données. Les stratégies de scaling varient en fonction du type de base de données.

Utilisez le tableau suivant pour en savoir plus sur les produits Google qui répondent aux cas d'utilisation de scaling.

Cas d'utilisation	Produit recommandé	Description
Effectuer un scaling horizontal de votre instance de base de données en ajoutant des nœuds à votre base de données lorsque vous devez augmenter la capacité de diffusion et l'espace de stockage.	Spanner	Une base de données relationnelle conçue pour le cloud.
Ajouter des nœuds pour mettre à l'échelle votre base de données.	Bigtable	Service de bases de données NoSQL big data entièrement géré.
Gérer automatiquement le scaling de la base de données.	Firestore	Base de données flexible et évolutive pour le développement mobile, Web et serveur.
Pour diffuser plus de requêtes, effectuez un scaling vertical à la hausse des instances de base de données Cloud SQL afin de leur accorder plus de capacité de calcul et de mémoire. Dans Cloud SQL, la couche de stockage est découplée de l'instance de base de données. Vous pouvez choisir de faire évoluer automatiquement votre couche de stockage chaque fois qu'elle s'approche de sa pleine capacité.	Cloud SQL	Service de base de données entièrement géré qui vous aide à configurer, maintenir, gérer et administrer vos bases de données relationnelles sur Google Cloud.

Opérations

Cette section présente les bonnes pratiques en matière d'opérations pour votre système.

Utiliser Cloud Monitoring pour surveiller et configurer des alertes pour votre base de données

Utilisez Cloud Monitoring pour surveiller vos instances de base de données et configurer des alertes afin d'avertir les équipes appropriées de certains événements. Pour en savoir plus sur les bonnes pratiques pour des alertes efficaces, consultez la section Créer des alertes efficaces.

Toutes les bases de données conçues pour le cloud fournissent des métriques de journalisation et de surveillance. Chaque service fournit un tableau de bord permettant de visualiser les métriques de journalisation et de surveillance. Les métriques de surveillance de tous les services sont intégrées à Google Cloud Observability. Spanner fournit des outils d'introspection des requêtes tels que Key Visualizer pour le débogage et l'analyse des causes fondamentales. Key Visualizer offre les fonctionnalités suivantes :

• Il permet d'analyser les schémas d'utilisation de Spanner en générant des rapports visuels pour vos bases de données. Les rapports affichent les modèles d'utilisation par plages de lignes au fil du temps.
• Fournit des informations sur les modèles d'utilisation à grande échelle.

Bigtable fournit également un outil de diagnostic Key Visualizer qui vous aide à analyser les schémas d'utilisation des instances Bigtable.

Licences

Cette section présente les bonnes pratiques relatives à la gestion des licences pour votre système.

Choisir entre licences à la demande et licences existantes

Si vous utilisez Cloud SQL pour SQL Server, il n'est pas possible d'importer vos propres licences. Vos coûts de licence sont basés sur le nombre d'heures d'utilisation par cœur.

Si vous souhaitez utiliser des licences Cloud SQL pour SQL Server existantes, envisagez d'exécuter Cloud SQL pour SQL Server sur des VM Compute. Pour en savoir plus, consultez les pages Licences Microsoft et Choisir entre licences à la demande et transfert de licences existantes.

Si vous utilisez Oracle et que vous migrez vers la solution Bare Metal pour Oracle, vous pouvez utiliser vos propres licences. Pour en savoir plus, consultez la page Planifier la solution Bare Metal.

Calendriers, méthodologie et ensembles d'outils de migration

Cette section présente les bonnes pratiques pour planifier et prendre en charge la migration de votre base de données de façon optimale pour votre système.

Déterminer si vous êtes prêt à moderniser votre base de données

Déterminez si votre organisation est prête à moderniser vos bases de données et à utiliser des bases de données conçues pour le cloud.

Pensez à la modernisation de la base de données lorsque vous planifiez les délais de migration des charges de travail, car cette modernisation est susceptible d'avoir un impact sur l'application.

Impliquer les parties prenantes pertinentes dans la planification de la migration

Pour migrer une base de données, procédez comme suit :

• Configurez les bases de données cibles.
• Convertissez le schéma.
• Configurez la réplication des données entre la base de données source et cible
• Déboguez les problèmes au fur et à mesure qu'ils surviennent.
• Établissez une connectivité réseau entre la couche d'application et la base de données.
• Mettez en œuvre la sécurité cible de la base de données.
• Assurez-vous que les applications se connectent aux bases de données cibles.

Ces tâches nécessitent bien souvent des compétences diverses et une collaboration de plusieurs équipes au sein de votre organisation pour effectuer la migration. Lorsque vous planifiez la migration, incluez les parties prenantes de toutes les équipes (développeurs d'applications, administrateurs de bases de données, équipes chargées de l'infrastructure et de la sécurité).

Si votre équipe ne dispose pas des compétences nécessaires pour ce type de migration, les partenaires de Google peuvent vous aider à effectuer vos migrations. Pour en savoir plus, consultez la page Google Cloud Partner Advantage.

Identifier les ensembles d'outils pour les migrations homogènes et hétérogènes

Une migration homogène est une migration de base de données entre des bases de données source et cible qui utilisent la même technologie de base de données. Une migration hétérogène est une migration dont la base de données cible est différente de la base de données source.

Les migrations hétérogènes impliquent généralement des étapes supplémentaires de conversion pour passer du moteur de base de données source au moteur de base de données cible. Vos équipes de base de données doivent évaluer les difficultés liées à la conversion de schéma, car elles dépendent de la complexité du schéma de base de données source.

Tester et valider chaque étape de la migration de données

Les migrations de données impliquent plusieurs étapes. Pour minimiser les erreurs de migration, testez et validez chaque étape de la migration avant de passer à l'étape suivante. Les facteurs suivants définissent le processus de migration :

• Migration est homogène ou hétérogène.
• Types d'outils et de compétences dont vous disposez pour effectuer la migration
• Pour les migrations hétérogènes, votre expérience avec le moteur de base de données cible.

Déterminer les exigences de réplication des données en continu

Créez un plan pour migrer les données initialement, puis répliquer en continu les données de la base de données source vers la base de données cible. Continuez la réplication jusqu'à ce que la cible soit stabilisée et que l'application soit complètement migrée vers la nouvelle base de données. Ce plan vous permet d'identifier les temps d'arrêt potentiels pendant le changement de base de données et de planifier en conséquence.

Si vous envisagez de migrer des moteurs de base de données depuis Cloud SQL, Cloud SQL pour MySQL ou Cloud SQL pour PostgreSQL, utilisez Database Migration Service pour automatiser ce processus de manière entièrement gérée. Pour en savoir plus sur les outils tiers compatibles avec d'autres types de migrations, consultez la page Cloud Marketplace.

Recommandations

Pour appliquer les recommandations du framework d'architecture à votre propre environnement, nous vous conseillons de procéder comme suit :

• L'architecture mutualisée pour les bases de données implique de stocker des données de plusieurs clients sur une infrastructure partagée (dans le cas présent, une base de données). Si vous proposez une offre SaaS (Software-as-a-Service) à vos clients, assurez-vous de bien comprendre comment isoler logiquement les ensembles de données appartenant à différents clients et comment fournir le niveau d'accès demandé. Par ailleurs, évaluez vos exigences en fonction de niveaux de séparation.

  Pour les bases de données relationnelles telles que Spanner et Cloud SQL, il existe plusieurs approches, telles que l'isolation des données des locataires au niveau de l'instance de base de données, au niveau de la base de données, au niveau du schéma ou au niveau de la table de base de données. Comme pour les autres décisions de conception, il y a un compromis à faire entre le degré d'isolation et d'autres facteurs tels que les coûts et les performances. Les stratégies IAM contrôlent l'accès à vos instances de base de données.

• Choisissez la base de données adaptée aux exigences de votre modèle de données.

• Choisissez les valeurs de clé de manière à éviter le hotspotting de clé. Un hotspot est un emplacement d'une table qui reçoit beaucoup plus de requêtes d'accès que d'autres emplacements. Pour en savoir plus sur les hotspots, consultez la page Bonnes pratiques relatives à la conception de schémas.

• Dans la mesure du possible, segmentez votre instance de base de données.

• Utilisez les bonnes pratiques de gestion des connexions, telles que le regroupement de connexions et l'intervalle exponentiel entre les tentatives.

• Évitez les très grosses transactions.

• Concevez et testez la réponse de votre application aux mises à jour de maintenance sur les bases de données.

• Sécurisez et isolez les connexions à votre base de données.

• Dimensionnez votre base de données et vos attentes en termes de croissance pour vous assurer que la base de données répond à vos besoins.

• Testez vos stratégies de basculement pour la haute disponibilité et la reprise après sinistre.

• Effectuez des sauvegardes et des restaurations, ainsi que des exportations et des importations afin de vous familiariser avec le processus.

Recommandations Cloud SQL

• Utilisez un réseau d'adresses IP privées (VPC). Pour plus de sécurité, tenez compte des points suivants :
  • Utilisez le proxy d'authentification Cloud SQL pour accepter les réseaux privés.
  • Restreignez l'accès des adresses IP publiques constraints/sql.restrictPublicIp.
• Si vous avez besoin d'un réseau d'adresses IP publiques, envisagez les éléments suivants :
  • Utilisez le pare-feu intégré avec une liste d'adresses IP limitée ou restreinte, et assurez-vous que les instances Cloud SQL obligent les connexions entrantes à utiliser SSL. Pour en savoir plus, consultez la page Configurer des certificats SSL/TLS.
• Pour plus de sécurité, tenez compte des points suivants :
  • N'accordez pas d'accès général. Utilisez plutôt le proxy d'authentification Cloud SQL.
  • Limitez les réseaux autorisés constraints/sql.restrictAuthorizedNetworks.
• Accordez des droits limités aux utilisateurs de base de données.

Étape suivante

Découvrez les bonnes pratiques en matière d'analyse de données, qui incluent les éléments suivants :

• Découvrez les principes fondamentaux de l'analyse de données et les services Google Cloud clés.
• Découvrez le cycle de vie des données.
• Découvrez comment ingérer des données.
• Choisissez et gérez le stockage de données.
• Traitement et transformation des données.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Analyser vos données

Ce document du framework d'architecture Google Cloud explique certains des principes fondamentaux et des bonnes pratiques pour l'analyse de données dans Google Cloud. Vous découvrirez certains des services clés d'analyse de données, et la façon dont ils peuvent vous aider aux différentes étapes du cycle de vie des données. Ces bonnes pratiques vous aident à répondre à vos besoins d'analyse de données et à concevoir votre système.

Principes de base

Les entreprises souhaitent analyser des données et générer des insights exploitables à partir de celles-ci. Google Cloud propose divers services qui vous aident tout au long du cycle de vie des données, de l'ingestion à la création de rapports, en passant par la visualisation. La plupart de ces services sont entièrement gérés, et certains sont sans serveur. Vous pouvez également créer et gérer un environnement d'analyse de données sur des VM Compute Engine, par exemple en auto-hébergeant Apache Hadoop ou Beam.

Votre objectif particulier, votre expertise de l'équipe et votre perspective stratégique vous aident à déterminer les services Google Cloud que vous adoptez pour répondre à vos besoins d'analyse de données. Par exemple, Dataflow vous permet d'écrire des transformations complexes dans une approche sans serveur, mais vous devez vous appuyer sur une version rigoureuse des configurations pour les besoins de calcul et de traitement. Sinon, Dataproc vous permet d'exécuter les mêmes transformations, mais vous gérez les clusters et ajustez les tâches vous-même.

Dans la conception de votre système, réfléchissez à la stratégie de traitement utilisée par vos équipes, telle que extraction, transformation, chargement (ETL) ou extraction, chargement, transformation (ELT). La conception de votre système doit également déterminer si vous devez traiter des analyses par lots ou des analyses de flux. Google Cloud fournit une plate-forme de données unifiée, et vous permet de créer un lac de données ou un entrepôt de données pour répondre à vos besoins métier.

Principaux services

Le tableau suivant offre une vue d'ensemble des services d'analyse Google Cloud :

Service Google Cloud	Description
Pub/Sub	Une base simple, fiable et évolutive pour l'analyse des flux et le calcul informatique basé sur des événements.
Dataflow	Service entièrement géré pour transformer et enrichir les données en mode flux (temps réel) ou lot (historique).
Dataprep by Trifacta	Service de données intelligent pour explorer, nettoyer et préparer visuellement des données structurées et non structurées à des fins d'analyse.
Dataproc	Service cloud rapide, facile à utiliser et entièrement géré permettant d'exécuter des clusters Apache Spark et Apache Hadoop.
Cloud Data Fusion	Service d'intégration de données entièrement géré, conçu pour le cloud, et permettant de créer et de gérer des pipelines de données ETL/ELT. Cloud Data Fusion fournit une interface graphique et une vaste bibliothèque Open Source de connecteurs et de transformations préconfigurés.
BigQuery	Entrepôt de données sans serveur, entièrement géré et à faible coût, qui évolue en fonction de vos besoins en termes de stockage et de puissance de calcul. BigQuery est une base de données en colonnes et ANSI SQL capable d'analyser plusieurs téraoctets ou pétaoctets de données.
Cloud Composer	Service d'orchestration de workflows entièrement géré qui vous permet de créer, de planifier et de surveiller vos pipelines dans plusieurs clouds ou des centres de données sur site.
Data Catalog	Service de gestion des métadonnées entièrement géré et évolutif qui vous aide à découvrir, gérer et comprendre toutes vos données.
Looker Studio	Service d'analyse visuelle entièrement géré qui peut vous aider à obtenir des insights à partir de vos données, via des tableaux de bord interactifs.
Looker	Plate-forme d'entreprise qui connecte, analyse et visualise les données dans des environnements multicloud.
Dataform	Produit entièrement géré pour vous aider à collaborer, à créer et à déployer des pipelines de données, et garantir la qualité des données.
Dataplex	Service de lac de données géré qui gère, surveille et régit les données de manière centralisée sur les lacs de données, les entrepôts de données et les magasins de données à l'aide de contrôles cohérents.
Analytics Hub	Plate-forme qui échange de manière efficace et sécurisée des éléments d'analyse de données au sein de votre organisation afin de relever les défis liés à la fiabilité et aux coûts des données.

Cycle de vie des données

Lorsque vous concevez votre système, vous pouvez regrouper les services d'analyse de données Google Cloud autour du transfert général des données dans un système ou autour du cycle de vie des données.

Le cycle de vie des données comprend les étapes et exemples de services suivants :

• L'ingestion inclut des services tels que Pub/Sub, le service de transfert de stockage, Transfer Appliance et BigQuery.
• Le stockage inclut des services tels que Cloud Storage, Bigtable, Memorystore et BigQuery.
• Le traitement et la transformation : incluent des services tels que Dataflow, Dataproc, Dataprep, la Protection des données sensibles et BigQuery.
• L'analyse et l'entreposage incluent des services tels que BigQuery.
• La création de rapports et la visualisation incluent des services tels que Looker Studio et Looker.

Les étapes et services suivants s'exécutent sur l'ensemble du cycle de vie des données :

• L'intégration des données inclut des services tels que Data Fusion.
• La gestion et la gouvernance des métadonnées incluent des services tels que Data Catalog.
• La gestion des workflows inclut des services tels que Cloud Composer.

Ingestion de données

Appliquez les bonnes pratiques suivantes à votre propre environnement pour l'ingestion de données.

Déterminer la source de données pour l'ingestion

Les données proviennent généralement d'un autre fournisseur ou service cloud, ou d'un emplacement sur site :

• Pour ingérer des données provenant d'autres fournisseurs cloud, vous utilisez généralement Cloud Data Fusion, le service de transfert de stockage ou le service de transfert BigQuery.

• Pour l'ingestion de données sur site, prenez en compte le volume de données à ingérer et l'ensemble de compétences de votre équipe. Si votre équipe préfère une approche d'interface utilisateur graphique (IUG) à faible code, utilisez Cloud Data Fusion avec un connecteur adapté, tel que Java Database Connectivity (JDBC). Pour les volumes de données importants, vous pouvez utiliser Transfer Appliance ou le service de transfert de stockage.

Réfléchissez à la manière dont vous souhaitez traiter vos données après leur ingestion. Par exemple, le service de transfert de stockage n'écrit que des données dans un bucket Cloud Storage et le service de transfert de données BigQuery n'écrit que des données dans un ensemble de données BigQuery. Cloud Data Fusion est compatible avec plusieurs destinations.

Identifier les sources de données par flux ou par lot

Réfléchissez à la façon dont vous devez utiliser vos données et identifiez les cas d'utilisation par flux ou par lot. Par exemple, si vous exécutez un service de streaming global ayant des exigences de faible latence, vous pouvez utiliser Pub/Sub. Si vous avez besoin de vos données pour des analyses et des rapports, vous pouvez diffuser des données dans BigQuery.

Si vous avez besoin de diffuser des données à partir d'un système tel que Apache Kafka dans un environnement sur site ou dans un autre environnement cloud, utilisez le modèle Kafka vers BigQuery Dataflow. Pour les charges de travail par lot, la première étape consiste généralement à ingérer des données dans Cloud Storage. Utilisez l'outil gsutil ou le service de transfert de stockage pour ingérer des données.

Ingérer des données avec des outils automatisés

Transférer manuellement des données depuis d'autres systèmes dans le cloud peut s'avérer compliqué. Si possible, utilisez des outils vous permettant d'automatiser les processus d'ingestion de données. Par exemple, Cloud Data Fusion fournit des connecteurs et des plug-ins permettant d'importer des données à partir de sources externes avec une IUG avec glisser-déposer. Si vos équipes souhaitent écrire du code, Dataflow ou BigQuery peuvent vous aider à automatiser l'ingestion de données. Pub/Sub peut être utile dans les deux cas. Pour ingérer des données dans des buckets de stockage, utilisez gsutil pour des tailles de données allant jusqu'à 1 To. Pour ingérer des quantités de données supérieures à 1 To, utilisez le service de transfert de stockage.

Utiliser des outils de migration pour ingérer un autre entrepôt de données

Si vous devez effectuer une migration depuis un autre système d'entreposage de données, tel que Teradata, Netezza ou Redshift, vous pouvez utiliser l'assistance à la migration du service de transfert de données BigQuery. Le service de transfert de données BigQuery fournit également des transferts tiers qui vous aident à ingérer des données de manière planifiée à partir de sources externes. Pour plus d'informations, consultez les approches de migration détaillées pour chaque entrepôt de données.

Estimer vos besoins en matière d'ingestion de données

Le volume de données que vous devez ingérer vous permet de déterminer le service à utiliser dans la conception de votre système. Pour l'ingestion de données en streaming, Pub/Sub effectue un scaling à des dizaines de gigaoctets par seconde. La capacité, le stockage et les exigences régionales de vos données vous aident à déterminer si Pub/Sub Lite est une meilleure option pour la conception de votre système. Pour plus d'informations, consultez la page Choisir Pub/Sub ou Pub/Sub Lite.

Pour l'ingestion de données par lots, estimez la quantité de données que vous souhaitez transférer au total, et la vitesse à laquelle vous souhaitez le faire. Examinez les options de migration disponibles, y compris une estimation sur la durée et la comparaison des transferts en ligne et hors connexion.

Utiliser les outils appropriés pour ingérer régulièrement les données de manière planifiée

Le service de transfert de stockage et le service de transfert de données BigQuery vous permettent de planifier des tâches d'ingestion. Pour contrôler avec précision le moment de l'ingestion, ou le système source et de destination, utilisez un système de gestion de workflows tel que Cloud Composer. Si vous souhaitez une approche plus manuelle, vous pouvez utiliser Cloud Scheduler et Pub/Sub pour déclencher une fonction Cloud.
Si vous souhaitez gérer l'infrastructure Compute, vous pouvez exécuter la commande gsutil avec Cron pour transférer des données allant jusqu'à 1 To. Si vous utilisez cette approche manuelle au lieu de Cloud Composer, suivez les bonnes pratiques pour créer des transferts de production.

Examiner les besoins en ingestion de données du serveur FTP/SFTP

Si vous avez besoin d'un environnement sans code pour ingérer les données d'un serveur FTP/SFTP, vous pouvez utiliser les plug-ins de copie FTP. Si vous souhaitez moderniser et créer une solution de workflow à long terme, Cloud Composer est un service entièrement géré qui vous permet de lire et d'écrire à partir de différents récepteurs et sources.

Utiliser des connecteurs Apache Kafka pour ingérer des données

Si vous utilisez Pub/Sub, Dataflow ou BigQuery, vous pouvez ingérer des données à l'aide de l'un des connecteurs Apache Kafka. Par exemple, le connecteur Pub/Sub Kafka Open Source vous permet d'ingérer des données provenant de Pub/Sub ou de Pub/Sub Lite.

Autres ressources

• Bonnes pratiques concernant les agents du service de transfert de stockage Cloud Storage
• Ingérer des données dans BigQuery pour les analyser
• Ingérer des données cliniques et opérationnelles avec Cloud Data Fusion
• Optimiser l'ingestion à grande échelle d'événements et de journaux d'analyse

Stockage de données

Appliquez les bonnes pratiques de stockage de données suivantes à votre propre environnement.

Choisissez le datastore adapté à vos besoins

Pour vous aider à choisir le type de solution de stockage à utiliser, examinez et comprenez l'utilisation en aval de vos données. Les cas d'utilisation courants de données suivants fournissent des recommandations pour les produits Google Cloud à utiliser :

Cas d'utilisation de données	Recommandation de produits
Basé sur un fichier	Filestore
Basés sur les objets	Cloud Storage
Latence faible	Bigtable
Séries temporelles	Bigtable
Cache en ligne	Memorystore
Traitement des transactions	Cloud SQL
Informatique décisionnelle (BI) et analyses	BigQuery
Traitement par lot	Cloud Storage Bigtable si les données entrantes sont des séries temporelles et que vous avez besoin d'un accès à faible latence. BigQuery si vous utilisez SQL.

Examiner vos besoins en matière de structure de données

Pour la plupart des données non structurées, telles que les documents et les fichiers texte, les fichiers audio et vidéo ou les journaux, un magasin basé sur les objets est le choix le plus approprié. Vous pouvez ensuite charger et traiter les données à partir du stockage d'objets lorsque vous en avez besoin.

Pour les données semi-structurées, telles que XML ou JSON, vos cas d'utilisation et modèles d'accès aux données vous aident à faire votre choix. Vous pouvez charger ces ensembles de données dans BigQuery pour la détection automatique de schéma. Si vous avez des exigences de faible latence, vous pouvez charger vos données JSON dans Bigtable. Si vous avez d'anciennes exigences ou si vos applications fonctionnent avec des bases de données relationnelles, vous pouvez également charger des ensembles de données dans un magasin de relations.

Pour les données structurées, telles que CSV, Parquet, Avro ou ORC, vous pouvez utiliser BigQuery si vous avez des exigences en termes d'informatique décisionnelle et d'analyse utilisant SQL. Pour en savoir plus, consultez la section Charger des données par lot. Si vous souhaitez créer un lac de données basé sur des normes et des technologies ouvertes, vous pouvez utiliser Cloud Storage.

Migrer des données et réduire les coûts pour HDFS

Essayez de transférer les données du système de fichiers distribué Hadoop (HDFS, Hadoop Distributed File System) depuis un environnement sur site ou un autre fournisseur cloud vers un système de stockage d'objets moins coûteux. Cloud Storage est l'option la plus courante que les entreprises utilisent comme magasin de données alternatif. Pour en savoir plus sur les avantages et les inconvénients de ce choix, consultez la section HDFS par rapport à Cloud Storage.

Vous pouvez déplacer des données avec une méthode push ou pull. Les deux méthodes utilisent la commande hadoop distcp. Pour en savoir plus, consultez la page Migrer des données HDFS sur site vers Google Cloud.

Vous pouvez également utiliser le connecteur Cloud Storage Open Source pour permettre aux tâches Hadoop et Spark d'accéder aux données dans Cloud Storage. Le connecteur est installé par défaut sur les clusters Dataproc et peut être installé manuellement sur d'autres clusters.

Utiliser le stockage d'objets pour créer un lac de données cohérent

Un lac de données est un dépôt centralisé conçu pour stocker, traiter et sécuriser de grands volumes de données structurées, semi-structurées et non structurées. Vous pouvez utiliser Cloud Composer et Cloud Data Fusion pour créer un lac de données.

Pour créer une plate-forme de données moderne, vous pouvez utiliser BigQuery comme source de données centrale au lieu de Cloud Storage. BigQuery est un entrepôt de données moderne offrant une séparation du stockage et du calcul. Un lac de données créé sur BigQuery vous permet d'effectuer des analyses traditionnelles à partir de BigQuery dans Cloud Console. Vous pouvez également accéder aux données stockées à partir d'autres frameworks, tels qu'Apache Spark.

Autres ressources

• Bonnes pratiques relatives à Cloud Storage
• Bonnes pratiques pour l'optimisation des coûts liés à Cloud Storage.
• Bonnes pratiques pour garantir la confidentialité et la sécurité de vos données dans Cloud Storage
• Bonnes pratiques pour Memorystore
• Optimiser le stockage dans BigQuery
• Conception de schéma Bigtable

Traiter et transformer les données

Appliquez les bonnes pratiques d'analyse de données suivantes à votre propre environnement lorsque vous traitez et transformez des données.

Découvrir les logiciels Open Source que vous pouvez utiliser dans Google Cloud

De nombreux services Google Cloud utilisent des logiciels Open Source pour faciliter la transition. Google Cloud propose des solutions gérées et sans serveur qui disposent d'API ouvertes et sont compatibles avec les frameworks Open Source pour réduire la dépendance vis-à-vis d'un fournisseur.

Dataproc est un service géré compatible avec Hadoop qui vous permet d'héberger des logiciels Open Source avec une faible charge opérationnelle. Dataproc est compatible avec Spark, Hive, Pig, Presto et Zookeeper. Il fournit également Hive Metastore en tant que service géré pour se retirer comme point de défaillance unique dans l'écosystème Hadoop.

Vous pouvez migrer vers Dataflow si vous utilisez actuellement Apache Beam comme moteur de traitement par lot et par flux. Dataflow est un service sans serveur entièrement géré qui utilise Apache Beam. Utilisez Dataflow pour écrire des tâches dans Beam, mais laissez Google Cloud gérer l'environnement d'exécution.

Si vous utilisez CDAP comme plate-forme d'intégration de données, vous pouvez migrer vers Cloud Data Fusion pour bénéficier d'une expérience entièrement gérée.

Déterminer vos besoins en termes de traitement des données ETL ou ELT

L'expérience et les préférences de votre équipe permettent de déterminer la conception de votre système pour le traitement des données. Google Cloud vous permet d'utiliser des systèmes de traitement de données ETL traditionnels ou ELT plus modernes.

• Pour les pipelines ETL, vous pouvez utiliser Data Fusion, Dataproc ou Dataflow.

  • Pour les nouveaux environnements, nous recommandons Dataflow pour une méthode unifiée de création d'applications par lot et par flux.
  • Pour une approche entièrement gérée, Data Fusion fournit une interface utilisateur graphique par glisser-déposer pour vous aider à créer des pipelines.

• Pour les pipelines ELT, utilisez BigQuery qui est compatible avec le chargement de données par lot et par flux. Une fois que vos données sont dans BigQuery, utilisez SQL pour effectuer toutes les transformations afin de générer de nouveaux ensembles de données pour vos cas d'utilisation métier.

• Si vous souhaitez moderniser et passer d'ETL à ELT, vous pouvez utiliser Dataform.

Utiliser le framework approprié pour votre cas d'utilisation des données

Vos cas d'utilisation des données déterminent les outils et les frameworks à utiliser. Certains produits Google Cloud sont conçus pour gérer tous les cas d'utilisation de données suivants, tandis que d'autres n'acceptent qu'un seul cas d'utilisation spécifique.

• Pour un système de traitement de données par lot, vous pouvez traiter et transformer des données dans BigQuery via une interface SQL connue. Si un pipeline existant s'exécute sur Apache Hadoop ou Spark sur site ou dans un autre cloud public, vous pouvez utiliser Dataproc.
  • Vous pouvez également utiliser Dataflow si vous souhaitez une interface de programmation unifiée pour les cas d'utilisation par lot et par flux. Nous vous recommandons de moderniser et d'utiliser Dataflow pour l'ETL et BigQuery pour l'ELT.

• Pour les pipelines de données par flux, vous utilisez un service géré et sans serveur tel que Dataflow qui fournit des fonctionnalités de fenêtrage, d'autoscaling et des modèles. Pour en savoir plus, consultez la page Créer des pipelines de données prêts pour la production à l'aide de Dataflow.

  • Si vous disposez d'équipes et de services spécialisés dans l'analyse et SQL, vous pouvez également diffuser des données dans BigQuery.

• Pour les cas d'utilisation en temps réel, comme l'analyse de séries temporelles ou l'analyse de flux vidéo, utilisez Dataflow.

Garder le contrôle sur votre moteur d'exécution

Pour minimiser la dépendance vis-à-vis d'un fournisseur et pouvoir utiliser une autre plate-forme à l'avenir, utilisez le modèle de programmation Apache Beam etDataflow en tant que solution gérée sans serveur. Le modèle de programmation Beam vous permet de changer de moteur d'exécution sous-jacent, en passant par exemple de Dataflow à Apache Flink ou Apache Spark.

Utiliser Dataflow pour ingérer des données provenant de plusieurs sources

Pour ingérer des données issues de plusieurs sources, telles que Pub/Sub, Cloud Storage, HDFS, S3 ou Kafka, utilisez Dataflow. Dataflow est un service géré sans serveur compatible avec les modèles Dataflow, qui permet à vos équipes d'exécuter des modèles à partir de différents outils.

Dataflow Premium fournit un autoscaling horizontal et vertical des machines utilisées dans le processus d'exécution d'un pipeline. Il fournit également des diagnostics et des recommandations intelligents qui identifient les problèmes et suggèrent comment les résoudre.

Détecter, identifier et protéger les données sensibles

Utilisez la protection des données sensibles pour inspecter et transformer les données structurées et non structurées. La protection des données sensibles peut traiter des données situées n'importe où dans Google Cloud, par exemple des données contenues dans Cloud Storage ou dans des bases de données. Vous pouvez classer, masquer et tokeniser vos données sensibles pour continuer à les utiliser en toute sécurité pour un traitement en aval. Utilisez la protection des données sensibles pour effectuer des actions telles que l'analyse des données BigQuery ou l'anonymisation et la restauration des informations personnelles dans les ensembles de données à grande échelle.

Moderniser vos processus de transformation des données

Utilisez Dataform pour écrire les transformations de données sous forme de code et commencer à utiliser le contrôle des versions par défaut. Vous pouvez également adopter les bonnes pratiques de développement logiciel, telles que l'intégration et la livraison continues, les tests unitaires et le contrôle des versions pour le code SQL. Dataform est compatible avec les principaux produits et bases de données d'entrepôts de données cloud, tels que PostgreSQL.

Autres ressources

• Dataproc
  • Guide des bonnes pratiques
  • Conseils pour les clusters de longue durée
  • Utiliser Apache Hive sur Dataproc
  • Bonnes pratiques pour l'exécution en production
  • Bonnes pratiques pour utiliser Apache Ranger
  • Recommandations de configuration de l'autoscaling
  • Aide pour les tâches Hadoop/Spark lentes
• Dataflow
  • Faire avancer des pipelines vers la production
  • Cas d'utilisation courants
• Data Fusion
  • Performances des pipelines
• BigQuery
  • Optimiser les performances des requêtes
• Dataform
  • Bonnes pratiques pour la gestion des projets
• Protection des données sensibles
  • Maîtriser les coûts
  • Inspecter le stockage et les bases de données pour identifier les données sensibles
  • Inspecter le texte pour identifier les données sensibles

Analyses de données et entrepôts

Appliquez les bonnes pratiques suivantes pour l'analyse de données et les entrepôts à votre propre environnement.

Examiner vos besoins en matière de stockage des données

Les lacs de données et les entrepôts de données ne s'excluent pas mutuellement. Les lacs de données sont utiles pour le stockage et le traitement de données non structurées et semi-structurées. Les entrepôts de données sont plus adaptés aux analyses et à l'informatique décisionnelle.

Examinez vos besoins en matière de données pour déterminer où stocker vos données et quel produit Google Cloud est le plus approprié pour les traiter et les analyser. Des produits tels que BigQuery peuvent traiter des pétaoctets de données et évoluer à la demande.

Identifier les possibilités de migration d'un entrepôt de données traditionnel vers BigQuery

Passez en revue les entrepôts de données traditionnels actuellement utilisés dans votre environnement. Pour réduire la complexité et potentiellement réduire les coûts, identifiez les opportunités de migration de vos entrepôts de données traditionnels vers un service Google Cloud tel que BigQuery. Pour obtenir plus d'informations et des exemples de scénarios, consultez la page Migrer des entrepôts de données vers BigQuery.

Planifier l'accès fédéré aux données

Examinez vos exigences en termes de données et découvrez comment interagir avec d'autres produits et services. Identifiez vos besoins en termes de fédération de données et concevez un système de manière appropriée.

Par exemple, BigQuery vous permet de définir des tables externes capables de lire les données d'autres sources, telles que Bigtable, Cloud SQL, Cloud Storage ou Google Drive. Vous pouvez joindre ces sources externes aux tables que vous stockez dans BigQuery.

Utiliser les emplacements Flex BigQuery pour offrir une capacité d'utilisation intensive à la demande

Parfois, vous avez besoin de capacité supplémentaire pour effectuer des analyses expérimentales ou exploratoires nécessitant beaucoup de ressources de calcul. BigQuery vous permet d'obtenir une capacité de calcul supplémentaire sous la forme d'emplacements Flex. Ces emplacements Flex vous aident à faire face à une période de forte demande ou à effectuer une analyse importante.

Comprendre les différences de schéma si vous migrez vers BigQuery

BigQuery accepte les schémas en étoile et en flocon de neige, mais utilise par défaut des champs imbriqués et répétés. Les champs imbriqués et répétés peuvent être plus faciles à lire et à mettre en corrélation que d'autres schémas. Si vos données sont représentées dans un schéma en étoile ou en flocon de neige et que vous souhaitez migrer vers BigQuery, examinez la conception de votre système pour détecter les modifications nécessaires des processus ou des analyses.

Autres ressources

• Bonnes pratiques pour les charges de travail mutualisées sur BigQuery
• Bonnes pratiques concernant la sécurité au niveau des lignes dans BigQuery
• Bonnes pratiques pour les vues matérialisées dans BigQuery

Rapports et visualisation

Appliquez les bonnes pratiques de création de rapports et de visualisation suivantes à votre propre environnement.

Visualiser vos données à l'aide de BigQuery BI Engine

BigQuery BI Engine est un service d'analyse en mémoire rapide. BI Engine peut analyser les données stockées dans BigQuery avec un temps de réponse aux requêtes inférieur à une seconde et une simultanéité élevée. BI Engine est intégré à l'API BigQuery. Utilisez la capacité BI Engine réservée pour gérer la tarification à la demande ou forfaitaire selon vos besoins. BI Engine peut également fonctionner avec d'autres applications de tableau de bord d'informatique décisionnelle ou personnalisées nécessitant des temps de réponse inférieurs à une seconde.

Moderniser vos processus d'informatique décisionnelle avec Looker

Looker est une plate-forme moderne d'entreprise pour l'informatique décisionnelle, les applications de données et les analyses intégrées. Vous pouvez créer des modèles de données cohérents au-dessus de vos données avec rapidité et précision. Vous pouvez accéder aux données dans des datastores transactionnels et analytiques. Looker peut également analyser vos données sur plusieurs bases de données et clouds. Si vous disposez de processus et d'outils d'informatique décisionnelle existants, nous vous recommandons de moderniser et d'utiliser une plate-forme centrale telle que Looker.

Autres ressources

• Migrer des entrepôts de données vers BigQuery : création de rapports et analyse
• Architecture permettant de connecter un logiciel de visualisation à Hadoop sur Google Cloud
• Accélérer les petites requêtes dans BigQuery avec BI Engine

Utiliser des outils de gestion des workflows

L'analyse de données implique de nombreux processus et services. Les données sont déplacées dans différents outils et pipelines de traitement au cours du cycle de vie de l'analyse de données. Pour gérer et maintenir des pipelines de données de bout en bout, utilisez des outils de gestion de workflow appropriés. Cloud Composer est un outil de gestion des workflows entièrement géré basé sur le projet Open Source Apache Airflow.

Vous pouvez utiliser Cloud Composer pour lancer des pipelines Dataflow et utiliser des modèles de workflow Dataproc. Cloud Composer peut également vous aider à créer un pipeline CI/CD pour tester, synchroniser et déployer des DAG ou utiliser un pipeline CI/CD pour les workflows de traitement de données. Pour en savoir plus, consultez la page Bonnes pratiques de développement pour Cloud Composer.

Ressources de migration

Si vous exécutez déjà une plate-forme d'analyse de données et que vous souhaitez migrer une partie ou l'ensemble des charges de travail vers Google Cloud, consultez les ressources de migration suivantes pour connaître les bonnes pratiques et obtenir des conseils :

• Conseils de migration généraux
  • Migration vers Google Cloud : choisir votre chemin de migration
  • Exemple de modernisation de la plate-forme d'analyse de l'engagement publicitaire de Twitter
• Migration vers Cloud Storage
  • Migrer des données HDFS sur site vers Google Cloud
  • Transférer des données d'Amazon S3 vers Cloud Storage à l'aide de VPC Service Controls et du service de transfert de stockage
• Migration vers Pub/Sub
  • Migration de Kafka vers Pub/Sub
• Migration vers Bigtable
  • Migrer des données de HBase vers Bigtable
  • Migrer de Aerospike vers Bigtable
• Migration vers Dataproc
  • Migrer l'infrastructure Hadoop sur site vers Google Cloud
  • Coûts et conseils pour la migration Hadoop
  • Hadoop vers Dataproc
  • Tâches Hadoop sur site vers Dataproc
  • Apache Spark vers Dataproc
  • Metastore Hive externe vers Dataproc Metastore
• Migration vers BigQuery
  • Défis liés à la migration des anciens entrepôts de données
  • Migrer des entrepôts de données vers BigQuery
  • BigQuery pour les professionnels de l'entrepôt de données
• Migration Composer
  • Migrer des environnements vers Airflow 2

Étape suivante

Découvrez les bonnes pratiques de conception de systèmes pour l'IA et le machine learning Google Cloud, y compris :

• Découvrez les services d'IA et de machine learning de Google Cloud compatibles avec la conception de système.
• Découvrez les bonnes pratiques de traitement des données de ML.
• Découvrez les bonnes pratiques de développement et d'entraînement des modèles.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Mettre en œuvre le machine learning

Ce document du framework d'architecture Google Cloud explique certains des principes fondamentaux et des bonnes pratiques pour l'analyse de données dans Google Cloud. Vous découvrirez certains des principaux services d'IA et de machine learning (ML), ainsi que leur rôle dans les différentes étapes du cycle de vie IA et ML. Ces bonnes pratiques vous aident à satisfaire vos besoins en matière d'IA et de ML et à créer votre conception de système. Dans ce document, nous partons du principe que vous maîtrisez les concepts de base de l'IA et du ML.

Pour simplifier le processus de développement et minimiser les frais liés à la création de modèles de ML sur Google Cloud, choisissez le niveau d'abstraction le plus élevé qui convient à votre cas d'utilisation. Le niveau d'abstraction est défini comme la complexité de conception ou de programmation d'un système. Plus le niveau d'abstraction est élevé, moins les détails sont disponibles pour l'utilisateur.

Pour sélectionner les services d'IA et de ML de Google en fonction des besoins de votre entreprise, utilisez le tableau suivant :

Personna	Services Google
Utilisateurs Business	Solutions standards telles que Contact Center AI Insights, Document AI, Discovery AI et API Cloud Healthcare.
Développeurs disposant d'une expérience minimale en ML	Les API pré-entraînées traitent des tâches perceptives courantes telles que la vision, la vidéo et le langage naturel. Ces API sont compatibles avec les modèles pré-entraînés et fournissent des détecteurs par défaut. Ils sont prêts à l'emploi sans aucune expérience en ML ou en développement de modèle. Les API pré-entraînées incluent : API Vision, API Video, API Natural Language, API Speech-to-Text, API Text-to-Speech et API Cloud Translation.
Generative AI pour les développeurs	Vertex AI Search and Conversation permet aux développeurs d'utiliser ses fonctionnalités prêtes à l'emploi pour créer et déployer des chatbots en quelques minutes et des moteurs de recherche en quelques heures. Les développeurs qui souhaitent combiner plusieurs fonctionnalités dans des workflows d'entreprise peuvent utiliser l'API Gen App Builder pour l'intégration directe.
Développeurs et data scientists	AutoML vous permet de développer des modèles personnalisés avec vos propres données d'image, de vidéo, de texte ou tabulaires. AutoML accélère le développement de modèles grâce à une recherche automatique dans tous les modèles Google afin de déterminer l'architecture de modèles la plus performante. Vous n'avez donc pas besoin de créer le modèle. AutoML gère les tâches courantes pour vous, comme le choix d'une architecture de modèle, le réglage des hyperparamètres, le provisionnement des machines pour l'entraînement et la diffusion.
Data scientists et ingénieurs en ML	Les outils de modèles personnalisés Vertex AI vous permettent d'entraîner et de diffuser des modèles personnalisés pour exploiter le workflow du ML. Vous pouvez également exécuter votre charge de travail de ML sur des ressources de calcul autogérées comme les VM Compute Engine.
Data scientists et ingénieurs en machine learning	La prise en charge de Generative AI sur Vertex AI (également appelée genai) permet d'accéder aux grands modèles d'IA générative de Google afin de pouvoir tester, régler et déployer des modèles dans vos applications basées sur l'IA.
Ingénieurs de données, data scientists et analystes de données familiarisés avec les interfaces SQL	BigQuery ML vous permet de développer des modèles basés sur SQL à partir de données stockées dans BigQuery.

Principaux services

Le tableau suivant offre une vue d'ensemble des services d'IA et de ML :

Service Google	Description
Cloud Storage et BigQuery	Fournit des options de stockage flexibles pour les données et les artefacts de machine learning.
BigQuery ML	Vous permet de créer des modèles de machine learning directement à partir de données hébergées dans BigQuery.
Pub/Sub, Dataflow, Cloud Data Fusion et Dataproc	Acceptent l'ingestion et le traitement de données par lot et en temps réel. Pour plus d'informations, consultez la page Analyse de données.
Vertex AI	Offre aux data scientists et aux ingénieurs en machine learning une plate-forme unique pour créer, entraîner, tester, surveiller, régler et déployer des modèles de ML pour toutes les applications, de l'IA générative au MLOps. Les outils comprennent les éléments suivants : Étiquetage de données Vertex, pour obtenir des étiquettes de données précises Conteneurs de deep learning, pour créer et déployer des modèles dans un environnement portable et cohérent. Vertex AI Workbench, pour un environnement JupyterLab géré ou géré par l'utilisateur. Vertex Training, pour un service d'entraînement entièrement géré. Vertex AI TensorBoard pour le suivi des tests. Vertex AI Vizier pour le réglage des hyperparamètres. Vertex Prediction, pour un framework de déploiement unifié compatible avec les modèles personnalisés, BigQuery ML et AutoML. Vertex Explainable AI, pour obtenir des explications sur les prédictions d'un modèle. Tests Vertex pour accélérer le déploiement de modèles en production. Maintenant, avec une sélection de modèles plus rapide. Des outils MLOps tels que Vertex AI Pipelines pour l'orchestration et Vertex AI Feature Store pour un dépôt de caractéristiques entièrement géré.
Vertex AI Search and Conversation	Permet de créer des chatbots et des moteurs de recherche qui utilisent les données d'entreprise pour des sites Web. Conversation AI sur Vertex AI Search and Conversation peut aider à réinventer les interactions client et employé avec des chatbots et des assistants numériques basés sur l'IA générative. Par exemple, avec ces outils, vous pouvez fournir bien plus que de simples informations en activant les transactions depuis l'expérience de chat. La recherche Google dans Vertex AI Search and Conversation permet aux entreprises de créer des expériences de recherche pour les clients et les employés sur leurs sites Web publics ou privés. En plus d'offrir des résultats de recherche multimodaux de haute qualité, Enterprise Search peut résumer les résultats et fournir les citations correspondantes grâce à l'IA générative.
IA générative sur Vertex AI	Vous permet d'accéder aux modèles d'IA générative de Google, afin que vous puissiez les tester, les régler et les déployer pour vos applications basées sur l'IA. Generative AI sur Vertex AI est également appelé genai. Les modèles Generative AI, également appelés modèles de base, sont classés en fonction du type de contenu qu'ils sont conçus pour générer. Ce contenu inclut les textes et le chat, les images, le code et les représentations vectorielles continues de texte. Vertex AI Studio vous permet de créer rapidement des prototypes et de tester des modèles d'IA générative dans la console Google Cloud. Vous pouvez tester des exemples d'invites, concevoir vos propres invites et personnaliser les modèles de base pour gérer les tâches qui répondent aux besoins de votre application. Réglage du modèle : permet de personnaliser des modèles de base pour des cas d'utilisation spécifiques en les ajustant à l'aide d'un ensemble de données contenant des exemples d'entrées/sorties. Le jardin de modèles fournit des modèles de base adaptés aux entreprises, des modèles spécifiques à des tâches, et des API.
API pré-entraînées	Les API pré-entraînées incluent l'API Vision, l'API vidéo, l'API Natural Language, l'API Speech-to-Text et API Text-to-Speech et l'API Cloud Translation.
AutoML	Fournit des outils de modélisation personnalisés pour créer, déployer et faire évoluer des modèles de ML. Les développeurs peuvent importer leurs propres données et utiliser le service AutoML applicable pour créer un modèle personnalisé. AutoML Image : effectue la classification d'images et la détection d'objets sur les données d'image. AutoML Video : effectue la détection d'objets, la classification et la reconnaissance d'actions sur des données vidéo. AutoML Text : effectue la classification du langage, l'extraction d'entités et l'analyse des sentiments sur des données textuelles. AutoML Translation : détecte et traduit entre des combinaisons linguistiques. AutoML Tabular : permet de créer un modèle de régression, de classification ou de prévision. Destiné aux données structurées.
AI Infrastructure	Vous permet d'utiliser des accélérateurs d'IA pour traiter des charges de travail de ML à grande échelle. Ces accélérateurs vous permettent d'entraîner et d'obtenir des inférences à partir de modèles de deep learning et de modèles de machine learning de manière rentable. Les GPU peuvent aider à réaliser des inférences à moindre coût et à effectuer un entraînement à la hausse ou à la baisse pour des modèles de deep learning. Les TPU (Tensor Processing Units) sont des ASIC conçus sur mesure pour entraîner et exécuter des réseaux de neurones profonds.
Dialogflow	Offre des agents virtuels pour une expérience de conversation.
Contact Center AI	Offre une expérience automatisée et riche d'informations pour les centres d'appels grâce à la fonctionnalité Agent Assist pour les agents humains.
Document AI	Permet de comprendre des documents à grande échelle de manière générale, mais aussi des types de documents spécifiques comme les documents de prêt et les documents liés aux achats.
Lending DocAI	Automatise le traitement des documents hypothécaires. Réduction du temps de traitement et rationalisation de la capture des données tout en respectant les exigences réglementaires et de conformité.
Procurement DocAI	Automatisez la capture de données d'approvisionnement à l'échelle requise en convertissant des documents non structurés comme des factures et des reçus en données structurées afin d'améliorer l'efficacité opérationnelle, d'améliorer l'expérience client et d'appuyer la prise de décisions.
Recommandations	Offre des recommandations de produits personnalisées.
IA Healthcare Natural Language	Permet d'examiner et d'analyser les documents médicaux.
API Media Translation	Permet la traduction vocale en temps réel à partir de données audio.

Traitement des données

Appliquez les bonnes pratiques de traitement des données qui suivent dans votre propre environnement.

S'assurer que vos données répondent aux exigences du ML

Les données que vous utilisez pour le ML doivent répondre à certaines exigences de base, quel que soit le type de données. Ces exigences incluent la capacité des données à prédire la cible, la cohérence entre les données utilisées pour l'entraînement et les données utilisées pour la prédiction, et la précision des données étiquetées pour l'entraînement. Le volume de vos données doit également être suffisant. Pour en savoir plus, consultez la section Traitement des données.

Stocker les données tabulaires dans BigQuery

Si vous utilisez des données tabulaires, envisagez de les stocker dans BigQuery et de lire les données à l'aide de l'API BigQuery Storage. Pour simplifier l'interaction avec l'API, utilisez l'une des options d'outils supplémentaires suivantes, en fonction de l'emplacement où vous souhaitez lire les données :

• Si vous utilisez Dataflow, utilisez le connecteur d'E/S BigQuery.
• Si vous utilisez TensorFlow ou Keras, utilisez le lecteur tf.data.dataset pour BigQuery.
• Si vous utilisez des données non structurées, telles que des images ou des vidéos, envisagez de les stocker dans Cloud Storage.

Le type de données d'entrée détermine également les outils de développement de modèle disponibles. Les API pré-entraînées, AutoML et BigQuery ML peuvent fournir des environnements de développement plus rentables et efficaces pour certains cas d'utilisation de données structurées, d'image, de vidéo et de texte.

Vérifier que vous disposez de suffisamment de données pour développer un modèle de ML

Pour développer un modèle de ML utile, vous devez disposer d'un volume suffisant de données. Pour prédire une catégorie, le nombre d'exemples recommandé pour chaque catégorie est de 10 fois le nombre de caractéristiques. Plus vous souhaitez prédire de catégories, plus vous avez besoin de données. Les ensembles de données déséquilibrés nécessitent encore plus de données. Si vous ne disposez pas de suffisamment de données étiquetées, envisagez d'utiliser l'apprentissage partiellement supervisé.

La taille des ensembles de données a également des répercussions sur l'entraînement et la diffusion. Un petit ensemble de données peut être entraîné directement dans une instance Notebooks alors qu'un ensemble de données plus volumineux nécessitant une entraînement distribué nécessitera d'utiliser le service d'entraînement personnalisé Vertex AI. Si vous souhaitez que Google entraîne le modèle pour vos données, utilisez AutoML.

Préparer les données à utiliser

Une bonne préparation des données peut accélérer le développement des modèles. Lorsque vous configurez votre pipeline de données, assurez-vous qu'il peut traiter à la fois les données par lot et par flux afin d'obtenir des résultats cohérents à partir des deux types de données.

Développement et entraînement de modèles

Appliquez les bonnes pratiques de développement et d'entraînement de modèle qui suivent dans votre propre environnement.

Choisir entre le développement géré ou personnalisé du modèle

Lorsque vous créez votre modèle, tenez compte du niveau d'abstraction le plus élevé possible. Utilisez AutoML lorsque cela est possible pour que les tâches de développement et d'entraînement soient gérées à votre place. Pour les modèles personnalisés, choisissez des options gérées pour l'évolutivité et la flexibilité plutôt que des options autogérées. Pour en savoir plus sur les options de développement de modèles, consultez la page Utiliser les outils et produits recommandés.

Envisagez d'utiliser le service d'entraînement Vertex AI plutôt que l'entraînement autogéré sur les VM Compute Engine ou sur les conteneurs de VM Deep Learning. Pour un environnement JupyterLab, envisagez d'utiliser Vertex AI Workbench, qui fournit des environnements JupyterLab gérés et gérés par l'utilisateur. Pour en savoir plus, consultez les pages Développement du machine learning et Entraînement opérationnel.

Utiliser des conteneurs prédéfinis ou personnalisés pour les modèles personnalisés

Pour les modèles personnalisés sur Vertex AI, vous pouvez utiliser des conteneurs prédéfinis ou personnalisés selon le framework de machine learning et la version du framework. Des conteneurs prédéfinis sont disponibles pour les applications d'entraînement Python créées pour des versions spécifiques de TensorFlow, scikit-learn, PyTorch et XGBoost.

Sinon, vous pouvez choisir de créer un conteneur personnalisé pour votre tâche d'entraînement. Par exemple, utilisez un conteneur personnalisé si vous souhaitez entraîner votre modèle à l'aide d'un framework de ML Python qui n'est pas disponible dans un conteneur prédéfini, ou si vous souhaitez effectuer l'entraînement dans un langage de programmation autre que Python. Dans le conteneur personnalisé, préinstallez votre application d'entraînement et toutes ses dépendances sur une image qui exécute la tâche d'entraînement.

Prendre en compte les exigences de l'entraînement distribué

Tenez compte de vos exigences en matière d'entraînement distribué. Certains frameworks de ML, tels que TensorFlow et PyTorch, vous permettent d'exécuter un code d'entraînement identique sur plusieurs machines. Ces frameworks coordonnent automatiquement la répartition des tâches en fonction des variables d'environnement définies sur chaque machine. D'autres frameworks peuvent nécessiter une personnalisation supplémentaire.

Étape suivante

Pour en savoir plus sur l'IA et le machine learning, consultez les ressources suivantes :

• Bonnes pratiques de mise en œuvre du machine learning sur Google Cloud.
• Guide opérationnel de MLOps : un cadre pour la livraison continue et l'automatisation du machine learning.

Découvrez d'autres catégories du framework d'architecture telles que la fiabilité, l'excellence opérationnelle, la sécurité, la confidentialité et la conformité.

Concevoir des solutions durables pour l'environnement

Ce document du framework d'architecture de Google Cloud explique comment vous pouvez aborder le développement durable pour vos charges de travail dans Google Cloud. Il explique comment réduire votre empreinte carbone sur Google Cloud.

Comprendre votre empreinte carbone

Pour comprendre l'empreinte carbone de votre utilisation de Google Cloud, utilisez le tableau de bord empreinte carbone. Le tableau de bord Carbon Footprint attribue les émissions aux projets Google Cloud que vous possédez et aux services cloud que vous utilisez.

Pour plus d'informations, consultez la section Comprendre votre empreinte carbone de la page "Réduire votre empreinte carbone de Google Cloud".

Choisir les régions cloud les plus adaptées

Une manière simple et efficace de réduire les émissions de carbone consiste à choisir des régions cloud qui présentent des émissions de carbone plus faibles. Pour vous aider à faire ce choix, Google publie des données sur les émissions de carbone pour toutes les régions Google Cloud.

Lorsque vous choisissez une région, vous devrez peut-être trouver un équilibre entre les émissions réduites et d'autres exigences, telles que la tarification et la latence du réseau. Pour vous aider à sélectionner une région, utilisez l'outil de sélection de régions Google Cloud.

Pour en savoir plus, consultez l'article Choisir les régions cloud les plus adaptées de la page "Réduire votre empreinte carbone de Google Cloud".

Choisir les services cloud les plus adaptés

Pour réduire votre empreinte carbone, envisagez de migrer vos charges de travail de VM sur site vers Compute Engine.

Notez également que de nombreuses charges de travail ne nécessitent pas de VM. Il est souvent possible d'utiliser une offre sans serveur. Ces services gérés peuvent optimiser l'utilisation des ressources cloud, souvent automatiquement, ce qui réduit simultanément les coûts liés au cloud et l'empreinte carbone.

Pour en savoir plus, consultez l'article Choisir les services cloud les plus adaptés de la page "Réduire votre empreinte carbone de Google Cloud".

Minimiser les ressources cloud inactives

Les ressources inactives entraînent des coûts et des émissions inutiles. Voici quelques causes courantes d'inactivité des ressources :

• Des ressources cloud actives et non utilisées, telles que des instances de VM inactives.
• Des ressources surprovisionnées, telles que des types de machines d'instances de VM plus grands que nécessaire pour une charge de travail.
• Les architectures non optimales, telles que les migrations Lift and Shift qui ne sont pas toujours optimisées pour l'efficacité. Pensez à apporter des améliorations incrémentielles à ces architectures.

Voici quelques stratégies générales permettant de réduire les gaspillages de ressources cloud :

• Identifiez les ressources inactives ou surprovisionnées, et supprimez-les ou redimensionnez-les.
• Refactorisez votre architecture pour intégrer une conception plus optimale.
• Migrez des charges de travail vers des services gérés.

Pour en savoir plus, consultez la section Réduire les ressources cloud inactives de la page "Réduire votre empreinte carbone de Google Cloud".

Réduire les émissions pour les charges de travail par lot

Exécutez des charges de travail par lot dans des régions présentant des émissions de carbone inférieures. Pour réduire davantage votre empreinte carbone, exécutez les charges de travail à des moments qui coinncident avec une intensité en carbone plus faible sur le réseau électrique, si possible.

Pour en savoir plus, consultez la section Réduire les émissions pour les charges de travail par lot de la page "Réduire votre empreinte carbone de Google Cloud".

Étape suivante

• Découvrez comment utiliser les données d'empreinte carbone pour mesurer, signaler et réduire vos émissions de carbone dans le cloud.
• Découvrez comment réduire votre empreinte carbone de Google Cloud.

Framework d'architecture Google Cloud : excellence opérationnelle

Cette catégorie du framework d'architecture de Google Cloud vous montre comment utiliser efficacement les services sur Google Cloud. Elle explique comment exécuter, gérer et surveiller les systèmes offrant une valeur commerciale. Elle aborde également les produits et fonctionnalités Google Cloud favorisant l'excellence opérationnelle. L'utilisation des principes d'excellence opérationnelle vous permet de poser les bases de la fiabilité. Pour ce faire, il configure les éléments de base tels que l'observabilité, l'automatisation et l'évolutivité.

Ce framework d'architecture décrit les bonnes pratiques, fournit des recommandations de mise en œuvre et détaille certains produits et services disponibles pour vous aider à atteindre l'excellence opérationnelle. Son but est de vous aider à concevoir votre déploiement Google Cloud pour répondre aux besoins de votre entreprise.

Dans la catégorie d'excellence opérationnelle du framework d'architecture, vous apprendrez à effectuer les opérations suivantes :

• Automatisez vos déploiements
• Configurer la surveillance, les alertes et la journalisation
• Établir des processus d'assistance et d'escalade des demandes d'assistance cloud
• Gérer la capacité et les quotas
• Planifier les pics de trafic et les événements de lancement
• Créer une culture de l'automatisation

Automatisez vos déploiements

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques pour automatiser vos compilations, vos tests et vos déploiements.

L'automatisation vous aide à standardiser les compilations, les tests et les déploiements en éliminant les erreurs causées par l'humain pour des processus répétés tels que les mises à jour de code. Cette section explique comment utiliser divers contrôles et garde-fous à des fins d'automatisation. Un processus standardisé contrôlé par la machine permet de garantir l'application sécurisée des déploiements. Il fournit également un mécanisme permettant de restaurer les déploiements précédents sans que cela n'affecte considérablement l'expérience utilisateur.

Stocker votre code dans les dépôts de code central

Stockez votre code dans des dépôts de code centralisés, qui comprennent un système de contrôle des versions avec tags et offrent la possibilité d'annuler les modifications de code. Le contrôle des versions vous permet d'organiser les fichiers et de contrôler l'accès, les mises à jour et la suppression entre les différentes équipes et organisations.

Pour les différentes étapes de développement, versionnez et ajoutez des libellés aux dépôts si nécessaire. Par exemple, les libellés peuvent être test, dev et prod.

Dans Google Cloud, vous pouvez stocker votre code dans Cloud Source Repositories, le versionner et en gérer l'intégration à d'autres produits Google Cloud. Si vous créez des applications conteneurisées, utilisez Artifact Registry, un registre géré pour les conteneurs.

Pour plus d'informations sur le contrôle des versions, consultez la page Contrôle des versions. Pour en savoir plus sur la mise en œuvre du développement à branche unique avec vos dépôts, consultez la page Développement à branche unique.

Utiliser l'intégration et le déploiement continus (CI/CD)

Automatisez vos déploiements à l'aide d'une approche d'intégration et de déploiement continus (CI/CD). Une approche CI/CD est une combinaison de pipelines que vous configurez et de processus que votre équipe de développement doit suivre.

Une approche CI/CD augmente la vitesse de déploiement en améliorant la productivité de votre équipe de développement logiciel. Cette approche permet aux développeurs d'apporter des modifications plus petites et plus fréquentes, qui sont testées minutieusement tout en réduisant le temps nécessaire à leur déploiement.

Dans le cadre de votre approche CI/CD, automatisez toutes les étapes de création, de test et de déploiement de votre code. Exemple :

• Chaque fois que du nouveau code est validé (commit) dans le dépôt, appelez automatiquement le pipeline de compilation et de test.
• Automatisez les tests d'intégration.
• Automatisez votre déploiement afin que les modifications soient effectives une fois que votre compilation satisfait des critères de test spécifiques.

Dans Google Cloud, vous pouvez utiliser Cloud Build et Cloud Deploy pour vos pipelines CI/CD.

Utilisez Cloud Build pour définir les dépendances et les versions que vous pouvez utiliser pour le packaging et la création d'un package d'application. Mettez à jour votre configuration de build pour vous assurer que tous vos builds sont cohérents et que vous pouvez effectuer un rollback vers une configuration précédente si nécessaire.

Utilisez Cloud Deploy (bêta) pour déployer vos applications dans des environnements spécifiques sur Google Cloud et gérer vos pipelines de déploiement.

Pour en savoir plus sur la mise en œuvre de la CI/CD, consultez les pages Intégration continue et Automatisation des déploiements.

Provisionner et gérer votre infrastructure à l'aide de l'infrastructure en tant que code

L'infrastructure en tant que code consiste à utiliser un modèle descriptif pour gérer l'infrastructure, telle que les VM, et les configurations, telles que les règles de pare-feu. L'infrastructure en tant que code vous permet d'effectuer les opérations suivantes :

• Créez automatiquement vos ressources cloud, y compris les environnements de déploiement ou de test pour votre pipeline CI/CD.
• Traitez les modifications d'infrastructure de la même manière que les modifications d'application. Par exemple, assurez-vous que les modifications apportées à la configuration sont examinées, testées et qu'elles peuvent être auditées.
• Ayez une version unique de votre infrastructure cloud.
• Répliquez votre environnement cloud selon vos besoins.
• Si nécessaire, effectuez un rollback vers une configuration précédente.

Ce concept d'Infrastructure as Code s'applique également aux projets dans Google Cloud. Vous pouvez utiliser cette approche pour définir des ressources telles que la connectivité de VPC partagé ou l'accès IAM (Identity and Access Management) dans vos projets. Pour obtenir un exemple de cette approche, consultez le module Terraform de la fabrique de projets Google Cloud.

Des outils tiers, tels que Terraform, vous aident à créer automatiquement votre infrastructure sur Google Cloud. Pour en savoir plus, consultez la page Gérer une infrastructure en tant que code avec Terraform, Cloud Build et GitOps.

Songez à utiliser les fonctionnalités Google Cloud, par exemple :privilèges du projet,règles de conservation Cloud Storage et verrous de bucket Cloud Storage pour protéger les ressources critiques contre toute suppression accidentelle ou malveillante.

Intégrer des tests tout au long du cycle de livraison des logiciels

Les tests sont essentiels au lancement réussi de votre logiciel. Les tests continus aident les équipes à créer plus rapidement des logiciels de haute qualité et à en améliorer la stabilité.

Types de test :

• Tests unitaires. Les tests unitaires sont rapides et vous permettent d'effectuer des déploiements rapides. Traiter les tests unitaires dans le cadre de la codebase et les inclure dans le processus de compilation.
• Tests d'intégration. Les tests d'intégration sont importants, en particulier pour les charges de travail conçues pour évoluer et dépendre de plusieurs services. Ces tests peuvent devenir complexes lorsque vous testez l'intégration avec des services interconnectés.
• Tests système. Les tests du système sont longs et complexes. Toutefois, ils vous aident à identifier les cas spéciaux et à résoudre les problèmes avant le déploiement.
• Autres tests. Vous devez exécuter d'autres tests, y compris des tests statiques, des tests de charge, des tests de sécurité, des tests de validation des règles, etc… Exécutez ces tests avant de déployer votre application en production.

Pour intégrer les tests, procédez comme suit :

• Effectuer tous les types de tests continus tout au long du cycle de livraison des logiciels.
• Automatisez ces tests et incluez-les dans le pipeline CI/CD. Vous devez faire échouer votre pipeline en cas d'échec de l'un des tests.
• Mettez à jour les tests et ajoutez-en de nouveaux en continu pour améliorer et maintenir l'état opérationnel de votre déploiement.

Pour vos environnements de test :

• Utilisez des projets Google Cloud distincts pour chaque environnement de test. Pour chaque application, utilisez un environnement de projet distinct. Cette séparation permet une distinction claire entre les ressources de l'environnement de production et les ressources de vos environnements inférieurs. Cette séparation permet de garantir que les modifications d'un environnement n'affectent pas accidentellement les autres environnements.
• Automatisez la création d'environnements de test. Une manière d'effectuer cette automatisation consiste à utiliser l'infrastructure en tant que code.
• Utilisez un environnement de production synthétique pour tester les modifications. Cet environnement fournit un environnement similaire à l'environnement de production pour tester votre application et effectuer différents types de tests sur vos charges de travail, y compris des tests de bout en bout et des tests de performances.

Pour en savoir plus sur la mise en œuvre des tests continus, consultez la page Automatiser les tests.

Lancer progressivement les déploiements

Choisissez votre stratégie de déploiement en fonction de paramètres importants, tels que la perturbation minimale des utilisateurs finaux, les mises à jour progressives, les stratégies de rollback et les stratégies de test A/B. Pour chaque charge de travail, évaluez ces exigences et choisissez une stratégie de déploiement utilisant des techniques éprouvées, telles que les mises à jour progressives, les déploiements bleu-vert et les déploiements Canary.

Ne laissez les processus CI/CD effectuer et appliquer des modifications que dans votre environnement de production.

Envisagez d'utiliser une infrastructure immuable. Une infrastructure immuable est une infrastructure qui n'est ni modifiée, ni mise à jour. Lorsque vous devez déployer un nouveau code ou modifier toute autre configuration dans votre environnement, vous devez remplacer l'intégralité de l'environnement (un ensemble de VM ou de pods, par exemple) par le nouvel environnement. Les déploiements bleu-vert sont un exemple d'infrastructure immuable.

Nous vous recommandons d'effectuer des tests en version Canary afin de détecter d'éventuelles erreurs dans votre système lorsque vous déployez des modifications. Ce type d'observation est plus facile si vous disposez d'un système de surveillance et d'alerte robuste. Pour effectuer des tests A/B ou des tests en version Canary, vous pouvez utiliser les groupes d'instances gérés de Google Cloud. Vous pouvez ensuite effectuer un déploiement lent ou une restauration si nécessaire.

Envisagez d'automatiser les déploiements et de gérer votre pipeline de déploiement à l'aide de Cloud Deploy. Vous pouvez également utiliser de nombreux outils tiers, tels que Spinnaker et Tekton, sur Google Cloud pour les déploiements automatisés et pour créer des pipelines de déploiement.

Restaurer facilement les versions précédentes

Définissez votre stratégie de restauration dans le cadre de votre stratégie de déploiement. Assurez-vous de pouvoir effectuer un rollback d'un déploiement ou d'une configuration d'infrastructure vers une version précédente du code source. La restauration d'un déploiement stable précédent est une étape importante de la gestion des incidents, à la fois pour la fiabilité et la sécurité.

Veillez également à restaurer l'environnement dans l'état dans lequel il se trouvait avant le début du processus de déploiement. Cela peut inclure :

• Possibilité d'annuler toutes les modifications de code dans votre application.
• Possibilité d'annuler les modifications de configuration apportées à l'environnement.
• L'utilisation d'une infrastructure immuable pour s'assurer que les déploiements ne modifient pas l'environnement Ces pratiques facilitent l'annulation des modifications de configuration.

Surveiller vos pipelines CI/CD

Pour garantir le bon fonctionnement de votre processus automatisé de compilation, de test et de déploiement, surveillez vos pipelines CI/CD. Définissez des alertes qui indiquent quand un pipeline échoue. Chaque étape de votre pipeline doit écrire des entrées de journalisation appropriées afin que votre équipe puisse effectuer une analyse des causes fondamentales en cas d'échec d'un pipeline.

Dans Google Cloud, tous les services CI/CD sont intégrés à Google Cloud Observability. Exemple :

• Cloud Source Repositories est intégré au service Pub/Sub.
• Cloud Build est intégré à Pub/Sub et stocke également les journaux d'audit et les journaux de build. Vous pouvez définir des alertes pour certains mots clés dans vos journaux de build et pour de nombreuses autres métriques à l'aide du service Cloud Monitoring.
• Cloud Deploy stocke les journaux d'audit.

Pour en savoir plus sur la surveillance et la journalisation, consultez la page Configurer la surveillance, les alertes et la journalisation.

Déployer des applications en toute sécurité

Consultez la section Déployer des applications en toute sécurité dans la catégorie "Sécurité, conformité et confidentialité" du framework d'architecture.

Établir des consignes de gestion pour les versions

Pour aider vos ingénieurs à éviter les erreurs et pour assurer des livraisons de logiciels rapides, assurez-vous que vos consignes de gestion pour la publication de nouvelles versions logicielles sont clairement documentées.

Les ingénieurs de versions supervisent la compilation et la livraison des logiciels. Le système d'ingénierie des versions est guidé par quatre pratiques :

• Mode libre-service. Permet de définir des consignes pour aider les ingénieurs logiciels à éviter les erreurs courantes. Ces consignes sont généralement codifiées dans des processus automatisés.

• Versions fréquentes. Une rapidité améliorée facilite le dépannage et la résolution des problèmes. Les versions fréquentes reposent sur des tests unitaires automatisés.

• Builds hermétiques. Permettent d'assurer la cohérence avec vos outils de compilation. Mettez à jour les compilateurs de build qui vous permettent de créer des builds aujourd'hui par rapport à ceux que vous utilisiez il y a un mois.

• Application des règles. Toutes les modifications nécessitent une vérification du code, idéalement sous la forme d'un ensemble de consignes et de règles destinées à la sécurité. L'application des règles améliore la vérification du code, le dépannage et les tests de nouvelle version.

Étape suivante

• Configurez la surveillance, les alertes et la journalisation (document suivant de cette série)
• Déployez des applications en toute sécurité depuis la catégorie "Sécurité, conformité et confidentialité" du framework d'architecture.
• Passez en revue les bonnes pratiques pour la création de conteneurs.
• Découvrez les capacités techniques.
• Explorez d'autres catégories du framework d'architecture, telles que la conception système, la sécurité, la confidentialité, la conformité, la fiabilité, l'optimisation des coûts et l'optimisation des performances.

Configurer la surveillance, les alertes et la journalisation

Ce document du framework d'architecture Google Cloud vous explique comment configurer la surveillance, les alertes et la journalisation afin de pouvoir réagir au comportement de votre système. Cela inclut l'identification de métriques significatives à suivre et la création de tableaux de bord, pour faciliter la visualisation des informations relatives à vos systèmes.

Le programme de recherche de DevOps Resource and Assessment (DORA) définit la surveillance comme suit :

La surveillance consiste à collecter, analyser et utiliser des informations pour suivre les applications et l'infrastructure afin d'orienter les décisions commerciales. Fonction essentielle, la surveillance vous donne un aperçu de vos systèmes et de vos tâches.

Avec la surveillance, les propriétaires de services peuvent :

• Prendre des décisions avisées lorsque des modifications apportées au service affectent les performances
• Appliquer une approche scientifique à la gestion des incidents
• Mesurer l'alignement de votre service sur les objectifs commerciaux

Une fois la surveillance, la journalisation et les alertes en place, vous pouvez effectuer les opérations suivantes :

• Analyser les tendances à long terme
• Comparer vos tests au fil du temps
• Définir des alertes sur les métriques essentielles
• Créer des tableaux de bord en temps réel pertinents
• Effectuer des analyses rétrospectives
• Surveiller les métriques propres à l'entreprise et les métriques d'état du système
  • Les métriques propres à l'entreprise vous aident à comprendre dans quelle mesure vos systèmes répondent aux besoins de votre activité. Par exemple, utilisez les métriques pour surveiller les éléments suivants :
    • Le coût d'une application pour servir un utilisateur
    • La variation du volume de trafic sur le site après une refonte
    • Le temps nécessaire à un client pour acheter un produit sur votre site
  • Les métriques d'état du système vous aident à déterminer si vos systèmes fonctionnent correctement et à des niveaux de performances acceptables.

Suivez les quatre signaux clés suivants pour surveiller votre système :

• Latence. Le temps nécessaire au traitement d'une requête.
• Trafic. La quantité de demandes sur votre système.
• Erreurs. Le taux de requêtes ayant échoué. L'échec peut être explicite (par exemple, HTTP 500s), implicite (par exemple, une réponse HTTP 200 associée au mauvais contenu) ou lié à une règle (par exemple, si vous vous engagez sur des temps de réponse d'une seconde, toute requête supérieure à une seconde est une erreur).
• Saturation. Le niveau d'occupation de votre service. La saturation est une mesure de la fraction système qui met l'accent sur les ressources les plus limitées (c'est-à-dire, dans un système à mémoire limitée, qui affiche la mémoire ; dans un système avec des E/S limitées, qui affiche les E/S).

Créer un plan de surveillance

Créez un plan de surveillance conforme à la mission de votre organisation et à sa stratégie d'exploitation. Incluez une planification de surveillance et d'observabilité dans le processus de développement des applications. L'inclusion d'un plan de surveillance dès le début du développement des applications peut permettre à une organisation d'atteindre l'excellence opérationnelle.

Incluez les informations suivantes dans votre plan de surveillance :

• Incluez tous vos systèmes, y compris les ressources sur site et les ressources cloud.
• Incluez la surveillance de vos coûts liés au cloud pour vous assurer que les événements de scaling n'entraînent pas le dépassement de vos seuils budgétaires.
• Établissez différentes stratégies de surveillance pour mesurer les performances de l'infrastructure, l'expérience utilisateur et les indicateurs clés de performance (KPI) commerciaux. Par exemple, les seuils statiques peuvent fonctionner correctement pour mesurer les performances de l'infrastructure, mais ils ne reflètent pas vraiment l'expérience utilisateur.

Mettez à jour le plan au fur et à mesure de l'évolution de vos stratégies de surveillance. Itérez à plusieurs reprises sur ce plan pour améliorer l'état des systèmes.

Définir des métriques qui mesurent tous les aspects de votre organisation

Définissez les métriques nécessaires pour mesurer le comportement de votre déploiement. Pour ce faire :

• Définissez vos objectifs commerciaux.
• Identifiez les métriques et les KPI qui peuvent vous fournir des informations quantifiables pour mesurer les performances. Assurez-vous que vos définitions de métriques prennent bien en compte tous les aspects de votre organisation, des besoins métier (y compris les coûts liés au cloud) aux composants techniques.
• Utilisez ces métriques pour créer des indicateurs de niveau de service (SLI pour "Service Level Indicator") pour vos applications. Pour en savoir plus, consultez la section Choisir les SLI appropriés.

Métriques courantes pour divers composants

Les métriques sont générées à tous les niveaux de votre service, de l'infrastructure et la mise en réseau à la logique métier. Exemple :

• Métriques de l'infrastructure :
  • Statistiques sur les machines virtuelles, y compris les instances, le processeur, la mémoire, l'utilisation et les décomptes.
  • Statistiques basées sur les conteneurs, y compris l'utilisation et la capacité des clusters, l'utilisation au niveau du pod et les décomptes.
  • Statistiques réseau, y compris les entrées/sorties, la bande passante entre les composants, la latence et le débit.
  • Requêtes par seconde, telles qu'évaluées par l'équilibreur de charge
  • Nombre total de blocs de disques lus, par disque
  • Paquets envoyés via une interface réseau donnée
  • Taille du tas de mémoire pour un processus donné
  • Distribution des latences de réponse
  • Nombre de requêtes non valides rejetées par une instance de base de données
• Métriques des applications :
  • Comportement propre aux applications, y compris les requêtes par seconde, les écritures par seconde et les messages envoyés par seconde.
• Métriques de statistiques de services gérés :
  • RPS, débit, latence et utilisation des services gérés par Google (API ou produits tels que BigQuery, App Engine et Bigtable)
• Métriques de statistiques de connectivité réseau :
  • Statistiques relatives aux VPN/interconnexions concernant la connexion à des systèmes sur site ou à des systèmes externes à Google Cloud.
• SLI
  • Métriques associées à l'état général du système.

Configurer la surveillance

Configurez la surveillance pour surveiller les ressources sur site et les ressources cloud.

Choisissez une solution de surveillance qui :

• est indépendant de la plate-forme ;
• fournit des fonctionnalités uniformes pour la surveillance des environnements sur site, hybrides et multicloud.

L'utilisation d'une plate-forme unique pour consolider les données de surveillance provenant de différentes sources vous permet de créer des métriques uniformes et des tableaux de bord de visualisation.

Lorsque vous configurez la surveillance, automatisez les tâches autant que possible.

Surveillance avec Google Cloud

L'utilisation d'un service de surveillance comme Cloud Monitoring est plus facile que de créer un service de surveillance vous-même. Surveiller une application complexe est déjà un projet d'ingénierie conséquent en soi. Même si vous disposez d'une infrastructure pour l'instrumentation, la collecte et l'affichage de données ou encore les alertes, créer et gérer cette infrastructure est une tâche à temps plein.

Pensez à utiliser Cloud Monitoring pour obtenir une visibilité sur les performances, la disponibilité et l'état de vos applications, qu'elles soient hébergées dans votre infrastructure sur site ou dans le cloud.

Cloud Monitoring est un service géré qui fait partie de Google Cloud Observability. Vous pouvez utiliser Cloud Monitoring pour surveiller les services Google Cloud et les métriques personnalisées. Cloud Monitoring fournit une API pour l'intégration à des outils de surveillance tiers.

Cloud Monitoring regroupe les métriques, les journaux et les événements de l'infrastructure cloud de votre système. Ces données fournissent aux développeurs et aux opérateurs un riche ensemble de signaux observables qui peuvent accélérer l'analyse des causes fondamentales des problèmes et réduire les délais moyens de résolution. Vous pouvez utiliser Cloud Monitoring pour définir des alertes et des métriques personnalisées qui répondent à vos objectifs d'entreprise et vous permettent d'agréger, de visualiser et de surveiller l'état du système.

Cloud Monitoring fournit des tableaux de bord configurés par défaut pour vos services applicatifs Open Source et cloud. Le modèle de métriques vous permet de définir des tableaux de bord personnalisés grâce à des outils de visualisation performants et de configurer des graphiques dans l'explorateur de métriques.

Configurer les alertes

Un bon système d'alerte améliore votre capacité à publier des fonctionnalités. Il permet de comparer les performances au fil du temps pour déterminer la vitesse de publication des fonctionnalités ou la nécessité d'effectuer un rollback de version. Pour en savoir plus sur les rollbacks, consultez la section Restaurer facilement des versions précédentes.

Lorsque vous configurez des alertes, mappez les alertes directement avec vos métriques critiques. Ces métriques critiques incluent les suivantes :

• Les quatre signaux clés :
  • Latence
  • Trafic
  • Erreurs
  • Saturation
• État du système
• Utilisation du service
• Événements relatifs à la sécurité
• Expérience utilisateur

Rendez les alertes exploitables afin de réduire le délai de résolution. Pour ce faire, procédez comme suit pour chaque alerte :

• Incluez une description claire, en indiquant le composant surveillé et son impact sur l'entreprise.
• Fournissez toutes les informations nécessaires pour agir immédiatement. Si la compréhension des alertes nécessite d'effectuer plusieurs clics et de consulter plusieurs pages, il est difficile pour la personne d'astreinte d'agir rapidement.
• Définissez des niveaux de priorité pour différentes alertes.
• Identifiez clairement la personne ou l'équipe responsable de la réponse aux alertes.

Pour les applications et les services critiques, intégrez des actions d'autoréparation dans les alertes déclenchées en raison de conditions d'erreur courantes telles que les échecs de fonctionnement du service, les modifications de configuration ou les pics de débit.

Lorsque vous configurez des alertes, essayez d'éliminer les tâches laborieuses. Par exemple, éliminez les erreurs fréquentes ou automatisez la correction de ces erreurs afin d'éviter le déclenchement d'une alerte. L'élimination des tâches laborieuses permet aux personnes d'astreinte de se concentrer sur la fiabilisation des composants opérationnels de votre application. Pour en savoir plus, consultez la section Créer une culture de l'automatisation.

Créer des tableaux de bord de surveillance et d'alerte

Une fois la surveillance activée, créez des tableaux de bord complexes et pertinents contenant les informations de vos systèmes de surveillance et d'alerte.

Choisir un moyen approprié de visualiser votre tableau de bord peut être difficile à lier à vos objectifs de fiabilité. Créez des tableaux de bord pour visualiser les deux éléments suivants :

• Analyse à court terme et en temps réel
• Analyse à long terme

Pour en savoir plus sur la mise en œuvre de la gestion visuelle, consultez l'article sur la fonctionnalité Gestion visuelle.

Activer la journalisation pour les applications critiques

Les services de journalisation sont essentiels à la surveillance de vos systèmes. Bien que les métriques constituent la base des éléments spécifiques à surveiller, les journaux contiennent des informations précieuses nécessaires au débogage, à l'analyse de la sécurité et aux exigences de conformité.

La journalisation des données générées par vos systèmes vous aide à garantir une stratégie de sécurité efficace. Pour plus d'informations sur la journalisation et la sécurité, consultez la section Mettre en œuvre la journalisation et les contrôles de détection dans la catégorie Sécurité du framework d'architecture.

Cloud Logging est un service de journalisation intégré qui vous permet de stocker, rechercher, analyser et surveiller les données et les événements des journaux, puis d'envoyer des alertes si nécessaire. Logging collecte automatiquement les journaux des services Google Cloud et d'autres fournisseurs de services cloud. Ces journaux peuvent vous servir à créer des métriques pour la surveillance ainsi que des exportations de journaux vers des services externes, tels que Cloud Storage, BigQuery et Pub/Sub.

Mettre en place un outil d'audit

Pour vous aider à répondre à des questions telles que "qui a fait quoi, où et quand" dans vos projets Google Cloud, utilisez les Cloud Audit Logs.

Cloud Audit Logs capture plusieurs types d'activités, telles que :

• Les journaux des activités d'administration contiennent des entrées relatives aux appels d'API et aux autres opérations d'administration qui modifient la configuration ou les métadonnées des ressources. Les journaux d'activité d'administration sont toujours activés.
• Les journaux d'audit de type Accès aux données enregistrent les appels d'API qui créent, modifient ou lisent des données fournies par l'utilisateur. Les journaux d'audit relatifs à l'accès aux données sont désactivés par défaut car leur taille peut être assez conséquente. Vous pouvez configurer les services Google Cloud qui génèrent des journaux d'accès aux données.

Pour obtenir la liste des services Google Cloud qui génèrent des journaux d'audit, consultez la page Services Google avec journaux d'audit. Limitez l'accès aux journaux d'audit à l'aide des contrôles IAM (Identity and Access Management).

Étapes suivantes

• Établir des processus d'assistance et de remontée des demandes d'assistance cloud (le prochain document de cette série)
• Explorez Google Cloud Observability.
• Déployer Cloud Monitoring pour obtenir une visibilité sur les performances, la disponibilité et l'état de vos applications et de votre infrastructure
• En savoir plus sur la surveillance et l'observabilité.
• Explorez d'autres catégories du framework d'architecture, telles que la conception système, la sécurité, la confidentialité, la conformité, la fiabilité, l'optimisation des coûts et l'optimisation des performances.

Établir des processus d'assistance et d'escalade des demandes d'assistance cloud

Le présent document du framework d'architecture Google Cloud vous explique comment définir un processus de remontée de demande d'assistance. Obtenir l'assistance de votre fournisseur cloud ou d'autres fournisseurs tiers est un élément clé pour la gestion efficace des remontées de demande d'assistance.

Google Cloud propose différents canaux d'assistance dont les suivants : assistance en direct ou via des conseils publiés au sein de communautés de développeurs ou dans la documentation produit. L'offre du Cloud Customer Care vous permet de travailler en collaboration avec Google Cloud pour exécuter vos charges de travail de manière efficace.

Obtenir l'assistance de vos fournisseurs

Souscrivez un contrat d'assistance auprès de votre fournisseur cloud ou d'autres fournisseurs tiers. L'assistance est essentielle pour garantir une réponse et une résolution rapides des problèmes opérationnels.

Pour travailler avec le service client Google Cloud, envisagez d'acheter une offre de service client incluant une assistance standard, avancée ou Premium. Pensez à utiliser l'assistance avancée ou Premium pour vos principaux environnements de production.

Définir votre processus de remontée de demande d'assistance

Un processus de remontée de demande d'assistance bien défini est essentiel pour réduire les efforts et le temps nécessaires pour identifier et résoudre les problèmes dans vos systèmes. Cela inclut les problèmes nécessitant une assistance pour des produits Google Cloud ou pour d'autres fournisseurs cloud ou services tiers.

Pour créer la procédure de remontée de demande d'assistance :

• Définissez quand et comment faire remonter les problèmes en interne.
• Définissez quand et comment créer des demandes d'assistance auprès de votre fournisseur cloud ou d'un autre fournisseur tiers.
• Apprenez à travailler efficacement avec les équipes d'assistance. Pour Google Cloud, nous vous recommandons (à vous et à vos équipes en charge des opérations) de consulter les bonnes pratiques pour utiliser le service client. Intégrez ces pratiques dans votre procédure de remontée des demandes d'assistance.
• Recherchez ou créez des documents décrivant votre architecture. Assurez-vous que ces documents incluent des informations utiles pour les ingénieurs d'assistance.
• Définissez la manière dont vos équipes communiquent en cas d'interruption de service.
• Assurez-vous que les personnes ayant besoin d'assistance disposent des niveaux d'autorisations d'assistance appropriés pour accéder au centre d'assistance Google Cloud ou pour communiquer avec d'autres fournisseurs d'assistance. Pour en savoir plus sur l'utilisation du centre d'assistance Google Cloud, consultez la page Procédures d'assistance.
• Configurez la surveillance, les alertes et la journalisation afin de disposer des informations nécessaires pour agir en cas de problème.
• Créez des modèles pour la création de rapports d'incident. Pour connaître les informations à inclure dans vos rapports d'incident, consultez la section Bonnes pratiques de travail avec le service client.
• Documentez la procédure de remontée des demandes d'assistance dans votre organisation. Assurez-vous de prendre des mesures claires et bien définies pour résoudre les problèmes que vous rencontrez.
• Incluez un plan pour apprendre aux nouveaux membres de l'équipe à interagir avec l'assistance.

Testez régulièrement votre processus de remontée des demandes d'assistance en interne. Testez votre processus de remontée des demandes d'assistance avant les événements majeurs tels que les migrations, les lancements de nouveaux produits ou les pics de trafic. Si vous disposez de l'assistance Premium de Cloud Customer Care, votre responsable de compte technique peut vous aider à évaluer votre processus de remontée des demandes d'assistance et à coordonner vos tests avec Cloud Customer Care.

Assurez-vous de recevoir les communications de l'assistance

Assurez-vous que vos administrateurs reçoivent bien les communications de votre fournisseur cloud et de vos services tiers. Ces informations permettent aux administrateurs de prendre des décisions avisées et de résoudre les problèmes avant qu'ils ne créent des problèmes plus importants. Assurez-vous que les conditions suivantes sont remplies :

• La configuration nécessaire est en place pour que les administrateurs système, réseau et sécurité reçoivent les e-mails critiques de Google Cloud et de vos autres fournisseurs ou services.
• La configuration nécessaire est en place pour que les administrateurs système, réseau et sécurité reçoivent les alertes système générées par des outils de surveillance comme Cloud Monitoring.
• Les propriétaires de projet disposent de noms d'utilisateur routables pour pouvoir recevoir les e-mails critiques.

Pour en savoir plus sur la gestion des notifications Google Cloud, consultez la page Gérer les contacts pour les notifications.

Mettre en place des processus d'examen

Mettez en place des processus d'examen ou de post-mortem. Suivez ces processus pour envoyer une nouvelle demande d'assistance ou faire remonter une demande d'assistance existante. Dans le cadre du post-mortem, documentez les apprentissages tirés et les mesures d'atténuation. Lors de cet examen, favorisez une culture post-mortem irréprochable.

Pour en savoir plus sur les analyses post-mortem, consultez la page Culture du postmortem : apprendre de ses échecs.

Construire des centres d'excellence

Il peut être utile d'enregistrer les informations, l'expérience et les modèles de votre organisation dans une base de connaissances interne, telle qu'un wiki, un site Google ou un site intranet. À mesure que de nouveaux produits et fonctionnalités sont déployés de manière continue dans Google Cloud, ces connaissances peuvent vous aider à comprendre pourquoi vous avez choisi une conception particulière pour vos applications et services. Pour en savoir plus, consultez la page Enregistrements de décision d'architecture.

Il est également recommandé de désigner des experts et des experts Google Cloud au sein de votre organisation. Une gamme d'options de formation et de certification est disponible pour aider les experts nommés à aller plus loin dans leur domaine de compétence. Les équipes peuvent rester informées des dernières actualités, des annonces et des témoignages clients en s'abonnant au blog Google Cloud.

Étape suivante

• Gérer la capacité et les quotas (prochain document de cette série)
• Explorez d'autres catégories du framework d'architecture, telles que la conception système, la sécurité, la confidentialité, la conformité, la fiabilité, l'optimisation des coûts et l'optimisation des performances.

Gérer la capacité et les quotas

Ce document du framework d'architecture Google Cloud vous explique comment évaluer et planifier votre capacité et vos quotas dans le cloud.

Dans un centre de données traditionnel, vous devez chaque trimestre consacrer un temps considérable à l'évaluation des besoins actuels en ressources et des besoins futurs. Vous devez tenir compte de problèmes physiques, logistiques et humains. Vous devez tenir compte des problématiques d'espace de stockage, de refroidissement, d'électricité, de bande passante, de câblage, de délais d'approvisionnement, de délais d'expédition et de nombre d'ingénieurs disponibles pour installer les nouveaux équipements. Vous devez également gérer activement la répartition de la capacité et des charges de travail pour que les tâches gourmandes en ressources (par exemple, les pipelines Hadoop) n'interfèrent pas avec les services qui doivent être hautement disponibles, comme les serveurs Web.

En revanche, lorsque vous utilisez Google Cloud, vous déléguez la majeure partie de ce travail de planification à Google. L'utilisation du cloud évite d'avoir à provisionner et à gérer des ressources inactives lorsqu'elles ne sont pas nécessaires. Par exemple, vous pouvez créer, faire évoluer et réduire des instances de VM en fonction de vos besoins. Grâce à la tarification à l'utilisation, vous pouvez optimiser vos dépenses, y compris la capacité excédentaire dont vous n'avez besoin que lors des pics de trafic. Pour vous aider à réaliser des économies, Compute Engine fournit des recommandations de type de machine lorsqu'il est détecté que certaines de vos instances de VM sont sous-utilisées et peuvent être redimensionnées ou supprimées.

Évaluer vos besoins en termes de capacité cloud

Pour gérer efficacement votre capacité, vous devez connaître les besoins en capacité de votre organisation.

Pour évaluer vos besoins en capacité, commencez par identifier vos charges de travail cloud les plus importantes. Évaluez les utilisations moyennes et maximales de ces charges de travail, ainsi que leurs besoins actuels et futurs en capacité.

Identifiez les équipes qui utilisent ces charges de travail principales. Collaborez avec ces équipes pour mettre en place un processus interne de planification de la demande. Utilisez ce processus pour mieux comprendre les besoins actuels et futurs des équipes en termes de ressources cloud.

Analysez le modèle de charge et la distribution des appels. Utilisez les métriques de pic d'activité sur les 30 derniers jours, par heure et par minute dans votre analyse.

Envisagez d'utiliser Cloud Monitoring pour bénéficier d'une visibilité sur les performances, la disponibilité et l'état général de vos applications et de votre infrastructure.

Afficher les métriques d'utilisation de votre infrastructure

Pour faciliter la planification des capacités, collectez et stockez des données d'historique d'utilisation des ressources cloud par votre organisation.

Assurez-vous de disposer d'une visibilité sur les métriques d'utilisation de l'infrastructure. Par exemple, pour les charges de travail principales, évaluez les éléments suivants :

• Utilisation moyenne et maximale
• Pics dans les modèles d'utilisation
• Pics saisonniers basés sur les exigences commerciales (périodes de vacances pour les sites marchands par exemple)
• Surprovisionnement nécessaire pour se préparer aux événements de pic d'activité et gérer rapidement les pics de trafic potentiels

Assurez-vous que votre organisation a configuré des alertes pour être informé automatiquement lorsque vous approchez des limites de quota et de capacité.

Utilisez les outils de surveillance de Google pour obtenir des informations sur l'utilisation et la capacité des applications. Par exemple, vous pouvez définir des métriques personnalisées avec Monitoring. Utilisez ces métriques personnalisées pour définir des tendances d'alertes. Stackdriver Monitoring fournit également des tableaux de bord flexibles et des outils de visualisation complets pour vous aider à identifier les problèmes émergents.

Créer un processus de planification de la capacité

Mettez en place un processus de planification de la capacité et documentez-le.

Lorsque vous créez ce processus, procédez comme suit :

1. Mettez en œuvre des tests de charge pour déterminer la charge que le système peut gérer tout en atteignant ses objectifs de latence, avec une quantité fixe de ressources. Les tests de charge doivent utiliser une combinaison de types de requêtes représentative du profil de trafic de production généré par de vrais utilisateurs. N'utilisez pas une combinaison d'opérations uniforme ou aléatoire. Incluez des pics d'utilisation dans votre profil de trafic.
2. Créez un modèle de capacité. Un modèle de capacité est un ensemble de formules permettant de calculer les ressources incrémentielles requises en fonction de l'augmentation de la charge du service, conformément aux conclusions des tests de charge.
3. Prévoyez le trafic futur et tenez compte de la croissance. Pour découvrir comment Google crée ses prévisions de trafic, consultez l'article Mesurer les charges futures.
4. Appliquez le modèle de capacité à la prévision pour déterminer les besoins futurs en ressources.
5. Estimez le coût des ressources dont votre organisation a besoin. Ensuite, faites approuver le budget par le service financier de votre organisation. Cette étape est essentielle, car l'entreprise peut choisir de faire des compromis en matière de coûts et de risques pour une gamme de produits. Ces compromis peuvent signifier que vous disposez d'une capacité inférieure ou supérieure aux prévisions pour un produit donné, en fonction des priorités commerciales.
6. Rapprochez-vous de votre fournisseur cloud pour obtenir une quantité adéquate de ressources lorsque vous en avez besoin grâce aux quotas et aux réservations. Faites appel aux équipes d'infrastructure pour la planification de la capacité et demandez aux équipes opérationnelles de créer des plans de capacité avec des intervalles de confiance.
7. Répétez les étapes précédentes tous les trimestres ou semestres.

Pour obtenir des conseils plus détaillés sur le processus de planification de la capacité tout en optimisant l'utilisation des ressources, consultez la section Planification des capacités.

Vérifier que vos quotas correspondent à vos besoins en capacité

Google Cloud applique des quotas pour limiter la quantité d'une ressource Google Cloud partagée spécifique que vous pouvez utiliser. Chaque quota représente une ressource dénombrable spécifique, telle que les appels d'API à un service particulier, le nombre d'équilibreurs de charge utilisés simultanément par votre projet ou le nombre de projets que vous pouvez créer. Par exemple, les quotas permettent de garantir qu'un petit nombre de clients ou de projets ne va pas monopoliser les cœurs de processeur dans une région ou une zone donnée.

Lorsque vous évaluez vos quotas, tenez compte des points suivants :

• Planifiez à l'avance les besoins en termes de capacité des projets afin d'éviter toute limitation inattendue de la consommation de ressources.
• Configurez votre quota et votre capacité de manière à pouvoir gérer une défaillance régionale complète.
• Utilisez les quotas pour limiter la consommation d'une ressource particulière. Par exemple, vous pouvez définir un quota maximal d'utilisation quotidienne des requêtes pour l'API BigQuery afin de vous assurer qu'un projet ne consomme pas trop de ressources BigQuery.
• Prévoyez les pics d'utilisation et incluez-les dans votre planification de quotas. Des pics d'utilisation peuvent survenir tout au long de la journée au gré de pics de trafic (prévus ou non) ou lors d'événements de lancement. Pour en savoir plus sur la planification pour les pics de trafic et les événements de lancement, consultez la section suivante intitulée "Excellence opérationnelle : Planifier les pics de trafic et les événements de lancement".

Si vos quotas actuels ne sont pas suffisants, vous pouvez gérer vos quotas dans la console Google Cloud. Si vous avez besoin d'une grande capacité, contactez votre équipe commerciale Google Cloud. Cependant, vous devez savoir que de nombreux services font également l'objet de limites qui ne sont pas liées au système de quotas. Pour en savoir plus, consultez la page Les quotas et leur utilisation.

Évaluez régulièrement vos quotas. Envoyez les demandes de quota avant qu'elles ne soient nécessaires. Consultez la page Les quotas et leur utilisation pour mieux comprendre comment les demandes sont approuvées ou refusées.

Il existe plusieurs façons d'afficher et de gérer votre quota Google Cloud :

• En utilisant la console Google Cloud
• En utilisant Google Cloud CLI
• En utilisant l'API Service Usage
• En utilisant Monitoring pour afficher des métriques de quota
• Pour gérer les quotas sur de nombreux projets Google Cloud au sein d'une organisation ou d'un dossier, envisagez de mettre en œuvre la solution de tableau de bord Monitoring pour les quotas.

Étape suivante

• Planifier les pics de trafic et les événements de lancement (document suivant de cette série)
• Explorez d'autres catégories du framework d'architecture, telles que la conception système, la sécurité, la confidentialité, la conformité, la fiabilité, l'optimisation des coûts et l'optimisation des performances.

Planifier les pics de trafic et les événements de lancement

Ce document du framework d'architecture Google Cloud vous explique comment planifier les pics de trafic et les événements de lancement afin d'éviter toute perturbation de votre activité.

Les événements de pic d'activité sont des événements commerciaux majeurs qui entraînent une augmentation significative du trafic au-delà de référence standard de l'application. Ces événements de pic d'activité nécessitent un scaling planifié.

Par exemple, les entreprises de vente au détail qui ont une présence en ligne peuvent s'attendre à des événements de pic d'activité pendant les fêtes de fin d'année. Le Black Friday, qui a lieu le lendemain de Thanksgiving aux États-Unis, est l'un des jours les plus importants de l'année en termes de ventes. Pour le secteur de la santé aux États-Unis, les mois d'octobre et novembre peuvent connaître des pics d'activité en raison des pics de trafic en ligne liés aux inscriptions aux prestations sociales.

Les événements de lancement sont des déploiements ou des migrations majeures de nouvelles fonctionnalités en production. Par exemple, une migration depuis une infrastructure sur site vers le cloud, ou un lancement d'un nouveau service ou d'une nouvelle fonctionnalité.

Si vous lancez un nouveau produit, vous devrez vous attendre à une augmentation de la charge de vos systèmes pendant et potentiellement après l'annonce. Ces événements peuvent souvent multiplier la charge par 5 ou 20 (voire plus) sur les systèmes de frontend. Cette charge accrue se répercute aussi sur les systèmes backend. Souvent, ces charges de frontend et de backend sont caractérisées par un scaling rapide sur une courte période lorsque le trafic Web est ouvert pour l'événement. Les événements de lancement impliquent une diminution progressive du trafic jusqu'à revenir à des niveaux normaux. Cette baisse est généralement plus lente que le scaling réalisé pour s'adapter au pic de trafic.

Les événements de pic d'activité et de lancement se décomposent en trois étapes :

• Planification et préparation de l'événement de lancement ou du pic de trafic
• Lancement de l'événement
• Évaluation des performances pendant l'événement et analyse post-événement

Les pratiques décrites dans le présent document vous aideront à garantir le bon déroulement de chacune de ces étapes.

Créer un guide général pour les événements de lancement ou de pic de trafic

Élaborez un guide général avec une vision à long terme des événements de pic d'activité actuels et futurs. Continuez à compiler vos apprentissages dans ce guide afin de pouvoir vous en servir de référence pour les futurs événements de pic d'activité.

Planifier votre événement de lancement ou de pic de trafic

Planifiez et préparez-vous. Créez des projections commerciales pour les lancements à venir et pour les événements de pic d'activité attendus (ou inattendus). La préparation de votre système en vue des pics d'activité dépend de votre compréhension des projections commerciales. Plus vous en savez sur les prévisions passées, plus vous améliorerez la précision de vos nouvelles prévisions commerciales. Ces nouvelles prévisions sont des éléments essentiels à la projection de la demande attendue sur le système.

Créer des équipes en charge de la gestion du programme et de la planification coordonnée (au sein de votre organisation et avec les fournisseurs tiers) est un facteur clé de la réussite. Créez ces équipes le plus tôt possible pour que votre équipe en charge de la gestion du programme puisse définir un calendrier, faire approuver des budgets et collecter des ressources pour l'infrastructure, les tests et les formations supplémentaires.

Il est important de mettre en place des canaux de communication clairs. La communication est essentielle à chaque étape de l'événement de lancement ou de pic de trafic. Abordez les risques et les sujets de préoccupation le plus tôt possible et solutionnez les problèmes avant qu'ils ne créent un blocage. Créez une documentation de planification des événements. Condensez les informations les plus importantes sur l'événement de pic d'activité et faites-les circuler dans l'entreprise. Cela permettra aux utilisateurs d'intégrer les informations de planification et de répondre aux questions de base. Ce document aide les nouveaux collaborateurs à se mettre à jour rapidement sur la planification des événements de pic d'activité.

Documentez votre plan pour chaque événement. Lorsque vous documentez votre plan, assurez-vous d'effectuer les actions suivantes :

• Identifiez les hypothèses, les risques et les inconnues.
• Passez en revue les événements passés et déterminez les informations pertinentes pour l'événement de lancement ou de pic d'activité à venir. Déterminez les données disponibles et la valeur qu'elles ont fournie par le passé.
• Détaillez le plan de rollback pour les événements de lancement et de migration.
• Passez en revue l'architecture :
  • Documentez les ressources clés et les composants architecturaux.
  • Servez-vous du framework d'architecture pour examiner tous les aspects de l'environnement afin de déterminer les risques et les problématiques de scaling.
  • Créez un schéma montrant comment les principaux composants de l'architecture sont connectés. L'examen du diagramme peut vous aider à isoler les problèmes et à en accélérer la résolution.
• Le cas échéant, configurez le service pour qu'il utilise des actions d'alerte afin de redémarrer automatiquement en cas d'échec. Lorsque vous utilisez Compute Engine, envisagez d'utiliser l'autoscaling pour gérer les pics de débit.
• Utilisez les réservations pour vous assurer que les ressources Compute Engine sont disponibles lorsque vous en avez besoin. Les réservations offrent un niveau très élevé d'assurance pour l'obtention de capacité de ressources zonales Compute Engine. Vous pouvez utiliser des réservations pour vous assurer que votre projet dispose de ressources disponibles.
• Identifiez les métriques et les alertes à suivre :
  • Identifiez les métriques métier et système à surveiller pour l'événement. Si des métriques ou des indicateurs de niveau de service (SLI) ne sont pas collectés, modifiez le système pour collecter les données.
  • Vérifiez que vous disposez de capacités de surveillance et d'alerte suffisantes, et que vous avez bien passé en revue les modèles de trafic normaux et des événements précédents. Assurez-vous que les alertes sont définies de manière appropriée. Utilisez les outils Google Cloud Monitoring pour afficher l'utilisation, la capacité et l'état général de vos applications et de votre infrastructure.
  • Assurez-vous que les métriques système sont capturées en incluant les données de surveillance et les niveaux d'alerte.
• Passez en revue les besoins de capacité accrue avec l'équipe responsable du compte Google Cloud et planifiez la gestion des quotas en fonction. Pour plus de détails, consultez la section Vérifier que vos quotas correspondent à vos besoins.
• Assurez-vous de disposer de niveaux d'assistance cloud appropriés, que votre équipe comprend comment ouvrir les demandes d'assistance et qu'une procédure de remontée d'assistance est définie. Pour en savoir plus, consultez l'article Établir des procédures d'assistance et de remontée d'assistance cloud.
• Définissez un plan de communication, un calendrier et des responsabilités :
  • Impliquez des parties prenantes pluridisciplinaires pour coordonner la communication et la planification du programme. Ces parties prenantes peuvent inclure des personnes pertinentes issues des équipes techniques, opérationnelles et dirigeantes, ainsi que des fournisseurs tiers.
  • Établissez une chronologie non ambiguë qui indique les tâches critiques et les équipes en charge de ces tâches.
  • Mettez en place une matrice d'affectation des responsabilités (RACI) pour communiquer les responsabilités aux équipes, chefs d'équipe, parties prenantes et parties responsables.
  • Vous pouvez utiliser le service de gestion des événements de l'assistance Premium pour les événements de pic d'activité planifiés. Grâce à ce service, Customer Care s'associe à votre équipe pour créer un plan et vous conseiller au cours de l'événement.

Mettre en place des processus d'examen

Une fois l'événement de lancement ou de pic de trafic terminé, faites un bilan en documentant vos apprentissages. Ensuite, mettez à jour votre guide pour inclure ces apprentissages. Pour finir, appliquez ces apprentissages lors de votre prochain événement majeur. Il est important de tirer des leçons des événements passés, en particulier lorsqu'ils mettent en évidence les contraintes subies par le système lorsqu'il est fortement sollicité.

Les examens rétrospectifs (également appelés post-mortems) des événements de lancement ou de pic de trafic sont une technique utile pour capturer des données et mieux comprendre les incidents. Effectuez cet examen pour les événements de lancement et de pic de trafic qui se sont déroulés comme prévu, ainsi que pour les incidents qui ont entraîné des problèmes. Cette démarche permet de cultiver une culture irréprochable.

Pour en savoir plus sur les analyses post-mortem, consultez la page Culture du postmortem : apprendre de ses échecs.

Étape suivante

• Créer une culture d'automatisation (document suivant de cette série)
• Explorez d'autres catégories du framework d'architecture, telles que la conception système, la sécurité, la confidentialité, la conformité, la fiabilité, l'optimisation des coûts et l'optimisation des performances.

Créer une culture de l'automatisation

Le présent document du framework d'architecture Google Cloud vous montre comment évaluer les tâches laborieuses et en limiter l'impact sur vos systèmes et vos équipes.

Les tâches laborieuses constituent un travail manuel et répétitif sans valeur durable, qui augmentent à mesure que le service se développe. Essayez constamment de réduire ou d'éliminer les tâches laborieuses. Sinon, le travail opérationnel risque de surcharger les opérateurs, après quoi toute augmentation de l'utilisation ou de la complexité du produit peut nécessiter une équipe supplémentaire.

L'automatisation est un moyen essentiel pour réduire l'impact des tâches laborieuses. L'automatisation améliore également la vitesse de publication et réduit les erreurs humaines.

Pour en savoir plus, consultez la page Éliminer les tâches laborieuses.

Faire l'inventaire et évaluer le coût des tâches laborieuses

Commencez par faire l'inventaire et évaluez les coûts des tâches laborieuses pour les équipes qui gèrent vos systèmes. Faites en sorte que ce processus s'effectue en continu et investissez dans une automatisation personnalisée pour étendre les solutions déjà fournies par les services et partenaires Google Cloud. Vous pouvez généralement modifier l'automatisation Google Cloud (par exemple l'autoscaler de Compute Engine).

Prioriser l'élimination des tâches laborieuses

L'automatisation est utile mais ne résout pas tous les problèmes opérationnels. Première étape pour traiter les tâches laborieuses connues, nous vous recommandons de passer en revue votre inventaire de tâches laborieuses existantes et de hiérarchiser autant que possible. Vous pourrez ensuite vous concentrer sur l'automatisation.

Automatiser les tâches laborieuses nécessaires

Certaines tâches laborieuses dans vos systèmes ne peuvent pas être éliminées. Deuxième étape pour éliminer une tâche laborieuse connue, automatiser la tache en utilisant les solutions d'automatisation personnalisables de Google Cloud.

Voici quelques domaines dans lesquels l'automatisation configurable ou personnalisée peut aider votre organisation à éliminer les tâches laborieuses :

• La gestion des identités (par exemple, Cloud Identity et IAM).
• Les solutions hébergées par Google Cloud par opposition aux solutions développées par vos soins, par exemple la gestion des clusters (Google Kubernetes Engine ou GKE), des bases de données relationnelles (Cloud SQL), des entrepôts de données (BigQuery) et des API (Apigee).
• Les services Google Cloud et le provisionnement des locataires (par exemple, Terraform et le kit Cloud Foundation).
• L'orchestration automatique des workflows pour les opérations en plusieurs étapes (par exemple, Cloud Composer).
• Le provisionnement de capacités supplémentaires (plusieurs produits Google Cloud tels que Compute Engine et GKE offrent un autoscaling configurable). Évaluez les services Google Cloud que vous utilisez pour déterminer s'ils incluent un autoscaling configurable.
• Les pipelines CI/CD avec déploiement automatisé (par exemple, Cloud Build).
• L'analyse Canary permettant de valider les déploiements.
• L'entraînement automatisé des modèles (pour le machine learning), par exemple AutoML.

Si un produit ou un service Google Cloud ne répond que partiellement à vos besoins techniques lors de l'automatisation ou de la suppression des workflows manuels, envisagez d'envoyer une demande de fonctionnalité par l'intermédiaire de votre responsable de compte Google Cloud. Votre problème peut être une priorité pour d'autres clients ou déjà faire partie de notre feuille de route. Si tel est le cas, connaître la priorité et la chronologie de déploiement de la fonctionnalité vous permettra de mieux évaluer le compromis entre la création de votre propre solution et le fait d'attendre une fonctionnalité Google Cloud.

Créer ou acheter des solutions pour des tâches laborieuses plus coûteuses

La troisième étape, qui peut être réalisée en parallèle de la première et de la deuxième étape, consiste à évaluer la création ou l'achat d'autres solutions si vos coûts associés à des tâches laborieuses restent élevés (par exemple, si le travail laborieux prend beaucoup de temps à l'une des équipes qui gérent vos systèmes de production).

Lorsque vous créez ou achetez des solutions, tenez compte des coûts d'intégration, de sécurité, de confidentialité et de conformité. La conception et la mise en œuvre de votre propre automatisation engendrent des coûts de maintenance et des risques de fiabilité qui dépassent les coûts initiaux de développement et de configuration. Ne choisissez donc cette option qu'en dernier recours.

Étape suivante

Explorez d'autres catégories du framework d'architecture, telles que la conception système, la sécurité, la confidentialité, la conformité, la fiabilité, l'optimisation des coûts et l'optimisation des performances.

Framework d'architecture Google Cloud : sécurité, confidentialité et conformité

Cette catégorie du framework d'architecture Google Cloud vous explique comment concevoir et exploiter des services sécurisés sur Google Cloud. Vous découvrirez également les produits et fonctionnalités Google Cloud compatibles avec la sécurité et la conformité.

Le framework d'architecture décrit les bonnes pratiques, fournit des recommandations de mise en œuvre et explique certains des produits et services disponibles. Le framework vous aide à concevoir votre déploiement Google Cloud pour répondre aux besoins de votre entreprise.

Le transfert de vos charges de travail vers Google Cloud nécessite une évaluation des exigences, des risques, des obligations de conformité et des contrôles de sécurité de votre entreprise. Ce document vous aide à prendre en compte les bonnes pratiques de conception d'une solution sécurisée dans Google Cloud.

Les principes de base de Google incluent la défense en profondeur, à grande échelle et par défaut. Dans Google Cloud, les données et les systèmes sont protégés par des défenses multicouches incluant les règles et contrôles configurés sur IAM, le chiffrement, la mise en réseau, la détection, la journalisation et la surveillance.

Google Cloud offre de nombreux contrôles de sécurité sur lesquels vous pouvez vous appuyer, par exemple :

• Options sécurisées pour les données en transit et chiffrement par défaut pour les données au repos
• Fonctionnalités de sécurité intégrées pour les produits et services Google Cloud
• Infrastructure mondiale conçue pour la géoredondance, avec des contrôles de sécurité tout au long du cycle de vie du traitement des informations
• Fonctionnalités d'automatisation qui utilisent l'infrastructure en tant que code (IaC) et des garde-fous de configuration

Pour en savoir plus sur l'état de sécurité de Google Cloud, consultez l'article sur la sécurité de Google et la présentation de la sécurité sur l'infrastructure de Google. Pour obtenir un exemple d'environnement sécurisé par défaut, consultez le plan de base d'entreprise Google Cloud.

Dans la catégorie "Sécurité" du framework d'architecture, vous allez apprendre à effectuer les opérations suivantes :

• Découvrez les responsabilités partagées et le partage de sort sur Google Cloud
• Comprendre les principes de sécurité
• Gérer les risques à l'aide de contrôles
• Gérer vos assets
• Gérer l'identité et l'accès
• Mettre en œuvre la sécurité des ressources de calcul et des conteneurs
• Sécuriser votre réseau
• Appliquer la sécurité des données
• Déployer la sécurité des applications
• Gérer les obligations de conformité
• Mettre en œuvre des exigences de souveraineté et de résidence des données
• Mettre en œuvre des exigences de confidentialité
• Mettre en œuvre la journalisation et les contrôles de détection

Responsabilités partagées et partage de sort sur Google Cloud

Ce document décrit les différences entre le modèle de responsabilité partagée et le partage de sort dans Google Cloud. Il aborde les défis et les nuances du modèle de responsabilité partagée. Ce document explique le principe du partage de sort et notre méthode de collaboration avec nos clients pour relever les défis liés à la sécurité dans le cloud.

Il est important de comprendre le modèle de responsabilité partagée pour déterminer comment protéger au mieux vos données et vos charges de travail sur Google Cloud. Le modèle de responsabilité partagée décrit les tâches liées à la sécurité que vous devez effectuer dans le cloud et explique ce qui les différencie des autres tâches pour les fournisseurs de cloud.

Cependant, il peut être difficile de comprendre la responsabilité partagée. Le modèle nécessite une compréhension approfondie de chaque service utilisé, des options de configuration fournies par chaque service et des mesures mises en place par Google Cloud pour sécuriser ce service. Chaque service possède un profil de configuration différent, et il peut être difficile de déterminer la meilleure configuration de sécurité. Google pense que le modèle de responsabilité partagée ne suffit pas pour aider les clients cloud à obtenir de meilleures performances de sécurité. Nous préférons le partage de sort à la responsabilité partagée.

Le partage de sort nous permet de créer et d'exploiter une plate-forme cloud fiable pour vos charges de travail. Nous offrons des bonnes pratiques ainsi qu'un code d'infrastructure sécurisé et certifié qui vous permet de déployer vos charges de travail de manière sécurisée. Nous publions des solutions qui associent divers services Google Cloud afin de résoudre des problèmes de sécurité complexes. Nous proposons également des options d'assurance innovantes pour vous aider à évaluer et à limiter les risques que vous devez accepter. Le partage de sort nous oblige à interagir de manière plus étroite avec vous lorsque vous sécurisez vos ressources sur Google Cloud.

Responsabilité partagée

Personne ne connaît mieux que vous les exigences de sécurité et les obligations réglementaires pour votre entreprise, ainsi que les exigences liées à la protection de vos données et ressources confidentielles. Lorsque vous exécutez vos charges de travail sur Google Cloud, vous devez identifier les contrôles de sécurité que vous devez configurer dans Google Cloud pour protéger vos données confidentielles et toutes vos charges de travail. Pour déterminer les contrôles de sécurité à mettre en œuvre, vous devez prendre en compte les facteurs suivants :

• Vos obligations liées à la conformité réglementaire
• Les normes de sécurité et le plan de gestion des risques de votre organisation
• Les exigences de sécurité de vos clients et de vos fournisseurs

Défini par les charges de travail

Traditionnellement, les responsabilités sont définies en fonction du type de charge de travail que vous exécutez et des services cloud dont vous avez besoin. Les services cloud incluent les catégories suivantes :

Service cloud	Description
Infrastructure as a Service (IaaS)	Les services IaaS incluent Compute Engine, Cloud Storage et des services de mise en réseau tels que Cloud VPN, Cloud Load Balancing et Cloud DNS. L'IaaS fournit des services de calcul, de stockage et de réseau à la demande grâce au paiement à l'usage. Vous pouvez utiliser l'IaaS si vous prévoyez de migrer une charge de travail sur site existante vers le cloud à l'aide de la migration Lift and Shift, ou si vous souhaitez exécuter votre application sur des VM spécifiques, à l'aide de bases de données ou de configurations réseau spécifiques. Dans le domaine IaaS, vous êtes responsable des questions de sécurité, et nous sommes en charge de l'infrastructure sous-jacente et la sécurité physique.
Platform as a Service (PaaS)	Les services PaaS incluent App Engine, Google Kubernetes Engine (GKE) et BigQuery. PaaS fournit l'environnement d'exécution dans lequel vous pouvez développer et exécuter vos applications. Vous pouvez utiliser PaaS si vous créez une application (comme un site Web) et que vous souhaitez vous concentrer sur le développement plutôt que sur l'infrastructure sous-jacente. Dans le domaine PaaS, nous sommes responsables d'un plus grand nombre de contrôles qu'avec la solution IaaS, y compris les contrôles de réseau. Vous partagez avec nous la responsabilité des contrôles au niveau de l'application et de la gestion IAM. Vous demeurez responsable de la sécurité de vos données et de la protection de vos clients.
Software as a Service (SaaS)	Les applications SaaS incluent Google Workspace, Chronicle et les applications SaaS tierces disponibles dans Google Cloud Marketplace. SaaS fournit des applications en ligne auxquelles vous pouvez vous abonner ou que vous pouvez payer d'une manière ou d'une autre. Vous pouvez utiliser des applications SaaS lorsque votre entreprise ne dispose pas de l'expertise interne ou des exigences métier pour créer l'application elle-même, mais cela nécessite d'avoir la capacité de traiter des charges de travail. Dans le domaine SaaS, nous assumons la plupart des responsabilités liées à la sécurité. Vous restez responsable de vos contrôles d'accès et des données que vous choisissez de stocker dans l'application.
Functions as a Service (FaaS) ou sans serveur	FaaS fournit aux développeurs une plate-forme permettant d'exécuter un petit code à usage unique (appelé fonctions) qui s'exécute en réponse à des événements particuliers. Vous pouvez utiliser FaaS lorsque vous souhaitez que des opérations spécifiques se produisent en fonction d'un événement particulier. Par exemple, vous pouvez créer une fonction qui s'exécute chaque fois que des données sont importées dans Cloud Storage à des fins de classement. La liste des responsabilités partagées du domaine FaaS est semblable à celle du domaine SaaS. Cloud Functions est une application FaaS.

Le schéma suivant illustre les services cloud et définit la manière dont les responsabilités sont partagées entre le fournisseur cloud et le client.

Comme le montre le schéma, le fournisseur cloud reste responsable du réseau et de l'infrastructure sous-jacents, et les clients restent responsables de leurs règles d'accès et de leurs données.

Défini par le secteur et le cadre réglementaire

Différents secteurs possèdent des cadres réglementaires qui définissent les contrôles de sécurité à mettre en place. Lorsque vous déplacez vos charges de travail vers le cloud, vous devez connaître les points suivants :

• Les contrôles de sécurité qui relèvent de votre responsabilité
• Les contrôles de sécurité disponibles dans l'offre cloud
• Les contrôles de sécurité par défaut qui sont hérités

Les contrôles de sécurité hérités (tels que notre chiffrement par défaut et nos contrôles d'infrastructure) sont des contrôles que vous pouvez fournir en tant que preuves de votre stratégie de sécurité aux auditeurs et aux autorités de régulation. Par exemple, la norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS, Payment Card Industry Data Security Standard) définit les réglementations pour les sociétés de traitement des paiements. Lorsque vous migrez votre entreprise vers le cloud, ces réglementations sont partagées entre vous et votre FSC. Pour comprendre comment les responsabilités PCI DSS sont partagées entre vous et Google Cloud, consultez la page Google Cloud : tableau de responsabilité partagée PCI DSS.

Autre exemple : aux États-Unis, la loi HIPAA (Health Insurance Portability and Accountability Act) a établi des normes concernant le traitement des données de santé électroniques à caractère personnel. Ces responsabilités sont également partagées entre le FSC et vous-même. Pour en savoir plus sur la manière dont Google Cloud respecte nos responsabilités en vertu de la loi HIPAA, consultez la section Loi HIPAA – Conformité.

D'autres secteurs (par exemple, la finance ou l'industrie) appliquent également des réglementations qui définissent la façon dont les données peuvent être collectées, traitées et stockées. Pour en savoir plus sur la responsabilité partagée dans ces cas-là et sur la manière dont Google Cloud respecte nos responsabilités, consultez la page Centre de ressources pour la conformité.

Défini par l'emplacement

Selon votre scénario d'entreprise, vous devrez peut-être prendre en compte vos responsabilités en fonction de l'emplacement de vos bureaux, de vos clients et de vos données. Plusieurs pays et régions ont créé des réglementations indiquant comment traiter et stocker les données de vos clients. Par exemple, si votre entreprise dispose de clients qui résident dans l'Union européenne, elle peut être amenée à respecter les exigences décrites dans le Règlement général sur la protection des données (RGPD) et vous pourriez être tenu de conserver vos données client dans l'UE. Dans ce cas, vous devez vous assurer que les données que vous collectez restent dans les régions Google Cloud de l'UE. Pour en savoir plus sur le respect de nos obligations liées au RGPD, consultez la page RGPD et Google Cloud.

Pour en savoir plus sur les exigences liées à votre région, consultez la section Offres de conformité. Si votre scénario est particulièrement complexe, nous vous recommandons de contacter notre équipe commerciale ou l'un de nos partenaires pour vous aider à évaluer vos responsabilités liées à la sécurité.

Défis liés à la responsabilité partagée

Bien que la responsabilité partagée permet de définir les rôles de sécurité dont vous ou le fournisseur cloud disposez, l'exploitation de la responsabilité partagée peut toujours constituer un défi. Étudions les cas de figure suivants :

• La plupart des brèches de sécurité dans le cloud sont le résultat direct d'une mauvaise configuration (définie en tant que numéro 3 dans le rapport 11 sur la pandémie de Cloud Security Alliance), et cette tendance devrait augmenter. Les produits cloud sont en constante évolution, et de nouveaux produits sont constamment lancés. S'adapter aux changements constants peut sembler fastidieux. Les clients ont besoin de fournisseurs cloud pour leur fournir des bonnes pratiques recommandées afin de se tenir au courant des changements, en commençant par les bonnes pratiques par défaut et en établissant une configuration sécurisée de référence.
• Même si la division des éléments entre les services cloud est utile, de nombreuses entreprises ont des charges de travail qui nécessitent plusieurs types de services cloud. Dans ce cas, vous devez examiner les interactions entre les différents contrôles de sécurité de ces services, y compris leur éventuel chevauchement entre les services. Par exemple, vous pouvez avoir une application sur site que vous migrez vers Compute Engine, utiliser Google Workspace pour la messagerie professionnelle, et exécuter BigQuery pour analyser les données afin d'améliorer vos produits.
• Votre entreprise et vos marchés évoluent en permanence, à mesure que la réglementation évolue, que vous pénétrez de nouveaux marchés ou que vous acquérez d'autres entreprises. Vos nouveaux marchés peuvent avoir des exigences différentes, et vos nouvelles acquisitions peuvent héberger les charges de travail sur un autre cloud. Pour gérer les changements constants, vous devez réévaluer en permanence votre profil de risque et être capable de mettre en œuvre rapidement de nouveaux contrôles.
• La façon dont vous gérez les clés de chiffrement de vos données est une décision importante à prendre en compte pour protéger vos données. L'option que vous choisissez dépend de vos exigences réglementaires, que vous exécutiez un environnement cloud hybride ou que vous disposiez toujours d'un environnement sur site, et de la sensibilité des données que vous traitez et stockez.
• La gestion des incidents est un domaine important et souvent négligé, dans lequel vos responsabilités et celles du fournisseur cloud ne sont pas facilement définies. De nombreux incidents nécessitent une collaboration étroite et une assistance de la part du fournisseur cloud si vous souhaitez les examiner et les limiter. D'autres incidents peuvent être dus à une mauvaise configuration des ressources cloud ou au vol d'identifiants, et les bonnes pratiques liées à la sécurisation de vos ressources et de vos comptes peuvent être difficiles à suivre
• Les menaces persistantes avancées et les nouvelles failles peuvent avoir une incidence inattendue sur vos charges de travail lorsque vous démarrez votre transformation cloud. Il est difficile de rester informé de l'évolution du paysage et de savoir qui est responsable de l'atténuation des menaces, en particulier si votre entreprise ne dispose pas d'une large équipe de sécurité.

Partage de sort

Nous avons développé le partage de sort dans Google Cloud pour commencer à relever les défis que le modèle de responsabilité partagée ne résout pas. Le partage de sort consiste à permettre à toutes les parties d'interagir plus efficacement afin d'améliorer continuellement la sécurité. Le partage de sort s'appuie sur le modèle de responsabilité partagée, car il considère la relation entre le fournisseur cloud et le client comme un partenariat continu pour améliorer la sécurité.

Le partage de sort consiste à assumer nos responsabilités concernant la sécurité de Google Cloud. Le partage de sort vous permet de commencer à utiliser une zone de destination sécurisée, et d'être clair, ferme, et transparent sur les contrôles de sécurité, ainsi que sur les paramètres et les bonnes pratiques associées. Il vous aide à quantifier et à gérer les risques avec la cyberassurance, grâce à Risk Protection Program. Avec le partage de sort, nous souhaitons faire passer le framework de responsabilité partagée standard au niveau supérieur afin de vous aider à mieux sécuriser votre entreprise et à développer la confiance dans Google Cloud.

Les sections suivantes décrivent divers composants du partage de sort.

Aide à la mise en route

Les ressources que nous fournissons pour vous aider à démarrer dans une configuration sécurisée au sein de Google Cloud constituent un élément clé du partage de sort. Commencer par une configuration sécurisée permet de réduire le problème des erreurs de configuration, qui est la cause principale de la plupart des brèches de sécurité.

Nos ressources peuvent inclure les éléments suivants :

• Le plan de base d'entreprise, qui englobe les principaux problèmes de sécurité et nos recommandations les plus importantes.

• Les plans sécurisés, qui vous permettent de déployer et de gérer des solutions sécurisées via Infrastructure as Code (IaC) Les recommandations de sécurité des plans sont activées par défaut. De nombreux plans sont créés par les équipes de sécurité de Google et gérés en tant que produits. Cela signifie qu'ils sont régulièrement mis à jour, qu'ils sont soumis à un processus de test rigoureux et qu'ils reçoivent des attestations de la part de groupes de tests tiers. Les plans incluent les éléments suivants : plan de base d'entreprise, plan d'entrepôt de données sécurisé et plan des notebooks Vertex AI Workbench.

• Bonnes pratiques liées au framework d'architecture traitant des principales recommandations pour intégrer la sécurité à vos conceptions. Le framework d'architecture comprend une section sur la sécurité et une zone communautaire qui vous permettent de communiquer avec des experts et des pairs.

• Les guides de navigation des zones de destination vous guident dans les principales décisions que vous devez prendre pour créer une base sécurisée pour vos charges de travail, y compris la hiérarchie des ressources, l'intégration des identités, la gestion de la sécurité et des clés, ainsi que la structure du réseau.

Risk Protection Program

Le partage de sort inclut également Risk Protection Program (actuellement en version bêta), qui vous aide à utiliser la puissance de Google Cloud en tant que plate-forme de gestion des risques, plutôt que de considérer les charges de travail cloud comme d'autres sources de risques à gérer. Risk Protection Program est le fruit de la collaboration entre Google Cloud et deux grandes entreprises de cyberassurance, Munich Re et Allianz Global & Corporate Speciality.

Risk Protection Program comprend Risk Manager, qui fournit des insights basés sur les données qui peuvent vous servir à mieux comprendre votre stratégie de sécurité dans le cloud. Si vous cherchez à souscrire une cyberassurance, vous pouvez partager les insights générés par Risk Manager directement avec nos partenaires assureurs afin d'obtenir un devis. Pour en savoir plus, consultez la page Risk Protection Program de Google Cloud actuellement en version bêta.

Aide concernant le déploiement et la gouvernance

Le partage de sort contribue également à la gouvernance continue de votre environnement. Par exemple, nous nous concentrons sur les produits suivants :

• Assured Workloads, qui vous aide à respecter vos obligations réglementaires.
• Security Command Center Premium, qui utilise les renseignements sur les menaces, la détection des menaces, l'analyse Web et d'autres méthodes avancées dans le but de surveiller et de détecter les menaces. Cette solution permet également de résoudre rapidement et automatiquement de nombreuses menaces.
• Les règles d'administration et les paramètres de ressources vous permettent de configurer des stratégies à travers l'ensemble de votre hiérarchie de dossiers et de projets.
• Les outils Policy Intelligence, qui fournissent des insights sur l'accès aux comptes et aux ressources.
• L'informatique confidentielle, qui permet de chiffrer les données utilisées.
• Sovereign Cloud, disponible en Allemagne et mettant en œuvre des exigences en termes de résidence des données.

Appliquer la responsabilité partagée et le partage de sort

Lors de votre processus de planification, envisagez les actions suivantes pour vous aider à comprendre et à mettre en œuvre des contrôles de sécurité appropriés :

• Créez une liste des types de charges de travail que vous hébergez dans Google Cloud et indiquez si elles nécessitent les services IaaS, PaaS et SaaS. Vous pouvez utiliser le schéma de responsabilité partagée pour vous assurer que vous connaissez les contrôles de sécurité à prendre en compte.
• Créez une liste d'exigences réglementaires à respecter et accédez aux ressources du Centre de ressources pour la conformité associées à ces exigences.
• Consultez la liste des plans et architectures disponibles dans le Centre d'architecture pour connaître les contrôles de sécurité requis pour vos charges de travail particulières. Les plans fournissent une liste de commandes recommandées et le code IaC nécessaire au déploiement de cette architecture.
• Utilisez la documentation sur les zones de destination et les recommandations du guide sur les principes de base de l'entreprise pour concevoir une hiérarchie de ressources et une architecture réseau conformes à vos exigences. Vous pouvez utiliser les plans de charge de travail avisés, comme l'entrepôt de données sécurisé, pour accélérer votre processus de développement.
• Après avoir déployé vos charges de travail, vérifiez que vous répondez à vos responsabilités de sécurité à l'aide de services tels que Risk Manager, Assured Workloads, les outils Policy Intelligence et Security Command Center Premium.

Pour en savoir plus, consultez le guide du RSSI sur la transformation cloud.

Étape suivante

• Passez en revue les principes de sécurité (document suivant de cette série).
• Tenez-vous informé des ressources de partage de sort.
• Familiarisez-vous avec les plans disponibles, y compris avec le plan de base de sécurité et les exemples de charges de travail, comme l'entrepôt de données sécurisé.
• En savoir plus sur le partage de sort
• Pour en savoir plus sur notre infrastructure sécurisée sous-jacente, consultez la présentation de la sécurité sur l'infrastructure de Google.
• Découvrez comment mettre en œuvre les bonnes pratiques du CyberSecurity Framework du National Institute of Standards and Technology (NIST) dans Google Cloud (PDF).

Principes de sécurité

Le présent document du framework d'architecture Google Cloud explique les principes de base pour exécuter des services sécurisés et conformes sur Google Cloud. La plupart des principes de sécurité que vous connaissez déjà dans votre environnement sur site s'appliquent aux environnements cloud.

Créer une approche multicouche de la sécurité

Mettez en œuvre la sécurité à chaque niveau de votre application et de votre infrastructure en appliquant une approche de défense en profondeur. Utilisez les fonctionnalités de chaque produit pour limiter l'accès et configurer le chiffrement le cas échéant.

Concevoir des systèmes découplés sécurisés

Simplifiez la conception du système pour plus de flexibilité et documentez les exigences de sécurité pour chaque composant. Intégrez un mécanisme sécurisé et robuste pour tenir compte de la résilience et de la reprise après sinistre.

Automatiser le déploiement des tâches sensibles

Libérez vos développeurs du flux de travail en automatisant les déploiements et d'autres tâches d'administration.

Surveillance automatique de sécurité

Surveillez votre application et votre infrastructure à l'aide d'outils automatisés. Pour rechercher les failles et détecter les incidents de sécurité dans votre infrastructure, utilisez l'analyse automatisée dans vos pipelines d'intégration continue et de déploiement continu (CI/CD).

Satisfaire les exigences de conformité pour vos régions

Sachez que vous devrez peut-être masquer des informations personnelles pour répondre à vos exigences réglementaires. Dans la mesure du possible, automatisez vos efforts de conformité. Par exemple, utilisez la protection des données sensibles et Dataflow pour automatiser le masquage des informations personnelles avant que les nouvelles données ne soient stockées dans le système.

Respecter les exigences de résidence et de souveraineté des données

Vous pouvez avoir des exigences internes (ou externes) qui vous obligent à contrôler les emplacements de stockage et de traitement des données. Ces exigences varient en fonction des objectifs de conception des systèmes, de la réglementation du secteur, du droit national, des implications fiscales et de la culture. La résidence des données décrit l'emplacement de stockage de vos données. Pour vous aider à respecter les exigences de résidence des données, Google Cloud vous permet de contrôler l'emplacement de stockage des données, leur mode d'accès et leur traitement.

Déplacer la sécurité en amont

Le DevOps et l'automatisation du déploiement permettent à votre organisation d'accélérer la livraison de produits. Pour garantir la sécurité de vos produits, intégrez des processus de sécurité dès le début du processus de développement. Par exemple, vous pouvez effectuer les opérations suivantes :

• Rechercher les failles de sécurité dans le code aussi tôt que possible dans le pipeline de déploiement.
• Analyser les images de conteneurs et l'infrastructure cloud de manière continue.
• Automatiser la détection des erreurs de configuration et des anti-modèles de sécurité. Par exemple, utilisez l'automatisation pour rechercher des secrets codés en dur dans les applications ou dans la configuration.

Étape suivante

Découvrez les principes de base de la sécurité avec les ressources suivantes :

• Gérer les risques avec des contrôles (document suivant de cette série)
• Plan de base d'entreprise de Google Cloud
• Document sur la sécurité de Google
• Conception de la sécurité dans l'infrastructure de Google
• Créer un processus collaboratif de gestion des incidents
• Plans déployables par secteur

Gérer les risques à l'aide de contrôles

Ce document du framework d'architecture de Google Cloud décrit les bonnes pratiques de gestion des risques dans un déploiement cloud. L'analyse approfondie des risques qui s'appliquent à votre organisation vous permet de déterminer les contrôles de sécurité requis. Vous devez effectuer une analyse des risques avant de déployer des charges de travail sur Google Cloud, puis régulièrement en fonction des besoins de votre entreprise, des exigences réglementaires et des menaces qui affectent votre organisation.

Identifier les risques pour votre organisation

Avant de créer et de déployer des ressources sur Google Cloud, effectuez une évaluation des risques afin de déterminer les fonctionnalités de sécurité dont vous avez besoin pour répondre à vos exigences de sécurité internes et à vos exigences réglementaires externes. L'évaluation des risques vous fournit un catalogue des risques pertinents pour vous et vous indique votre capacité à détecter et contrer les menaces de sécurité.

Les risques dans un environnement cloud diffèrent de ceux dans un environnement sur site en raison de l'accord de responsabilité partagée que vous passez avec votre fournisseur cloud. Par exemple, dans un environnement sur site, vous devez limiter les failles de la pile matérielle. En revanche, dans un environnement cloud, ces risques viennent du fournisseur cloud.

En outre, vos risques varient selon la manière dont vous envisagez d'utiliser Google Cloud. Transférez-vous certaines de vos charges de travail vers Google Cloud, ou toutes ? Utilisez-vous Google Cloud uniquement à des fins de reprise après sinistre ? Configurez-vous un environnement cloud hybride ?

Nous vous recommandons d'utiliser un framework d'évaluation des risques standard dans l'industrie, qui s'applique aux environnements cloud et à vos exigences réglementaires. Par exemple, la Cloud Security Alliance (CSA) fournit la matrice des contrôles cloud (CCM). En outre, il existe des modèles de menace, tels que la modélisation des menaces d'application OWASP, qui fournissent une liste de lacunes potentielles et suggèrent des actions pour corriger ces failles. Vous pouvez consulter notre annuaire des partenaires pour obtenir la liste des experts qui évaluent les risques pour Google Cloud.

Pour vous aider à cataloguer vos risques, envisagez d'utiliser Risk Manager, qui fait partie du Risk Protection Program. (Ce programme est actuellement disponible en version bêta.) Risk Manager analyse vos charges de travail pour vous aider à comprendre les risques liés à votre entreprise. Ses rapports détaillés fournissent une référence de sécurité. Vous pouvez également utiliser les rapports de Risk Manager pour comparer les risques par rapport aux risques décrits dans le benchmark CIS (Center for Internet Security).

Après avoir catalogué vos risques, vous devez déterminer comment les corriger, c'est-à-dire si vous souhaitez les accepter, les éviter, les transférer ou les limiter. La section suivante décrit les contrôles de limites.

Limiter vos risques

Vous pouvez limiter les risques à l'aide de contrôles techniques, de protections contractuelles et d'attestations ou de vérifications tierces. Le tableau suivant répertorie comment limiter ces risques lorsque vous adoptez de nouveaux services de cloud public.

Atténuation	Description
Contrôles techniques	Les contrôles techniques désignent les fonctionnalités et technologies qui vous permettent de protéger votre environnement. Celles-ci incluent des contrôles de sécurité cloud intégrés, tels que les pare-feu et la journalisation. Les contrôles techniques peuvent également inclure l'utilisation d'outils tiers pour renforcer ou soutenir votre stratégie de sécurité. Il existe deux catégories de contrôles techniques : Google Cloud comprend divers contrôles de sécurité pour vous permettre de limiter les risques qui vous concernent. Par exemple, si vous disposez d'un environnement sur site, vous pouvez utiliser Cloud VPN et Cloud Interconnect pour sécuriser la connexion entre votre environnement sur site et vos ressources cloud. Google a mis en place des contrôles internes et des audits rigoureux pour se protéger contre les accès d'initiés aux données client. Nos journaux d'audit fournissent à nos clients des journaux en temps quasi réel sur l'accès administrateur à Google sur Google Cloud.
Protections contractuelles	Les protections contractuelles désignent les engagements juridiques que nous avons pris concernant les services Google Cloud. Google Cloud s'engage à maintenir et à développer notre portefeuille de solutions de conformité. Le document Avenant relatif au traitement des données dans le cloud (ATDC) définit notre engagement à maintenir nos certifications ISO 27001, 27017 et 27018, ainsi qu'à mettre à jour nos rapports SOC 2 et SOC 3 tous les 12 mois. Le document DPST décrit également les contrôles mis en place pour limiter l'accès des ingénieurs de l'assistance Google aux environnements des clients. Il décrit notre journalisation rigoureuse. et au processus d'approbation. Nous vous recommandons de consulter les contrôles contractuels de Google Cloud avec vos experts juridiques et réglementaires, et de vérifier qu'ils répondent à vos exigences. Pour en savoir plus, contactez votre responsable de compte technique.
Vérifications ou attestations tierces	Les validations ou attestations tierces consistent à demander à un fournisseur tiers d'effectuer un audit du fournisseur cloud pour s'assurer qu'il répond aux exigences de conformité. Par exemple, Google a fait l'objet d'un audit réalisé par un tiers afin de vérifier sa conformité avec la norme ISO 27017. Vous pouvez consulter les certifications et les lettres d'attestation Google Cloud actuelles dans le Centre de ressources pour la conformité.

Étape suivante

Pour en savoir plus sur la gestion des risques, consultez les ressources suivantes :

• Gérez vos assets (document suivant de cette série)

• Risk Protection Program

• Centre de ressources pour la conformité

• Gouvernance des risques de la transformation numérique dans le cloud (PDF)

Gérer vos éléments

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques à suivre pour la gestion des actifs.

La gestion des actifs est un élément important de l'analyse des besoins de votre entreprise. Vous devez avoir une excellente compréhension de vos actifs, de leur valeur et des chemins ou processus critiques qui s'y rapportent. Vous devez disposer d'un inventaire précis des actifs avant de pouvoir concevoir le moindre contrôle de sécurité visant à les protéger.

Pour gérer les incidents de sécurité et répondre aux exigences réglementaires de votre organisation, vous avez besoin d'un inventaire précis et à jour des actifs, avec un moyen d'analyser les données historiques de cet inventaire. Vous devez être en mesure de suivre vos actifs, y compris l'évolution de leur exposition au risque au fil du temps.

Le passage à Google Cloud signifie que vous devez modifier vos processus de gestion des actifs pour vous adapter à un environnement cloud. Par exemple, l'un des avantages du passage au cloud est que vous augmentez la capacité de votre entreprise à évoluer rapidement. Toutefois, la possibilité d'évoluer rapidement peut entraîner des problèmes informatiques fantômes lorsque vos employés créent des ressources cloud qui ne sont pas correctement gérées et sécurisées. Par conséquent, vos processus de gestion des actifs doivent offrir une flexibilité suffisante aux employés pour leur permettre d'effectuer leur travail, tout en intégrant des contrôles de sécurité appropriés.

Utiliser les outils cloud de gestion des actifs

Les outils de gestion des actifs Google Cloud sont spécialement adaptés à notre environnement et aux principaux cas d'utilisation de nos clients.

L'un de ces outils est l'inventaire des éléments cloud, qui fournit des informations en temps réel sur l'état actuel de vos actifs ainsi qu'un historique sur cinq semaines. Grâce à ce service, vous pouvez obtenir un instantané de votre inventaire à l'échelle de l'organisation pour une grande variété de ressources et de règles Google Cloud. Les outils d'automatisation peuvent ensuite se servir de cet instantané pour la surveillance, l'application de règles ou l'archivage à des fins d'audit de conformité. Si vous souhaitez analyser les modifications apportées à des actifs, l'inventaire des éléments cloud permet également d'exporter l'historique des métadonnées.

Pour en savoir plus sur l'inventaire des éléments cloud, consultez les pages Solution personnalisée pour répondre à des modifications d'éléments et Contrôles de détection.

Gestion automatisée des actifs

L'automatisation vous permet de créer et de gérer rapidement des actifs en fonction des exigences de sécurité que vous spécifiez. Vous pouvez automatiser les aspects du cycle de vie des actifs de différentes manières :

• Déployez votre infrastructure cloud à l'aide d'outils d'automatisation tels que Terraform. Google Cloud fournit un plan de base d'entreprise qui vous aide à configurer des ressources d'infrastructure conformes aux bonnes pratiques de sécurité. De plus, il configure des notifications pour les modifications d'actifs et la conformité dans l'inventaire des éléments cloud.
• Déployez vos applications en utilisant des outils d'automatisation tels que Cloud Run et Artifact Registry.

Surveiller les manquements aux règles de conformité

Des manquements aux règles peuvent se produire pendant toutes les phases du cycle de vie des actifs. Par exemple, les actifs peuvent être créés sans les contrôles de sécurité appropriés, ou leurs privilèges peuvent être trop élevés. De même, les actifs peuvent être abandonnés sans que les procédures de fin de vie appropriées ne soient appliquées.

Pour éviter ces scénarios, nous vous recommandons de surveiller les actifs pour détecter les manquements aux règles de conformité. L'ensemble d'actifs que vous surveillez dépend des résultats de votre évaluation des risques et de vos exigences commerciales. Pour en savoir plus sur la surveillance des actifs, consultez la section Surveiller les modifications d'actifs.

Intégrer GCP à vos systèmes existants de surveillance de la gestion des actifs

Si vous utilisez déjà un système SIEM ou un autre système de surveillance, intégrez vos actifs Google Cloud à ce système. L'intégration garantit que votre organisation dispose d'une vue unifiée et complète de l'ensemble des ressources, quel que soit l'environnement. Pour en savoir plus, consultez les pages Exporter des données de sécurité Google Cloud vers votre système SIEM et Scénarios d'exportation de données Cloud Logging : Splunk.

Enrichir votre surveillance à l'aide de l'analyse de données

Vous pouvez exporter votre inventaire vers une table BigQuery ou un bucket Cloud Storage à des fins d'analyse supplémentaire.

Étapes suivantes

Pour en savoir plus sur la gestion de vos actifs, consultez les ressources suivantes :

• Gérer l'identité et l'accès (document suivant de cette série)
• Gestion des ressources
• Conception du système

Gérer l'identité et l'accès

Ce document du framework d'architecture de Google Cloud décrit les bonnes pratiques de gestion des identités et des accès.

La gestion de l'authentification et des accès (généralement appelée IAM, Identity and Access Management) vous permet de vous assurer que les bonnes personnes peuvent accéder aux bonnes ressources. IAM aborde les aspects suivants concernant l'authentification et l'autorisation :

• Gestion des comptes, y compris provisionnement
• Gouvernance des identités
• Authentification
• Contrôle des accès (autorisation)
• Fédération d'identité

La gestion d'IAM peut s'avérer difficile lorsque vous avez des environnements différents ou si vous utilisez plusieurs fournisseurs d'identité. Cependant, il est essentiel de configurer un système capable de répondre aux exigences de votre entreprise tout en limitant les risques.

Les recommandations de ce document vous aident à examiner vos stratégies et procédures IAM actuelles, et à déterminer celles que vous devrez peut-être modifier pour vos charges de travail dans Google Cloud. Par exemple, vous devez examiner les éléments suivants :

• Si vous pouvez gérer l'accès à l'aide de groupes existants ou en créer de nouveaux.
• Vos exigences d'authentification (telles que l'authentification multifacteur (MFA) à l'aide d'un jeton).
• L'impact des comptes de service sur vos stratégies actuelles.
• Si vous utilisez Google Cloud pour la reprise après sinistre, maintenez la séparation des tâches appropriée.

Dans Google Cloud, vous utilisez Cloud Identity pour authentifier vos utilisateurs et vos ressources, ainsi que le produit Identity and Access Management (IAM) de Google pour déterminer l'accès aux ressources. Les administrateurs peuvent limiter l'accès au niveau de l'organisation, du dossier, du projet et de la ressource. Les stratégies Google IAM déterminent qui peut faire quoi sur quelles ressources. Correctement configurées, les stratégies IAM vous permettent de sécuriser votre environnement en empêchant tout accès non autorisé aux ressources.

Pour en savoir plus, consultez la page Présentation de la gestion de l'authentification et des accès.

Utiliser un seul fournisseur d'identité

De nombreux clients possèdent des comptes utilisateur gérés et provisionnés par des fournisseurs d'identité en dehors de Google Cloud. Google Cloud est compatible avec la fédération avec la plupart des fournisseurs d'identité et avec des annuaires sur site tels qu'Active Directory.

La plupart des fournisseurs d'identité vous permettent d'activer l'authentification unique (SSO, Single Sign-On) pour vos utilisateurs et vos groupes. Pour les applications que vous déployez sur Google Cloud et qui utilisent votre fournisseur d'identité externe, vous pouvez étendre votre fournisseur d'identité à Google Cloud. Pour en savoir plus, consultez les pages Architectures de référence et Modèles pour l'authentification des utilisateurs d'entreprise dans un environnement hybride.

Si vous ne disposez d'aucun fournisseur d'identité, vous pouvez utiliser Cloud Identity Premium ou Google Workspace afin de gérer les identités pour vos employés.

Protéger le compte super-administrateur

Le compte super-administrateur (géré par Google Workspace ou Cloud Identity) vous permet de créer votre organisation Google Cloud. Ce compte administrateur est donc hautement privilégié. Les bonnes pratiques concernant ce compte sont les suivantes :

• Créez un compte spécifique à cet effet ; n'utilisez pas de compte utilisateur existant.
• Créer et protéger des comptes de sauvegarde
• Activez l'authentification multifacteur.

Pour plus d'informations, consultez les bonnes pratiques concernant les comptes super-administrateur.

Planifier l'utilisation des comptes de service

Un compte de service est un compte Google qui permet aux applications d'appeler l'API Google d'un service.

Contrairement à vos comptes utilisateur, les comptes de service sont créés et gérés dans Google Cloud. Les comptes de service s'authentifient également différemment des comptes utilisateur :

• Pour permettre à une application exécutée sur Google Cloud de s'authentifier à l'aide d'un compte de service, vous pouvez associer un compte de service à la ressource de calcul sur laquelle l'application s'exécute.
• Pour permettre à une application exécutée sur GKE de s'authentifier à l'aide d'un compte de service, vous pouvez utiliser Workload Identity.
• Pour permettre aux applications qui s'exécutent en dehors de Google Cloud de s'authentifier à l'aide d'un compte de service, vous pouvez utiliser la fédération d'identité de charge de travail.

Lorsque vous utilisez des comptes de service, vous devez envisager une séparation des tâches appropriée lors du processus de conception. Notez les appels d'API que vous devez effectuer, et déterminez les comptes de service et les rôles associés requis par les appels d'API. Par exemple, si vous configurez un entrepôt de données BigQuery, vous aurez probablement besoin d'identités pour au moins les processus et services suivants :

• Cloud Storage ou Pub/Sub, selon que vous fournissez un fichier par lots ou créez un service de streaming.
• Dataflow et la protection des données sensibles pour anonymiser les données sensibles.

Si vous souhaitez en savoir plus, consultez Bonnes pratiques d'utilisation des comptes de service.

Mettre à jour vos processus d'identité pour le cloud

La gouvernance des identités vous permet de suivre les accès, les risques et les cas de non-respect des règles afin de répondre à vos exigences réglementaires. Cette gouvernance nécessite que vous mettiez en place des processus et des stratégies pour que vous puissiez accorder et auditer les rôles et autorisations d'accès aux utilisateurs. Vos processus et règles doivent répondre aux exigences de vos environnements, par exemple, test, développement et production.

Avant de déployer des charges de travail sur Google Cloud, examinez vos processus d'identité actuels et mettez-les à jour si nécessaire. Assurez-vous de planifier correctement les types de comptes dont votre organisation a besoin, et de bien comprendre ses rôles et ses exigences d'accès.

Pour vous aider à auditer les activités Google IAM, Google Cloud crée des journaux d'audit qui incluent les éléments suivants :

• Activité d'administration. Il est impossible de désactiver cette journalisation.
• Activité d'accès aux données. Vous devez activer cette journalisation.

Si nécessaire, ou si vous souhaitez configurer une analyse des journaux (par exemple, avec votre système SIEM), vous pouvez exporter les journaux. Étant donné que les journaux peuvent augmenter vos besoins en stockage, ils peuvent affecter vos coûts. Veillez à n'enregistrer que les actions requises et à définir des calendriers de conservation appropriés.

Configurer l'authentification unique et l'authentification multifacteur

Votre fournisseur d'identité gère l'authentification des comptes utilisateur. Les identités fédérées peuvent s'authentifier auprès de Google Cloud à l'aide de l'authentification unique. Pour les comptes privilégiés, tels que les super-administrateurs, vous devez configurer l'authentification multifacteur. Les clés de sécurité Titan sont des jetons physiques que vous pouvez utiliser pour l'authentification à deux facteurs (2FA) afin de prévenir les attaques par hameçonnage.

Cloud Identity est compatible avec MFA à l'aide de diverses méthodes. Pour plus d'informations, consultez la section Appliquer la MFA de manière uniforme aux ressources de l'entreprise.

Google Cloud est compatible avec l'authentification pour les identités de charge de travail à l'aide du protocole OAuth 2.0 ou des jetons Web JSON (JWT) signés. Pour en savoir plus sur l'authentification des charges de travail, consultez la page Présentation de l'authentification.

Mettre en œuvre le principe du moindre privilège et de la séparation des tâches

Vous devez vous assurer que les bonnes personnes n'accèdent qu'aux ressources et services dont elles ont besoin pour effectuer leurs tâches. Autrement dit, vous devez suivre le principe du moindre privilège. De plus, vous devez vous assurer qu'il existe une séparation des tâches appropriée.

Le surprovisionnement des accès utilisateur peut accroître le risque de menace interne, de ressources mal configurées et de non-conformité avec les audits. L'accord d'autorisations insuffisantes peut empêcher les utilisateurs d'accéder aux ressources dont ils ont besoin pour effectuer leurs tâches.

Une façon d'éviter le surprovisionnement consiste à mettre en œuvre un accès privilégié juste à temps, c'est-à-dire à ne fournir un accès privilégié que si nécessaire, et de n'accorder l'accès que temporairement.

Sachez que lorsqu'une organisation Google Cloud est créée, les rôles de créateur de compte de facturation et de créateur de projet sont attribués par défaut à tous les utilisateurs de votre domaine. Identifiez les utilisateurs qui effectueront ces tâches et révoquez ces rôles pour les autres utilisateurs. Pour plus d'informations, consultez la page Créer et gérer des organisations.

Pour en savoir plus sur le fonctionnement des rôles et des autorisations dans Google Cloud, consultez les pages Présentation et Comprendre les rôles de la documentation IAM. Pour plus d'informations sur l'application du moindre privilège, consultez la section Appliquer le principe du moindre privilège avec les recommandations de rôle.

Accès d'audit

Pour surveiller les activités des comptes privilégiés afin de détecter les écarts par rapport aux conditions approuvées, utilisez Cloud Audit Logs. Cloud Audit Logs enregistre les actions effectuées par les membres de votre organisation Google Cloud dans vos ressources Google Cloud. Vous pouvez utiliser différents types de journaux d'audit pour les services Google. Pour en savoir plus, consultez la page Utiliser des journaux d'audit Cloud pour gérer les risques internes (vidéo).

Utilisez l'outil de recommandation Cloud IAM pour suivre l'utilisation et ajuster les autorisations le cas échéant. Les rôles recommandés par l'outil de recommandation IAM peuvent vous aider à déterminer les rôles à attribuer à un utilisateur en fonction de son comportement passé et d'autres critères. Pour en savoir plus, consultez la page Bonnes pratiques pour les recommandations de rôles.

Pour contrôler l'accès à vos ressources par le personnel d'assistance et l'ingénierie de Google, vous pouvez utiliser Access Transparency. Access Transparency enregistre les actions effectuées par le personnel de Google. Utilisez Access Approval, qui fait partie d'Access Transparency, pour accorder une approbation explicite à chaque accès au contenu du client. Pour en savoir plus, consultez la page Contrôler l'accès des administrateurs cloud à vos données.

Automatiser vos contrôles de règles

Définissez les autorisations d'accès de manière automatisée dans la mesure du possible. Pour connaître les bonnes pratiques, consultez la page Contraintes liées aux règles d'administration. Les scripts Terraform pour le plan de base d'entreprise se trouvent dans l'exemple de dépôt de base.

Google Cloud inclut Policy Intelligence, qui vous permet d'examiner et de mettre à jour automatiquement vos autorisations d'accès. Policy Intelligence inclut les outils de l'outil de recommandation, Policy Troubleshooter et Policy Analyzer qui effectuent les opérations suivantes :

• Fournir des recommandations pour l'attribution de rôle IAM
• Surveiller et éviter les stratégies IAM trop permissives
• Résoudre les problèmes liés au contrôle des accès.

Définir des restrictions sur les ressources

Google IAM se concentre sur la réponse à la question qui et vous permet d'autoriser une personne à agir sur des ressources spécifiques en fonction des autorisations. Le service de règles d'administration se concentre sur la réponse à la question quoi et vous permet de définir des restrictions sur les ressources pour spécifier leur configuration. Par exemple, vous pouvez utiliser une règle d'administration pour effectuer les opérations suivantes :

• Limiter le partage des ressources en fonction du domaine.
• Limiter l'utilisation des comptes de service.
• Limiter l'emplacement physique des ressources nouvellement créées.

En plus d'utiliser des règles d'administration pour ces tâches, vous pouvez restreindre l'accès aux ressources via l'une des méthodes suivantes :

• Utilisez des tags pour gérer l'accès à vos ressources sans définir les autorisations d'accès sur chaque ressource. Vous devez ajouter le tag, puis définir la définition d'accès pour le tag lui-même.
• Utilisez les conditions IAM pour effectuer un contrôle conditionnel des accès aux ressources basé sur des attributs.
• Mettez en œuvre la défense en profondeur en utilisant VPC Service Controls pour restreindre davantage l'accès aux ressources.

Pour en savoir plus sur la gestion des ressources, consultez la page Gestion des ressources.

Étape suivante

Pour en savoir plus sur IAM, consultez les ressources suivantes :

• Mettre en œuvre la sécurité des ressources de calcul et des conteneurs (document suivant de cette série)

• Utiliser Cloud IAM en toute sécurité

• Architectures de référence

• Outil de recommandation IAM : moindre privilège avec moins d'efforts

• Confidentialité des données cloud

• Présentation de la gestion de l'authentification et des accès

Mettre en œuvre la sécurité des ressources de calcul et des conteneurs

Google Cloud comprend des contrôles permettant de protéger vos ressources de calcul et vos ressources de conteneurs Google Kubernetes Engine (GKE). Le présent document du framework d'architecture Google Cloud décrit les principaux contrôles et les bonnes pratiques pour leur utilisation.

Utiliser des images de VM renforcées et sélectionnées

Google Cloud inclut une VM protégée, qui vous permet de renforcer vos instances de VM. Les VM protégées sont conçues pour empêcher le chargement de code malveillant pendant le cycle de démarrage. Elles garantissent la sécurité du démarrage, vérifient l'intégrité et utilisent le module vTPM (Virtual Trusted Platform Module). Utilisez des VM protégées pour les charges de travail sensibles.

En plus d'utiliser des VM protégées, vous pouvez utiliser des solutions partenaires Google Cloud pour mieux protéger vos VM. De nombreuses solutions partenaires proposées sur Google Cloud s'intègrent à Security Command Center, qui fournit une détection des menaces et une surveillance d'état. Vous pouvez faire appel à des partenaires pour bénéficier d'une analyse avancée des menaces ou d'une meilleure sécurité de l'environnement d'exécution.

Utilisez l'informatique confidentielle pour traiter les données sensibles.

Par défaut, Google Cloud chiffre les données au repos et en transit sur le réseau, mais les données ne sont pas chiffrées lorsqu'elles sont utilisées en mémoire. Si votre organisation gère des données confidentielles, vous devez limiter les menaces qui compromettent la confidentialité et l'intégrité de l'application ou des données stockées dans la mémoire système. Les données confidentielles incluent les informations personnelles, financières et médicales.

L'informatique confidentielle est basée sur les VM protégées. Elle protège les données utilisées en effectuant les calculs dans un environnement d'exécution approuvé au niveau de la couche matérielle. Ce type d'environnement sécurisé et isolé permet d'empêcher toute modification ou tout accès non autorisé aux applications et aux données pendant l'utilisation des données. Un environnement d'exécution de confiance offre également une garantie de sécurité pour les organisations qui gèrent des données sensibles et réglementées.

Dans Google Cloud, vous pouvez activer l'informatique confidentielle en utilisant des VM Confidential VMs ou des nœuds Confidential GKE Nodes. Activez l'informatique confidentielle si vous traitez des charges de travail confidentielles ou si vous disposez de données confidentielles (par exemple, des secrets) qui doivent être exposées pendant leur traitement. Pour en savoir plus, consultez le Confidential Computing Consortium.

Protéger les VM et les conteneurs

OS Login permet à vos employés de se connecter à vos VM en utilisant des autorisations Identity and Access Management (IAM) en tant que source de vérité plutôt que des clés SSH. Vous n'avez donc pas besoin de gérer les clés SSH dans votre organisation. OS Login permet de lier l'accès administrateur au cycle de vie de l'employé, ce qui signifie que si un employé change de rôle ou quitte votre organisation, son accès est révoqué avec son compte. OS Login est également compatible avec l'authentification à deux facteurs, qui ajoute une couche de sécurité supplémentaire contre les attaques par piratage de compte.

Dans GKE, App Engine exécute des instances d'application dans des conteneurs Docker. Pour activer un profil de risque défini et empêcher les employés de modifier les conteneurs, assurez-vous que vos conteneurs sont sans état et immuables. Le principe d'immuabilité signifie que vos employés ne peuvent pas modifier le conteneur ou y accéder de manière interactive. Si le conteneur doit être modifié, vous devez créer une nouvelle image et la déployer. N'activez l'accès SSH aux conteneurs sous-jacents que dans des scénarios de débogage spécifiques.

Désactiver les adresses IP externes, sauf si elles sont nécessaires

Pour désactiver l'allocation d'adresses IP externes (vidéo) pour vos VM de production et empêcher l'utilisation d'équilibreurs de charge externes, vous pouvez utiliser des règles d'administration. Si vous souhaitez que vos VM puissent accéder à Internet ou à votre centre de données sur site, vous pouvez activer une passerelle Cloud NAT.

Vous pouvez déployer des clusters privés dans GKE. Dans un cluster privé, les nœuds ne disposent que d'adresses IP internes, ce qui signifie que les nœuds et les pods sont isolés par défaut d'Internet. Vous pouvez également définir une règle de réseau afin de gérer la communication entre les pods dans le cluster. Pour en savoir plus, consultez la page Options d'accès privé pour les services.

Surveiller votre utilisation des instances Compute Engine et de GKE

Les journaux d'audit Cloud sont automatiquement activés pour Compute Engine et GKE. Les journaux d'audit vous permettent de capturer automatiquement toutes les activités de votre cluster et de surveiller toute activité suspecte.

Vous pouvez intégrer GKE à des produits partenaires pour garantir la sécurité des environnements d'exécution. Vous pouvez intégrer ces solutions à Security Command Center afin de disposer d'une interface unique pour surveiller vos applications.

Maintenir vos images et vos clusters à jour

Google Cloud fournit des images d'OS sélectionnées qui bénéficient de correctifs réguliers. Vous pouvez importer des images personnalisées et les exécuter sur Compute Engine, mais vous devrez appliquer vous-même les correctifs. Google Cloud met régulièrement à jour les images d'OS pour corriger les nouvelles failles (comme décrit dans les bulletins de sécurité) et fournit des solutions pour corriger les failles des déploiements existants.

Si vous utilisez GKE, nous vous recommandons d'activer la mise à jour automatique des nœuds pour que Google puisse mettre à jour vos nœuds de cluster en appliquant les derniers correctifs. Google gère les plans de contrôle GKE, qui sont automatiquement mis à jour et corrigés. En outre, vous pouvez utiliser des images optimisées pour les conteneurs qui sont sélectionnées par Google pour votre déploiement. Google corrige et met régulièrement à jour ces images.

Contrôler l'accès à vos images et clusters

Il est important de savoir qui peut créer et lancer des instances. Vous pouvez contrôler cet accès à l'aide d'IAM. Pour savoir comment déterminer quel niveau d'accès fournir aux charges de travail, consultez la page Planifier les identités de charge de travail.

De plus, vous pouvez utiliser VPC Service Controls pour définir des quotas personnalisés sur des projets spécifiques afin de limiter le nombre d'utilisateurs pouvant lancer des images. Pour en savoir plus, consultez la section Sécuriser votre réseau.

Pour assurer la sécurité de l'infrastructure de votre cluster, GKE vous permet d'utiliser IAM avec le contrôle des accès basé sur les rôles (RBAC) afin de gérer l'accès à votre cluster et à vos espaces de noms.

Isoler des conteneurs dans un bac à sable

Utilisez GKE Sandbox pour déployer des applications mutualisées nécessitant une couche de sécurité et d'isolation supplémentaire par rapport à leur noyau hôte. Par exemple, utilisez GKE Sandbox lorsque vous exécutez du code inconnu ou non approuvé. GKE Sandbox est une solution d'isolation de conteneur qui constitue une seconde couche de défense entre les charges de travail conteneurisées dans GKE.

GKE Sandbox a été conçu pour les applications à faible volume d'E/S mais très évolutives. Ces charges de travail conteneurisées doivent maintenir leur vitesse d'exécution et leurs performances, mais elles peuvent aussi impliquer du code non approuvé nécessitant une sécurité renforcée. Utilisez gVisor, un bac à sable d'exécution de conteneur, pour renforcer l'isolation de sécurité entre les applications et le noyau hôte. gVisor fournit des vérifications d'intégrité supplémentaires et limite le niveua d'accès d'un service. Il ne s'agit pas d'un service destiné à renforcer la protection des conteneurs contre les menaces externes. Pour plus d'informations sur gVisor, consultez la page gVisor : Protéger les utilisateurs de GKE et de solutions sans serveur dans le monde réel.

Étape suivante

Pour en savoir plus sur la sécurité des ressources de calcul et des conteneurs, consultez les ressources suivantes :

• Sécuriser votre réseau (document suivant de cette série)
• Pourquoi la sécurité des conteneurs est-elle importante ? (PDF)
• Checklist avant lancement pour Google Cloud
• Vérifier l’identité des instances
• Workload Identity
• VM protégée
• Bonnes pratiques pour les instantanés de disques persistants
• Bonnes pratiques pour la gestion des images

Sécuriser votre réseau

Ce document du framework d'architecture Google Cloud décrit les bonnes pratiques à adopter pour sécuriser votre réseau.

L'extension de votre réseau existant aux environnements cloud a de nombreuses conséquences en termes de sécurité. Votre approche sur site des défenses multicouches implique probablement un périmètre distinct entre Internet et votre réseau interne. Vous protégerez probablement le périmètre à l'aide de pare-feu physiques, de routeurs, de systèmes de détection d'intrusion, etc… Comme la limite est clairement définie, vous pouvez facilement surveiller les intrusions et réagir en conséquence.

Lorsque vous migrez vers le cloud (de manière complète ou hybride), vous allez au-delà de votre périmètre sur site. Ce document décrit les différentes manières de sécuriser les données et les charges de travail de votre organisation sur Google Cloud. Comme indiqué dans la section Gérer les risques avec des contrôles, la façon dont vous configurez et sécurisez votre réseau Google Cloud dépend des exigences de votre entreprise et de votre intérêt pour les risques.

Dans cette section, nous partons du principe que vous avez lu la section Mise en réseau de la catégorie Conception système et que vous avez déjà créé un schéma d'architecture de base de vos composants réseau Google Cloud. Pour obtenir un exemple de schéma, consultez la section Architecture hub-and-spoke.

Déployer des réseaux "zéro confiance"

Le passage au cloud implique que le modèle de confiance de votre réseau doit changer. Étant donné que vos utilisateurs et vos charges de travail ne sont plus derrière votre périmètre sur site, vous ne pouvez pas utiliser les protections périmétriques de la même manière pour créer un réseau interne fiable. Le modèle de sécurité "zéro confiance" signifie que personne n'est approuvé par défaut, que ce soit à l'intérieur ou à l'extérieur du réseau de votre organisation. Lors de la validation des requêtes d'accès, le modèle de sécurité "zéro confiance" nécessite de vérifier à la fois l'identité de l'utilisateur et le contexte. Contrairement à un VPN, vous déplacez les contrôles d'accès du périmètre réseau vers les utilisateurs et les appareils.

Dans Google Cloud, vous pouvez utiliser BeyondCorp Enterprise comme solution zéro confiance. BeyondCorp Enterprise fournit une prévention des menaces et une protection des données, ainsi que des contrôles d'accès supplémentaires. Pour en savoir plus sur la configuration, consultez la page Premiers pas avec BeyondCorp Enterprise.

En plus de BeyondCorp Enterprise, Google Cloud inclut Identity-Aware Proxy (IAP). IAP vous permet d'étendre la sécurité "zéro confiance" à vos applications à la fois dans Google Cloud et sur site. IAP utilise des stratégies de contrôle d'accès pour fournir l'authentification et l'autorisation aux utilisateurs qui accèdent à vos applications et à vos ressources.

Sécurisez les connexions à vos environnements sur site ou multicloud.

De nombreuses organisations disposent de charges de travail à la fois dans les environnements cloud et sur site. En outre, pour plus de résilience, certaines organisations utilisent des solutions multicloud. Dans ces scénarios, il est essentiel de sécuriser la connectivité entre tous les environnements.

Google Cloud comprend des méthodes d'accès privé pour les VM compatibles avec Cloud VPN ou Cloud Interconnect, y compris les suivantes :

• Utilisez Cross-Cloud Interconnect en tant que service géré pour associer vos réseaux VPC à d'autres fournisseurs de services cloud compatibles via des connexions directes à haut débit. Avec Cross-Cloud Interconnect, vous n'avez pas besoin de fournir votre propre routeur ni de travailler avec un fournisseur tiers.
• Utilisez l'interconnexion dédiée et l'interconnexion partenaire pour associer vos réseaux VPC à votre centre de données sur site ou à d'autres fournisseurs cloud via des connexions directes à haut débit.
• Utilisez des VPN IPsec pour associer vos réseaux VPC (cloud privé virtuel) à votre centre de données sur site ou à d'autres fournisseurs de services cloud.
• Utilisez les points de terminaison Private Service Connect pour accéder aux services publiés, qui sont fournis par votre organisation ou par un autre fournisseur.
• Utilisez des points de terminaison Private Service Connect pour permettre à vos VM d'accéder aux APIs Google, à l'aide d'adresses IP internes. Avec Private Service Connect, vos VM n'ont pas besoin d'adresses IP externes pour accéder aux services Google.
• Si vous utilisez GKE Enterprise, envisagez d'utiliser des passerelles de sortie Anthos Service Mesh. Si vous n'utilisez pas GKE Enterprise, utilisez une option tierce.

Pour comparer les produits, consultez la section Choisir un produit de connectivité réseau.

Désactiver les réseaux par défaut

Lorsque vous créez un projet Google Cloud, un réseau VPC Google Cloud par défaut avec des adresses IP en mode automatique et des règles de pare-feu préremplies sont automatiquement provisionnées. Pour les déploiements de production, nous vous recommandons de supprimer les réseaux par défaut dans les projets existants et de désactiver la création de réseaux par défaut dans les nouveaux projets.

Les réseaux VPC (cloud privé virtuel) vous permettent d'utiliser n'importe quelle adresse IP interne. Pour éviter les conflits d'adresses IP, nous vous recommandons de commencer par planifier votre réseau et votre allocation d'adresses IP sur l'ensemble de vos déploiements connectés et de vos projets. Même si un projet autorise plusieurs réseaux VPC, il est généralement recommandé de limiter ces réseaux à un par projet afin d'appliquer efficacement le contrôle des accès.

Sécuriser votre périmètre

Dans Google Cloud, vous pouvez utiliser différentes méthodes pour segmenter et sécuriser votre périmètre cloud, y compris des pare-feu et VPC Service Controls.

Utilisez le VPC partagé pour créer un déploiement de production qui vous donne un seul réseau partagé et qui isole les charges de travail dans des projets individuels pouvant être gérés par différentes équipes. Le VPC partagé permet un déploiement, une gestion et un contrôle centralisés des ressources réseau et de sécurité réseau sur plusieurs projets. Un VPC partagé comprend des projets hôte et de service qui effectuent les opérations suivantes :

• Un projet hôte contient les ressources réseau et de sécurité réseau telles que les réseaux VPC, les sous-réseaux, les règles de pare-feu et la connectivité hybride.
• Un projet de service est associé à un projet hôte. Il vous permet d'isoler les charges de travail et les utilisateurs au niveau du projet en utilisant Identity and Access Management (IAM), tout en partageant les ressources réseau du projet hôte géré de manière centralisée.

Définissez des stratégies et des règles de pare-feu au niveau de l'organisation, du dossier et du réseau VPC. Vous pouvez configurer des règles de pare-feu pour autoriser ou refuser le trafic vers ou depuis des instances de VM. Pour obtenir des exemples, consultez les sections Exemples de stratégies de pare-feu réseau global et régional et Exemples de stratégies de pare-feu hiérarchique. Outre la définition de règles basées sur des adresses IP, des protocoles et des ports, vous pouvez gérer le trafic et appliquer des règles de pare-feu en fonction du compte de service utilisé par une instance de VM ou à l'aide de tags sécurisés.

Pour contrôler le déplacement des données dans les services Google et configurer une sécurité périmétrique basée sur le contexte, envisagez d'utiliser VPC Service Controls. VPC Service Controls offre un niveau de sécurité supplémentaire pour les services Google Cloud, indépendamment des règles et stratégies de pare-feu IAM et VPC. Par exemple, VPC Service Controls vous permet de configurer des périmètres entre des données confidentielles et non confidentielles afin d'appliquer des contrôles permettant d'éviter l'exfiltration de données.

Les règles de sécurité Google Cloud Armor vous permettent d'autoriser, de refuser ou de rediriger les requêtes vers votre équilibreur de charge d'application externe à la périphérie de Google Cloud, aussi près que possible de la source du trafic entrant. Ces stratégies empêchent le trafic indésirable de consommer des ressources ou d'entrer dans votre réseau.

Utilisez le proxy Web sécurisé pour appliquer des règles précises de contrôle des accès à votre trafic Web de sortie et pour surveiller l'accès aux services Web non approuvés.

Inspecter le trafic réseau

Vous pouvez utiliser Cloud IDS et la mise en miroir de paquets pour vous aider à garantir la sécurité et la conformité des charges de travail s'exécutant dans Compute Engine et Google Kubernetes Engine (GKE).

Utilisez Cloud Intrusion Detection System (actuellement en version bêta) pour obtenir une visibilité sur le trafic entrant et sortant de vos réseaux VPC. Cloud IDS crée un réseau appairé géré par Google qui dispose de VM en miroir. Les technologies de protection contre les menaces Palo Alto Networks mettent en miroir et inspectent le trafic. Pour plus d'informations, consultez la Présentation de Cloud IDS.

La mise en miroir de paquets clone le trafic de certaines instances de VM spécifiées dans votre réseau VPC et le transfère pour le collecter, le conserver et l'examiner. Une fois que vous avez configuré la mise en miroir de paquets, vous pouvez utiliser Cloud IDS ou des outils tiers pour collecter et inspecter le trafic réseau à grande échelle. Ce type d'inspection permet de détecter les intrusions et de surveiller les performances des applications.

Utiliser un pare-feu d'application Web

Pour les applications et les services Web externes, vous pouvez activer Google Cloud Armor pour fournir une protection contre le déni de service distribué (DDoS) et des fonctionnalités de pare-feu d'application Web (WAF). Google Cloud Armor est compatible avec les charges de travail Google Cloud exposées à l'aide de l'équilibrage de charge HTTP(S) externe, de l'équilibrage de charge proxy TCP ou de l'équilibrage de charge proxy SSL.

Google Cloud Armor est proposé en deux niveaux de service : Standard et Managed Protection Plus. Pour tirer pleinement parti des fonctionnalités avancées de Google Cloud Armor, vous devez investir dans Managed Protection Plus pour vos principales charges de travail.

Automatiser le provisionnement de l'infrastructure

L'automatisation vous permet de créer une infrastructure immuable, ce qui signifie qu'elle ne peut plus être modifiée après le provisionnement. Cette mesure permet à votre équipe chargée des opérations de bénéficier d'un état sain connu, d'effectuer un rollback rapide et de résoudre les problèmes. Pour l'automatisation, vous pouvez utiliser des outils tels que Terraform, Jenkins et Cloud Build.

Pour vous aider à créer un environnement utilisant l'automatisation, Google Cloud fournit une série de plans de sécurité qui s'appuient sur le plan de base d'entreprise. Le plan de sécurité de base présente la conception rigoureuse de Google pour un environnement d'application sécurisé. Il décrit étape par étape comment configurer et déployer votre parc Google Cloud. En suivant les instructions et les scripts du plan de sécurité de base, vous pouvez configurer un environnement conforme à nos bonnes pratiques et principes de sécurité. Vous pouvez vous appuyer sur ce plan en utilisant des plans supplémentaires ou en concevant votre propre automatisation.

Pour en savoir plus sur l'automatisation, consultez la page Utiliser un pipeline CI/CD pour les workflows de traitement des données.

Surveiller le réseau

Surveiller le réseau et le trafic en utilisant la télémétrie

Les journaux de flux VPC et la journalisation des règles de pare-feu offrent une visibilité en temps quasi réel sur le trafic et l'utilisation du pare-feu dans votre environnement Google Cloud. Par exemple, la journalisation des règles de pare-feu consigne le trafic vers et depuis les instances de VM Compute Engine. Lorsque vous combinez ces outils avec Cloud Logging et Cloud Monitoring, vous pouvez suivre et visualiser le trafic et les modèles d'accès puis créer des alertes afin d'améliorer la sécurité opérationnelle de votre déploiement.

Firewall Insights vous permet d'examiner les règles de pare-feu correspondant aux connexions entrantes et sortantes, et de déterminer si les connexions ont été autorisées ou refusées. La fonctionnalité de règles bloquées vous aide à ajuster la configuration de votre pare-feu en vous indiquant les règles qui ne sont jamais déclenchées car une autre règle est toujours déclenchée en premier.

Utilisez Network Intelligence Center pour examiner les performances de votre topologie et de votre architecture réseau. Vous pouvez obtenir des insights précis sur les performances réseau et optimiser votre déploiement afin d'éliminer les goulots d'étranglement dans votre service. Les tests de connectivité vous fournissent des insights sur les règles de pare-feu et les stratégies appliquées au chemin réseau.

Pour en savoir plus sur la surveillance, consultez la page Mettre en œuvre la journalisation et les contrôles de détection.

Étape suivante

Pour en savoir plus sur la sécurité des réseaux, consultez les ressources suivantes :

• Appliquer des contrôles de sécurité des données (document suivant de cette série)
• Bonnes pratiques et architectures de référence pour la conception de VPC
• Rôles IAM pour l'administration de VPC Service Controls
• Intégration en tant que partenaire Security Command Center
• Identifier les failles et les menaces dans Security Command Center
• Mise en miroir de paquets : visualisez et protégez votre réseau cloud
• Utiliser la mise en miroir de paquets pour détecter les intrusions
• Utiliser la mise en miroir de paquets avec une solution IDS partenaire

Appliquer la sécurité des données

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques à suivre pour appliquer la sécurité des données.

Dans le cadre de votre architecture de déploiement, vous devez prendre en compte les données que vous prévoyez de traiter et de stocker dans Google Cloud, ainsi que leur sensibilité. Concevez vos contrôles pour sécuriser les données tout au long de leur cycle de vie, pour identifier leur propriétaire et leur classification, et pour protéger les données contre toute utilisation non autorisée.

Pour obtenir un plan de sécurité qui déploie un entrepôt de données BigQuery avec les bonnes pratiques de sécurité décrites dans ce document, consultez la page Sécuriser un entrepôt de données BigQuery qui stocke des données confidentielles.

Classer automatiquement vos données

Classez les données le plus tôt possible dans le cycle de gestion des données, idéalement lorsqu'elles sont créées. En général, les tâches de classification des données ne nécessitent que quelques catégories comme les suivantes :

• Public : données dont l'accès public a été approuvé.
• Interne : données non sensibles qui ne sont pas divulguées au public.
• Confidentiel : données sensibles disponibles pour une distribution interne générale.
• Limitée : données très sensibles ou réglementées qui nécessitent une distribution restreinte.

Utilisez la protection des données sensibles pour détecter et classifier les données de votre environnement Google Cloud. La protection des données sensibles dispose d'une compatibilité native pour l'analyse et la classification de données sensibles dans Cloud Storage, BigQuery et Datastore. Il offre également une API de streaming compatible avec d'autres sources de données et charges de travail personnalisées.

La protection des données sensibles peut identifier les données sensibles à l'aide d'infoTypes intégrés. Il peut automatiquement classer, masquer, tokeniser et transformer des éléments sensibles (tels que les informations personnelles) pour vous permettre de gérer les risques liés à la collecte, au stockage et à l'utilisation des données. En d'autres termes, il peut s'intégrer à vos processus de cycle de vie des données pour garantir la protection des données à chaque étape.

Pour en savoir plus, consultez la section Anonymiser et désanonymiser les informations personnelles dans les ensembles de données à grande échelle à l'aide de la protection des données sensibles.

Gérer la gouvernance des données à l'aide de métadonnées

La gouvernance des données est un ensemble de processus qui garantissent la sécurité, la confidentialité, l'exactitude, la disponibilité et l'exploitabilité des données. Bien que vous soyez seul responsable de la définition d'une stratégie de gouvernance des données pour votre entreprise, Google Cloud fournit des outils et des technologies qui vous aideront à mettre en œuvre votre stratégie. Google Cloud propose également un framework pour la gouvernance des données (PDF) dans le cloud.

Utilisez Data Catalog pour trouver, organiser et utiliser des métadonnées afin de décrire vos éléments de données dans le cloud. Vous pouvez utiliser Data Catalog pour rechercher des éléments de données, puis leur ajouter des tags contenant des métadonnées. Pour accélérer vos efforts de classification des données, intégrez Data Catalog à la protection des données sensibles pour identifier automatiquement les données confidentielles. Une fois les données taguées, vous pouvez utiliser Google Identity and Access Management (IAM) pour limiter les données que les utilisateurs peuvent interroger ou utiliser via les vues Data Catalog.

Utilisez Dataproc Metastore ou le métastore Hive pour gérer les métadonnées des charges de travail. Data Catalog dispose d'un connecteur Hive qui permet au service de découvrir les métadonnées présentes dans un métastore Hive.

Utilisez Dataprep by Trifacta pour définir et appliquer des règles de qualité des données via une console. Vous pouvez utiliser Dataprep à partir de Cloud Data Fusion ou en tant que service autonome.

Protéger les données en fonction de leur phase de cycle de vie et de leur classification

Une fois que vous avez défini les données dans le contexte de leur cycle de vie et que vous les avez classées en fonction de leur sensibilité et des risques associés, vous pouvez attribuer des contrôles de sécurité appropriés pour les protéger. Vous devez vous assurer que vos contrôles offrent des protections appropriées, respectent les exigences de conformité et réduisent les risques. Lors de la transition vers le cloud, examinez votre stratégie actuelle et les points susceptibles de nécessiter une modification de vos processus actuels.

Le tableau suivant décrit trois caractéristiques d'une stratégie de sécurité des données dans le cloud.

Caractéristique	Description
Identification	Comprenez l'identité des utilisateurs, des ressources et des applications lors de la création, de la modification, du stockage, de l'utilisation, du partage et de la suppression de données. Utilisez Cloud Identity et IAM pour contrôler l'accès aux données. Si vos identités requièrent des certificats, envisagez d'utiliser Certificate Authority Service. Pour en savoir plus, consultez la page Gérer l'authentification et l'accès.
Limites et accès	Mettez en place des contrôles sur la manière dont les données sont accessibles, par qui et dans quelles circonstances. Les limites d'accès aux données peuvent être gérées à ces niveaux : Accès à la couche réseau, à l'aide de contrôles tels que Cloud Firewall. Pour en savoir plus sur votre couche réseau, utilisez Network Intelligence Center. Utilisez VPC Service Controls pour créer des périmètres qui protègent les ressources et les données des services que vous spécifiez. Contrôle des accès IAM, à l'aide d'IAM Pour plus d'informations sur la gestion des rôles IAM, consultez la page Utiliser les hiérarchies de ressources pour le contrôle des accès.
Visibilité	Vous pouvez auditer l'utilisation et créer des rapports montrant comment les données sont contrôlées et consultées. Google Cloud Logging et Access Transparency fournissent des informations sur les activités de vos propres administrateurs cloud et du personnel Google. Pour en savoir plus, consultez la page Surveiller vos données.

Chiffrer les données

Par défaut, Google Cloud chiffre les données client stockées au repos, sans aucune action requise de votre part. En plus du chiffrement par défaut, Google Cloud propose des options de chiffrement encapsulé et de gestion des clés de chiffrement. Par exemple, les disques persistants Compute Engine sont chiffrés automatiquement mais vous pouvez fournir ou gérer vos propres clés.

Vous devez identifier les solutions les plus adaptées à vos exigences en termes de génération, de stockage et de rotation des clés, que ce soit pour des charges de travail de stockage, de calcul ou de big data.

Google Cloud propose les options suivantes pour le chiffrement et la gestion des clés :

• Clés de chiffrement gérées par le client (CMEK). Vous pouvez générer et gérer vos clés de chiffrement à l'aide de Cloud Key Management Service (Cloud KMS). Utilisez cette option si vous avez des exigences spécifiques pour la gestion des clés, par exemple si vous avez besoin d'alterner régulièrement les clés de chiffrement.
• Clés de chiffrement fournies par le client (CSEK). Vous pouvez créer et gérer vos propres clés de chiffrement, puis les fournir à Google Cloud si nécessaire. Utilisez cette option pour apporter votre propre clé (BYOK) si vous générez vos propres clés à l'aide de votre système de gestion de clés sur site. Si vous fournissez vos propres clés à l'aide de CSEK, Google les réplique et les met à la disposition de vos charges de travail. Toutefois, la sécurité et la disponibilité des CSEK relèvent de votre responsabilité, car les clés fournies par le client ne sont pas stockées dans les modèles d'instance ni dans l'infrastructure Google. Si vous perdez l'accès aux clés, Google ne peut pas vous aider à récupérer les données chiffrées. Réfléchissez bien aux clés que vous souhaitez créer et gérer vous-même. Vous pouvez utiliser les CSEK pour les informations les plus sensibles. Une autre option consiste à effectuer un chiffrement côté client sur vos données, puis à stocker les données chiffrées dans Google Cloud, où les données sont à nouveau chiffrées par Google.
• Système de gestion de clés tiers avec Cloud External Key Manager (Cloud EKM). Cloud EKM protège vos données au repos à l'aide de clés de chiffrement stockées et gérées dans un système de gestion de clés tiers que vous contrôlez en dehors de l'infrastructure Google. Lorsque vous utilisez cette méthode, vous avez la certitude que vos données ne sont pas accessibles à des personnes externes à votre organisation. Cloud EKM vous permet d'obtenir un modèle HYOK ("Hold Your Own Key") pour la gestion des clés. Pour plus d'informations sur la compatibilité, consultez la liste des services compatibles avec Cloud EKM.

Cloud KMS vous permet également de chiffrer vos données avec des clés de chiffrement logicielles ou des modules de sécurité matériels (HSM) validés FIPS 140-2 de niveau 3. Si vous utilisez Cloud KMS, vos clés cryptographiques sont stockées dans la région où vous déployez la ressource. Cloud HSM distribue vos besoins en gestion des clés entre les régions, et assure la redondance et la disponibilité mondiale des clés.

Pour en savoir plus sur le fonctionnement du chiffrement encapsulé, consultez la page Chiffrement au repos dans Google Cloud.

Contrôler l'accès des administrateurs cloud à vos données

Vous pouvez contrôler l'accès de votre personnel d'assistance et d'ingénierie à votre environnement Google Cloud. Access Approval vous permet d'autoriser explicitement les employés de Google à accéder à vos données ou ressources sur Google Cloud. Ce produit vient compléter la visibilité fournie par Access Transparency, qui génère des journaux lorsque le personnel de Google interagit avec vos données. Ces journaux incluent l'emplacement du bureau et le motif de l'accès.

En utilisant ces produits ensemble, vous pouvez refuser à Google la possibilité de déchiffrer vos données pour quelque raison que ce soit.

Configurez l'emplacement de stockage de vos données et l'emplacement où les utilisateurs peuvent y accéder.

Vous pouvez contrôler les emplacements réseau à partir desquels les utilisateurs peuvent accéder aux données à l'aide de VPC Service Controls. Cet outil vous permet de limiter l'accès aux utilisateurs d'une région spécifique. Vous pouvez appliquer cette contrainte même si l'utilisateur est autorisé conformément à votre stratégie IAM Cloud. À l'aide de VPC Service Controls, vous pouvez créer un périmètre de service qui définit les limites virtuelles à partir desquelles un service est accessible, ce qui empêche le déplacement des données en dehors de ces limites.

Pour en savoir plus, consultez les ressources suivantes :

• Automatisation de la classification des données téléchargées sur Cloud Storage
• Gouvernance des données dans le cloud
• Gouvernance de données depuis l'entrepôt de données vers BigQuery
• Métastore Hive désormais disponible

Gérer les secrets avec le gestionnaire de secrets

Secret Manager vous permet de stocker tous vos secrets de manière centralisée. Les codes secrets sont des informations de configuration telles que les mots de passe de base de données, les clés API ou les certificats TLS. Vous pouvez effectuer une rotation automatique des secrets et configurer les applications pour qu'elles utilisent automatiquement la dernière version d'un secret. Chaque interaction avec Secret Manager génère une entrée de journal d'audit. Vous pouvez donc contrôler chaque accès à chaque secret.

La protection des données sensibles intègre également une catégorie de détecteurs pour vous aider à identifier les identifiants et les secrets dans les données pouvant être protégées par Secret Manager.

Surveiller vos données

Pour consulter les journaux des activités d'administration et de l'utilisation des clés, utilisez Cloud Audit Logging. Pour sécuriser vos données et vous assurer que vos clés sont utilisées correctement, surveillez les journaux à l'aide de Cloud Monitoring.

Cloud Logging capture les événements Google Cloud et vous permet d'ajouter des sources supplémentaires si nécessaire. Vous pouvez segmenter vos journaux par région, les stocker dans des buckets et intégrer du code personnalisé pour le traitement des journaux. Pour obtenir un exemple, consultez la section Solution personnalisée pour l'analyse automatisée des journaux.

Vous pouvez également exporter les journaux vers BigQuery pour effectuer des analyses de sécurité et d'accès afin d'identifier les modifications non autorisées et les accès inappropriés aux données de votre organisation.

Security Command Center peut vous aider à identifier et à résoudre les problèmes d'accès non sécurisé aux données organisationnelles sensibles stockées dans le cloud. Grâce à une interface de gestion unique, vous pouvez rechercher une grande variété de failles et de risques de sécurité dans votre infrastructure cloud. Par exemple, vous pouvez surveiller l'exfiltration de données, rechercher des données confidentielles dans les systèmes de stockage et détecter les buckets Cloud Storage ouverts à Internet.

Étape suivante

Pour en savoir plus sur la sécurité des données, consultez les ressources suivantes :

• Déployer des applications en toute sécurité (document suivant de cette série)

• Sécuriser un entrepôt de données BigQuery qui stocke des données confidentielles

• Concevoir et déployer une stratégie de sécurité des données (PDF)

• Stocker des données en toute confiance avec Google Cloud Platform (PDF)

• Règles de conservation utilisant des verrous de bucket

• Bonnes pratiques relatives à Cloud Storage

• Bonnes pratiques pour les instances SQL Server

• Bonnes pratiques concernant Datastore

• Data Catalog

Déployer des applications en toute sécurité

Le présent document du framework d'architecture Google Cloud décrit les bonnes pratiques pour déployer des applications en toute sécurité.

Pour déployer des applications sécurisées, vous devez disposer d'un cycle de vie de développement logiciel bien défini, avec des contrôles de sécurité appropriés pendant les phases de conception, de développement, de test et de déploiement. Lorsque vous concevez une application, nous vous recommandons d'utiliser une architecture système en couches qui met en œuvre des frameworks standardisés pour l'authentification, les autorisations et le contrôle des accès.

Automatiser l'application des versions sécurisées

Sans outils automatisés, il peut s'avérer difficile de déployer, de mettre à jour et d'appliquer des correctifs aux environnements applicatifs complexes pour satisfaire les exigences de sécurité. Nous vous recommandons donc de créer un pipeline CI/CD pour ces tâches, ce qui peut résoudre de nombreux problèmes. Les pipelines automatisés suppriment les erreurs manuelles, fournissent des boucles de rétroaction standardisées pour le développement et permettent une itération rapide des produits. Par exemple, les pools privés Cloud Build vous permettent de déployer un pipeline CI/CD hautement sécurisé et géré pour des secteurs hautement réglementés comme la finance ou la santé.

Vous pouvez utiliser l'automatisation pour rechercher les failles de sécurité lors de la création des artefacts. Vous pouvez également définir des règles pour différents environnements (développement, test, production, etc.) afin que seuls les artefacts validés soient déployés.

Garantir que les déploiements d'applications suivent les processus approuvés

Si un pirate informatique compromet le pipeline CI/CD, l'ensemble de votre pile peut être affecté. Pour sécuriser le pipeline, vous devez appliquer un processus d'approbation bien défini avant de déployer le code en production.

Si vous prévoyez d'utiliser Google Kubernetes Engine (GKE) ou GKE Entreprise, vous pouvez mettre en place ces contrôles de sécurité en utilisant l'autorisation binaire. L'autorisation binaire associe des signatures configurables aux images de conteneurs. Ces signatures (également appelées attestations) aident à valider l'image. Au moment du déploiement, l'autorisation binaire utilise ces attestations pour déterminer si un processus a été mis en œuvre précédemment. Par exemple, vous pouvez utiliser l'autorisation binaire pour effectuer les opérations suivantes :

• Vérifier qu'un système de compilation ou un pipeline d'intégration continue (CI) spécifique a bien créé une image de conteneur.
• Vérifier qu'une image de conteneur est conforme aux règles de signature des failles.
• Vérifier qu'une image de conteneur transmet des critères de promotion à l'environnement de déploiement suivant, par exemple de l'environnement de développement vers l'environnement de contrôle qualité

Rechercher les failles connues avant le déploiement

Nous vous recommandons d'utiliser des outils automatisés pour analyser en continu les failles des images de conteneurs avant leur déploiement en production.

Utilisez Artifact Analysis pour rechercher automatiquement les failles des conteneurs stockés dans Artifact Registry et Container Registry. Ce processus comprend deux tâches : l'analyse incrémentielle et l'analyse continue.

Pour commencer, Artifact Analysis analyse les nouvelles images au fur et à mesure de leur importation dans Artifact Registry ou Container Registry. Cette analyse extrait des informations sur les packages système du conteneur.

Artifact Analysis recherche ensuite les failles lorsque vous importez l'image. Une fois l'analyse initiale terminée, Artifact Analysis surveille en permanence les métadonnées des images analysées dans Artifact Registry et Container Registry afin de détecter de nouvelles failles. Lorsque Artifact Analysis reçoit de nouvelles informations ou des informations actualisées sur les failles, en provenance des sources de failles, il effectue les opérations suivantes :

• Mise à jour des métadonnées des images analysées afin de les actualiser.
• Création d'occurrences de failles pour les nouvelles notes.
• Suppression des occurrences de failles qui ne sont plus valides.

Détecter les failles connues dans votre code d'application

Il est recommandé d'utiliser des outils automatisés pour surveiller en permanence le code de votre application afin de détecter les failles connues, comme le OWASP Top 10. Pour obtenir une description des produits et des fonctionnalités Google Cloud compatibles avec le top 10 des techniques d'atténuation OWASP, consultez la page Top 10 des options d'atténuation de l'OWASP sur Google Cloud.

Utilisez Web Security Scanner pour identifier les failles de sécurité dans vos applications Web App Engine, Compute Engine et Google Kubernetes Engine. Le service explore votre application et tous les liens associés à vos URL de démarrage, et tente de tester un maximum d'entrées utilisateur et de gestionnaires d'événements. Il recherche et détecte automatiquement les failles courantes, y compris les scripts intersites (XSS), les injections Flash, les contenus mixtes (HTTP dans HTTPS) et les bibliothèques obsolètes ou non sécurisées. Web Security Scanner vous permet d'identifier rapidement ces types de failles avec un faible taux de faux positifs.

Contrôler le mouvement des données entre les périmètres

Pour contrôler le mouvement des données sur un périmètre, vous pouvez configurer des périmètres de sécurité autour des ressources de vos services gérés par Google. Utilisez VPC Service Controls pour placer tous les composants et services de votre pipeline CI/CD (par exemple, Container Registry, Artifact Registry, Artifact Analysis et l'autorisation binaire) à l'intérieur d'un périmètre de sécurité.

VPC Service Controls vous aide à limiter les risques de copie ou de transfert non autorisé de données (exfiltration de données) à partir de services gérés par Google. Cette solution vous permet de configurer des périmètres de sécurité autour des ressources de vos services gérés par Google et de contrôler le déplacement des données au-delà des limites des périmètres. Lorsqu'un périmètre de service est forcé, les requêtes qui ne respectent pas la règle de périmètre, telles que les requêtes adressées à des services protégés en dehors d'un périmètre, sont refusées. Lorsqu'un service est protégé par un périmètre forcé, VPC Service Controls garantit les éléments suivants :

• Un service ne peut pas transmettre de données en dehors du périmètre. Les services protégés fonctionnent normalement à l'intérieur du périmètre, mais ne peuvent pas envoyer de ressources ni de données en dehors de celui-ci. Cette restriction permet d'éviter que des initiés malveillants susceptibles d'avoir accès à des projets du périmètre ne puissent exfiltrer des données.
• Les requêtes émises depuis l'extérieur du périmètre vers le service protégé ne sont prises en compte que si elles répondent aux critères des niveaux d'accès attribués au périmètre.
• Un service peut être rendu accessible aux projets situés dans d'autres périmètres à l'aide de liaisons de périmètre.

Chiffrer vos images de conteneur

Dans Google Cloud, vous pouvez chiffrer vos images de conteneurs en utilisant des clés de chiffrement gérées par le client (CMEK). Les clés CMEK sont gérées dans Cloud Key Management Service (Cloud KMS). Lorsque vous utilisez la fonctionnalité CMEK, vous pouvez désactiver temporairement ou définitivement l'accès à une image de conteneur chiffrée en désactivant ou en détruisant la clé.

Étape suivante

Pour en savoir plus sur la sécurisation de votre chaîne d'approvisionnement et de vos applications, consultez les ressources suivantes :

• Gérer les obligations de conformité (document suivant de cette série)
• Excellence opérationnelle
• Autorisation binaire
• Artifact Analysis
• Artifact Registry

Gérer les obligations de conformité

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques à adopter pour gérer les obligations de conformité.

Vos obligations réglementaires sur le cloud dépendent d'une combinaison de facteurs, parmi lesquels :

• Les lois et réglementations qui appliquent aux emplacements physiques de votre organisation
• Les lois et réglementations qui s'appliquent à l'emplacement physique de vos clients.
• Les exigences réglementaires de votre secteur d'activité.

Ces exigences façonnent de nombreuses décisions que vous devez prendre pour ce qui est des contrôles de sécurité à appliquer à vos charges de travail dans Google Cloud.

Un processus de conformité typique passe par trois étapes : évaluation, correction des lacunes et surveillance continue. Cette section décrit les bonnes pratiques que vous pouvez appliquer à chaque étape.

Évaluer vos besoins en conformité

L'évaluation de la conformité commence par un examen approfondi de toutes vos obligations réglementaires et de la façon dont votre entreprise les met en œuvre. Pour vous aider à évaluer les services Google Cloud, utilisez le Centre de ressources pour la conformité. Ce site fournit des détails sur les points suivants :

• Compatibilité du service avec les différentes réglementations
• Certifications et attestations de Google Cloud

Vous pouvez demander un entretien avec un spécialiste de la conformité Google pour mieux comprendre le cycle de vie de la conformité chez Google et découvrir comment respecter à vos obligations réglementaires.

Pour en savoir plus, consultez la section Assurer la conformité dans le cloud (PDF).

Déployer Assured Workloads

Assured Workloads est l'outil Google Cloud qui s'appuie sur les contrôles internes de Google Cloud pour vous aider à respecter vos obligations réglementaires. Assured Workloads vous permet d'effectuer les opérations suivantes :

• Choisir votre régime de conformité. L'outil définit ensuite automatiquement les contrôles d'accès pour le personnel de référence.
• Définir l'emplacement de vos données à l'aide de règles d'administration afin que vos données au repos et vos ressources ne résident que dans la région de votre choix.
• Choisir l'option de gestion des clés (par exemple, la période de rotation des clés) qui correspond le mieux à vos exigences de sécurité et de conformité.
• Pour certaines exigences réglementaires telles que le niveau d'impact modéré du FedRAMP, sélectionnez les critères d'accès du personnel d'assistance Google (par exemple, si la personne a fait l'objet d'une vérification d'antécédents appropriée).
• Vérifiez que les clés de chiffrement gérées par Google sont conformes à la norme FIPS-140-2 et conformes au niveau d'impact modéré du programme FedRAMP. Pour ajouter une couche de contrôle et de séparation des tâches, vous pouvez utiliser des clés de chiffrement gérées par le client (CMEK). Pour en savoir plus sur les clés, consultez la page Chiffrer vos données.

Passez en revue les plans des modèles et les bonnes pratiques applicables à votre régime de conformité

Google a publié des plans et des guides de solution qui décrivent les bonnes pratiques et incluent des modules Terraform permettant de déployer un environnement qui vous aidera à assurer la conformité. Le tableau suivant répertorie une sélection de plans qui répondent aux problématiques de sécurité et de respect des obligations réglementaires.

Standard	Description
PCI	Plan de sécurité : PCI sur GKE Conformité avec la norme de sécurité des données PCI Limiter le champ d'application de la conformité pour les environnements PCI dans Google Cloud Conformité avec la norme PCI DSS sur GKE
FedRAMP	Guide de mise en œuvre du programme FedRAMP sur Google Cloud (PDF) Configurer une charge de travail à trois niveaux conforme au programme FedRAMP sur Google Cloud
HIPAA	Protéger les données de santé sur Google Cloud (PDF) Configurer une charge de travail en conformité avec la loi HIPAA à l'aide du kit de protection des données (PDF)

Surveiller la conformité

La plupart des réglementations vous obligent à surveiller des activités particulières, ce qui inclut parfois les contrôles d'accès. Pour vous aider dans la surveillance, vous pouvez utiliser :

• Access Transparency, qui fournit des journaux en temps quasi réel lorsque les administrateurs Google Cloud accèdent à votre contenu.
• La journalisation des règles de pare-feu qui enregistre les connexions TCP et UDP au sein d'un réseau VPC pour toutes les règles que vous créez vous-même. Ces journaux peuvent être utiles pour auditer l'accès au réseau ou pour identifier le plus tôt possible les cas d'utilisation non approuvée du réseau.
• Les journaux de flux VPC qui enregistrent les flux de trafic réseau envoyés ou reçus par les instances de VM.
• Security Command Center Premium qui surveiller la conformité avec différentes normes.
• OSSEC (ou un autre outil Open Source) qui consigne l'activité des personnes disposant d'un accès administrateur à votre environnement.
• Key Access Justifications qui indique les raisons d'une demande d'accès à une clé.

Automatiser la conformité

Pour vous aider à respecter les réglementations changeantes, déterminez s'il existe des moyens d'automatiser vos stratégies de sécurité en les incorporant dans votre infrastructure en tant que déploiements de code. Nous vous conseillons, par exemple, de suivre les recommandations suivantes :

• Utilisez des plans de sécurité pour créer vos règles de sécurité dans vos déploiements d'infrastructure.

• Configurez Security Command Center pour être averti en cas de problèmes de non-conformité. Par exemple, surveillez des problèmes tels que la désactivation des comptes de service ou de la validation en deux étapes par des utilisateurs. Pour en savoir plus, consultez la section Configurer des notifications de recherche.

• Configurez la résolution automatique pour des notifications spécifiques. Pour en savoir plus, consultez la section Code Cloud Functions.

Pour plus d'informations sur l'automatisation de la conformité, consultez la page Risk and Compliance as Code (RCaC) (Risques et conformité en tant que code).

Étape suivante

Pour en savoir plus sur la conformité, consultez les ressources suivantes :

• Mettre en œuvre des exigences de résidence et de souveraineté des données (document suivant de cette série)
• Centre de ressources pour la conformité
• Livre blanc sur la sécurité de Google (PDF)
• Assured Workloads

Mettre en œuvre des exigences de souveraineté et de résidence des données

Le présent document du framework d'architecture Google Cloud présente les bonnes pratiques pour mettre en œuvre des exigences de souveraineté et de résidence des données.

Les exigences de souveraineté et de résidence des données dépendent de la réglementation régionale et spécifique au secteur, et différentes organisations peuvent avoir des exigences de souveraineté des données différentes. Par exemple, vous pouvez avoir les exigences suivantes :

• Le contrôle sur tout accès à vos données par Google Cloud, y compris le type de personnel pouvant accéder aux données et la région depuis laquelle ils peuvent y accéder.
• La possibilité d'inspecter les modifications apportées à l'infrastructure et aux services cloud qui sont susceptibles d'avoir une incidence sur l'accès à vos données ou sur leur sécurité. Le fait d'obtenir des informations sur ces types de modifications permet de s'assurer que Google Cloud ne peut pas contourner les contrôles ou transférer vos données hors de la région.
• La survavibilité de vos charges de travail pendant une période prolongée lorsque vous ne pouvez pas recevoir de mises à jour logicielles de Google Cloud.

Gérer la souveraineté de vos données

La souveraineté des données fournit un mécanisme qui empêche Google d'accéder à vos données. Vous n'approuvez l'accès que pour les actions fournisseur que vous jugez nécessaires.

Par exemple, vous pouvez gérer la souveraineté de vos données de différentes manières :

• Stocker et gérer les clés de chiffrement en dehors du cloud.
• N'accorder l'accès aux clés qu'avec une justification d'accès détaillée.
• Protéger les données utilisées.

Gérer votre souveraineté opérationnelle

La souveraineté opérationnelle vous garantit que le personnel de Google ne peut pas compromettre vos charges de travail.

Par exemple, vous pouvez gérer la souveraineté opérationnelle de plusieurs manières :

• Limiter le déploiement des nouvelles ressources à des régions de fournisseur spécifiques.
• Limiter l'accès du personnel de Google en fonction d'attributs prédéfinis tels que la citoyenneté ou l'emplacement géographique.

Gérer la souveraineté logicielle

La souveraineté logicielle vous garantit que vous pouvez contrôler la disponibilité de vos charges de travail et les exécuter où vous le souhaitez, sans dépendre d'un fournisseur cloud unique. La souveraineté logicielle inclut la capacité à survivre aux événements qui nécessitent de modifier rapidement l'emplacement de déploiement de vos charges de travail et le niveau de connexion externe autorisé.

Par exemple, Google Cloud est compatible avec les déploiements hybrides et multicloud. De plus, GKE Enterprise vous permet de gérer et de déployer vos applications simultanément dans des environnements cloud et sur site.

Contrôler la résidence des données

La résidence des données décrit l'emplacement de stockage de vos données au repos. Les exigences de résidence des données varient en fonction des objectifs de conception des systèmes, de la réglementation applicable au secteur, de la législation nationale, des implications fiscales et même de la culture.

Le contrôle de la résidence des données commence par ce qui suit :

• Comprendre le type de données et leur emplacement
• Déterminer les risques qui existent pour vos données, et les lois et réglementations qui s'appliquent
• Contrôler l'emplacement des données ou leur destination

Pour vous aider à respecter les exigences de résidence des données, Google Cloud vous permet de contrôler l'emplacement de stockage de vos données, leur mode d'accès et leur traitement. Vous pouvez utiliser des règles d'emplacement des ressources pour limiter l'emplacement de création des ressources et l'emplacement des données dupliquées entre les régions. Vous pouvez utiliser la propriété "location" d'une ressource pour identifier où le service est déployé et qui le gère.

Pour en savoir plus sur la compatibilité, consultez la section Services compatibles avec les emplacements de ressources.

Étape suivante

Pour en savoir plus sur la résidence et la souveraineté des données, consultez les ressources suivantes :

• Mettre en œuvre des exigences de confidentialité (document suivant de cette série)
• Résidence des données, transparence opérationnelle et vie privée pour les clients européens sur Google Cloud (PDF)
• Concevoir et déployer une stratégie de sécurité des données (PDF)
• Cloud Key Management Service
• Stocker des données en toute confiance avec Google Cloud Platform (PDF)
• Accès privilégié chez Google
• Google Cloud Access Transparency

Mettre en œuvre des exigences de confidentialité

Le présent document du framework d'architecture de Google Cloud décrit les bonnes pratiques à adopter pour mettre en œuvre des exigences de confidentialité.

Les réglementations en matière de confidentialité définissent la manière dont vous pouvez obtenir, traiter, stocker et gérer les données de vos utilisateurs. De nombreux paramètres de confidentialité (les contrôles sur les cookies, la gestion des sessions et l'obtention de l'autorisation de l'utilisateur par exemple) relèvent de votre responsabilité car vous êtes propriétaire de vos données (ce qui inclut les données que vous recevez de vos utilisateurs).

Google Cloud inclut les contrôles suivants pour faciliter la confidentialité :

• Chiffrement par défaut de toutes les données au repos, en transit et pendant leur traitement.
• Protection contre les accès par des initiés.
• Compatibilité avec de nombreuses réglementations en matière de confidentialité.

Pour en savoir plus, consultez la page Engagements de Google Cloud en matière de confidentialité.

Classer vos données confidentielles

Vous devez définir les données confidentielles, puis vous assurer qu'elles sont correctement protégées. Les données confidentielles peuvent inclure des numéros de carte de crédit, des adresses, des numéros de téléphone et d'autres informations personnelles.

À l'aide de la protection des données sensibles, vous pouvez configurer les classifications appropriées. Vous pouvez ensuite ajouter des tags à vos données et les tokeniser avant de les stocker dans Google Cloud. Pour en savoir plus, consultez la page Classer automatiquement vos données.

Verrouillage de l'accès aux données sensibles

Placez les données sensibles dans leur propre périmètre de service à l'aide de VPC Service Controls, et définissez des contrôles d'accès Google Identity and Access Management (IAM) pour ces données. Configurez l'authentification multifacteur (MFA) pour tous les utilisateurs ayant besoin d'accéder à des données sensibles.

Pour en savoir plus, consultez les pages Contrôler le mouvement des données entre les périmètres et Configurer l'authentification unique et l'authentification multifacteur.

Surveiller les attaques par hameçonnage

Assurez-vous que votre système de messagerie est configuré pour vous protéger contre les attaques par hameçonnage, ce qui est souvent utilisé pour la fraude et les attaques de logiciels malveillants.

Si votre organisation utilise Gmail, vous pouvez appliquer la protection avancée contre l'hameçonnage et les logiciels malveillants. Cet ensemble de paramètres fournit des contrôles pour mettre en quarantaine les e-mails, protéger contre les types de pièces jointes anormaux et protéger contre les e-mails frauduleux. Le bac à sable de sécurité détecte les logiciels malveillants dans les pièces jointes. Gmail est mis à jour en continu et de façon automatique avec les dernières améliorations de sécurité et protections pour sécuriser la messagerie de votre organisation.

Étendre la sécurité "zéro confiance" à vos équipes hybrides

Un modèle de sécurité "zéro confiance" signifie que personne n'est approuvé implicitement, qu'il se trouve à l'intérieur ou à l'extérieur du réseau de votre organisation. Lorsque vos systèmes IAM vérifient les requêtes d'accès, une stratégie de sécurité "zéro confiance" signifie que l'identité de l'utilisateur et le contexte (par exemple, son adresse IP ou son emplacement) sont pris en compte. Contrairement à un VPN, la sécurité "zéro confiance" déplace les contrôles d'accès du périmètre réseau vers les utilisateurs et leurs appareils. La sécurité "zéro confiance" permet aux utilisateurs de travailler de manière plus sécurisée où qu'ils se trouvent. Par exemple, les utilisateurs peuvent accéder aux ressources de votre organisation depuis leur domicile avec un ordinateur portable ou un appareil mobile.

Sur Google Cloud, vous pouvez configurer BeyondCorp Enterprise et Identity-Aware Proxy (IAP) pour mettre en place la sécurité "zéro confiance" pour vos ressources cloud. Si vos utilisateurs utilisent Google Chrome et que vous activez BeyondCorp Enterprise, vous pouvez intégrer la sécurité "zéro confiance" dans le navigateur de vos utilisateurs.

Étape suivante

Pour en savoir plus sur la sécurité et la confidentialité, consultez les ressources suivantes :

• Mettre en œuvre la journalisation et les contrôles de détection (document suivant de cette série)
• Centre de confidentialité

• Déclaration de confidentialité de Google Cloud

• Bonnes pratiques de confidentialité lorsque vous travaillez avec l'assistance Google Cloud

• Comment Google garantit la sécurité et la confidentialité des données de votre entreprise ?

• FAQ sur la confidentialité

Mettre en œuvre la journalisation et les contrôles de détection

Ce document du framework d'architecture Google Cloud décrit les bonnes pratiques de mise en œuvre de la journalisation et de contrôles de détection.

Les contrôles de détection utilisent la télémétrie pour détecter les erreurs de configuration, les failles et les activités potentiellement malveillantes dans un environnement cloud. Google Cloud vous permet de créer des contrôles de surveillance et de détection personnalisés pour votre environnement. Cette section décrit ces fonctionnalités et recommandations supplémentaires pour leur utilisation.

Surveiller les performances du réseau

Network Intelligence Center vous donne la visibilité sur les performances de la topologie et de l'architecture de votre réseau. Vous pouvez obtenir des insights détaillés sur les performances du réseau, puis utiliser ces informations pour optimiser votre déploiement en supprimant les goulots d'étranglement sur vos services. Les tests de connectivité vous fournissent des insights sur les règles de pare-feu et les stratégies appliquées au chemin réseau.

Surveiller et empêcher l'exfiltration de données

L'exfiltration de données est une préoccupation majeure pour les entreprises. Cela se produit généralement lorsqu'une personne autorisée extrait des données d'un système sécurisé, puis les partage avec une partie non autorisée ou les transfère vers un système non sécurisé.

Google Cloud fournit plusieurs fonctionnalités et outils qui vous aident à détecter et à empêcher l'exfiltration des données. Pour en savoir plus, consultez la section Prévenir l'exfiltration de données.

Centraliser la surveillance

Security Command Center fournit une visibilité sur les ressources dont vous disposez dans Google Cloud et sur leur état de sécurité. Security Command Center vous aide à prévenir, à détecter et à contrer les menaces. Il fournit un tableau de bord centralisé qui vous permet d'identifier les erreurs de configuration de sécurité dans des machines virtuelles, dans des réseaux, dans des applications et dans des buckets de stockage. Vous pouvez résoudre ces problèmes avant qu'ils ne nuisent à votre activité. Les fonctionnalités intégrées de Security Command Center peuvent révéler des activités suspectes dans vos journaux de sécurité Cloud Logging ou indiquer des machines virtuelles compromises.

Vous pouvez réagir aux menaces en suivant les recommandations applicables ou en exportant vos fichiers journaux vers votre solution SIEM pour une analyse plus approfondie. Pour en savoir plus sur l'utilisation d'un système SIEM avec Google Cloud, consultez la section Analyse des journaux de sécurité dans Google Cloud.

Security Command Center fournit également plusieurs détecteurs qui vous aident à analyser la sécurité de votre infrastructure. Ces détecteurs incluent les éléments suivants :

• Event Threat Detection
• Security Health Analytics (SHA)
• Service d'actions sensibles

D'autres services Google Cloud, tels que les journaux Google Cloud Armor, fournissent également des résultats à afficher dans Security Command Center.

Activez les services dont vous avez besoin pour vos charges de travail, puis surveillez et analysez uniquement les données importantes. Pour en savoir plus sur l'activation de la journalisation sur les services, consultez la section Activer les journaux dans l'analyse des journaux de sécurité dans Google Cloud.

Surveiller les menaces

Event Threat Detection est un service géré facultatif de Security Command Center Premium qui détecte les menaces dans votre flux de journal. Avec Event Threat Detection, vous pouvez détecter les menaces coûteuses qui présentent un risque élevé telles que les logiciels malveillants, le minage de cryptomonnaie, l'accès non autorisé aux ressources Google Cloud, les attaques DDoS et les attaques SSH par force brute. À l'aide des fonctionnalités de l'outil afin de diffuser des volumes de données de journaux, vos équipes de sécurité peuvent rapidement identifier les incidents à haut risque et se concentrer sur la mise en place de mesures correctives.

Pour détecter les comptes utilisateur potentiellement compromis dans votre organisation, utilisez les journaux Cloud Platform d'actions sensibles afin d'identifier le moment où des actions sensibles sont effectuées et de confirmer que des utilisateurs valides ont effectué ces actions à des fins valides. Une action sensible est une action, telle que l'ajout d'un rôle très privilégié, qui pourrait nuire à votre entreprise si elle est effectuée par un individu malveillant. Utilisez Cloud Logging pour afficher, surveiller et interroger les journaux des actions sensibles de Cloud Platform. Vous pouvez également afficher les entrées de journal d'actions sensibles avec le service Actions sensibles, un service intégré de Security Command Center Premium.

Chronicle peut stocker et analyser toutes vos données de sécurité de manière centralisée. Pour vous aider à évaluer l'intégralité d'une attaque, Chronicle peut mapper les journaux dans un modèle commun, les enrichir, puis les associer en chronologie. Vous pouvez également utiliser Chronicle pour créer des règles de détection, configurer la mise en correspondance d'indicateurs de compromission (IoC) et effectuer des activités de recherche des menaces. Vous écrivez vos règles de détection en langage YARA-L. Pour obtenir des exemples de règles de détection des menaces en YARA-L, consultez le dépôt Community Security Analytics (CSA). En plus d'écrire vos propres règles, vous pouvez profiter des avantages des sélections de détections dans Chronicle. Ces détections sélectionnées sont un ensemble de règles YARA-L prédéfinies et gérées qui peuvent vous aider à identifier les menaces.

Une autre option pour centraliser vos journaux à des fins d'analyse de sécurité, d'audit et d'enquête consiste à utiliser BigQuery. Dans BigQuery, vous surveillez les menaces ou les erreurs de configuration courantes à l'aide de requêtes SQL (telles que celles du dépôt CSA) pour analyser les modifications d'autorisations, l'activité de provisionnement, l'utilisation des charges de travail, l'accès aux données et l'activité réseau. Pour en savoir plus sur l'analyse des journaux de sécurité dans BigQuery, de la configuration à l'analyse, consultez la section Analyse des journaux de sécurité dans Google Cloud.

Le schéma suivant montre comment centraliser votre surveillance en utilisant à la fois les fonctionnalités de détection des menaces intégrées de Security Command Center et la détection des menaces que vous effectuez dans BigQuery, Chronicle ou un système SIEM tiers.

Comme le montre le schéma, les sources de données de sécurité que vous devez surveiller sont nombreuses. Ces sources de données incluent les journaux de Cloud Logging, les modifications d'éléments provenant de l'inventaire des éléments cloud, les journaux Google Workspace, ou encore les événements de l'hyperviseur ou d'un noyau invité. Le schéma montre que vous pouvez utiliser Security Command Center pour surveiller ces sources de données. Cette surveillance est effectuée automatiquement si vous avez activé les fonctionnalités et les détecteurs de menaces appropriés dans Security Command Center. Le schéma montre que vous pouvez également surveiller les menaces en exportant les données de sécurité et les résultats de Security Command Center vers un outil d'analyse tel que BigQuery, Chronicle ou une solution SIEM tierce. Dans votre outil d'analyse, le schéma montre que vous pouvez effectuer une analyse et une enquête plus approfondie en utilisant et en étendant des requêtes et des règles comme celles disponibles dans les CSA.

Étapes suivantes

Pour en savoir plus sur la journalisation et la détection, consultez les ressources suivantes :

• Cloud Logging

• Présentation de Chronicle Detect de Google Cloud

• Créer un processus collaboratif de gestion des incidents

Framework d'architecture Google Cloud : Fiabilité

Cette catégorie du framework d'architecture Google Cloud vous explique comment concevoir et exploiter des services fiables sur une plate-forme cloud. Vous découvrirez également certains des produits et fonctionnalités Google Cloud qui assurent la fiabilité.

Le framework d'architecture décrit les bonnes pratiques, fournit des recommandations de mise en œuvre et explique certains des produits et services disponibles. Son but est de vous aider à concevoir votre déploiement Google Cloud pour répondre aux besoins de votre entreprise.

Pour exécuter un service fiable, votre architecture doit inclure les éléments suivants :

• Des objectifs de fiabilité mesurables, avec des écarts que vous corrigez rapidement.
• Modèles de conception pour l'évolutivité, la haute disponibilité, la reprise après sinistre et la gestion automatisée du changement.
• Des composants qui s'autoréparent si possible et du code incluant une instrumentation pour l'observabilité.
• Des procédures opérationnelles qui exécutent le service avec un minimum de travail manuel et de charge cognitive sur les opérateurs, et qui vous permettent de limiter rapidement les défaillances.

La fiabilité est la responsabilité de tous les ingénieurs, y compris les équipes de développement, de gestion des produits, d'opérations et d'ingénierie en fiabilité des sites (SRE). Chacun doit être responsable et comprendre les cibles de fiabilité de son application, ainsi que les marges de risque et d'erreur. Les équipes doivent être en mesure de hiérarchiser le travail de manière appropriée et de faire remonter les conflits de priorité entre la fiabilité et le développement des fonctionnalités produit.

Dans la catégorie "Sécurité" du framework d'architecture, vous allez apprendre à effectuer les opérations suivantes :

• Comprendre les principes fondamentaux de la fiabilité
• Définir vos objectifs de fiabilité
• Définir des SLO
• Adopter des SLO
• Intégrer l'observabilité dans votre infrastructure et vos applications
• Concevoir des solutions évolutives et à haute disponibilité
• Créer des processus et des outils opérationnels fiables
• Créer des alertes efficaces
• Créer un processus collaboratif de gestion des incidents

Principes de fiabilité

Ce document du framework d'architecture explique certains des principes fondamentaux permettant d'exécuter des services fiables sur une plate-forme cloud. Ces principes aident à créer une compréhension commune lorsque vous lisez d'autres sections du framework d'architecture qui vous montrent comment certains produits et fonctionnalités Google Cloud sont compatibles avec des services fiables.

Terminologie clé

Plusieurs termes courants sont associés aux bonnes pratiques de fiabilité. Ces éléments sont connus de nombreux lecteurs. Toutefois, pour un rappel, consultez les descriptions détaillées sur la page Terminologie.

Principes de base

L'approche de Google en termes de fiabilité est basée sur les principes de base suivants.

La fiabilité est votre priorité

Les nouvelles fonctionnalités du produit sont parfois votre priorité absolue à court terme. Cependant, la fiabilité est votre principale fonctionnalité à long terme, car si le produit est trop lent ou indisponible sur une longue période, vos utilisateurs risquent d'abandonner, sans tirer parti des nouvelles caractéristiques du produit.

La fiabilité est définie par l'utilisateur.

Pour les charges de travail destinées aux utilisateurs, mesurez l'expérience utilisateur. L'utilisateur doit être satisfait des performances de votre service. Par exemple, interrogez le taux de réussite des requêtes des utilisateurs, et pas uniquement les métriques du serveur telles que l'utilisation du processeur.

Pour les charges de travail par lot et par flux, vous devrez peut-être mesurer les indicateurs clés de performance (KPI) pour le débit de données, tels que le nombre de lignes analysées par fenêtre temporelle, plutôt que des métriques de serveur comme l'utilisation du disque. Les KPI de débit peuvent permettre de s'assurer que le rapport quotidien ou trimestriel requis par l'utilisateur sera terminé à temps.

La fiabilité à 100 % est la mauvaise cible

Vos systèmes doivent être suffisamment fiables pour que les utilisateurs en soient satisfaits. Toutefois, veillez à ne pas dépasser le niveau de fiabilité requis, car cela pourrait entraîner des coûts injustifiés. Définissez des SLO qui définissent le seuil de fiabilité souhaité, puis utilisez des marges d'erreur pour gérer le taux de variation approprié.

N'appliquez les principes de conception et d'exploitation de ce framework à un produit que si le SLO de ce produit ou de cette application en justifie le coût.

Fiabilité et innovation rapide sont complémentaires

Utilisez des marges d'erreur pour trouver un équilibre entre la stabilité du système et l'agilité des développeurs. Les instructions suivantes vous aident à déterminer quand effectuer un déplacement rapide ou lent :

• Lorsqu'une marge d'erreur suffisante est disponible, vous pouvez innover rapidement et améliorer le produit ou lui ajouter des fonctionnalités.
• Lorsque la marge d'erreur diminue, ralentissez et concentrez-vous sur les fonctionnalités de fiabilité.

Principes de conception et opérationnels

Pour optimiser la fiabilité du système, les principes de conception et opérationnels suivants s'appliquent. Chacun de ces principes est décrit en détail dans la suite de la catégorie de fiabilité du framework d'architecture.

Définir vos objectifs de fiabilité

Les bonnes pratiques abordées dans cette section du framework d'architecture sont les suivantes :

• Choisissez des SLI appropriés.
• Définir des SLO en fonction de l'expérience utilisateur
• Améliorer les SLO de manière itérative
• Utiliser des SLO internes stricts
• Gérez la vitesse de développement à l'aide des marges d'erreur.

Pour en savoir plus, consultez la page Définir vos objectifs de fiabilité dans la catégorie de fiabilité du framework d'architecture.

Intégrez l'observabilité dans votre infrastructure et vos applications.

Le principe de conception suivant est traité dans cette section du framework d'architecture :

• Optimisez l'observabilité en instrumentant votre code.

Pour en savoir plus, consultez la page Intégrer l'observabilité dans votre infrastructure et vos applications dans la catégorie de fiabilité du framework d'architecture.

Concevoir des solutions évolutives et à haute disponibilité

Les principes de conception suivants sont traités dans cette section du framework d'architecture :

• Créer une redondance pour une meilleure disponibilité
• Répliquez les données dans plusieurs régions pour la reprise après sinistre.
• Concevez une architecture multirégionale pour la résilience aux pannes régionales.
• Éliminez les goulots d'étranglement liés à l'évolutivité.
• Dégrader les niveaux de service de manière optimale en cas de surcharge
• Anticiper et atténuer les pics de trafic
• Nettoyer et valider les entrées
• Prévenez les défaillances de manière à préserver la fonction système.
• Concevez des appels d'API et des commandes opérationnelles réexécutables.
• Identifiez et gérez les dépendances système.
• Réduire au maximum les dépendances critiques
• S'assurer que chaque modification peut faire l'objet d'un rollback

Pour en savoir plus, consultez la page Concevoir des solutions évolutives et à haute disponibilité dans la catégorie de fiabilité du framework d'architecture.

Créer des processus et des outils opérationnels fiables

Les principes opérationnels suivants sont traités dans cette section du framework d'architecture :

• Choisissez des noms appropriés pour les applications et les services.
• Mettez en œuvre des déploiements progressifs avec des tests en version Canary
• Diffuser le trafic pour les promotions et les lancements planifiés
• Automatiser les processus de compilation, de test et de déploiement
• Se protéger contre les erreurs d'opérateur
• Tester les procédures de reprise après échec
• Effectuer des tests de reprise après sinistre
• Pratiquer l'ingénierie du chaos

Pour en savoir plus, consultez la page Créer des processus et des outils opérationnels fiables dans la catégorie de fiabilité du framework d'architecture.

Créer des alertes efficaces

Les principes opérationnels suivants sont traités dans cette section du framework d'architecture :

• Optimiser les retards d'alerte
• Alerter sur les symptômes plutôt que sur les causes
• Alerter sur les anomalies, et non les moyennes.

Pour en savoir plus, consultez la page Créer des alertes efficaces dans la catégorie de fiabilité du framework d'architecture.

Créer un processus collaboratif de gestion des incidents

Les principes opérationnels suivants sont traités dans cette section du framework d'architecture :

• Attribuer une propriété de service claire
• Réduisez le temps de détection grâce à des alertes bien réglées.
• Réduisez le temps nécessaire à la résolution avec des plans de gestion des incidents et des formations.
• Concevez des dispositions et du contenu de tableau de bord de façon à minimiser le temps nécessaire à la résolution.
• Documentez les procédures de diagnostic et l'atténuation des risques de défaillances connues.
• Utilisez les analyses post-mortem irréprochables pour tirer des leçons des interruptions de service et éviter les récurrences

Pour en savoir plus, consultez la section Créer un processus collaboratif de gestion des incidents dans la catégorie de fiabilité du framework d'architecture.

Étape suivante

• Définissez vos objectifs de fiabilité (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é.

Définissez vos objectifs de fiabilité.

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques à suivre pour définir des méthodes appropriées de mesure de l'expérience client pour vos services, afin d'exécuter des services fiables. Vous apprendrez à effectuer des itérations sur les objectifs de niveau de service (SLO) que vous définissez et à utiliser les marges d'erreur pour savoir quand la fiabilité peut être affectée si vous publiez des mises à jour supplémentaires.

Choisissez des SLI appropriés

Il est important de choisir les indicateurs de niveau de service (SLI) appropriés pour mieux comprendre les performances de votre service. Par exemple, si votre application possède une architecture mutualisée typique des applications SaaS utilisées par plusieurs clients indépendants, capturez les SLI au niveau de chaque locataire. Si vos SLI ne sont mesurés qu'au niveau global, vous pouvez passer à côté de problèmes critiques dans votre application, qui affectent un seul client important ou une minorité de clients. À la place, concevez votre application de manière à inclure un identifiant de locataire dans chaque requête utilisateur, puis propagez cet identifiant dans chaque couche de la pile. Cet identifiant permet à votre système de surveillance d'agréger des statistiques au niveau de chaque locataire sur chaque couche ou microservice qui se trouve sur le chemin de la requête.

Le type de service que vous exécutez détermine également les SLI à surveiller, comme illustré dans les exemples suivants.

Systèmes de diffusion

Les SLI suivants sont courants dans les systèmes qui diffusent des données :

• La disponibilité, qui indique la durée pendant laquelle un service est utilisable. Elle correspond souvent au nombre de requêtes correctement formulées qui aboutissent, telles que 99%.
• La latence, qui indique la rapidité avec laquelle un certain pourcentage de requêtes peut être traité. Elle correspond souvent à un centile autre que le 50e, tel que "99e centile à 300 ms".
• La qualité, qui vous indique la qualité d'une réponse donnée. La définition de la qualité est souvent spécifique au service, révélant dans quelle mesure le contenu de la réponse à une requête diffère du contenu de la réponse idéale. La qualité de la réponse peut être binaire (bonne ou mauvaise) ou exprimée sur une échelle de 0 à 100 %.

Systèmes de traitement des données

Les SLI suivants sont typiques des systèmes qui traitent des données :

• La couverture vous indique la fraction des données qui ont été traitées, telles que 99,9%.
• L'exactitude, qui indique la fraction des données de sortie considérées comme étant correctes (par exemple, 99,99 %).
• La fraîcheur, qui indique la fraîcheur des données sources ou des données de sortie agrégées, en gardant généralement la valeur la plus récemment mise à jour, par exemple 20 minutes.
• Le débit, qui indique la quantité de données en cours de traitement, par exemple 500 Mio/s, voire 1 000 requêtes par seconde (RPS).

Systèmes de stockage

Les SLI suivants sont typiques dans les systèmes qui stockent des données :

• La durabilité, qui indique la probabilité que les données écrites dans le système puissent être récupérées à l'avenir (par exemple, 99,9999 %). Tout incident de perte définitive de données réduit la métrique de durabilité.
• Le débit et la latence sont également des SLI courants pour les systèmes de stockage.

Choisir des SLI et définir des SLO en fonction de l'expérience utilisateur

L'un des principes fondamentaux de cette section d'architecture est que la fiabilité est définie par l'utilisateur. Mesurez les métriques de fiabilité les plus près possible de l'utilisateur, telles que les options suivantes :

• Si possible, instrumentez le client mobile ou Web.
  • Par exemple, utilisez la surveillance des performances Firebase pour obtenir des informations sur les caractéristiques de performance de vos applications iOS, Android et Web.
• Si cela n'est pas possible, instrumentez l'équilibreur de charge.
  • Par exemple, utilisez Cloud Monitoring pour la journalisation et la surveillance de l'équilibreur de charge d'application externe.
• Une mesure de fiabilité au niveau du serveur doit être la dernière option.
  • Par exemple, surveillez une instance Compute Engine avec Cloud Monitoring.

Définissez un SLO suffisamment élevé pour que la plupart des utilisateurs soient satisfaits de votre service, mais pas au-delà. En raison de problèmes de connectivité réseau ou d'autres problèmes temporaires côté client, vos clients ne percevront peut-être pas certains problèmes de fiabilité causés par votre application, ce qui vous permet de réduire votre SLO.

Pour le temps d'activité et d'autres métriques essentielles, visez une cible inférieure à 100 %, mais proche de celle-ci. Les propriétaires de services doivent évaluer objectivement le niveau minimal de performances et de disponibilité du service qui pourraient satisfaire la plupart des utilisateurs, et pas seulement en fonction de niveaux contractuels externes.

La vitesse à laquelle vous modifiez les performances affecte la fiabilité de votre système. Cependant, la possibilité d'effectuer de petites modifications fréquentes vous aide à fournir des fonctionnalités plus rapidement et avec une meilleure qualité. Les objectifs de fiabilité réalisables adaptés à l'expérience client permettent de définir le rythme et le champ d'application des modifications (vitesse des caractéristiques) maximal que les clients peuvent tolérer.

Si vous ne pouvez pas mesurer l'expérience client et définir des objectifs basés sur celle-ci, vous pouvez exécuter une analyse comparative de la concurrence. S'il n'y a pas de concurrence comparable, mesurez l'expérience client, même si vous ne pouvez pas encore définir d'objectifs. Par exemple, mesurez la disponibilité du système ou le taux de transactions significatives et réussies pour le client. Vous pouvez établir une corrélation avec les métriques commerciales ou les indicateurs clés de performance, tels que le volume de commandes dans le commerce de détail ou le volume d'appels au service client et de demandes d'assistance et leur gravité. Sur une période donnée, vous pouvez utiliser ces exercices de corrélation pour atteindre un seuil raisonnable de satisfaction client. Ce seuil correspond à votre SLO.

Améliorer les SLO de manière itérative

Les SLO ne doivent pas être figés. Revoyez les SLO une fois par trimestre ou au moins une fois par an, et confirmez qu'ils continuent de refléter avec précision la satisfaction des utilisateurs et qu'ils sont bien corrélés aux interruptions de service. Assurez-vous qu'ils couvrent les besoins actuels de l'entreprise et les nouveaux parcours utilisateur critiques. Révisez et augmentez vos SLO si nécessaire après ces examens périodiques.

Utiliser des SLO internes stricts

Il est recommandé de définir des SLO internes plus stricts que les contrats de niveau de service externes. Comme les violations du contrat de niveau de service nécessitent généralement l'émission d'un crédit financier ou de remboursements clients, vous souhaitez résoudre les problèmes avant qu'ils n'aient un impact financier.

Nous vous recommandons d'utiliser ces SLO internes plus stricts avec un processus de post-mortem irréprochable et des examens d'incidents. Pour en savoir plus, consultez la section Créer un processus collaboratif de gestion des incidents dans la catégorie de fiabilité du Centre d'architecture.

Gérez la vitesse de développement à l'aide des marges d'erreur.

Elles vous indiquent si votre système est plus ou moins fiable que nécessaire sur une période donnée. Les marges d'erreur sont calculées sur la base de 100 % - SLO sur une période donnée, par exemple 30 jours.

Lorsqu'il vous reste de la capacité dans votre marge d'erreur, vous pouvez continuer à lancer rapidement des améliorations ou de nouvelles fonctionnalités. Lorsque la marge d'erreur est proche de zéro, figez ou ralentissez les modifications de service et consacrez des ressources techniques pour améliorer les fonctionnalités de fiabilité.

Google Cloud Observability inclut une surveillance des SLO afin de réduire les efforts de configuration des SLO et des marges d'erreur. Les services comprennent une interface utilisateur graphique pour vous aider à configurer manuellement les SLO, une API pour la configuration programmatique des SLO et des tableaux de bord intégrés pour suivre le taux d'utilisation de la marge d'erreur. Pour en savoir plus, consultez la page Créer un SLO.

Recommandations

Pour appliquer les instructions du framework d'architecture à votre propre environnement, suivez les recommandations ci-dessous :

• Définissez et mesurez des SLI centrés sur le client, tels que la disponibilité ou la latence du service.
• Définissez une marge d'erreur centrée sur le client plus stricte que votre contrat de niveau de service externe. Incluez les conséquences en cas de non-respect des règles, comme le blocage de la production.
• Configurez des SLI de latence pour capturer les valeurs aberrantes, telles que le 90e ou le 99e centile, afin de détecter les réponses les plus lentes.
• Examinez les SLO au moins une fois par an et assurez-vous qu'ils sont corrélés à la satisfaction des utilisateurs et aux interruptions de service.

Étape suivante

Découvrez comment définir vos objectifs de fiabilité à l'aide des ressources suivantes :

• Intégrer l'observabilité dans votre infrastructure et votre application (document suivant de cette série)
• Coursera : SRE : mesurer et gérer la fiabilité
• Chapitre SLO dans le livre sur l'ingénierie SRE etManuel d'ingénierie SRE pour mettre en œuvre des SLO
• Affiner vos métriques SLI

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é.

Définir des SLO

Ce document constitue la première partie d'une série comprenant deux volets. Il décrit comment les équipes opérant les services en ligne peuvent aborder la création et l'adoption d'une culture de l'ingénierie en fiabilité des sites (SRE, Site Reliability Engineering) à l'aide des objectifs de niveau de service (SLO, Service Level Objectives). Un SLO est un niveau cible de fiabilité pour un service.

Dans un modèle SaaS (Software as a Service), il existe une tension naturelle entre la vitesse de développement des produits et la stabilité opérationnelle. Plus vous modifiez votre système, plus les chances de dysfonctionnement augmentent. Les outils de surveillance et d'observabilité vous aident à rester confiant en votre stabilité opérationnelle à mesure que vous augmentez la vitesse de développement. Cependant, bien que ces outils, également appelés outils de gestion des performances des applications (APM, Application Performance Management), soient importants, l'une des applications les plus importantes de ces outils est le paramétrage des SLO.

S'il est correctement défini, un SLO peut aider les équipes à prendre des décisions opérationnelles basées sur les données, ce qui augmente la vitesse de développement sans compromettre la stabilité. Le SLO peut également assurer l'harmonie entre les équipes chargées du développement et les équipes opérationnelles autour d'un seul et même objectif convenu, ce qui peut réduire les tensions naturelles entre leurs objectifs : créer et itérer des produits (développement) et maintenir l'intégrité du système (opérations).

Les SLO sont présentés en détail dans le Livre sur l'ingénierie SRE et le Classeur d'ingénierie SRE, avec d'autres pratiques d'ingénierie SRE. Cette série tente de simplifier le processus de compréhension et de développement des SLO pour vous aider à les adopter plus facilement. Une fois que vous aurez lu et compris ces articles, vous pourrez en trouver d'autres dans les livres.

Cette série vise à expliquer de façon claire comment mettre en œuvre des SLO dans votre organisation :

• Ce document passe en revue les SLO et explique comment les définir pour vos services.
• Adopter des SLO couvre différents types de SLO en fonction des types de charge de travail, puis explique comment les mesurer et comment développer des alertes reposant sur ces SLO.

Cette série est destinée aux ingénieurs SRE, aux équipes opérationnelles, au DevOps, aux administrateurs système et aux autres personnes responsables de la stabilité et de la fiabilité d'un service en ligne. Elle suppose que vous comprenez comment les services Internet communiquent avec les navigateurs Web et les appareils mobiles, et que vous comprenez les principes de base des services Web en termes de surveillance, de déploiement et de résolution des problèmes.

Les rapports sur l'état du DevOps identifient les capacités qui améliorent les performances de livraison de logiciels. Cette série vous aidera à développer les capacités suivantes :

• Surveillance et observabilité
• Systèmes de surveillance permettant d'éclairer les décisions métier
• Notification proactive des échecs

Pourquoi les SLO ?

Lorsque vous créez une culture d'ingénierie SRE, pourquoi commencer par les SLO ? Pour faire simple, si vous ne définissez pas de niveau de service, il est difficile de mesurer si vos clients sont satisfaits ou non de votre service. Même si vous savez que vous pouvez améliorer votre service, l'absence d'un niveau de service défini vous empêche de déterminer où et combien investir dans ces améliorations.

Il peut être tentant de développer des SLO distincts pour chaque service, qu'il soit visible ou non par les utilisateurs. Par exemple, une erreur courante consiste à mesurer séparément deux services ou plus (par exemple, un service frontend et un datastore backend) alors que l'utilisateur s'appuie sur les deux services à la fois et ne fait pas la distinction. Une meilleure approche consiste à développer des SLO basés sur le produit (l'ensemble de services) et à se concentrer sur les interactions les plus importantes que vos utilisateurs ont avec lui.

Par conséquent, pour développer un SLO efficace, il est essentiel de comprendre les interactions de vos utilisateurs avec votre service, aussi appelées parcours utilisateur critiques (CUJ). Un CUJ tient compte des objectifs de vos utilisateurs et de la manière dont ils utilisent vos services pour atteindre ces objectifs. Le CUJ est défini du point de vue de votre client, sans tenir compte des limites du service. Si le CUJ est atteint, le client est satisfait. Et les clients satisfaits sont un indicateur clé de la réussite d'un service.

L'un des aspects essentiels de la satisfaction du client eu égard à un service est la fiabilité de ce service. Peu importe ce que fait un service s'il n'est pas fiable. La fiabilité est donc la fonctionnalité la plus importante de tout service. La métrique de temps d'activité (uptime) est une métrique de fiabilité couramment utilisée, généralement associée au temps pendant lequel un système est opérationnel. Cependant, nous lui préférons une métrique plus utile et plus précise : la disponibilité (availability). La disponibilité répond toujours à la question de savoir si un système est opérationnel, mais de manière plus précise qu'en mesurant le temps écoulé depuis son arrêt. Dans les systèmes distribués actuels, les services peuvent être partiellement indisponibles, un facteur mal pris en compte par le temps d'activité.

La disponibilité est souvent décrite sous forme d'une série de chiffres 9 : par exemple, 99,9 % de disponibilité (trois chiffres 9) ou 99,99 % de disponibilité (quatre chiffres 9). La mesure d'un SLO de disponibilité est l'un des meilleurs moyens de mesurer la fiabilité de votre système.

En plus d'aider à définir la réussite opérationnelle, un SLO peut vous aider à choisir où investir les ressources. Par exemple, les livres d'ingénierie SRE expliquent souvent que chaque 9 peut entraîner un un coût incrémentiel avec une utilité marginale. Il est généralement reconnu qu'une disponibilité avec un 9 de plus vous coûte dix fois plus cher qu'avec un en moins.

Choisir un SLI

Pour déterminer si un SLO est atteint (c'est-à-dire réussi), vous devez disposer d'une mesure. Cette mesure est appelée indicateur de niveau de service (SLI). Un SLI mesure le niveau pour un service particulier que vous fournissez à votre client. Dans l'idéal, le SLI doit être lié à un CUJ validé.

Sélectionner les meilleures métriques

La première étape du développement d'un SLI consiste à choisir une métrique à mesurer, par exemple les requêtes par seconde, les erreurs par seconde, la longueur de la file d'attente, la distribution des codes de réponse sur une période donnée ou le nombre d'octets transmis.

Ces métriques sont généralement des types suivants :

• Compteur. Par exemple, le nombre d'erreurs qui se sont produites jusqu'à un point de mesure donné. Ce type de métrique peut augmenter, mais pas diminuer.
• Distribution. Par exemple, le nombre d'événements dans un segment de mesure particulier pour une période donnée. Vous pouvez être amené à mesurer combien de requêtes prennent de 0 à 10 ms, de 11 à 30 ms et de 31 à 100 ms. Le résultat est un décompte pour chaque bucket, par exemple, [0-10: 50], [11-30: 220], [31-100: 1103].
• Jauge. Par exemple la valeur réelle d'une partie mesurable du système (telle que la longueur de la file d'attente). Ce type de métrique peut augmenter ou diminuer.

Pour en savoir plus sur ces types, consultez la documentation du projet Prometheus et les types de métriques Cloud Monitoring ValueType et MetricKind.

La principale distinction à faire avec les SLI est que toutes les métriques ne sont pas des SLI. Le Classeur d'ingénierie SRE indique d'ailleurs ce qui suit (souligné) :

"…nous recommandons généralement de traiter le SLI comme le rapport entre deux nombres : le nombre d'événements satisfaisants divisé par le nombre total d'événements..."

"Le SLI varie donc de 0 % à 100 %, où 0 % signifie que rien ne fonctionne et 100 % signifie que tout fonctionne. Nous avons trouvé cette échelle intuitive, et ce style se prête facilement au concept de marge d'erreur."

De nombreux éditeurs de logiciels assurent le suivi de centaines de milliers de métriques, mais seules quelques-unes de ces métriques sont considérées comme des SLI. Hormis le ratio entre les événements satisfaisants et le nombre total d'événements, comment choisir une métrique qui ferait un bon SLI ? Une métrique qui ferait un bon SLI présente les caractéristiques suivantes :

• La métrique est directement liée à la satisfaction de l'utilisateur. En règle générale, les utilisateurs sont mécontents si un service ne se comporte pas comme prévu, s'il échoue ou s'il est lent. Tous les SLO basés sur ces métriques peuvent être validés en comparant votre SLI à d'autres signaux de satisfaction de l'utilisateur (par exemple, le nombre de réclamations, le volume d'appels d'assistance, le sentiment général qui se dégage sur les médias sociaux ou les signalements). Si votre métrique ne correspond pas à ces autres indicateurs de satisfaction des utilisateurs, l'utiliser comme SLI pourrait ne pas s'avérer judicieux.
• La détérioration d'une métrique dépend des interruptions et pannes. Une métrique qui semble correcte en cas d'interruption n'est pas une bonne métrique pour un SLI. De la même façon, une métrique qui semble incorrecte en fonctionnement normal n'est pas une bonne métrique pour un SLI.
• La métrique fournit un bon rapport signal sur bruit. Toute métrique qui génère un grand nombre de faux négatifs ou de faux positifs n'est pas un bon SLI.
• La métrique évolue de façon monotone et approximativement linéaire avec la satisfaction du client. À mesure que la métrique s'améliore, la satisfaction client s'améliore.

Examinons les graphiques du diagramme suivant. Deux métriques pouvant être utilisées comme SLI pour un service sont représentées graphiquement au fil du temps. La période pendant laquelle un service se dégrade est mise en évidence en rouge et la période pendant laquelle un service est satisfaisant est mise en évidence en bleu.

Dans le cas d'un mauvais SLI, le mécontentement de l'utilisateur ne correspond pas directement à un événement négatif (par exemple, une dégradation, une lenteur ou une interruption du service). En outre, le SLI varie indépendamment de la satisfaction des utilisateurs. Avec un bon SLI, le SLI et la satisfaction des utilisateurs sont corrélés, les différents niveaux de satisfaction sont clairs, et il y a beaucoup moins de fluctuations non pertinentes.

Sélectionner le nombre approprié de métriques

Généralement, un seul service possède plusieurs SLI, en particulier si le service effectue différents types de tâches ou gère différents types d'utilisateurs. Par exemple, séparer les requêtes de lecture des requêtes d'écriture est une bonne idée, car ces requêtes ont tendance à agir de différentes manières. Dans ce cas, il est préférable de sélectionner des métriques appropriées pour chaque service.

En revanche, de nombreux services effectuent des tâches similaires dans le service, qui peuvent être directement comparables. Par exemple, si vous disposez d'une place de marché en ligne, les utilisateurs peuvent consulter une page d'accueil, une sous-catégorie ou un Top 10, afficher une page d'informations ou rechercher des éléments. Au lieu de développer et de mesurer un SLI distinct pour chacune de ces actions, vous pouvez les combiner en une seule catégorie de SLI, par exemple, parcourir les services.

En réalité, les attentes d'un utilisateur ne changent pas beaucoup entre différentes actions d'une catégorie similaire. Leur satisfaction ne dépend pas de la structure des données qu'ils consultent, qu'elles proviennent d'une liste statique d'articles mis en avant ou qu'elles soient générées dynamiquement par une recherche assistée par machine learning sur un vaste ensemble de données. Leur satisfaction est quantifiable par une simple réponse à la question : "Ai-je pu consulter une page complète d'articles rapidement ?"

Idéalement, vous devez utiliser le moins de SLI possible pour représenter avec précision les tolérances d'un service donné. En règle générale, un service doit comporter entre deux et six SLI. Si vous avez trop peu de SLI, vous pouvez passer à côté de signaux utiles. Si vous disposez d'un trop grand nombre de SLI, votre équipe d'astreinte ne peut pas tous les suivre et leur utilité est marginale. N'oubliez pas que les SLI doivent simplifier votre compréhension de l'état de santé de production et fournir une vision d'ensemble de la couverture.

Choisir un SLO

Un SLO se compose des valeurs suivantes :

• Un SLI. Par exemple, le ratio entre le nombre de réponses avec le code HTTP 200 et le nombre total de réponses.
• Une durée. Période au cours de laquelle une métrique est mesurée. Cette période peut être basée sur un calendrier (du premier jour du mois au premier jour du mois suivant, par exemple) ou sur une période glissante (les 30 derniers jours, par exemple).
• Une cible. Par exemple, un pourcentage cible d'événements satisfaisants par rapport au nombre total d'événements (99,9 %, par exemple) que vous prévoyez pendant une durée donnée.

Lorsque vous développez un SLO, il peut être difficile de définir la durée et la cible. Une méthode pour commencer le processus consiste à identifier les SLI et à les suivre au fil du temps. Si vous ne parvenez pas à choisir la durée et la cible à utiliser, n'oubliez pas que votre SLO n'a pas besoin d'être parfait immédiatement. Vous devrez probablement réitérer votre SLO pour vous assurer qu'il concorde avec la satisfaction client et qu'il répond aux besoins de votre entreprise. Vous pouvez commencer avec deux 9 (99,0 %) pendant un mois.

Lorsque vous effectuez le suivi de conformité des SLO lors d'événements tels que des déploiements, des interruptions ou un trafic quotidien normal, vous pouvez mieux comprendre quelle cible est correcte, incorrecte ou même tolérable. Par exemple, pour un processus d'arrière-plan, vous pouvez définir 75 % de réussite comme une valeur adéquate. Toutefois, pour les requêtes critiques des utilisateurs, vous pouvez viser une valeur plus stricte, comme 99,95 %.

Bien entendu, il n'existe aucun SLO applicable à tous les cas d'utilisation. Les SLO dépendent de plusieurs facteurs :

• attentes des clients
• type de charge de travail
• infrastructure pour la diffusion, l'exécution et la surveillance
• complexité de votre domaine

La seconde partie de cette série, Adopter des SLO, se concentre sur les SLO indépendants du domaine. Les SLO indépendants du domaine (tels que la disponibilité du service) ne remplacent pas les indicateurs de haut niveau (tels que les widgets vendus par minute). Toutefois, ils peuvent vous aider à déterminer si un service fonctionne, quel que soit le cas d'utilisation de l'entreprise.

Les indicateurs indépendants du domaine peuvent souvent être réduits à une simple question : par exemple, "Le service est-il disponible ?" ou "Le service est-il suffisamment rapide ?" La réponse se trouve le plus souvent dans un SLO tenant compte de deux facteurs : la disponibilité et la latence. Vous pouvez décrire un SLO dans les termes suivants, où X = 99,9 % et Y = 800 ms :

X % des requêtes valides aboutissent et elles aboutissent plus vite que Y ms.

Étape suivante

• Consultez la section Adopter des SLO, qui explore ces définitions plus en détail et présente d'autres SLI qui pourraient être plus appropriés pour différents types de charges de travail.
• Consultez d'autres ressources d'ingénierie SRE :
  • Le Livre d'ingénierie SRE
  • Le Classeur d'ingénierie SRE
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.
• Consultez nos ressources sur DevOps.
• Obtenez davantage d'informations sur les capacités DevOps associées à cette série :
  • Surveillance et observabilité
  • Systèmes de surveillance permettant d'éclairer les décisions métier
  • Notification proactive des échecs
• Effectuez l'évaluation DevOps rapide pour comprendre votre position par rapport au reste du secteur.

Adopter des SLO

Ce document définit plusieurs objectifs de niveau de service (SLO) utiles pour différents types de charges de travail de service courantes. Il s'agit de la première partie d'une série comprenant deux volets. La partie 1, Définir des SLO, présente les SLO, montre comment les SLO dérivent des indicateurs de niveau de service (SLI) et décrit ce qui constitue un bon SLO.

Les rapports sur l'état du DevOps identifient les capacités qui améliorent les performances de livraison de logiciels. Ces deux documents vous aideront à effectuer les opérations suivantes :

• Surveillance et observabilité
• Systèmes de surveillance permettant d'éclairer les décisions métier
• Notification proactive des échecs

Données à évaluer

Quel que soit votre domaine, de nombreux services partagent des fonctionnalités communes et peuvent utiliser des SLO génériques. La démonstration suivante sur les SLO génériques est organisée par type de service et fournit des explications détaillées sur les SLI qui s'appliquent à chaque SLO.

Services basés sur des requêtes

Un service basé sur des requêtes reçoit une requête d'un client (un autre service ou un utilisateur), effectue un calcul, envoie éventuellement des requêtes réseau à un backend, puis renvoie une réponse au client. Les services basés sur des requêtes sont le plus souvent mesurés par des SLI de disponibilité et de latence.

Disponibilité en tant que SLI

Le SLI de disponibilité indique si le service fonctionne. Le SLI de disponibilité est défini comme suit :

La proportion de requêtes valides traitées avec succès.

Vous devez d'abord définir ce qui est valide. Certaines définitions de base peuvent être "non nulles" ou "adhérées à un protocole client-serveur", mais il appartient à un propriétaire de service de définir ce qu'il considère valide. Une méthode courante pour évaluer la validité consiste à utiliser un code de réponse HTTP (ou RPC). Par exemple, nous considérons souvent les erreurs HTTP 500 comme des erreurs de serveur qui sont comptabilisées dans un SLO et les erreurs 400 comme des erreurs du client qui ne le sont pas.

Une fois que vous avez choisi ce que vous souhaitez évaluer, vous devez examiner chaque code de réponse renvoyé par votre système pour vous assurer que l'application les utilise correctement et de manière cohérente. Lorsque vous utilisez des codes d'erreur pour des SLO, il est important de vous demander si un code est un indicateur précis de l'expérience utilisateur de votre service. Par exemple, si un utilisateur tente de commander un article en rupture de stock, le site est-il interrompu et renvoie-t-il un message d'erreur ou suggère-t-il des produits similaires ? Pour être utilisées avec les SLO, les codes d'erreur doivent être liés aux attentes des utilisateurs.

Les développeurs peuvent faire un usage abusif des erreurs. Dans le cas où un utilisateur demande un produit temporairement indisponible, un développeur peut programmer à tort le renvoi d'une erreur, alors que le système fonctionne correctement. Le code doit être renvoyé comme réussi, même si l'utilisateur n'a pas pu acheter l'article souhaité. Bien sûr, les propriétaires du service doivent savoir qu'un produit est en rupture de stock, mais l'impossibilité de réaliser la vente n'est pas une erreur du point de vue du client et ne doit pas être comptabilisée dans un SLO. Cependant, si le service ne peut pas se connecter à la base de données pour déterminer si l'article est en stock, cette erreur est comptabilisée dans votre marge d'erreur.

Votre service peut être plus complexe. Par exemple, il se peut qu'il gère des requêtes asynchrones ou qu'il fournisse un processus s'exécutant longuement aux clients. Dans ces cas, vous pourriez indiquer la disponibilité d'une autre manière. Toutefois, nous vous recommandons de représenter encore la disponibilité en tant que proportion de requêtes valides qui réussissent. Vous pourriez définir la disponibilité comme étant le nombre de minutes pendant lesquelles la charge de travail d'un client s'exécute comme demandé. (On appelle parfois cette approche méthode des "bonnes minutes" de mesure de la disponibilité.) Dans le cas d'une machine virtuelle, vous pourriez mesurer la disponibilité comme étant la proportion de minutes après une requête initiale pour une VM pendant lesquelles la VM est accessible via SSH.

Latence en tant que SLI

Le SLI de latence (parfois appelé vitesse) indique si le service est suffisamment rapide. Le SLI de latence est défini de la même manière que la disponibilité :

La proportion de requêtes valides diffusées plus rapidement qu'un certain seuil.

Vous pouvez évaluer la latence en calculant la différence entre le démarrage d'un minuteur et son arrêt pour un type de requête donné. La clé est la perception de latence d'un utilisateur. Un problème fréquent consiste à être trop précis pour mesurer la latence. En réalité, les utilisateurs ne peuvent pas faire la distinction entre une actualisation de 100 millisecondes (ms) et de 300 ms et peuvent accepter tout point compris entre 300 ms et 1 000 ms.

Au lieu de cela, il est recommandé de développer des métriques axées sur l'activité qui maintient l'attention de l'utilisateur, comme dans les processus suivants :

• Interactif : 1 000 ms correspondant au temps d'attente d'un utilisateur après avoir cliqué sur un élément.
• Écriture : 1 500 ms pour modifier un système distribué sous-jacent. Bien que cette durée soit considérée comme lente pour un système, les utilisateurs ont tendance à l'accepter. Nous vous recommandons de faire explicitement la distinction entre les écritures et les lectures dans vos métriques.
• Contexte : 5 000 ms pour une action non visible par l'utilisateur, telle qu'une actualisation périodique des données ou d'autres requêtes asynchrones.

La latence est couramment mesurée en tant que distribution (consultez la section Choisir un SLI dans la partie 1 de cette série). Avec une distribution, vous pouvez mesurer différents centiles. Par exemple, vous pouvez évaluer le nombre de requêtes qui sont plus lentes que le 99e centile de l'historique. Dans ce cas, nous considérons que les événements corrects sont des événements supérieurs à ce seuil, qui a été défini en examinant la distribution historique. Vous pouvez également définir ce seuil en fonction des exigences du produit. Vous pouvez même définir plusieurs SLO de latence, par exemple la latence typique par rapport à la latence de queue.

Nous vous recommandons de ne pas utiliser uniquement la latence moyenne (ou médiane) comme SLI. SI vous découvrez que la latence médiane est trop lente, cela signifie que la moitié de vos utilisateurs ne sont pas heureux. En d'autres termes, la latence peut être mauvaise pendant des jours avant de détecter une réelle menace pour votre marge d'erreur à long terme. Par conséquent, nous vous recommandons de définir votre SLO pour la latence de queue (95e centile) et pour la latence médiane (50e centile).

Dans l'article d'ACM Métriques importantes, Benjamin Tinyor Sloss écrit ce qui suit :

Une bonne règle de base...est que la latence du 99e centile ne doit pas dépasser de trois à cinq fois la latence médiane."

Treynor Sloss continue :

"Les valeurs des 50e, 95e et 99e centiles de latence d'un service ont chacune leur utilité et les SLO doivent être définis idéalement autour de ces valeurs."

Un bon modèle à suivre consiste à déterminer vos seuils de latence en fonction des centiles historiques, puis de déterminer le nombre de requêtes comprises dans chaque bucket. Pour en savoir plus, consultez la section sur les alertes de latence plus loin dans ce document.

Qualité en tant que SLI

La qualité est un SLI utile pour les services complexes conçus pour échouer en se dégradant lorsque les dépendances sont lentes ou indisponibles. Le SLI de qualité est défini comme suit :

La proportion de requêtes valides diffusées sans que le service se dégrade.

Par exemple, une page Web peut charger son contenu principal à partir d'un datastore et un auxiliaire de chargement, des éléments facultatifs provenant de 100 autres services et datastores. Si un service facultatif est hors service ou trop lent, la page peut toujours être affichée sans les éléments auxiliaires. En mesurant le nombre de requêtes qui reçoivent une réponse dégradée (c'est-à-dire une réponse n'ayant pas reçu au moins une réponse d'un service de backend), vous pouvez signaler le taux de requêtes insatisfaisantes. Vous pouvez même effectuer le suivi du nombre de réponses à l'utilisateur n'ayant pas reçu de réponse d'un ou de plusieurs backends.

Services de traitement des données

Certains services ne sont pas conçus pour répondre aux requêtes utilisateur. Ils utilisent plutôt les données d'une entrée, traitent ces données et génèrent une sortie. L'exécution de ces services lors des étapes intermédiaires n'est pas aussi importante que le résultat final. Avec ces services, les SLI les plus performants sont l'actualisation, la couverture, l'exactitude et le débit, et non la latence et la disponibilité.

Actualité en tant que SLI

Le SLI d'actualisation est défini comme suit :

La proportion de données valides qui est mise à jour plus récemment qu'un certain seuil.

Dans les systèmes de traitement par lots, par exemple, l'actualisation peut être évaluée en tant que temps écoulé depuis la fin de l'exécution du traitement pour un résultat donné. Dans les systèmes de traitement plus complexes ou en temps réel, vous pouvez suivre l'âge du dernier enregistrement traité dans un pipeline.

Prenons l'exemple d'un jeu en ligne qui génère des tuiles d'un plan en temps réel. Il est possible que les utilisateurs ne remarquent pas la vitesse de création des tuiles du plan, mais qu'ils remarquent l'absence ou la non actualisation des données du plan.

Vous pouvez également envisager d'utiliser un système qui lit les enregistrements d'un système de suivi en stock pour générer le message "X articles en stock" pour un site Web de commerce électronique. Vous pouvez définir le SLI d'actualisation comme suit :

Le pourcentage de vues qui ont utilisé les informations sur le stock qui ont été actualisées au cours de la dernière minute.

Vous pouvez également utiliser une métrique pour diffuser des données non actualisées afin d'informer le SLI de qualité.

Couverture en tant que SLI

Le SLI de couverture est défini comme suit :

La proportion de données valides qui a bien été traitée.

Pour définir la couverture, vous devez d'abord déterminer si une entrée doit être acceptée comme valide ou ignorée. Par exemple, si un enregistrement d'entrée est corrompu ou présente une longueur nulle et ne peut pas être traité, vous pourriez considérer cet enregistrement comme non valide pour mesurer votre système.

Vous devez ensuite compter le nombre d'enregistrements valides. Vous pouvez effectuer cette étape avec une méthode count() simple ou une autre méthode. Il s'agit du nombre total d'enregistrements.

Enfin, afin de générer votre SLI pour la couverture, vous comptez le nombre d'enregistrements traités avec succès et comparez ce nombre au nombre total d'enregistrements valides.

Exactitude en tant que SLI

Le SLI d'exactitude est défini comme suit :

La proportion de données valides ayant généré un résultat correct.

Dans certains cas, il existe des méthodes permettant de déterminer l'exactitude d'un résultat pouvant être utilisé pour valider le traitement de la sortie. Par exemple, un système qui fait pivoter ou colorise une image ne doit jamais produire une image de zéro octet, ou une image dont la longueur ou la largeur est égale à zéro. Il est important de séparer cette logique de validation de la logique de traitement elle-même.

Une méthode permettant de mesurer un SLI d'exactitude consiste à utiliser des données d'entrée de test connues, c'est-à-dire des données qui ont une sortie correcte connue. Les données d'entrée doivent être représentatives des données utilisateur. Dans d'autres cas, il est possible qu'une vérification mathématique ou logique puisse être effectuée sur la sortie, comme dans l'exemple précédent de rotation d'une image. Un autre exemple peut être un système de facturation qui détermine si une transaction est valide en vérifiant si la différence entre le solde avant la transaction et après la transaction correspond à la valeur de la transaction elle-même.

Débit en tant que SLI

Le SLI de débit est défini comme suit :

La proportion de temps où le taux de traitement des données était plus rapide qu'un seuil.

Dans un système de traitement de données, le débit est souvent plus représentatif de la satisfaction des utilisateurs que, par exemple, une seule évaluation de la latence pour un travail donné. Par exemple, si la taille de chaque entrée varie considérablement, il peut être inutile de comparer la durée d'exécution de chaque élément si une tâche avance à une vitesse acceptable.

Les octets par seconde sont un moyen courant d'évaluer la quantité de travail nécessaire au traitement des données, quelle que soit la taille d'un ensemble de données. Cependant, toute métrique qui évolue de manière linéaire par rapport au coût de traitement peut fonctionner.

Il peut être utile de partitionner vos systèmes de traitement des données en fonction des taux de débit attendus, ou de mettre en œuvre un système de qualité de service pour garantir le traitement des entrées à priorité élevée et la mise en file d'attente des entrées à faible priorité. Dans les deux cas, la mesure du débit telle que définie dans cette section peut vous aider à déterminer si votre système fonctionne comme prévu.

Services d'exécution planifiée

Pour les services qui doivent effectuer une action à intervalles réguliers, tels que les tâches Cron Kubernetes, vous pouvez évaluer le décalage et la durée d'exécution. Voici un exemple de tâche Cron Kubernetes planifiée :

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

Décalage en tant que SLI

Le SLI de décalage est défini comme suit :

La proportion d'exécutions qui commencent dans un intervalle acceptable de l'heure de début attendue

.

Le décalage évalue la différence entre le moment où une tâche est planifiée et celui où elle démarre. Par exemple, si la tâche Cron Kubernetes précédente, configurée pour démarrer à la minute zéro de chaque heure, commence trois minutes après, le décalage est de trois minutes. Lorsqu'une tâche s'exécute en avance, le décalage est négatif.

Vous pouvez évaluer le décalage en tant que distribution dans le temps, avec des plages acceptables qui définissent un décalage correct. Pour déterminer le SLI, vous devez comparer le nombre d'exécutions comprises dans une plage acceptable.

Exécution en tant que SLI

En tant que SLI, la durée d'exécution est définie comme suit :

La proportion d'exécutions qui se terminent dans l'intervalle de temps acceptable.

La durée d'exécution correspond au temps nécessaire à la réalisation d'une tâche. Pour une exécution donnée, un mode d'échec courant consiste à ce que la durée réelle dépasse la durée programmée.

Il est intéressant de savoir comment appliquer ce SLI pour intercepter une tâche interminable. Étant donné que ces tâches ne se terminent pas, vous devez enregistrer le temps passé sur une tâche donnée au lieu d'attendre qu'elle se termine. Cette approche fournit une répartition précise de la durée du travail à effectuer, même dans le pire des cas.

Comme pour le décalage, vous pouvez suivre la durée d'exécution comme une distribution et définir des limites supérieures et inférieures acceptables pour les événements satisfaisants.

Types de métriques pour d'autres systèmes

De nombreuses autres charges de travail ont leurs propres métriques que vous pouvez utiliser pour générer des SLI et des SLO. Prenons les exemples suivants :

• Systèmes de stockage : durabilité, débit, délai avant le premier octet, disponibilité des objets blob
• Média/vidéo : continuité de lecture du client, délai de démarrage de la lecture, exhaustivité du transcodage de l'exécution de graphe
• Jeux vidéo : temps nécessaire pour associer les joueurs actifs et temps nécessaire pour générer une carte

Comment effectuer l'évaluation

Une fois que vous savez ce que vous évaluez, vous pouvez décider comment l'évaluer. Vous pouvez recueillir vos SLI de plusieurs manières.

Journalisation côté serveur

Méthode de génération des SLI

Traiter des journaux côté serveur de requêtes ou de données traitées.

Remarques

Avantages :

• Les journaux existants peuvent être traités à nouveau pour remplir les enregistrements SLI historiques.
• Les identifiants de session interservices peuvent reconstruire des parcours utilisateur complexes sur plusieurs services.

Inconvénients :

• Les requêtes qui n'arrivent pas au serveur ne sont pas enregistrées.
• Il est possible que les requêtes qui provoquent le plantage d'un serveur ne soient pas enregistrées.
• La durée de traitement des journaux peut entraîner des SLI obsolètes, ce qui peut être problématique pour une réponse opérationnelle.
• L'écriture du code pour traiter des journaux peut être une tâche chronophage et une source d'erreurs.

Méthodes et outils de mise en œuvre :

• BigQuery
• Dataflow, Apache Spark
• Splunk

Métriques des serveurs d'applications

Méthode de génération des SLI

Exportation de métriques des SLI à partir du code qui diffuse les requêtes des utilisateurs ou traite leurs données

Remarques

Avantage :

• L'ajout de nouvelles métriques dans le code est généralement rapide et peu coûteux.

Inconvénients :

• Les requêtes qui n'arrivent pas aux serveurs d'applications ne sont pas enregistrées.
• Les requêtes multiservices peuvent être difficiles à suivre.

Méthodes et outils de mise en œuvre :

• Cloud Monitoring
• Prometheus
• Produits APM tiers

Métriques de l'infrastructure d'interface

Méthode de génération des SLI

Utilisation des métriques de l'infrastructure d'équilibrage de charge (par exemple, l'équilibreur de charge global de couche 7 de Google Cloud)

Remarques

Avantages :

• Souvent, les métriques et les données historiques existent déjà, ce qui réduit les efforts d'ingénierie pour commencer.
• Les évaluations sont réalisées au point le plus proche du client, mais au sein de l'infrastructure de diffusion.

Inconvénients :

• Non viable pour les SLI de traitement des données.
• Permet uniquement d'estimer les parcours utilisateur à requêtes multiples.

Méthodes et outils de mise en œuvre :

• Cloud Monitoring
• Métriques CDN/LB ou API de création de rapports (Cloudflare, Akamai, Fastly)

Clients ou données synthétiques

Méthode de génération des SLI

Création d'un client qui envoie des requêtes fabriquées à intervalles réguliers et valide les réponses. Pour les pipelines de traitement de données, la création de données d'entrée synthétiques connues correctes et la validation des sorties.

Remarques

Avantages :

• Toutes les étapes d'un parcours utilisateur à requêtes multiples sont évaluées.
• Envoyer des requêtes depuis l'extérieur de votre infrastructure permet de capturer une plus grande partie du chemin de requête global dans le SLI.

Inconvénients :

• Estimation approximative de l'expérience utilisateur avec des requêtes synthétiques, qui peuvent prêter à confusion (faux positifs ou faux négatifs).
• La couverture de tous les cas particuliers est complexe et peut faire l'objet de tests d'intégration.
• Les cibles à haute fiabilité nécessitent des vérifications fréquentes pour des évaluations précises.
• Le trafic de vérification peut dépasser le trafic réel.

Méthodes et outils de mise en œuvre :

• Tests de disponibilité Cloud Monitoring
• Solutions Open Source :
  • Cloudprober
  • blackbox_exporter
• Solutions du fournisseur :
  • Catchpoint Synthetic Monitoring
  • New Relic Synthetics
  • Datadog Synthetic Monitoring

Instrumentation du client

Méthode de génération des SLI

Ajout de fonctionnalités d'observabilité au client avec lequel l'utilisateur interagit, et journalisation des événements sur votre infrastructure de diffusion qui effectue le suivi des SLI

Remarques

Avantages :

• Fournit l'évaluation la plus précise de l'expérience utilisateur.
• Peut quantifier la fiabilité des tiers, par exemple les fournisseurs de CDN ou de services de paiement.

Inconvénients :

• La latence d'ingestion et de traitement des journaux client rend ces SLI inappropriés pour déclencher une réponse opérationnelle.
• L'évaluation des SLI contiendront un certain nombre de facteurs hautement variables qui peuvent échapper au contrôle direct.
• Intégrer une instrumentation au client peut impliquer beaucoup de travail d'ingénierie.

Méthodes et outils de mise en œuvre :

• Google Analytics, Firebase
• Analyse des utilisateurs : Amplitude et outils similaires
• Surveillance des mobiles et des interfaces : New Relic Browser, Raygun Real User Monitoring, Sentry
• Client et serveur personnalisés pour enregistrer et suivre

Choisir une méthode d'évaluation

Dans l'idéal, vous devez choisir une méthode de mesure qui correspond le mieux à l'expérience de votre client par rapport à votre service et qui nécessite le moins d'efforts de votre part. Pour atteindre cet idéal, vous devrez peut-être utiliser une combinaison des méthodes des tables précédentes. Voici une approche que vous pouvez mettre en œuvre au fil du temps, répertoriée par ordre d'efforts croissants :

1. Utiliser les exportations du serveur d'applications et les métriques d'infrastructure : en règle générale, vous pouvez accéder immédiatement à ces métriques et elles fournissent rapidement une valeur. Certains outils APM incluent des outils de SLO intégrés.
2. Utilisation de l'instrumentation du client : étant donné que les anciens systèmes ne disposent généralement pas d'une instrumentation intégrée du client final, l'instrumentation peut entraîner un investissement important. Toutefois, si vous utilisez une suite APM ou un framework d'interface fournissant une instrumentation client, vous pouvez rapidement obtenir des informations sur la satisfaction de vos clients.
3. Utilisation du traitement des journaux : si vous ne pouvez pas mettre en œuvre des exportations de serveurs ou l'instrumentation du client mais que des journaux existent, le traitement des journaux est peut-être la solution idéale pour vous. Une autre approche consiste à combiner les exportations et le traitement des journaux, en utilisant les exportations comme source immédiate pour certains SLI (tels que la disponibilité immédiate) et le traitement des journaux pour les indicateurs à long terme (comme les alertes lentes décrites plus loin dans la section concernant les SLO et alertes).
4. Mettre en œuvre des tests synthétiques : une fois que vous avez une bonne compréhension de l'utilisation de votre service par vos clients, vous pouvez tester votre niveau de service. Par exemple, vous pouvez alimenter les comptes de test avec des données correctes et effectuer une requête. Ces tests peuvent vous aider à mettre en évidence les modes de défaillance qui ne sont pas facilement observés, par exemple dans le cas de services à faible trafic.

Définir vos objectifs

L'un des meilleurs moyens de définir des objectifs consiste à créer un document partagé décrivant vos SLO et la manière dont vous les avez développés. Votre équipe peut effectuer des itérations sur le document au fur et à mesure de sa mise en œuvre et de son itération sur les SLO.

Nous recommandons aux propriétaires d'entreprise, aux propriétaires de produits et aux responsables d'examiner ce document. Ceux-ci peuvent fournir des renseignements sur les attentes en matière de service et les compromis de fiabilité du produit.

Voici un modèle permettant de développer un SLO pour les parcours utilisateur les plus importants (CUJ, Critical User Journey) pour votre entreprise :

1. Choisissez une spécification SLI (par exemple, disponibilité ou actualisation).
2. Définissez le mode de mise en œuvre de la spécification SLI.
3. Lisez attentivement votre plan pour vous assurer que les CUJ sont pris en compte.
4. Définissez des SLO en fonction des performances passées ou des besoins de l'entreprise.

Les CUJ ne doivent pas être limités à un seul service, ni à une seule équipe de développement ou une seule organisation. Si vos utilisateurs dépendent de centaines de microservices qui fonctionnent à 99,5 %, mais personne n'effectue le suivi de la disponibilité de bout en bout, votre client n'est probablement pas satisfait.

Supposons que vous ayez une requête qui dépend de cinq services fonctionnant en séquence : un équilibreur de charge, une interface, un mélangeur, un backend et une base de données.

Si chaque composant dispose d'une disponibilité de 99,5 %, la disponibilité la plus basse pour les utilisateurs est la suivante :

99,5 % x 99,5 % x 99,5 % x 99,5 % x 99,5 % = 97,52 %

Il s'agit de la disponibilité la plus basse pour les utilisateurs, car le système global échoue si l'un des cinq services échoue. Cela ne serait vrai que si toutes les couches de la pile doivent toujours être immédiatement disponibles pour gérer chaque requête utilisateur, sans facteurs de résilience tels que les nouvelles tentatives d'exécution intermédiaires, les caches ou les files d'attente. Un système avec un couplage étroit entre les services est une mauvaise conception et s'oppose au modèle de microservices.

Le simple fait de mesurer les performances par rapport au SLO d'un système distribué de cette manière (service par service) ne reflète pas exactement l'expérience de votre client et peut donner lieu à une interprétabilité trop sensible.

Au lieu de cela, vous devez mesurer les performances par rapport au SLO au niveau de l'interface afin de comprendre l'expérience des utilisateurs. Si un service de composants échoue et qu'une requête est automatiquement générée et relancée, cela n'a aucune importance pour l'utilisateur tant que sa requête aboutit. Si vous avez partagé des services internes, ces services peuvent mesurer séparément les performances par rapport à leurs SLO, les services visibles par l'utilisateur servant de clients. Vous devez gérer ces SLO séparément les uns des autres.

Il est possible de créer un service à disponibilité élevée (par exemple, 99,99 %) sur un service moins disponible (par exemple, 99,9 %) en utilisant des facteurs de résilience tels que les nouvelles tentatives d'exécution intelligentes, la mise en cache et la mise en file d'attente.

En règle générale, quiconque ayant une connaissance pratique des statistiques devrait pouvoir lire et comprendre votre SLO sans comprendre votre service ou mise en page organisationnelle sous-jacents.

Exemple de feuille de calcul de SLO

Lorsque vous développez votre SLO, n'oubliez pas de procéder comme suit :

• Assurez-vous que vos SLI spécifient un événement, un critère de réussite et où et comment vous enregistrez le succès ou l'échec.
• Définissez la spécification SLI en termes de proportion d'événements satisfaisants.
• Assurez-vous que votre SLO spécifie un niveau cible et une période d'évaluation.
• Décrivez les avantages et les inconvénients de votre approche pour que les parties intéressées comprennent les compromis et les subtilités impliqués.

Prenons l'exemple de la feuille de calcul de SLO suivante.

CUJ : chargement de la page d'accueil

Type de SLI : latence Spécification du SLI : proportion de requêtes de page d'accueil diffusées en moins de 100 ms Mises en œuvre du SLI : Proportions de requêtes de page d'accueil diffusées en moins de 100 ms, évaluées à partir de la colonne de latence du journal du serveur (Inconvénient : cette évaluation ne prend pas en compte les requêtes qui n'atteignent pas le backend.) Proportion de requêtes de page d'accueil diffusées en moins de 100 ms, évaluées par les vérificateurs qui exécutent JavaScript dans un navigateur exécuté sur une machine virtuelle (Avantages et inconvénients : cette évaluation détecte les erreurs lorsque les requêtes ne peuvent pas atteindre le réseau, mais peut passer à côté des problèmes affectant uniquement un sous-ensemble d'utilisateurs.) SLO : 99 % des requêtes de page d'accueil au cours des 28 derniers jours ont été traitées en moins de 100 ms.

Remarque : Si vous n'êtes pas en mesure de vous mettre d'accord en tant qu'équipe au niveau de la cible, choisissez un autre niveau et acceptez d'y revenir dessus dans un délai de six mois. Il est préférable de choisir un nombre incorrect plutôt que d'en choisir aucun.

Étape suivante

• Lisez The Art of SLOs (L'art des SLO), un atelier développé par l'équipe Google chargée de l'ingénierie en fiabilité client.
• Suivez le cours en ligne Site Reliability Engineering: Measuring and Managing Reliability (Ingénierie en fiabilité des sites : évaluation et gestion de la fiabilité).
• Consultez la page Site Reliability Engineering: Implementing SLOs (Ingénierie en fiabilité des sites : mettre en œuvre des SLO).
• Consultez la page Concepts de surveillance des services.
• Consultez la page Développer des SLO avec Cloud Monitoring.
• Essayez le Générateur de SLO flexible de la Professional Services Organization de Google (PSO).
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.
• Consultez nos ressources sur DevOps.
• Obtenez davantage d'informations sur les capacités DevOps associées à cette série :
  • Surveillance et observabilité
  • Systèmes de surveillance permettant d'éclairer les décisions métier
  • Notification proactive des échecs
• Effectuez l'évaluation DevOps rapide pour comprendre votre position par rapport au reste du secteur.

Terminologie

Ce document fournit des définitions courantes pour les termes liés au SLO qui sont utilisés dans la section Framework d'architecture Google Cloud : Fiabilité.

• niveau de service : mesure des performances attendues par l'utilisateur d'un service donné. Vous pouvez décrire cette mesure en termes de satisfaction des utilisateurs et la mesurer selon différentes méthodes, en fonction de ce que fait le service et de ce que l'utilisateur attend de lui ou des capacités qui lui ont été communiquées.

  Exemple : "Un utilisateur attend de notre service qu'il soit disponible et rapide".

• parcours utilisateur critique (CUJ, Critical User Journey) : ensemble des interactions entre un utilisateur et un service pour atteindre un seul objectif, par exemple un simple clic ou un pipeline en plusieurs étapes.

  Exemple : "Un utilisateur clique sur le bouton de paiement et attend la réponse spécifiant que le panier d'achat est traité, suivie de l'envoi d'un reçu."

• indicateur de niveau de service (SLI, Service Level Indicator) : jauge de satisfaction des utilisateurs qui peut être mesuré de manière quantitative pour un niveau de service. En d'autres termes, pour mesurer un niveau de service, vous devez mesurer un indicateur qui représente la satisfaction des utilisateurs eu égard à ce niveau de service, par exemple la disponibilité d'un service. Un SLI peut être considéré comme une ligne sur un graphique qui change au fil du temps, à mesure que le service s'améliore ou se dégrade. Il s'agit généralement d'un ratio des requêtes ayant abouti par rapport au nombre total de requêtes, exprimé en pourcentage sans unité. En utilisant systématiquement ces pourcentages, les équipes peuvent comprendre le SLI sans connaître sa mise en œuvre.

  Exemple : "Mesurer le nombre de requêtes ayant abouti au cours des 10 dernières minutes, puis le diviser par le nombre de requêtes valides au cours des 10 dernières minutes".

• objectif de niveau de service (SLO, Service Level Objective) : niveau qu'un service est supposé atteindre la plupart du temps et par rapport auquel un SLI est mesuré.

  Exemple : "Le service doit répondre en moins de 400 millisecondes (ms) pour 95 % des requêtes valides mesurées sur 14 jours."

  

• contrat de niveau de service (SLA, Service Level Agreement) : description de ce qui doit se produire si un SLO n'est pas atteint. Généralement, un contrat de niveau de service est un accord juridique entre les fournisseurs et les clients, et peut même inclure des conditions de compensation. Dans les discussions techniques sur l'ingénierie SRE, ce terme est souvent évité.

  Exemple : "Si le service ne fournit pas une disponibilité de 99,95 % sur un mois calendaire, le fournisseur de services compense le client pour chaque minute non conforme".

• marge d'erreur : durée ou nombre d'événements négatifs possible avant d'être en échec pour votre SLO. Cette mesure indique le nombre d'erreurs auquel votre entreprise peut s'attendre ou qu'elle peut tolérer. Cette marge d'erreur est essentielle pour vous aider à prendre des décisions potentiellement risquées.

  Exemple : "Si notre SLO prévoit une disponibilité de 99,9 %, nous autorisons un taux d'erreur de 0,1 % pour les requêtes, qu'il s'agisse d'incidents, d'accidents ou de tests."

SLO et alertes

Ce document de la section Framework d'architecture Google Cloud : Fiabilité fournit des détails sur les alertes concernant les SLO.

Une approche erronée lors de l'introduction d'un nouveau système d'observabilité comme celui des SLO consiste à complètement remplacer un ancien système par le nouveau. À la place, vous devez voir les SLO comme un système complémentaire. Par exemple, au lieu de supprimer vos alertes existantes, nous vous recommandons de les exécuter en parallèle avec les alertes SLO mentionnées ici. Cette approche vous permet d'identifier les anciennes alertes prévisibles des alertes SLO, celles qui se déclenchent en parallèle avec vos alertes SLO, et celles qui ne se déclenchent jamais.

Un principe d'ingénierie SRE consiste à envoyer des alertes en fonction des symptômes, et non des causes. Les SLO sont, par nature, des évaluation des symptômes. À mesure que vous adoptez des alertes SLO, vous pouvez constater que l'alerte des symptômes se déclenche avec d'autres alertes. Si vous constatez que vos anciennes alertes basées sur les causes se déclenchent sans SLO ni symptômes, elles peuvent être complètement désactivées, transformées en alertes relatives à la gestion des requêtes ou consignées pour être consultées ultérieurement.

Pour plus d'informations, consultez le classeur d'ingénierie SRE, chapitre 5.

Taux d'utilisation des SLO

Le taux d'utilisation d'un SLO permet de mesurer la rapidité avec laquelle une indisponibilité expose les utilisateurs aux erreurs et consomme la marge d'erreur. En mesurant votre taux d'utilisation, vous pouvez déterminer le temps s'écoulant avant qu'un service ne viole son SLO. Les alertes basées sur le taux d'utilisation de SLO sont une approche intéressante. N'oubliez pas que votre SLO repose sur une durée, qui peut être très longue (des semaines, voire des mois). Toutefois, l'objectif est de détecter rapidement une condition qui entraîne une violation de SLO avant que cette violation ne se produise.

Le tableau suivant indique le temps nécessaire pour dépasser un objectif si 100 % des requêtes échouent pour l'intervalle spécifié, en supposant que le nombre de requêtes par seconde (RPS) est constant. Par exemple, si un SLO de 99,9 % est mesuré sur une période de 30 jours, vous pouvez supporter 43,2 minutes de temps d'arrêt complet pendant cette période. Par exemple, ce temps d'arrêt peut survenir en une seule fois ou se répartir sur plusieurs incidents.

Objectif	90 jours	30 jours	7 jours	1 jour
90 %	9 jours	3 jours	16,8 heures	2,4 heures
99 %	21,6 heures	7,2 heures	1,7 heure	14,4 minutes
99,9 %	2,2 heures	43,2 minutes	10,1 minutes	1,4 minute
99,99 %	13 minutes	4,3 minutes	1 minute	8,6 secondes
99,999 %	1,3 minute	25,9 secondes	6 secondes	0,9 secondes

En pratique, vous ne pouvez pas supporter d'incidents avec une interruption à 100 % si vous souhaitez atteindre des pourcentages élevés. Cependant, de nombreux systèmes distribués peuvent partiellement échouer ou se dégrader de manière concertée. Même dans ce cas, vous devez toujours savoir si une intervention humaine est nécessaire, même dans des échecs partiels, et les alertes SLO vous permettent de le déterminer.

Quand alerter

Une question importante consiste à savoir quand agir en fonction de votre taux d'utilisation de SLO. En règle générale, si vous épuisez votre marge d'erreur en 24 heures, le moment auquel appeler une personne pour résoudre un problème est maintenant.

Il n'est pas toujours simple d'évaluer le taux d'échec. Une série d'erreurs mineures peut sembler effrayante sur le moment, mais s'avérer de courte durée et n'avoir qu'un impact indirect sur votre SLO. De même, si un système est légèrement défectueux depuis longtemps, ces erreurs peuvent entraîner une violation du SLO.

Dans l'idéal, votre équipe réagira à ces signaux afin que vous dépensiez la quasi-totalité de votre marge d'erreur (mais sans la dépasser) pendant une période donnée. Si vous dépensez trop, vous enfreignez votre SLO. Si vous dépensez trop peu, vous ne prenez aucun risque ou vous risquez de surmener votre équipe d'astreinte.

Il vous faut un moyen de déterminer si un système est suffisamment défectueux pour qu'un humain intervienne. Les sections suivantes présentent certaines approches à cette question.

Utilisation rapide

L'un des types d'utilisation du SLO est une utilisation rapide du SLO, car il consomme rapidement votre marge d'erreur et nécessite votre intervention pour éviter la violation du SLO.

Supposons que votre service fonctionne normalement à 1 000 requêtes par seconde (RPS) et que vous souhaitez maintenir une disponibilité de 99 % telle que mesurée sur une semaine de sept jours. Votre marge d'erreur correspond à environ 6 millions d'erreurs autorisées (environ 600 millions de requêtes). Par exemple, si vous disposez de 24 heures avant l'épuisement de votre marge d'erreur, la limite est d'environ 70 erreurs par seconde, soit 252 000 erreurs par heure. Ces paramètres sont basés sur la règle générale selon laquelle les incidents nécessitant une intervention doivent consommer au moins 1 % de la marge d'erreur trimestriel.

Vous pouvez choisir de détecter ce taux d'erreurs avant qu'une heure ne soit écoulée. Par exemple, après avoir observé 15 minutes d'un taux d'erreur de 70 par seconde, vous pouvez décider de faire appel à l'ingénieur par téléphone, comme le montre le schéma suivant.

Idéalement, le problème est résolu avant que vous ne dépensiez une heure de votre marge d'erreur pour 24 heures. Le fait de choisir de détecter ce taux dans une période plus courte (par exemple, une minute) risque de générer trop d'erreurs. Si votre délai de détection est inférieur à 15 minutes, ce nombre peut être ajusté.

Utilisation lente

Un autre type de taux d'utilisation est l'utilisation lente. Supposons que vous introduisez un bug qui consomme votre marge d'erreur hebdomadaire au bout de cinq ou six jours, ou votre budget mensuel à la deuxième semaine. Quelle est la meilleure réponse ?

Dans ce cas, vous risquez d'introduire une alerte d'utilisation lente de SLO, qui vous informe que vous êtes sur le point d'épuiser votre marge d'erreur avant la fin de la période d'alerte. Bien entendu, cette alerte peut renvoyer de nombreux faux positifs. Par exemple, il arrive souvent que des erreurs surviennent brièvement, mais à un rythme qui consomme rapidement votre marge d'erreur. Dans ces cas, la condition est un faux positif, car elle ne dure que peu de temps et ne menace pas votre marge d'erreur à long terme. N'oubliez pas que l'objectif n'est pas de supprimer toutes les sources d'erreurs, mais de ne pas dépasser la plage acceptable pour ne pas dépasser votre marge d'erreur. Vous souhaitez éviter d'alerter un agent afin d'identifier les événements qui ne constituent pas une menace légitime de votre marge d'erreur.

Nous vous recommandons de prévenir une file d'attente de billets (plutôt que d'appeler ou d'envoyer un e-mail) en cas d'événements d'utilisation lente. Les événements d'utilisation lente ne sont pas des urgences, mais nécessitent une attention humaine avant l'expiration du budget. Ces alertes ne doivent pas être des e-mails adressés à une liste d'équipes, qui deviennent rapidement une gêne à ignorer. Les billets doivent être traçables, attribuables et transférables. Les équipes doivent développer des rapports sur la charge des billets, les taux de fermeture, les possibilités d'action et les doublons. Les billets inexploitables excessifs constituent un bon exemple de tâche laborieuse.

L'utilisation optimale des alertes SLO peut prendre du temps, et dépendre de la culture et des attentes de votre équipe. N'oubliez pas que vous pouvez affiner vos alertes SLO au fil du temps. Vous pouvez également utiliser plusieurs méthodes d'alerte avec différentes périodes d'alerte, en fonction de vos besoins.

Alertes de latence

En plus des alertes de disponibilité, vous pouvez également avoir des alertes de latence. Avec les SLO de latence, vous évaluez le pourcentage de requêtes qui n'atteignent pas une cible de latence. En utilisant ce modèle, vous pouvez utiliser le même modèle d'alerte que celui utilisé pour détecter les utilisations rapides ou lentes de votre marge d'erreur.

Comme indiqué plus haut à propos des SLO de latence médiane, la moitié de vos requêtes peuvent être hors du SLO. En d'autres termes, vos utilisateurs peuvent faire l'expérience d'une mauvaise latence pendant des jours avant que vous ne détectez l'impact sur votre marge d'erreur à long terme. Les services doivent plutôt définir des objectifs de latence de queue et des objectifs de latence typique. Nous vous suggérons d'utiliser le 90e centile historique pour définir la latence typique et le 99e centile pour la queue. Une fois ces cibles définies, vous pouvez définir des SLO en fonction du nombre de requêtes que vous prévoyez de recevoir dans chaque catégorie de latence et du nombre de requêtes trop lentes. Le concept de cette approche est identique à celui d'une marge d'erreur et doit être traitée de la même manière. Ainsi, vous pouvez obtenir une déclaration du type "90 % des requêtes seront traitées dans les limites de la latence typique et 99,9 % dans les limites de la latence de queue". Ces cibles garantissent que la plupart des utilisateurs feront l'expérience d'une latence typique, mais vous permettent de suivre le nombre de requêtes plus lentes que vos cibles de latence de queue.

Certains services peuvent disposer d'environnements d'exécution avec des variantes très élevées. Par exemple, pour un système de datastore, les attentes en termes de lecture peuvent être très différentes par rapport à celles d'écriture. Au lieu d'énumérer toutes les attentes possibles, vous pouvez introduire des buckets de performances d'exécution, comme le montrent les tableaux suivants. Cette approche suppose que ces types de requêtes sont identifiables et pré-.classés dans chaque bucket. Il ne faut pas s'attendre à classer les requêtes à la volée.

Site Web pour l'utilisateur
Bucket	Exécution maximale attendue
Lire	1 seconde
Écrire/Mettre à jour	3 secondes

Systèmes de traitement des données
Bucket	Exécution maximale attendue
S	10 secondes
M	1 minute
L	5 minutes
Géante	1 heure
Énorme	8 heures

En évaluant le système tel qu'il est actuellement, vous pouvez connaître le temps nécessaire à l'exécution de ces requêtes. Prenons l'exemple d'un système de traitement de vidéos mises en ligne. Si la vidéo est très longue, le temps de traitement doit être plus long. Nous pouvons utiliser la durée de la vidéo en secondes pour classer ce travail dans un bucket, comme le montre le tableau suivant. La table enregistre le nombre de requêtes par bucket et plusieurs centiles pour la distribution de l'exécution au cours de la semaine.

Durée de la vidéo	Nombre de requêtes évaluées en une semaine	10 %	90 %	99,95 %
S	0	-	-	-
M	1,9 million	864 millisecondes	17 secondes	86 secondes
L	25 millions	1,8 secondes	52 secondes	9,6 minutes
Géante	4,3 millions	2 secondes	43 secondes	23,8 minutes
Énorme	81 000	36 secondes	1,2 minute	41 minutes

À partir de cette analyse, vous pouvez déduire quelques paramètres d'alerte :

• fast_typical : au maximum, 10 % des requêtes sont plus rapides que ce délai. Si trop de requêtes sont plus rapides que ce délai, vos cibles sont peut-être incorrectes ou votre système a peut-être changé.
• slow_typical : au moins 90 % des requêtes sont plus rapides que ce délai. Cette limite permet d'augmenter votre SLO principal de latence. Ce paramètre indique si la plupart des requêtes sont suffisamment rapides.
• slow_tail : au moins 99,95 % des requêtes sont plus rapides que ce délai. Cette limite garantit qu'il n'y a pas trop de requêtes lentes.
• deadline : point auquel le RPC ou le traitement en arrière-plan de l'utilisateur expire et échoue (une limite généralement déjà codée en dur dans le système). Ces requêtes ne seront pas réellement lentes, mais auront réellement échoué avec une erreur et à la place sont comptabilisées dans votre SLO de disponibilité.

Dans le cadre de la définition de buckets, il est recommandé de conserver les valeurs fast_typical, slow_typical et slow_tail d'un bucket selon un ordre de grandeur défini. Cela vous permet de ne pas disposer d'un bucket trop large. Nous vous recommandons de ne pas essayer de prévenir les chevauchements ou les écarts entre les buckets.

Bucket	fast_typical	slow_typical	slow_tail	deadline
S	100 millisecondes	1 seconde	10 secondes	30 secondes
M	600 millisecondes	6 secondes	60 secondes (1 minute)	300 secondes
L	3 secondes	30 secondes	300 secondes (5 minutes)	10 minutes
Géante	30 secondes	6 minutes	60 minutes (1 heure)	3 heures
Énorme	5 minutes	50 minutes	500 minutes (8 heures)	12 heures

Ceci résulte dans une règle telle que api.method: SMALL => [1s, 10s]. Dans ce cas, le système de suivi SLO voit une requête, en détermine le bucket (peut-être en analysant son URI ou son nom de méthode et en comparant le nom à une table de conversion), puis met la statistique à jour en fonction de l'environnement d'exécution de cette requête. Si cela prend 700 millisecondes, c'est dans l'ordre de la valeur cible slow_typical. Si cela prend 3 millisecondes, c'est dans l'ordre de la valeur slow_tail. Si cela prend 22 millisecondes, c'est au-delà de la valeur slow_tail, sans encore constituer une erreur.

En termes de satisfaction utilisateur, la latence de queue manquante équivaut à l'indisponibilité. (La réponse est si lente que la réponse doit être considérée comme un échec.) C'est pourquoi nous vous suggérons d'utiliser le même pourcentage que celui utilisé pour la disponibilité, par exemple :

99,95 % de toutes les requêtes sont satisfaites en 10 secondes.

Ce que vous considérez comme une latence typique dépend de vous. Certaines équipes de Google considèrent 90 % comme une bonne cible. Cela est lié à votre analyse et à la façon dont vous avez choisi les durées pour slow_typical. Exemple :

90 % de l'ensemble des requêtes sont traitées en une seconde.

Alertes suggérées

Compte tenu de ces consignes, le tableau suivant inclut un ensemble de référence d'alertes de SLO.

SLO	Période d'évaluation	Budget dépensé	Action
Disponibilité, utilisation rapide Latence typique latence de queue	Période d'une heure	Moins de 24 heures pour la violation du SLO	Envoyer une alerte à quelqu'un
Disponibilité, utilisation lente Latence typique, utilisation lente Latence de queue, utilisation lente	Période de sept jours	Plus de 24 heures avant la violation du SLO	Créer une demande

Cela peut prendre du temps de développer des alertes SLO optimales. Les durées présentées dans cette section sont des suggestions. vous pouvez les ajuster en fonction de vos besoins et de votre niveau de précision. Vous pouvez régler les alertes en fonction de la période d'évaluation ou l'épuisement de la marge d'erreur. Vous pouvez également ajouter une couche d'alerte supplémentaire entre les utilisations rapides et lentes.

Intégrez l'observabilité dans votre infrastructure et vos applications.

Ce document du framework d'architecture Google Cloud présente les bonnes pratiques à suivre pour ajouter l'observabilité à vos services afin de mieux comprendre les performances de vos services et d'identifier rapidement les problèmes. L'observabilité inclut la surveillance, la journalisation, le traçage, le profilage, le débogage et d'autres systèmes semblables.

La surveillance est à la base de la hiérarchie de la fiabilité du service dans le manuel SRE de Google. Sans système de surveillance approprié, vous ne pouvez pas savoir si une application fonctionne correctement.

Optimiser l'observabilité en instrumentant votre code

Un système bien conçu vise à garantir un bon niveau d'observabilité dès le début de sa phase de développement. N'attendez pas qu'une application soit en production pour commencer à la surveiller. Instrumentez votre code et suivez les instructions suivantes :

• Pour déboguer et résoudre les problèmes efficacement, réfléchissez aux entrées de journal et de trace à écrire, et aux métriques à surveiller et à exporter. Hiérarchisez les modes de défaillance les plus probables ou les plus fréquents du système.
• Auditez et éliminez régulièrement votre système de surveillance. Supprimez les tableaux de bord, les graphiques, les alertes, le traçage et la journalisation inutilisés ou inutiles afin d'éliminer tout encombrement.

Google Cloud Observability fournit une surveillance en temps réel, une surveillance et une journalisation hybrides multicloud (par exemple, pour AWS et Azure), ainsi que le traçage, le profilage et le débogage. Google Cloud Observability peut également détecter et surveiller automatiquement les microservices exécutés sur App Engine ou dans un maillage de services tel qu'Istio.

Si vous générez de nombreuses données d'application, vous pouvez optimiser l'ingestion à grande échelle de journaux d'événements d'analyse avec BigQuery. BigQuery convient également pour la persistance et l'analyse des données de séries temporelles à cardinalité élevée de votre framework de surveillance. Cette approche est utile, car elle vous permet d'exécuter des requêtes arbitraires à moindre coût plutôt que d'essayer de concevoir votre surveillance parfaitement dès le début, et de dissocier les rapports de la surveillance. Vous pouvez créer des rapports à partir des données à l'aide de Looker Studio ou de Looker.

Recommandations

Pour appliquer les instructions du framework d'architecture à votre propre environnement, suivez les recommandations ci-dessous :

• Mettez en œuvre la surveillance de manière anticipée, par exemple avant de lancer une migration ou avant de déployer une nouvelle application dans un environnement de production.
• Faites la distinction entre les problèmes d'application et les problèmes liés au cloud sous-jacents. Utiliser l'API Monitoring ou d'autres produits Cloud Monitoring et Google Cloud Status Dashboard.
• Définissez une stratégie d'observabilité au-delà de la surveillance incluant le traçage, le profilage et le débogage.
• Nettoyez régulièrement les artefacts d'observabilité que vous n'utilisez pas ou qui ne fournissent pas de valeur, tels que les alertes non exploitables.
• Si vous générez de grandes quantités de données d'observabilité, envoyez des événements d'application à un système d'entrepôt de données tel que BigQuery.

Étape suivante

• Concevoir des solutions évolutives et à haute disponibilité (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é.

Concevoir des solutions évolutives et à haute disponibilité

Ce document du framework d'architecture Google Cloud présente les principes et bonnes pratiques de conception et d'organisation des services, afin qu'ils puissent tolérer les défaillances et s'adapter à la demande des clients. Un service fiable répond aux demandes des clients en cas de forte demande ou en cas d'événement de maintenance. Les principes et bonnes pratiques de conception de fiabilité suivants doivent faire partie de votre architecture système et de votre plan de déploiement.

Créer une redondance pour une meilleure disponibilité

Les systèmes nécessitant des niveaux de fiabilité élevés ne doivent présenter aucun point de défaillance unique et leurs ressources doivent être répliquées sur plusieurs domaines de défaillance. Un domaine de défaillance est un pool de ressources pouvant échouer indépendamment, telles qu'une instance de VM, une zone ou une région. Lorsque vous répliquez des données sur plusieurs domaines de défaillance, vous obtenez un niveau de disponibilité global plus élevé que celui des instances individuelles. Pour en savoir plus, consultez la page Régions et zones.

Illustration spécifique de l'intégration du critère de redondance à votre architecture système : pour cantonner à des zones spécifiques les défaillances de l'enregistrement DNS, utilisez des noms DNS zonaux pour que les instances du même réseau aient accès l'une à l'autre.

Concevoir une architecture multizone avec basculement pour la haute disponibilité

Rendez votre application résiliente aux défaillances de zone en la développant dans des pools de ressources répartis sur plusieurs zones, avec la réplication des données, l'équilibrage de charge et le basculement automatique entre les zones. Exécutez des instances dupliquées zonales de chaque couche de la pile d'applications et éliminez toutes les dépendances interzones de l'architecture.

Répliquer les données dans plusieurs régions pour la reprise après sinistre

Répliquez ou archivez les données dans une région distante pour permettre la reprise après sinistre en cas de panne régionale ou de perte de données. Lorsque la réplication est utilisée, la récupération est plus rapide, car les systèmes de stockage de la région distante disposent déjà de données quasiment à jour, à l'exception de la perte possible d'une petite quantité de données due au délai de réplication. Lorsque vous utilisez l'archivage périodique au lieu de la réplication continue, la reprise après sinistre implique la restauration des données à partir de sauvegardes ou d'archives dans une nouvelle région. Cette procédure entraîne généralement un temps d'arrêt de service plus long que l'activation d'une instance dupliquée de base de données mise à jour en continu et peut entraîner une perte de données plus importante en raison de l'intervalle de temps entre les opérations de sauvegarde consécutives. Quelle que soit l'approche utilisée, l'intégralité de la pile d'applications doit être redéployée et démarrée dans la nouvelle région, et le service sera indisponible pendant cette opération.

Pour en savoir plus sur les concepts et les techniques de reprise après sinistre, consultez la page Concevoir une solution de reprise après sinistre pour les pannes d'infrastructures cloud.

Concevoir une architecture multirégionale pour la résilience aux pannes régionales

Si votre service doit fonctionner sans interruption même dans les rares cas de défaillance d'une région entière, concevez-le de manière à utiliser des pools de ressources de calcul répartis dans différentes régions. Exécutez des instances dupliquées régionales de chaque couche de la pile d'applications.

Utilisez la réplication de données entre régions et le basculement automatique en cas de défaillance d'une région. Certains services Google Cloud proposent des variantes multirégionales, telles que Spanner. Pour plus de résilience contre les défaillances régionales, utilisez ces services multirégionaux dans la mesure du possible. Pour en savoir plus sur les régions et la disponibilité des services, consultez la page Emplacements Google Cloud.

Assurez-vous qu'il n'existe aucune dépendance interrégionale afin que l'étendue d'un impact au niveau d'une région soit limitée à cette région.

Éliminez les points de défaillance uniques, tels qu'une base de données principale à région unique qui, en cas d'inaccessibilité, pourrait entraîner une panne globale. Les architectures multirégionales coûtent souvent plus cher. Vous devez donc tenir compte des besoins de l'entreprise par rapport au coût avant d'adopter cette approche.

Pour plus d'informations sur la mise en œuvre de la redondance entre les domaines de défaillance, consultez l'article sur les archétypes de déploiement pour les applications cloud (PDF).

Éliminer les goulots d'étranglement liés à l'évolutivité

Identifiez les composants système qui ne peuvent pas dépasser les limites de ressources d'une seule VM ou d'une seule zone. Certaines applications évoluent verticalement, ce qui vous permet d'ajouter des cœurs de processeur, de la mémoire ou de la bande passante réseau sur une seule instance de VM pour gérer l'augmentation de la charge. Ces applications sont soumises à des limites strictes en termes d'évolutivité, et vous devez souvent les configurer manuellement pour gérer la croissance.

Si possible, repensez ces composants pour les faire évoluer horizontalement, par exemple avec des partitions ou un partitionnement entre des VM ou des zones. Pour gérer la croissance du trafic ou de l'utilisation, vous devez ajouter des partitions. Utilisez des types de VM standards qui peuvent être ajoutés automatiquement afin de gérer les augmentations de charge par partition. Consultez la section Modèles d'applications évolutives et résilientes pour plus d'informations.

Si vous ne pouvez pas redéfinir l'application, vous pouvez remplacer les composants gérés par vous par des services cloud entièrement gérés, conçus pour évoluer horizontalement sans aucune action de l'utilisateur.

Dégrader les niveaux de service de manière concertée en cas de surcharge

Concevez vos services de manière à tolérer une surcharge. Les services doivent détecter une surcharge et renvoyer des réponses de qualité inférieure à l'utilisateur ou supprimer partiellement le trafic, sans échouer complètement en cas de surcharge.

Par exemple, un service peut répondre aux requêtes des utilisateurs avec des pages Web statiques et désactiver temporairement un comportement dynamique plus coûteux à traiter. Ce comportement est détaillé dans le modèle de basculement tiède de Compute Engine vers Cloud Storage. Le service peut également autoriser des opérations en lecture seule et désactiver temporairement les mises à jour de données.

Les opérateurs doivent être notifiés qu'ils doivent corriger la condition d'erreur en cas de dégradation d'un service.

Anticiper et atténuer les pics de trafic

Ne synchronisez pas les requêtes entre les clients. Lorsqu'un nombre trop élevé de clients envoient du trafic au même moment, cela peut entraîner des pics de trafic, qui eux-mêmes peuvent générer des défaillances en cascade.

Mettez en œuvre des stratégies de limitation des pics côté serveur, telles que la limitation, la mise en file d'attente, le délestage ou la rupture de circuit, la dégradation élégante et la priorité des requêtes critiques.

Les stratégies d'atténuation sur le client incluent une limitation côté client et un intervalle exponentiel entre les tentatives avec gigue.

Nettoyer et valider les entrées

Pour éviter les entrées erronées, aléatoires ou malveillantes entraînant des pannes de service ou des failles de sécurité, nettoyez et validez les paramètres d'entrée des API et des outils opérationnels. Par exemple, Apigee et Google Cloud Armor peuvent vous aider à vous protéger contre les attaques par injection.

Utilisez régulièrement des tests flous lorsqu'un faisceau de test appelle intentionnellement des API avec des entrées aléatoires, vides ou trop volumineuses. Effectuez ces tests dans un environnement de test isolé.

Les outils opérationnels doivent valider automatiquement les modifications de configuration avant leur déploiement et rejeter les modifications en cas d'échec de la validation.

Prévention de défaillance d'une manière qui préserve la fonction

En cas de défaillance due à un problème, les composants du système doivent échouer de manière à permettre au système global de continuer à fonctionner. Ces problèmes peuvent être un bug logiciel, une entrée ou une configuration incorrecte, une panne d'instance non planifiée ou une erreur humaine. Le processus de vos services permet de déterminer si vous devez être trop permissif ou trop simpliste, plutôt que trop restrictif.

Voici des exemples de scénarios et des procédures à suivre pour gérer les défaillances :

• Il est généralement préférable qu'un composant de pare-feu ayant une configuration incorrecte ou vide s'ouvre et permette au trafic réseau non autorisé de circuler pendant une courte période pendant que l'opérateur corrige l'erreur. Ce comportement permet de maintenir le service disponible, plutôt que de tomber en panne et de bloquer 100 % du trafic. Le service doit s'appuyer sur des vérifications d'authentification et d'autorisation plus en profondeur dans la pile d'applications pour protéger les zones sensibles pendant que tout le trafic passe.
• Toutefois, il est préférable qu'un composant de serveur d'autorisations qui contrôle l'accès aux données utilisateur échoue et bloque tous les accès. Ce comportement entraîne une interruption du service lorsque la configuration est corrompue, mais évite le risque de fuite de données utilisateur confidentielles en cas d'échec.

Dans les deux cas, l'échec doit déclencher une alerte de priorité élevée afin qu'un opérateur puisse corriger la condition d'erreur. Les composants du service doivent échouer par excès de défaillance, sauf si cela présente des risques extrêmes pour l'entreprise.

Concevoir des appels d'API et des commandes opérationnelles réexécutables

Les API et les outils opérationnels doivent, dans la mesure du possible, rendre les réexécutions plus sûres. Une approche naturelle des nombreuses conditions d'erreur consiste à retenter l'action précédente, mais vous pourriez ne pas savoir si la première tentative a réussi.

Votre architecture système doit effectuer des actions idempotentes : si vous effectuez l'action identique sur un objet deux ou plusieurs fois de suite, elle doit produire les mêmes résultats qu'un seul appel. Les actions non idempotentes nécessitent du code plus complexe pour éviter la corruption de l'état du système.

Identifier et gérer les dépendances de service

Les concepteurs et propriétaires de services doivent gérer une liste complète de dépendances sur d'autres composants du système. La conception du service doit également inclure la récupération en cas d'échec des dépendances, ou une dégradation élégante si une récupération complète n'est pas possible. Tenez compte des dépendances sur les services cloud utilisés par votre système et des dépendances externes, telles que les API de services tierces, en tenant compte du fait que chaque dépendance système présente un taux d'échec non nul.

Lorsque vous définissez des cibles de fiabilité, vous devez savoir que le SLO d'un service est limité mathématiquement par les SLO de toutes ses dépendances critiques. Vous ne pouvez pas être plus fiable que le SLO le plus bas de l'une des dépendances. Pour en savoir plus, consultez la page Calcul de la disponibilité d'un service.

Dépendances de démarrage

Les services se comportent différemment à leur démarrage et à l'état stable. Les dépendances de démarrage peuvent différer considérablement des dépendances d'exécution à l'état stable.

Par exemple, au démarrage, un service peut avoir besoin de charger des informations sur l'utilisateur ou le compte à partir d'un service de métadonnées utilisateur qu'il rappelle rarement. Lorsque de nombreuses instances dupliquées de service redémarrent après un plantage ou une maintenance de routine, elles peuvent augmenter considérablement la charge sur les dépendances de démarrage, en particulier lorsque les caches sont vides et doivent être rechargés.

Testez le démarrage du service en cas de charge et provisionnez les dépendances de démarrage en conséquence. Envisagez une conception qui se dégrade de manière élégante en enregistrant une copie des données récupérées dans les dépendances de démarrage critiques. Ce comportement permet à votre service de redémarrer avec des données potentiellement obsolètes au lieu de ne pas pouvoir démarrer en cas de panne d'une dépendance critique. Votre service peut ensuite charger des données récentes, lorsque cela est possible, pour rétablir un fonctionnement normal.

Les dépendances de démarrage sont également importantes lorsque vous amorcez un service dans un nouvel environnement. Concevez votre pile d'applications avec une architecture en couches, sans dépendances cycliques entre les couches. Les dépendances cycliques peuvent sembler tolérables, car elles ne bloquent pas les modifications incrémentielles apportées à une seule application. Cependant, elles peuvent rendre difficile, voire impossible, le redémarrage après qu'une catastrophe a supprimé l'intégralité de la pile de services.

Minimiser les dépendances critiques

Minimisez le nombre de dépendances critiques pour votre service, c'est-à-dire d'autres composants dont la défaillance provoquerait inévitablement des interruptions de service. Pour rendre votre service plus résilient aux pannes ou aux lenteurs des autres composants dont il dépend, examinez les exemples de techniques et de principes de conception suivants pour convertir les dépendances critiques en dépendances non critiques :

• Augmentez le niveau de redondance dans les dépendances critiques. L'ajout d'instances dupliquées réduit la probabilité qu'un composant entier soit indisponible.
• Utilisez des requêtes asynchrones vers d'autres services au lieu de rester bloqué sur une réponse, ou utilisez une messagerie Pub/Sub pour dissocier les requêtes des réponses.
• Mettez en cache les réponses d'autres services pour récupérer des indisponibilités à court terme des dépendances.

Pour rendre les défaillances de votre service moins préjudiciables aux autres composants qui en dépendent, consultez les exemples de techniques et de principes de conception suivants :

• Utilisez des files d'attente de requêtes prioritaires et accordez une priorité plus élevée aux requêtes pour lesquelles un utilisateur attend une réponse.
• Diffusez les réponses à partir d'un cache pour réduire la latence et la charge.
• Prévention de défaillance d'une manière qui préserve la fonction
• Se dégrader de manière élégante en cas de surcharge du trafic.

S'assurer que chaque modification peut faire l'objet d'un rollback

S'il n'existe pas de moyen bien défini d'annuler certains types de modifications apportées à un service, modifiez la conception du service de manière à ce qu'il accepte le rollback. Testez régulièrement les processus de rollback. Les API de chaque composant ou microservice doivent être versionnées, avec une rétrocompatibilité permettant aux générations précédentes de clients de fonctionner correctement à mesure que l'API évolue. Ce principe de conception est essentiel pour permettre le déploiement progressif des modifications d'API, avec un rollback rapide si nécessaire.

Le rollback peut être coûteux à mettre en œuvre dans les applications mobiles. Firebase Remote Config est un service Google Cloud qui simplifie le rollback des fonctionnalités.

Étant donné qu'il n'est pas possible d'annuler facilement les modifications du schéma d'une base de données, vous devez les exécuter en plusieurs phases. Concevez chaque phase pour permettre la réception des requêtes sécurisées de lecture et de mise à jour du schéma par la dernière version de votre application et la version précédente. Cette approche de conception vous permet d'effectuer un rollback en toute sécurité en cas de problème avec la dernière version.

Recommandations

Pour appliquer les conseils du framework d'architecture à votre propre environnement, procédez comme suit :

• Mettez en œuvre un intervalle exponentiel entre les tentatives avec une logique de nouvelle tentative aléatoire pour les applications clientes.
• Mettez en œuvre une architecture multirégionale avec basculement automatique pour une haute disponibilité.
• Distribuez les requêtes des utilisateurs entre les segmentations et les régions à l'aide de l'équilibrage de charge.
• Concevez l'application de manière à ce qu'elle se dégrade de manière élégante en cas de surcharge. Diffusez des réponses partielles ou fournissez des fonctionnalités limitées plutôt que d'échouer complètement.
• Établissez un processus basé sur les données pour la planification de la capacité, et utiliser les tests de charge et les prévisions de trafic pour déterminer quand provisionner les ressources.
• Définissez des procédures de reprise après sinistre et testez-les régulièrement.

Étape suivante

• Créez des processus et des outils opérationnels fiables (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é.

Créer des processus et des outils opérationnels fiables

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é.

Créer des alertes efficaces

Ce document du framework d'architecture Google Cloud présente les principes opérationnels pour créer des alertes qui vous aident à exécuter des services fiables. Plus vous disposerez d'informations sur les performances de votre service, plus vos décisions seront éclairées en cas de problème. Concevez vos alertes pour une détection précoce et précise de tous les problèmes du système ayant un impact sur les utilisateurs, tout en réduisant les faux positifs.

Optimiser le délai d'alerte

Il existe un équilibre entre les alertes envoyées trop tôt qui exercent une pression sur l'équipe chargée des opérations, et les alertes envoyées trop tardivement qui entraînent de longues interruptions de service. Réglez le délai d'alerte avant que le système de surveillance n'avertisse les utilisateurs d'un problème afin de minimiser le temps de détection, tout en optimisant le rapport signal-bruit. Utilisez le taux de consommation de la marge d'erreur pour obtenir la configuration d'alerte optimale.

Alerter sur les symptômes plutôt que sur les causes

Déclenchez des alertes en fonction de l'impact direct sur l'expérience utilisateur. La non-conformité avec les SLO mondiaux ou ceux associés à chaque client indique un impact direct. Ne définissez pas d'alertes sur toutes les causes premières potentielles d'une défaillance, en particulier lorsque l'impact est limité à une seule instance dupliquée. En pareil cas, un système distribué bien conçu se rétablit de manière totalement transparente.

Alerter sur les valeurs aberrantes plutôt que sur les moyennes

Lorsque vous surveillez la latence, définissez des SLO et des alertes pour la latence au 90e, 95e ou 99e centile (en sélectionner deux sur trois), et non pour la latence moyenne ou au 50e centile. Des valeurs de latence moyennes ou médianes satisfaisantes peuvent masquer des valeurs trop élevées au 90e centile ou plus, ce qui nuit à l'expérience utilisateur. Par conséquent, vous devez appliquer ce principe d'alerte en cas de valeurs aberrantes lors de la surveillance de la latence pour toute opération critique, telle qu'une interaction requête-réponse avec un serveur Web, un traitement par lot dans un pipeline de traitement de données, ou une opération de lecture ou d'écriture sur un service de stockage.

Créer un processus collaboratif de gestion des incidents

Ce document du framework d'architecture Google Cloud fournit les bonnes pratiques pour gérer les services et définir des processus de réponse aux incidents. Les incidents se produisent dans tous les services. Vous devez donc disposer d'un processus bien documenté pour réagir efficacement à ces problèmes et les atténuer.

Présentation de la gestion des incidents

Il est inévitable que votre système bien conçu ne parvienne pas à atteindre ses objectifs de niveau de service. En l'absence de SLO, vos clients définissent de manière approximative le niveau de service acceptable à partir de leur expérience passée. Les clients font remonter votre demande à l'assistance technique ou à un groupe similaire, quel que soit le contenu de votre contrat de niveau de service.

Pour répondre correctement à vos clients, établissez et testez régulièrement un plan de gestion des incidents. Le plan peut être aussi court qu'une simple liste d'une page comportant dix éléments. Ce processus aide votre équipe à réduire le temps de détection (Time to detect, TTD) et le temps d'atténuation des risques (Time to mitigate, TTM).

Le TTM est préférable au TTR, où le R pour la réparation ou la récupération est souvent utilisé pour désigner une correction complète par rapport à l'atténuation des risques. Le système TTM met l'accent sur la résolution rapide pour limiter rapidement l'impact pour le client d'une panne, puis lance un processus souvent beaucoup plus long pour résoudre complètement le problème.

Un système bien conçu avec des opérations d'excellente qualité augmente le délai entre les défaillances (Time between failures, TBF). En d'autres termes, les principes de fiabilité opérationnels, y compris la bonne gestion des incidents, ont pour but de rendre les défaillances moins fréquentes.

Pour exécuter des services fiables, appliquez les bonnes pratiques suivantes dans votre processus de gestion des incidents.

Attribuer une propriété de service claire

Tous les services et leurs dépendances critiques doivent avoir des propriétaires clairs responsables du respect de leurs SLO. En cas de réorganisations ou de départs d'équipe, les responsables ingénieurs doivent s'assurer que la propriété est explicitement transférée à une nouvelle équipe, ainsi que la documentation et la formation nécessaires. Les propriétaires d'un service doivent être facilement détectables par d'autres équipes.

Réduisez le temps de détection grâce à des alertes bien réglées.

Avant de pouvoir réduire le TTD, examinez et mettez en œuvre les recommandations figurant dans les sections Intégrer l'observabilité dans votre infrastructure et vos applications et Définir vos objectifs de fiabilité de la catégorie de fiabilité du framework d'architecture. Par exemple, faites la distinction entre les problèmes d'application et les problèmes liés au cloud.

Un ensemble de SLI bien défini prévient votre équipe au bon moment, tout en évitant la surabondance d'alertes. Pour plus d'informations, consultez la section Créer des alertes efficaces du pilier "Architecture Framework" ou "Affiner vos métriques SLI : blog CRE Life Lessons".

Réduisez le temps nécessaire à la résolution avec des plans de gestion des incidents et des formations.

Pour réduire le TTM, définissez un plan de gestion des incidents documenté et correctement testé. disposer de données aisément accessibles documentant les changements apportés à l'environnement ; Assurez-vous que les équipes connaissent les atténuations génériques qu'elles peuvent appliquer rapidement pour minimiser le TTM. Ces techniques d'atténuation incluent le drainage, le rollback, le redimensionnement des ressources et la dégradation de la qualité de service.

Comme indiqué dans un autre document clé lié à la catégorie de fiabilité du framework Architecture, créez des processus et des outils opérationnels fiables pour pouvoir effectuer un rollback rapide et sécurisé des modifications.

Concevez des dispositions et du contenu de tableau de bord de façon à minimiser le temps nécessaire à la résolution.

Organisez la mise en page de votre tableau de bord et la navigation de votre service afin qu'un opérateur puisse déterminer en une minute ou deux si le service, ainsi que toutes ses dépendances critiques, sont en cours d'exécution. Pour identifier rapidement les causes potentielles des problèmes, les opérateurs doivent pouvoir analyser tous les graphiques du tableau de bord afin de rechercher rapidement des graphiques qui changent de manière significative au moment de l'alerte.

La liste suivante d'exemples de graphiques peut se trouver sur votre tableau de bord pour vous aider à résoudre des problèmes. Le personnel chargé de répondre aux incidents doit pouvoir les consulter sur un même écran.

• Les indicateurs de niveau de service, tels que le nombre de requêtes ayant réussi, divisés par le nombre total de requêtes valides
• Configuration et déploiements binaires
• Requêtes par seconde envoyées au système
• Réponses d'erreurs par seconde provenant du système
• Requêtes par seconde depuis le système vers ses dépendances
• Réponses d'erreur par seconde au système à partir de ses dépendances

D'autres graphiques courants permettant de résoudre les problèmes incluent la latence, la saturation, la taille de la requête, la taille de la réponse, le coût des requêtes, l'utilisation du pool de threads et les métriques de machine virtuelle Java (JVM) (le cas échéant). La saturation fait référence à l'exhaustivité en fonction d'une certaine limite, telle que le quota ou la taille de la mémoire système. L'utilisation du pool de threads recherche les régressions dues à l'épuisement du pool.

Testez l'emplacement de ces graphiques sur quelques scénarios de panne pour vous assurer que les graphiques les plus importants sont proches du haut et que l'ordre des graphiques correspond à votre workflow de diagnostic standard. Vous pouvez également appliquer le machine learning et la détection d'anomalies statistiques pour faire apparaître le sous-ensemble approprié de ces graphiques.

Documenter les procédures de diagnostic et l'atténuation des risques de défaillances connues

Rédigez des guides et des liens vers ces derniers à partir des notifications d'alerte. Si ces documents sont accessibles à partir des notifications d'alerte, les opérateurs peuvent obtenir rapidement les informations dont ils ont besoin pour résoudre les problèmes.

Utilisez les analyses post-mortem irréprochables pour tirer des leçons des interruptions de service et éviter les récurrences

Établir une culture post-mortem irréprochable et un processus d'examen des incidents. Sans reproches signifie que votre équipe évalue et documente les erreurs de manière objective, sans qu'il soit nécessaire d'attribuer le problème.

Les erreurs sont des opportunités d'apprentissage, et non des critiques. Veillez à toujours améliorer la résilience du système pour qu'il puisse récupérer rapidement d'une erreur humaine, ou mieux, pour qu'il soit capable de détecter et d'éviter les erreurs humaines. Extrayez le plus d'apprentissage possible de chaque post-mortem et effectuez un suivi minutieux de chaque action post-mortem afin de réduire les fréquences d'interruption, ce qui aura pour effet d'augmenter le TBF.

Exemple de plan de gestion des incidents

Des problèmes de production ont été détectés, par exemple via une alerte ou une page, ou s'ils m'ont été signalés :

• Dois-je déléguer cette tâche à une autre personne ?
  • Oui, si vous et votre équipe ne parvenez pas à résoudre le problème.
• S'agit-il d'une atteinte à la vie privée ou d'une violation de la sécurité ?
  • Si oui, déléguez cette tâche à l'équipe chargée de la confidentialité ou de la sécurité.
• S'agit-il d'une urgence ou des SLO sont-ils menacés ?
  • En cas de doute, traitez le problème comme s'il s'agissait d'une urgence.
• Dois-je impliquer davantage de personnes ?
  • Oui, si cela concerne plus de X% des clients ou si la résolution du problème prend plus de Y minutes. En cas de doute, impliquez toujours plus de personnes, en particulier pendant les heures de travail.
• Définissez un canal de communication principal, tel que IRC, Hangouts Chat ou Slack.
• Déléguez des rôles précédemment définis, tels que les suivants :
  • Responsable des incidents chargé de la coordination générale.
  • Responsable de la communication chargé des communications internes et externes.
  • Responsable des opérations chargé d'atténuer le problème.
• Déterminez quand l'incident est terminé. Vous aurez peut-être d'abord à vous adresser à un conseiller de l'équipe d'assistance ou à d'autres équipes similaires.
• Collaborez sur le post-mortem irréprochable.
• Participez à une réunion dédiée à l'examen des incidents post-mortem au cours de laquelle vous pourrez discuter des points à traiter et des tâches à effectuer.

Recommandations

Pour appliquer les instructions du framework d'architecture à votre propre environnement, suivez les recommandations ci-dessous :

• Mettez en place un plan de gestion des incidents et formez vos équipes à son utilisation.
• Pour réduire le TTD, mettez en œuvre les recommandations permettant de créer une observabilité dans votre infrastructure et vos applications.
• Créer un tableau de bord "Qu'est-ce qui a changé ?" que vous pouvez consulter en cas d'incident.
• Documentez les extraits de requête ou créez un tableau de bord Looker Studio avec des requêtes de journal fréquentes.
• Évaluez Firebase Remote Config pour limiter les problèmes de déploiement des applications mobiles.
• Testez la reprise après échec, y compris la restauration des données à partir de sauvegardes, afin de réduire le TTM pour un sous-ensemble de vos incidents.
• Concevez des solutions adaptées aux rollbacks de la configuration et des binaires et effectuez des tests.
• Répliquez les données dans plusieurs régions pour la reprise après sinistre et utilisez des tests de reprise après sinistre pour réduire le TTM après les pannes régionales.
• Concevez une architecture multirégionale pour la résilience aux pannes régionales si les besoins de haute disponibilité justifient le coût, ce qui augmente le TBF.

Étape suivante

Découvrez comment créer un processus collaboratif de gestion des incidents à l'aide des ressources suivantes :

• Google Cloud Status Dashboard
• Gestion des incidents chez Google
• Processus de gestion des incidents liés aux données
• Chapitre sur la gestion des incidents dans le livre sur l'ingénierie SRE

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é.

Framework d'architecture Google Cloud : guides sur la fiabilité des produits

Cette section du framework d'architecture présente des bonnes pratiques spécifiques au produit pour ce qui concerne la fiabilité, la disponibilité et la cohérence de certains produits Google Cloud. Vous y trouverez également des recommandations pour réduire les pannes et récupérer en cas de pannes, et pour faire évoluer vos applications correctement lorsqu'elles subissent une charge élevée.

Remarque : Pour en savoir plus sur les composants fondamentaux de la fiabilité au niveau de la plate-forme dans Google Cloud (zones, régions et ressources à l'échelle de l'emplacement), ainsi que sur les niveaux de disponibilité qu'ils fournissent, consultez le Guide de fiabilité de l'infrastructure Google Cloud. Ce guide fournit également des instructions pour évaluer les exigences de fiabilité de vos charges de travail, et présente des recommandations architecturales pour la création et la gestion d'une infrastructure fiable dans Google Cloud.

Les guides sur la fiabilité des produits sont organisés dans les domaines suivants :

• Compute
  • Compute Engine
  • Cloud Run
  • Cloud Functions
  • Google Kubernetes Engine
• Espace de stockage et bases de données
  • Cloud Storage
  • Firestore
  • Bigtable
  • Cloud SQL
  • Spanner
  • Filestore
  • Memorystore
• Mise en réseau
  • Cloud DNS
  • Cloud Load Balancing
  • Cloud CDN
• Analyse de données
  • BigQuery
  • Dataflow
  • Dataproc

Guide de fiabilité Compute Engine

Compute Engine est un service de calcul personnalisable qui permet aux utilisateurs de créer et d'exécuter des machines virtuelles à la demande sur l'infrastructure de Google.

Bonnes pratiques

• Bonnes pratiques concernant les API Compute Engine : bonnes pratiques recommandées pour utiliser l'API Compute Engine et atténuer les effets des limites de débit des API.
• Concevoir des systèmes résilients : instructions détaillées sur la conception de vos applications Compute Engine pour la reprise après sinistre ou la récupération après une panne ou un redémarrage d'une VM isolée, ou après des défaillances de zone ou régionales.
• Augmenter la disponibilité en effectuant un surprovisionnement : ajoutez des ressources redondantes pour garantir le bon fonctionnement de votre application en cas de perte de capacité due à des perturbations de zone ou régionales.
• Utiliser l'équilibrage de charge pour les applications à disponibilité élevée : utilisez Cloud Load Balancing avec Compute Engine pour garantir la haute disponibilité, même pendant une panne de zone.
• Bonnes pratiques pour la sélection des régions Compute Engine : choisissez les régions Google Cloud à utiliser pour vos ressources Compute Engine afin d'optimiser la latence de vos applications tout en tenant compte des compromis prix/performances.
• Bonnes pratiques pour la migration des VM à l'aide de Migrate to Virtual Machines : découvrez comment migrer des VM depuis un environnement source compatible vers Compute Engine avec Migrate to Virtual Machines, y compris l'évaluation, la planification et la réalisation de la migration. Découvrez également comment résoudre les problèmes courants qui peuvent survenir avec la migration.
• Modèles d'utilisation d'adresses IP flottantes dans Compute Engine : découvrez comment mettre en œuvre des adresses IP partagées ou virtuelles dans un environnement Compute Engine en remplaçant l'architecture par un modèle pour votre cas d'utilisation. Les modèles incluent ceux utilisant l'équilibrage de charge, les routes Google Cloud et l'autoréparation.
• Bonnes pratiques pour les instantanés de disques persistants : créez des instantanés plus rapidement et avec une plus grande fiabilité.
• Disques persistants et réplication : comment les disques persistants utilisent Colossus pour le backend de stockage et l'accès aux disques persistants à partir de VM. Vous pouvez également surveiller la latence des disques persistants, répliquer des disques persistants entre des régions ou des zones, et gérer les requêtes de lecture et d'écriture pour les instances répliquées.
• Configurer les disques pour répondre aux exigences de performances : facteurs qui affectent les performances des volumes de stockage de blocs associés aux instances de VM.
• Bonnes pratiques pour la gestion des images : conseils détaillés sur la gestion des images Compute Engine, telles que le choix d'une image de démarrage, la personnalisation des images, le cycle de vie des images et le partage d'images entre projets.
• Bonnes pratiques concernant les familles d'images : importance de tester la dernière image dans une famille avant de l'utiliser en production, et comment configurer la procédure de test.
• Bonnes pratiques pour les instances SQL Server : bonnes pratiques pour optimiser les instances Compute Engine qui exécutent Microsoft SQL Server, ainsi que pour optimiser SQL Server Enterprise Edition. Découvrez également comment utiliser les paramètres réseau par défaut du système d'exploitation et les activités opérationnelles pour améliorer les performances et la stabilité.

Guide de fiabilité Cloud Run

Cloud Run est une plate-forme de calcul gérée, adaptée aux déploiements d'applications en conteneurs. C'est une plate-forme sans serveur. Cloud Run élimine toute infrastructure, ce qui permet aux utilisateurs de se concentrer sur la création d'applications.

Bonnes pratiques

• Conseils généraux pour Cloud Run : comment mettre en œuvre un service Cloud Run, démarrer rapidement des conteneurs, utiliser des variables globales et améliorer la sécurité des conteneurs.
• Bonnes pratiques pour les tests de charge : découvrez comment effectuer un test de charge des services Cloud Run, y compris comment résoudre les problèmes de simultanéité avant les tests de charge, comment gérer le nombre maximal d'instances, comment choisir la meilleure région pour les tests de charge et comment garantir le scaling des services suivant la charge.
• Scaling d'instance : apprenez à effectuer le scaling et la limite d'instances de conteneur, et réduisez le temps de réponse en gardant certaines instances inactives au lieu de les arrêter.
• Utilisation du nombre minimal d'instances : spécifiez le nombre minimal d'instances de conteneur prêtes à être diffusées et, lorsque ce nombre est suffisamment élevé, diminuez le temps de réponse moyen en réduisant le nombre de démarrages à froid.
• Optimiser les applications Java pour Cloud Run : découvrez les compromis de certaines optimisations pour les services Cloud Run écrits en Java, et réduisez le temps de démarrage et l'utilisation de la mémoire.
• Optimisation des applications Python pour Cloud Run : optimisez l'image de conteneur en améliorant l'efficacité du serveur WSGI, et optimisez les applications en réduisant le nombre de threads et en exécutant les tâches de démarrage en parallèle.

Guide de fiabilité Cloud Functions

Cloud Functions est une plate-forme sans serveur évolutive, basée sur des événements, permettant de créer et de connecter des services. Les fonctions Cloud Functions peuvent être appelées via une requête HTTP ou déclenchées en fonction d'événements en arrière-plan.

Bonnes pratiques

• Bonnes pratiques Cloud Functions : instructions pour utiliser et interagir avec Cloud Functions, mettre en œuvre l'idempotence, déployer des fonctions et optimiser les performances.

Guide de fiabilité Google Kubernetes Engine

Google Kubernetes Engine (GKE) est un système permettant d'exploiter des applications conteneurisées dans le cloud, à grande échelle. GKE déploie, gère et provisionne les ressources pour vos applications en conteneur. L'environnement GKE comprend des instances Compute Engine regroupées pour former un cluster.

Bonnes pratiques

• Bonnes pratiques pour l'exploitation de conteneurs : découvrez comment utiliser des mécanismes de journalisation, vous assurer que les conteneurs sont sans état et immuables, surveiller les applications et effectuer des vérifications d'activité et d'aptitude
• Bonnes pratiques pour la création de conteneurs : découvrez comment empaqueter une seule application par conteneur, gérer les identifiants de processus (PID), optimiser le cache de création de Docker et créer des images plus petites pour accélérer les importations et les téléchargements
• Bonnes pratiques pour la gestion de réseaux Google Kubernetes Engine : utilisez des clusters de VPC natif pour faciliter le scaling, planifiez les adresses IP, adaptez la connectivité des clusters, utilisez Google Cloud Armor pour bloquer les attaques par déni de service distribué (DDoS), mettez en œuvre un équilibrage de charge natif en conteneurs pour une latence plus faible, utilisez la fonctionnalité de vérification d'état des équilibreurs de charge d'application externes pour le basculement progressif et utilisez des clusters régionaux pour augmenter la disponibilité des applications dans un cluster.
• Préparer des applications Kubernetes basées sur le cloud : bonnes pratiques pour planifier la capacité de vos applications, développer les applications horizontalement ou verticalement, définir des limites de ressources pour les demandes de ressources en termes de mémoire ou de processeur, simplifier les conteneurs pour accélérer le démarrage de l'application et limiter la perturbation de Pod en définissant un Pod Disruption Budget (PDB). Découvrez également comment configurer des vérifications d'activité et d'aptitude pour le démarrage en douceur des applications, garantir des arrêts sans perturbation, et mettre en œuvre un intervalle exponentiel entre les tentatives pour les nouvelles tentatives afin d'éviter les pics de trafic qui surchargent votre application.
• Bonnes pratiques pour l'architecture mutualisée de GKE : comment concevoir une architecture de cluster mutualisée pour bénéficier d'une haute disponibilité et fiabilité, utiliser la mesure de l'utilisation de Google Kubernetes Engine (GKE) pour les métriques d'utilisation par locataire, fournir des journaux spécifiques au locataire et fournir une surveillance spécifique au locataire.

Guide de fiabilité Cloud Storage

Cloud Storage est un dépôt d'objets durable et hautement disponible, doté de fonctionnalités avancées de sécurité et de partage. Ce service permet de stocker des données sur l'infrastructure Google Cloud et d'y accéder.

Bonnes pratiques

• Bonnes pratiques pour Cloud Storage : bonnes pratiques générales pour Cloud Storage, y compris des conseils pour optimiser la disponibilité et minimiser la latence de vos applications, améliorer la fiabilité des opérations d'importation et améliorer les performances des suppressions de données à grande échelle.
• Consignes relatives aux taux de demandes et à la distribution des accès : comment réduire la latence et les réponses d'erreur lors des opérations de lecture, d'écriture et de suppression à des taux de demandes très élevés en comprenant le fonctionnement de l'autoscaling Cloud Storage.

Guide de fiabilité Firestore

Firestore est une base de données de documents NoSQL qui vous permet de stocker, de synchroniser et d'interroger des données pour vos applications Web et mobiles à l'échelle mondiale.

Bonnes pratiques

• Bonnes pratiques Firestore : sélectionnez l'emplacement de votre base de données pour améliorer la fiabilité, minimiser les problèmes d'indexation, améliorer les performances des opérations de lecture et d'écriture, réduire la latence des notifications de modification et bénéficier d'une conception évolutive.

Guide de fiabilité Bigtable

Bigtable est une base de données NoSQL entièrement gérée et évolutive, pour les charges de travail analytiques et opérationnelles d'envergure. Cloud Bigtable est conçu comme une table partiellement remplie qui peut être étendue à des milliards de lignes et des milliers de colonnes pour une haute capacité de lecture et d'écriture à faible latence.

Bonnes pratiques

• Comprendre les performances de Bigtable : estimer le débit pour Bigtable, planifier la capacité de Bigtable en examinant le débit et l'utilisation de l'espace de stockage, comprendre en quoi l'activation de la réplication va affecter différemment le débit en lecture et en écriture, et découvrir comment Bigtable optimise les données au fil du temps.
• Conception de schéma Bigtable : conseils pour concevoir un schéma Bigtable, comprenant l'explication des concepts de stockage clé/valeur, la conception de clés de ligne basées sur des requêtes de lecture planifiées, la gestion des colonnes et des lignes, et les cas d'utilisation spéciaux.
• Présentation de la réplication Bigtable : comment répliquer Bigtable sur plusieurs zones ou régions, comprendre les implications en termes de performances de la réplication, et comment Bigtable résout les conflits et gère les basculements.
• À propos des sauvegardes Bigtable : enregistrez une copie du schéma et des données d'une table avec les sauvegardes Bigtable, ce qui peut vous aider à récupérer des données corrompues au niveau de l'application ou à corriger des erreurs d'opérateur, comme la suppression accidentelle d'une table.

Guide de fiabilité Cloud SQL

Cloud SQL est un service de base de données relationnelle entièrement géré pour MySQL, PostgreSQL et SQL Server. Cloud SQL s'intègre facilement aux applications existantes et aux services Google Cloud tels que Google Kubernetes Engine et BigQuery.

Bonnes pratiques

• Haute disponibilité pour Cloud SQL : présentation de la configuration de la haute disponibilité pour Cloud SQL, comprenant la gestion des instances dupliquées avec accès en lecture et le processus de basculement. Cette page explique également comment contrôler la chronologie des événements de maintenance de base de données, et comment l'utilisation d'un disque persistant régional dans la configuration de la haute disponibilité affecte les performances de la base de données. Ce contenu est divisé en trois sections :

  • Haute disponibilité pour MySQL
  • Haute disponibilité pour PostgreSQL
  • Haute disponibilité pour SQL Server

• Reprise après sinistre des bases de données Cloud SQL : présentation de la configuration de la reprise après sinistre pour Cloud SQL à l'aide d'une instance répliquée interrégionale avec accès en lecture.

  • Reprise après sinistre MySQL
  • Reprise après sinistre PostgreSQL
  • Reprise après sinistre SQL Server

• Bonnes pratiques générales pour Cloud SQL : conseils sur la configuration des instances, l'architecture des données, l'importation et l'exportation de données, et la sauvegarde et la récupération. Ce contenu est divisé en trois sections :

  • Bonnes pratiques concernant MySQL
  • Bonnes pratiques concernant PostgreSQL
  • Bonnes pratiques concernant SQL Server

• Bonnes pratiques pour l'importation et l'exportation de données : dans quelles circonstances les buckets Cloud Storage ne peuvent pas être utilisés, compresser les données afin de réduire les coûts, limites connues de l'importation et de l'exportation des données, comment automatiser les opérations d'exportation, et résoudre les problèmes des opérations d'importation et d'exportation.

  • Bonnes pratiques concernant MySQL
  • Bonnes pratiques concernant PostgreSQL
  • Bonnes pratiques concernant SQL Server

Guide de fiabilité Spanner

Spanner est un service distribué de gestion et de stockage de bases de données SQL. Il propose des fonctionnalités telles que les transactions mondiales, un scaling horizontal à disponibilité élevée et une cohérence transactionnelle.

Bonnes pratiques

• Sauvegarde et restauration de Spanner : principales fonctionnalités de sauvegarde et de restauration de Spanner, comparaison des fonctionnalités de sauvegarde et de restauration avec celles d'importation et d'exportation, détails de mise en œuvre et contrôle de l'accès aux ressources Spanner.
• Configurations régionales et multirégionales : description des deux types de configurations d'instance proposés par Spanner : configurations régionales et multirégionales. La description inclut les différences et les compromis entre chaque configuration.
• Autoscaling Spanner : présentation d'Autoscaler pour Spanner, un outil Open Source que vous pouvez utiliser comme élément associé à Spanner. Cet outil vous permet d'augmenter ou de réduire automatiquement le nombre de nœuds ou d'unités de traitement dans une ou plusieurs instances Spanner en fonction des métriques d'utilisation de chaque instance Spanner.
• À propos de la récupération à un moment précis (PITR) : description de la récupération à un moment précis de Spanner, qui protège contre la suppression ou l'écriture accidentelles de données Spanner. Par exemple, un opérateur écrit par inadvertance des données ou un déploiement d'application corrompt la base de données. La récupération PITR vous permet de récupérer facilement vos données à un moment antérieur précis (au maximum sept jours).
• Bonnes pratiques Spanner : conseils sur le chargement groupé, utilisation d'un langage de manipulation de données (LMD), conception de schémas pour éviter les hotspots et bonnes pratiques SQL.

Guide de fiabilité Filestore

Filestore est un service géré de stockage de fichiers destiné aux applications Google Cloud, avec une interface de système de fichiers et un système de fichiers partagé pour les données. Filestore offre un stockage en réseau (NAS) en ligne à l'échelle du pétaoctet pour les instances Compute Engine et Google Kubernetes Engine.

Bonnes pratiques

• Performances de Filestore - paramètres de performances et recommandations de types de machines Compute Engine, options d'installation NFS pour des performances optimales sur les instances de VM clientes Linux, et utilisation des outils fio pour tester les performances. Inclut des recommandations pour améliorer les performances sur plusieurs ressources Google Cloud.

• Sauvegardes Filestore : description des sauvegardes Filestore, cas d'utilisation courants et bonnes pratiques pour créer et utiliser des sauvegardes.

• Instantanés Filestore : description des instantanés Filestore, cas d'utilisation courants et bonnes pratiques pour créer et utiliser des instantanés.

• Mise en réseau Filestore : réseaux et ressources IP nécessaires pour utiliser Filestore.

Guide de fiabilité Memorystore

Memorystore est un magasin en mémoire entièrement géré qui fournit une version gérée de deux solutions Open Source de mise en cache : Redis et Memcached. Memorystore est évolutif et automatise les tâches complexes telles que le provisionnement, la réplication, le basculement et l'application de correctifs.

Bonnes pratiques

• Bonnes pratiques générales Redis - conseils sur l'exportation de sauvegardes de base de données Redis (RDB), les opérations exigeantes en ressources et les opérations nécessitant une nouvelle tentative de connexion. Informations supplémentaires sur la maintenance, la gestion de la mémoire et la configuration du connecteur d'accès au VPC sans serveur, ainsi que sur le mode de connexion d'accès aux services privés, la surveillance et les alertes.
• Bonnes pratiques pour la gestion de la mémoire Redis - concepts concernant la gestion de la mémoire, tels que la capacité des instances et la configuration de Maxmemory, les opérations d'exportation, de scaling et de mise à niveau des versions, les métriques de gestion de la mémoire, et la résolution d'une condition de mémoire insuffisante.
• Intervalle exponentiel entre les tentatives Redis - comment fonctionne l'intervalle exponentiel entre les tentatives, exemple d'algorithme, et comment fonctionnent l'intervalle maximal entre les tentatives et le nombre maximal de nouvelles tentatives.
• Bonnes pratiques Memcached - comment concevoir une application pour les défauts de cache (miss), se connecter directement aux adresses IP des nœuds, et service de détection automatique de Memcached. Vous trouverez également des conseils sur la configuration du paramètre max-item-size, l'équilibrage des clusters et l'utilisation de Cloud Monitoring pour surveiller les métriques essentielles.
• Bonnes pratiques pour la gestion de la mémoire Memcached - configurer la mémoire pour une instance Memcached, configuration de la mémoire réservée, à quel moment augmenter la mémoire réservée, et métriques d'utilisation de la mémoire.

Guide de fiabilité Cloud DNS

Cloud DNS est un système de noms de domaine à faible latence qui permet d'enregistrer, de gérer et de diffuser vos domaines. Cloud DNS s'adapte à un grand nombre de zones et d'enregistrements DNS, et vous pouvez créer et mettre à jour des millions d'enregistrements DNS via une interface utilisateur.

Bonnes pratiques

• Bonnes pratiques Cloud DNS : découvrez comment gérer les zones privées, configurer le transfert DNS et créer des règles de serveur DNS. Inclut des conseils sur l'utilisation de Cloud DNS dans un environnement hybride.

Guide de fiabilité Cloud Load Balancing

Cloud Load Balancing est un service défini par logiciel qui est entièrement géré et distribué pour tout votre trafic. Cloud Load Balancing fournit également un autoscaling fluide, un équilibrage de charge de couche 4 et de couche 7, et une compatibilité avec des fonctionnalités telles que l'équilibrage de charge global IPv6.

Bonnes pratiques

• Bonnes pratiques en matière de performances : découvrez comment répartir la charge sur des instances d'application pour obtenir des performances optimales. Les stratégies incluent l'emplacement du backend dans les régions les plus proches du trafic, la mise en cache, la sélection du protocole de règle de transfert et la configuration de l'affinité de session.
• Utiliser l'équilibrage de charge pour les applications à disponibilité élevée : utilisez Cloud Load Balancing avec Compute Engine pour garantir la haute disponibilité, même pendant une panne de zone.

Guide de fiabilité Cloud CDN

Le réseau de diffusion de contenu Cloud CDN est un service qui accélère la diffusion des contenus Internet en exploitant le réseau périphérique de Google pour diffuser les contenus au plus près de l'utilisateur. Cloud CDN réduit la latence, les coûts et la charge, et permet ainsi de faire évoluer facilement les services aux utilisateurs.

Bonnes pratiques

• Bonnes pratiques pour la diffusion de contenu : comment optimiser le taux d'accès au cache à l'aide de clés de cache, s'assurer que HTTP/3 est activé pour des performances optimales, et consulter les métriques de surveillance à l'aide du tableau de bord de surveillance personnalisé de Cloud CDN. Et comment examiner les rapports sur la disponibilité, la latence et le débit à partir de tests de performances tiers

Guide de fiabilité BigQuery

BigQuery est la plate-forme d'entrepôt de données de Google Cloud permettant de stocker et d'analyser des données à grande échelle.

Bonnes pratiques

• Présentation de la fiabilité : bonnes pratiques et présentation de concepts tels que la disponibilité, la durabilité et la cohérence des données.
• Disponibilité et durabilité : les types de domaines de défaillance qui peuvent se produire dans les centres de données Google Cloud, la manière dont BigQuery fournit une redondance de stockage en fonction de l'emplacement de stockage des données et la raison pour laquelle les ensembles de données interrégionaux améliorent la reprise après sinistre.
• Bonnes pratiques pour les charges de travail mutualisées sur BigQuery : modèles courants utilisés dans les plates-formes de données mutualisées. Ces modèles garantissent la fiabilité et l'isolation pour les clients des fournisseurs de logiciels en tant que service (SaaS), les quotas et limites BigQuery importants pour la planification de la capacité, l'utilisation du service de transfert de données BigQuery pour copier des ensembles de données pertinents dans une autre région, et bien plus encore.
• Utiliser les vues matérialisées : découvrez comment utiliser les vues matérialisées BigQuery pour accélérer les requêtes à moindre coût, y compris comment interroger des vues matérialisées, aligner des partitions et comprendre les réglages intelligents (réécriture automatique des requêtes).

Guide de fiabilité Dataflow

Dataflow est un service de traitement des données entièrement géré qui permet de développer rapidement et facilement des pipelines de données par flux à l'aide de bibliothèques Apache Beam Open Source. Dataflow réduit la latence, la durée des traitements et les coûts grâce à l'autoscaling et au traitement par lot.

Bonnes pratiques

Créer des pipelines de données prêts pour la production à l'aide de Dataflow : série de documents sur l'utilisation de Dataflow, y compris la planification, le développement, le déploiement et la surveillance des pipelines Dataflow.

• Présentation : présentation des pipelines Dataflow.
• Planifier : mesurer les SLO, comprendre l'impact des sources et des récepteurs de données sur l'évolutivité et les performances du pipeline, et prendre en compte la haute disponibilité, la reprise après sinistre et les performances réseau lors de la spécification des régions pour exécuter vos tâches Dataflow.
• Développer et tester : configurer des environnements de déploiement, prévenir les pertes de données en utilisant des files d'attente de lettres mortes pour le traitement des erreurs, et réduire la latence et les coûts en minimisant les opérations coûteuses par élément. Utiliser également le traitement par lot pour réduire l'impact sur les performance sans surcharger les services externes, dissocier les étapes fusionnées de manière inappropriée pour les séparer afin d'améliorer les performances, et exécuter des tests de bout en bout en préproduction pour vous assurer que le pipeline continue de respecter vos SLO et autres exigences de production.
• Déployer : intégration continue (CI) et livraison et déploiement continus (CD), avec informations spécifiques au déploiement de nouvelles versions de pipelines de traitement par flux. Exemple de pipeline CI/CD et de certaines fonctionnalités permettant d'optimiser l'utilisation des ressources. Considérations concernant la haute disponibilité, la redondance géographique et les bonnes pratiques pour assurer la fiabilité des pipelines, y compris l'isolation régionale, l'utilisation d'instantanés, la gestion des erreurs d'envoi de tâches, ainsi que la résolution des erreurs et des pannes affectant les pipelines en cours d'exécution.
• Surveiller : observer les indicateurs de niveau de service (SLI), importants pour surveiller les performances du pipeline, définir et mesurer les objectifs de niveau de service (SLO).

Guide de fiabilité Dataproc

Dataproc est un service entièrement géré et évolutif permettant d'exécuter des tâches Apache Hadoop et Spark. Avec Dataproc, les machines virtuelles peuvent être personnalisées et faire l'objet d'un scaling à la hausse ou à la baisse en fonction des besoins. Dataproc s'intègre étroitement à Cloud Storage, BigQuery, Bigtable et d'autres services Google Cloud.

Bonnes pratiques

• Mode haute disponibilité de Dataproc : comparaison du mode haute disponibilité de Hadoop au mode standard par défaut concernant les noms d'instance, Apache ZooKeeper, Hadoop Distributed File System (HDFS) et Yet Another Resource Negotiator (YARN). Également, méthode de création d'un cluster haute disponibilité.
• Autoscaling des clusters : quand utiliser l'autoscaling Dataproc, comment créer une règle d'autoscaling, utilisation des stratégies multicluster, bonnes pratiques de fiabilité pour la configuration de l'autoscaling, métriques et journaux.
• Mode de flexibilité améliorée (EFM) de Dataproc : exemples d'utilisation du mode de flexibilité améliorée pour réduire les retards de progression de tâche, configuration avancée telle que le partitionnement et le parallélisme, mise hors service concertée YARN sur les clusters EFM.
• Mise hors service concertée : utilisation de la mise hors service concertée pour minimiser l'impact de la suppression des nœuds de calcul d'un cluster, utilisation de cette fonctionnalité avec des nœuds de calcul secondaires, exemples de commandes pour la mise hors service concertée.
• Jobs redémarrables : certains paramètres facultatifs vous permettent de configurer les jobs pour qu'ils redémarrent en cas d'échec afin de limiter les défaillances courantes des jobs, y compris les problèmes de saturation de la mémoire et les redémarrages inattendus de machines virtuelles Compute Engine.

Framework d'architecture Google Cloud : optimisation des coûts

Cette catégorie du framework d'architecture Google Cloud fournit des recommandations de conception et des bonnes pratiques pour aider les architectes, développeurs, administrateurs et autres professionnels du cloud à optimiser les coûts des charges de travail dans Google Cloud.

La migration de vos charges de travail informatiques vers le cloud vous permet d'innover à grande échelle, de proposer des fonctionnalités plus rapidement et de répondre à l'évolution des besoins de vos clients. Pour migrer des charges de travail existantes ou déployer des applications conçues pour le cloud, vous avez besoin d'une topologie optimisée pour la sécurité, la résilience, l'excellence opérationnelle, les coûts et les performances.

Dans la catégproe d'optimisation des coûts du framework d'architecture, vous allez apprendre à effectuer les opérations suivantes :

• Adopter et mettre en œuvre le FinOps : stratégies pour vous encourager à prendre en compte l'impact des coûts lors du provisionnement et de la gestion des ressources dans Google Cloud.
• Surveiller et contrôler les coûts : bonnes pratiques, outils et techniques permettant de suivre et de contrôler le coût de vos ressources dans Google Cloud.
• Optimiser les coûts : Compute Engine, conteneurs et informatique sans serveur : contrôles d'optimisation des coûts spécifiques aux services pour Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud Functions et App Engine.
• Optimiser les coûts : stockage : contrôles d'optimisation des coûts pour Cloud Storage, Persistent Disk et Filestore.
• Optimiser les coûts : bases de données et analyses intelligentes : contrôles d'optimisation des coûts pour BigQuery, Bigtable, Spanner, Cloud SQL, Dataflow et Dataproc.
• Optimiser les coûts : mise en réseau : contrôles d'optimisation des coûts pour vos ressources réseau dans Google Cloud.
• Optimiser les coûts : opérations cloud : recommandations pour vous aider à optimiser les coûts de surveillance et de gestion de vos ressources dans Google Cloud.

Adopter et mettre en œuvre FinOps

Ce document du framework d'architecture Google Cloud décrit les stratégies à mettre en place pour mieux prendre en compte l'impact des actions et des décisions sur le coût lors du provisionnement et de la gestion des ressources dans Google Cloud. Il aborde le FinOps, une pratique qui regroupe les personnes, les processus et les technologies pour promouvoir la responsabilité financière et la discipline dans l'optimisation des coûts pour une organisation, quelle que soit sa taille ou sa maturité dans le cloud.

Ces conseils sont destinés aux directeurs de la technologie, aux responsables des technologies de l'information et aux responsables chargés du contrôle des dépenses cloud de leur organisation. Elles aident également les opérateurs cloud individuels à comprendre et à adopter le FinOps.

Chaque employé de votre organisation peut contribuer à réduire le coût de vos ressources dans Google Cloud, quel que soit son rôle (analyste, architecte, développeur ou administrateur). Pour les équipes qui n'ont pas eu besoin d'assurer le suivi des coûts d'infrastructure par le passé, vous devrez peut-être informer les employés de cette nécessité d'une responsabilité collective.

Un modèle commun inclut une équipe FinOps centrale ou un Centre d'excellence cloud (CCoE) dont l'objectif est de standardiser le processus d'optimisation des coûts sur l'ensemble des charges de travail cloud. Ce modèle suppose que l'équipe centrale dispose des connaissances et de l'expertise nécessaires pour identifier des opportunités à forte valeur ajoutée afin d'améliorer l'efficacité.

Bien que le contrôle des coûts centralisé puisse fonctionner correctement lors des premières étapes de l'adoption du cloud lorsque l'utilisation est encore faible, il ne s'adapte pas bien lorsque l'adoption et l'utilisation du cloud augmentent. L'équipe centrale peut avoir des difficultés à se mettre à l'échelle, et les équipes de projet peuvent ne pas accepter les décisions prises par des personnes externes à leurs équipes.

Nous recommandons à l'équipe centrale de déléguer la prise de décisions en matière d'optimisation des ressources aux équipes projet. L'équipe centrale peut encourager l'adoption du FinOps dans l'ensemble de l'entreprise. Pour permettre aux équipes projet individuelles de s'entraîner au FinOps, l'équipe centrale doit standardiser le processus, la génération des rapports et les outils d'optimisation des coûts. L'équipe centrale doit travailler en étroite collaboration avec les équipes qui ne connaissent pas les pratiques FinOps et les aider à prendre en compte les coûts dans leurs processus décisionnels. L'équipe centrale doit également servir d'intermédiaire entre l'équipe financière et les équipes projet.

Les sections suivantes décrivent les principes de conception que nous recommandons pour votre équipe centrale.

Encourager la responsabilité individuelle

Tout employé qui crée et utilise des ressources cloud a une incidence sur l'utilisation et le coût de ces ressources. Pour qu'une organisation réussisse à mettre en œuvre le FinOps, l'équipe centrale doit aider les employés à passer d'un modèle où la responsabilité des coûts est extérieure à un modèle où les coûts sont une responsabilité individuelle. Dans le cadre de cette transition, les employés prennent eux-même les décisions concernant les coûts pour leurs charges de travail, leurs équipes et leur organisation. Cela s'étend de plus à la mise en œuvre d'actions d'optimisation des coûts basées sur les données.

Pour encourager la responsabilité des coûts, l'équipe centrale peut prendre les mesures suivantes :

• Éduquer les utilisateurs aux opportunités et aux techniques d'optimisation des coûts
• Récompensez et félicitez les employés qui contribuent à l'optimisation des coûts.
• Donner de la visibilité sur les coûts dans l'ensemble de l'organisation.

Donner de la visibilité sur les coûts

Pour que les employés prennent en compte les coûts lors du provisionnement et de la gestion des ressources dans le cloud, il leur faut une vue complète et aussi proche que possible du temps réel sur les données pertinentes. Les données des rapports et des tableaux de bord doivent refléter l'impact des décisions des membres de l'équipe sur les coûts à mesure que les effets surviennent. Les données d'utilisation et de coûts d'autres équipes peuvent servir de référence pour identifier des modèles de déploiement efficaces. Ces données peuvent vous aider à mieux comprendre les meilleures façons d'utiliser les services cloud.

Si l'organisation n'encourage pas le partage, les employés peuvent être réticents à partager les données de coût. Parfois, pour des raisons commerciales, une organisation peut ne pas autoriser le partage des données de coût brutes. Même dans ce cas, nous vous recommandons d'éviter toute règle par défaut qui restreint l'accès aux informations sur les coûts.

Pour rendre les coûts visibles dans l'ensemble de l'organisation, l'équipe centrale peut prendre les mesures suivantes :

• Utiliser une méthode unique et bien définie pour calculer les coût complet des ressources cloud. Par exemple, la méthode peut prendre en compte le montant total des dépenses cloud ajusté en fonction des remises achetées et des coûts partagés (coût des bases de données partagées par exemple).
• Configurer des tableaux de bord permettant aux employés de visualiser leurs dépenses cloud quasiment en temps réel.
• Pour inciter les membres de l'équipe à maîtriser leurs coûts, offrir aux équipes une visibilité accrue sur les dépenses liées au cloud.

Encourager la collaboration

Pour pouvoir gérer efficacement les coûts des ressources cloud, les équipes doivent améliorer leurs processus techniques et opérationnels. Une culture collaborative aide les équipes à concevoir des modèles de déploiement économiques basés sur un ensemble cohérent d'objectifs et de facteurs commerciaux.

Pour encourager la collaboration, l'équipe centrale peut prendre les mesures suivantes :

• Créer un processus d'intégration des charges de travail qui garantit la rentabilité dès la phase de conception grâce à l'examen par des pairs des architectures proposées par d'autres ingénieurs.
• Créer une base de connaissances inter-équipes avec des modèles architecturaux rentables.

Établir une culture irréprochable

Encouragez une culture de l'apprentissage et de la croissance qui permet de prendre des risques en toute sécurité, d'effectuer des corrections lorsque cela s'avère nécessaire et d'innover. Acceptez le fait que des erreurs, parfois coûteuses, peuvent se produire à n'importe quelle étape du cycle de conception et de déploiement IT, comme dans n'importe quelle autre partie de l'entreprise.

Plutôt que de blâmer et de pointer du doigt les individus qui ont entraîné des dépenses excessives ou du gaspillage, faites la promotion d'une culture irréprochable afin d'identifier la cause des dépenses excessives et des erreurs de calcul. Dans cet environnement, les membres de l'équipe sont plus susceptibles de partager leurs opinions et leur expérience. Les erreurs sont anonymisées et partagées au sein de l'entreprise afin d'éviter qu'elles ne se reproduisent.

Ne confondez pas une culture irréprochable avec un manque de responsabilité. Les employés restent responsables de leurs décisions et des sommes dépensées. Toutefois, en cas d'erreur, l'accent est mis sur l'opportunité d'apprentissage afin d'éviter que les erreurs ne se reproduisent.

Pour instaurer une culture irréprochable, l'équipe centrale peut prendre les mesures suivantes :

• Créer des rapports d'incidents pour les problèmes majeurs en se concentrant sur la cause systémique des problèmes plutôt que sur les personnes impliquées.
• Féliciter les membres de l'équipe qui répondent aux dépassements de budget et qui partagent les enseignements tirés de cette expérience. Encourager les autres membres de l'équipe à partager leurs erreurs, les actions entreprises et les enseignements tirés de cette expérience.

Se concentrer sur la valeur commerciale

Bien que les pratiques FinOps soient souvent axées sur la réduction des coûts, l'objectif d'une équipe centrale doit être de permettre aux équipes de projet de prendre des décisions qui maximisent la valeur commerciale de leurs ressources cloud. Il peut être tentant de prendre des décisions qui réduisent les coûts au maximum tout en offrant le niveau de service minimum souhaité. Toutefois, ces décisions déplacent souvent les coûts vers d'autres ressources, ce qui peut entraîner des coûts de maintenance plus élevés et augmenter votre coût total de possession. Par exemple, pour réduire les coûts, vous pouvez décider d'utiliser des machines virtuelles (VM) plutôt qu'un service géré. Toutefois, une solution basée sur des VM nécessite davantage d'efforts qu'un service géré, ce qui permet potentiellement au service géré d'offrir une valeur nette plus élevée.

Les pratiques FinOps peuvent fournir aux équipes de projet la visibilité et les informations dont elles ont besoin pour prendre des décisions architecturales et opérationnelles qui maximisent la valeur commerciale de leurs ressources cloud.

Pour aider les employés à se concentrer sur la valeur commerciale, l'équipe centrale peut prendre les mesures suivantes :

• Utiliser des services gérés et des architectures sans serveur pour réduire le coût total de possession des ressources de calcul. Pour en savoir plus, consultez la page Choisir une plate-forme de calcul.

• Corréler l'utilisation du cloud avec les métriques liées à la valeur commerciale (rentabilité, résilience, vélocité des fonctionnalités et innovation) afin de prendre des décisions adaptées pour optimiser les coûts. Pour en savoir plus sur les métriques liées à la valeur commerciale, consultez le livre blanc Cloud FinOps.

• Mettez en œuvre le coût unitaire pour tous vos services et applications exécutés dans le cloud.

Étape suivante

• Apprenez-en plus sur le FinOps :
  • Maximiser la valeur métier à l'aide de cloud FinOps
  • Premiers pas avec le FinOps sur Google Cloud
  • FinOps Foundation
  • Coûts unitaires dans le cloud
• Surveiller et contrôler les coûts
• Optimisez les coûts des services Google Cloud :
  • Optimiser les coûts : calcul, conteneurs et sans serveur
  • Optimiser les coûts : stockage
  • Optimiser les coûts : Bases de données et analyses intelligentes
  • Optimiser les coûts : mise en réseau
  • Optimiser les coûts : opérations cloud
• Explorez les autres catégories du framework d'architecture Google Cloud

Surveillance et contrôle des coûts

Ce document présenté dans le framework d'architecture Google Cloud décrit les bonnes pratiques, les outils et les techniques permettant de surveiller et de contrôler le coût de vos ressources dans Google Cloud.

Les conseils de cette section sont destinés aux utilisateurs qui provisionnent ou gèrent des ressources dans le cloud.

Domaines essentiels de la gestion des coûts

Le coût de vos ressources dans Google Cloud dépend de la quantité de ressources que vous utilisez et du tarif auquel vous êtes facturé pour les ressources.

Pour gérer le coût des ressources cloud, nous vous recommandons de vous concentrer sur les domaines suivants :

• Visibilité des coûts
• Optimisation des ressources
• Optimisation des tarifs

Visibilité des coûts

Effectuez le suivi de vos dépenses et de la facturation de vos ressources et services, afin de pouvoir analyser l'impact des coûts sur les résultats commerciaux. Nous vous recommandons d'appliquer le modèle d'exploitation FinOps, qui suggère les actions suivantes afin de rendre les informations sur les coûts visibles dans votre organisation :

• Attribuer : affectez un propriétaire à chaque élément de coût.
• Rapport : rendez les données de coût disponibles, consommables et exploitables.
• Prévoir : estimez et suivez les dépenses futures.

Optimisation des ressources

Alignez le nombre et la taille de vos ressources cloud sur les besoins de votre charge de travail. Dans la mesure du possible, envisagez d'utiliser des services gérés ou de restructurer vos applications. En règle générale, les équipes d'ingénieurs individuelles ont plus de contexte que l'équipe centrale FinOps (opérations financières) concernant les opportunités et les techniques d'optimisation du déploiement des ressources. Nous recommandons à l'équipe FinOps de collaborer avec les équipes d'ingénieurs individuelles pour identifier les opportunités d'optimisation des ressources pouvant être appliquées à l'ensemble de l'organisation.

Optimisation des tarifs

L'équipe FinOps prend régulièrement des décisions d'optimisation des tarifs de manière centralisée. Nous recommandons aux équipes individuelles d'ingénierie de travailler avec l'équipe FinOps centrale pour bénéficier de remises importantes sur les réservations, l'utilisation sur engagement, les VM Spot, la tarification forfaitaire, ainsi que de remises liées au volume et au contrat.

Recommandations en matière de conception

Cette section suggère des approches à utiliser pour surveiller et contrôler les coûts.

Facturation consolidée et gestion des ressources

Pour gérer efficacement la facturation et les ressources dans Google Cloud, nous vous recommandons d'utiliser un seul compte de facturation pour votre organisation et d'utiliser des mécanismes de rejet de débit internes pour allouer les coûts. Utilisez plusieurs comptes de facturation pour des conglomérats peu structurés et des organisations avec des entités qui ne s'affectent pas entre elles. Par exemple, les revendeurs peuvent avoir besoin de comptes distincts pour chaque client. L'utilisation de comptes de facturation distincts peut également vous aider à respecter les réglementations fiscales spécifiques à chaque pays.

Une autre bonne pratique recommandée consiste à déplacer tous les projets que vous gérez dans votre organisation. Nous vous recommandons d'utiliser Resource Manager pour créer une hiérarchie des ressources qui vous aide à atteindre les objectifs suivants :

• Établir une hiérarchie de propriété des ressources en fonction de la relation de chaque ressource avec son parent immédiat.
• Contrôler la manière dont les règles d'accès et les tags ou étiquettes d'allocation de coûts sont associés aux ressources de votre organisation et comment celles-ci en héritent.

En outre, nous vous recommandons d'allouer le coût des services partagés proportionnellement à la consommation. Examinez et ajustez régulièrement les paramètres de répartition des coûts en fonction de l'évolution de vos objectifs commerciaux et de vos priorités.

Suivre et allouer les coûts à l'aide de tags ou d'étiquettes

Les tags et les étiquettes sont deux méthodes différentes que vous pouvez utiliser pour annoter vos ressources Google Cloud. Les tags offrent plus de fonctionnalités que les étiquettes. Par exemple, vous pouvez mettre en œuvre un contrôle précis sur les ressources en créant des stratégies IAM (Identity and Access Management) qui revêtent un caractère conditionnel, selon qu'un tag est associé ou non à une ressource compatible. En outre, les tags associés à une ressource sont hérités par toutes les ressources enfants de la hiérarchie. Pour en savoir plus sur les différences entre les tags et les étiquettes, consultez la section Présentation des tags.

Si vous créez un framework pour l'allocation et le suivi des coûts, nous vous recommandons d'utiliser des tags.

Pour classer les données de coût avec le niveau de précision requis, établissez un schéma de taggage ou d'étiquetage adapté au mécanisme de rejet de débit de votre organisation, et qui vous aide à allouer les coûts de manière appropriée. Vous pouvez définir des tags au niveau de l'organisation ou du projet. Vous pouvez attribuer des étiquettes au niveau du projet et définir un ensemble d'étiquettes pouvant être appliquées par défaut à tous les projets.

Définissez un processus permettant de détecter et de corriger les anomalies de taggage et d'étiquetage, ainsi que les projets sans étiquette. Par exemple, à partir de l'inventaire des éléments cloud, vous pouvez télécharger un inventaire (fichier .csv) de toutes les ressources d'un projet et analyser cet inventaire afin d'identifier les ressources auxquelles aucun tag ni étiquette n'est attribué.

Pour suivre le coût des ressources et des services partagés (par exemple, des datastores communs, des clusters mutualisés et des abonnements d'assistance), envisagez d'utiliser une étiquette ou un tag spécial pour identifier les projets contenant des ressources partagées.

Configurer le contrôle des accès à la facturation

Pour contrôler l'accès à Cloud Billing, nous vous recommandons d'attribuer le rôle "Administrateur de compte de facturation" uniquement aux utilisateurs qui gèrent les coordonnées pour la facturation. Par exemple, les employés des services financiers, comptables et responsables des opérations peuvent avoir besoin de ce rôle.

Pour éviter tout point de défaillance unique pour l'assistance à la facturation, attribuez le rôle "Administrateur de compte de facturation" à plusieurs utilisateurs ou à un groupe. Seuls les utilisateurs disposant du rôle "Administrateur de compte de facturation" peuvent contacter l'assistance. Pour obtenir des conseils détaillés, consultez les sections Exemples de contrôle des accès Cloud Billing et Rôles importants.

Effectuez les configurations suivantes pour gérer l'accès à la facturation :

• Pour associer un compte de facturation à un projet, les membres doivent disposer du rôle "Utilisateur de compte de facturation" sur le compte de facturation et du rôle "Gestionnaire de la facturation du projet" sur le projet.
• Pour autoriser des équipes à associer manuellement des comptes de facturation à des projets, vous pouvez attribuer le rôle "Gestionnaire de la facturation du projet" au niveau de l'organisation et le rôle "Utilisateur de compte de facturation" au niveau du compte de facturation. Vous pouvez automatiser l'association des comptes de facturation lors de la création des projets en attribuant les rôles "Gestionnaire de la facturation du projet" et "Utilisateur du compte de facturation" à un compte de service. Nous vous recommandons de limiter le rôle "Créateur de compte de facturation" ou de supprimer toutes les attributions de ce rôle.
• Pour éviter les pannes causées par des modifications involontaires de l'état de facturation d'un projet, vous pouvez verrouiller l'association entre le projet et son compte de facturation. Pour plus d'informations, consultez la section Sécuriser l'association entre un projet et son compte de facturation.

Configurer les rapports de facturation

Configurez des rapports de facturation afin de fournir des données pour les métriques clés que vous devez suivre. Nous vous recommandons d'effectuer le suivi des métriques suivantes :

• Évolution des coûts
• Plus grosses dépenses (par projet et par produit)
• Zones de dépenses irrégulières
• Voici les insights clés à l'échelle de l'organisation :
  • Détection d'anomalies
  • Tendances dans le temps
  • Tendances au sein d'un modèle défini (mois par mois, par exemple)
  • Comparaison des coûts et analyse comparative des charges de travail internes et externes
  • Suivi d'un cas d'utilisation commercial et réalisation de valeur (par exemple, coûts liés au cloud comparés aux coûts de ressources sur site semblables)
  • Validation que les factures Google Cloud sont exactes et telles qu'attendues

Analyser les tendances et prévoir les coûts

Personnalisez et analysez les rapports de coûts en exportant vos données de facturation vers BigQuery, et visualisez les données de coûts à l'aide de Looker Studio. Évaluez les tendances des coûts réels et le montant que vous pourriez dépenser à l'aide de l'outil de prévision.

Optimiser l'utilisation et les coûts des ressources

Cette section recommande des bonnes pratiques pour vous aider à optimiser l'utilisation et les coûts de vos ressources sur les services Google Cloud.

Pour éviter les dépenses excessives, envisagez de configurer par défaut des budgets et des alertes avec des seuils élevés pour tous vos projets. Pour vous aider à respecter les budgets, nous vous recommandons d'effectuer les actions suivantes :

• Configurez des budgets et des alertes pour les projets dans lesquels des limites d'utilisation absolues sont nécessaires (par exemple, des projets d'entraînement ou des projets bac à sable).

• Définissez les budgets en fonction des budgets financiers que vous souhaitez surveiller. Par exemple, si un service dispose d'un budget cloud global, définissez le champ d'application du budget Google Cloud pour inclure les projets spécifiques que vous devez suivre.

• Pour garantir la maintenance des budgets, déléguez la responsabilité de la configuration des budgets et des alertes aux équipes qui possèdent les charges de travail.

Pour optimiser les coûts, nous vous recommandons également de procéder comme suit :

• Limitez l'utilisation des API lorsque leur impact est minime, voire nul. Le plafonnement peut s'avérer utile pour les projets de bac à sable ou d'entraînement, et pour les projets avec des budgets fixes (par exemple, des analyses ad hoc dans BigQuery). Le plafonnement ne supprime pas toutes les ressources et données des projets associés.
• Les quotas vous permettent de définir des limites strictes qui limitent le déploiement des ressources. Les quotas vous aident à contrôler les coûts et à éviter toute utilisation malveillante ou abusive des ressources. Les quotas sont appliqués au niveau du projet, par type de ressource et par emplacement.
• Affichez et mettez en œuvre les recommandations d'optimisation des coûts du centre de recommandations.
• Souscrivez des remises sur engagement d'utilisation pour réaliser des économies sur les ressources destinées aux charges de travail ayant des besoins en ressources prévisibles.

Outils et techniques

Le provisionnement à la demande et les caractéristiques de tarification à l'utilisation du cloud vous aident à optimiser vos dépenses informatiques. Cette section décrit les outils fournis par Google Cloud et les techniques que vous pouvez utiliser pour suivre et contrôler le coût de vos ressources dans le cloud. Avant d'utiliser ces outils et techniques, consultez les concepts de base de Cloud Billing.

Rapports de facturation

Google Cloud fournit des rapports de facturation dans la console Google Cloud pour vous aider à afficher vos dépenses actuelles et prévues. Les rapports de facturation vous permettent d'afficher les données de coût sur une seule page, de découvrir et d'analyser les tendances, de prévoir les coûts de fin de période et de prendre des mesures correctives si nécessaire.

Les rapports de facturation fournissent les données suivantes :

• Coûts et tendances des coûts pour une période donnée, organisés comme suit :
  • Par compte de facturation
  • Par projet
  • Par produit (par exemple, Compute Engine)
  • Par SKU (par exemple, adresses IP statiques)
• Coûts potentiels si des remises ou des avoirs promotionnels ont été exclus
• Dépenses prévues

Exportation de données vers BigQuery

Vous pouvez exporter des rapports de facturation vers BigQuery, et analyser les coûts à l'aide de vues détaillées et historiques des données, y compris des données classées à l'aide d'étiquettes ou de tags. Vous pouvez effectuer des analyses plus avancées à l'aide de BigQuery ML. Nous vous recommandons d'activer l'exportation des rapports de facturation vers BigQuery lorsque vous créez le compte de facturation Cloud. Votre ensemble de données BigQuery contient des données de facturation à partir de la date de configuration de l'exportation Cloud Billing. L'ensemble de données n'inclut pas les données de la période antérieure à l'activation de l'exportation.

Remarque : Les données de facturation exportées peuvent être différentes de celles des factures, en raison des données tardives, des variations de l'horodatage, des erreurs et des ajustements, ainsi que des taxes. Pour en savoir plus, consultez la section Différences entre les données exportées et les factures.

Pour visualiser les données de coût, vous pouvez créer des tableaux de bord personnalisés qui s'intègrent à BigQuery (exemples de modèles : Looker, Looker Studio).

Vous pouvez utiliser des tags et des étiquettes comme critères de filtrage des données de facturation exportées. Le nombre d'étiquettes incluses dans l'exportation de la facturation est limité. Jusqu'à 1 000 mappages de libellés en une période d'une heure sont conservés. Les étiquettes n'apparaissent pas dans la facture au format PDF ou CSV. Pensez à annoter les ressources à l'aide de tags ou d'étiquettes indiquant l'unité commerciale, l'unité de rejet de débit interne ainsi que les autres métadonnées pertinentes.

Contrôle des accès à la facturation

Vous pouvez contrôler l'accès à Cloud Billing pour des ressources spécifiques en définissant des stratégies Identity and Access Management (IAM) pour les ressources. Pour accorder ou limiter l'accès à Cloud Billing, vous pouvez définir une stratégie IAM au niveau de l'organisation, au niveau du compte de facturation ou au niveau du projet.

Remarque : Bien que les comptes de facturation soient associés à des projets, ils ne sont pas des projets parents dans IAM. Les projets n'héritent pas des autorisations du compte de facturation auquel ils sont associés.

Le contrôle des accès pour la facturation et la gestion des ressources suit le principe de séparation des tâches. Chaque utilisateur ne dispose que des autorisations nécessaires pour son rôle métier. Les rôles "Administrateur de l'organisation" et "Administrateur de la facturation" ne disposent pas des mêmes autorisations.

Vous pouvez définir des autorisations concernant la facturation au niveau du compte de facturation et de l'organisation. Les rôles courants incluent "Administrateur de compte de facturation", "Utilisateur de compte de facturation" et "Lecteur de compte de facturation".

Nous vous recommandons d'utiliser la facturation avec paiement sur facture mensuelle ou de configurer un mode de paiement secondaire. Gérez les paramètres de contact et de notification pour la facturation et le paiement.

Budgets, alertes et quotas

Les budgets vous permettent de suivre les coûts réels de Google Cloud par rapport aux dépenses planifiées. Lorsque vous créez un budget, vous pouvez configurer des règles d'alerte pour déclencher des notifications par e-mail lorsque les dépenses réelles ou prévisionnelles dépassent un certain seuil. Vous pouvez également utiliser des budgets pour automatiser les réponses au contrôle des coûts.

Les budgets peuvent déclencher des alertes afin de vous tenir informé de l'utilisation des ressources et de l'évolution des coûts, et vous invitent à prendre des mesures d'optimisation des coûts. Toutefois, les budgets n'empêchent pas l'utilisation ni la facturation de vos services lorsque le coût réel atteint ou dépasse le budget ou le seuil. Pour contrôler automatiquement les coûts, vous pouvez utiliser les notifications de budget afin de désactiver de manière automatisée Cloud Billing pour un projet. Vous pouvez également limiter l'utilisation des API pour arrêter les coûts après un seuil d'utilisation défini.

Vous pouvez configurer des alertes pour les comptes de facturation et les projets. Configurez au moins un budget par compte.

Pour éviter de provisionner des ressources au-delà d'un niveau prédéterminé ou pour limiter le volume d'opérations spécifiques, vous pouvez définir des quotas au niveau de la ressource ou de l'API. Vous trouverez ci-dessous des exemples d'utilisation de quotas :

• Contrôler le nombre d'appels d'API par seconde
• Limiter le nombre de VM créées
• Limiter la quantité de données interrogées par jour dans BigQuery

Les propriétaires de projet peuvent réduire le montant de quota pouvant être imputé sur une limite de quota, en utilisant l'API Service Usage pour appliquer des remplacements client à certaines limites de quota spécifiques. Pour en savoir plus, consultez la section Créer un remplacement de quota client.

Améliorer l'efficacité des charges de travail

Nous recommandons les stratégies suivantes pour vous aider à rendre vos charges de travail dans Google Cloud économiques :

• Optimisez l'utilisation des ressources en améliorant l'efficacité des produits.
• Réduisez le tarif auquel vous êtes facturé pour les ressources.
• Contrôlez et limitez l'utilisation des ressources et leurs dépenses.

Lorsque vous sélectionnez des techniques de réduction des coûts et des fonctionnalités Google Cloud, tenez compte des efforts requis et des économies attendues, comme indiqué dans le graphique suivant :

Voici un récapitulatif des techniques présentées dans le graphique précédent :

• Les techniques suivantes peuvent vous permettre de réaliser des économies importantes sans effort :
  • Remises sur engagement d'utilisation
  • Autoscaling
  • Emplacements BigQuery
• Les techniques suivantes peuvent vous permettre de faire des économies importantes au prix d'efforts modérés à élevés :
  • VM Spot
  • Modifier l'architecture en tant qu'applications sans serveur ou conteneurisées
  • Changer de plate-forme pour utiliser des services gérés
• Les techniques suivantes peuvent vous permettre de réaliser des économies modérées au prix d'efforts modérés :
  • Machines personnalisées
  • Gestion du cycle de vie Cloud Storage
  • Dimensionnement
  • Récupérer des ressources inactives

Les techniques expliquées dans les sections suivantes peuvent vous aider à améliorer l'efficacité de vos charges de travail.

Refactorisation ou modification de l'architecture

Vous pouvez réaliser des économies considérables en refactorisant ou en restructurant l'architecture de votre charge de travail de manière à utiliser les produits Google Cloud. Par exemple, l'adoption de services sans serveur (tels que Cloud Storage, Cloud Run, BigQuery et Cloud Functions) compatibles avec le scaling à zéro instance contribue à améliorer l'efficacité. Pour évaluer et comparer le coût de ces produits, vous pouvez utiliser le simulateur de coût.

Dimensionnement

Cette technique vous permet de vous assurer que l'échelle de votre infrastructure correspond à l'utilisation prévue. Cette stratégie est principalement pertinente pour les solutions IaaS (Infrastructure as a Service), dans lesquelles l'infrastructure sous-jacente vous est facturée. Par exemple, vous avez déployé 50 VM, mais les VM ne sont pas entièrement utilisées et vous déterminez que les charges de travail peuvent s'exécuter efficacement sur un nombre de VM inférieur ou sur des VM plus petites. Dans ce cas, vous pouvez supprimer ou redimensionner certaines VM. Google Cloud propose des recommandations de redimensionnement pour vous aider à détecter les opportunités permettant de réaliser des économies sans affecter les performances en provisionnant des VM plus petites. Le redimensionnement nécessite moins d'efforts pendant la phase de conception qu'après le déploiement des ressources en production.

Autoscaling

Si les produits que vous utilisez sont compatibles avec l'autoscaling dynamique, envisagez de concevoir les charges de travail de manière à exploiter l'autoscaling pour obtenir des avantages en termes de coûts et de performances. Par exemple, pour les charges de travail nécessitant beaucoup de ressources de calcul, vous pouvez utiliser des groupes d'instances gérés dans Compute Engine ou conteneuriser les applications et les déployer sur un cluster Google Kubernetes Engine.

Recommandations Active Assist

Active Assist utilise les données, l'intelligence et le machine learning pour réduire la complexité du cloud et les tâches administratives. Active Assist facilite l'optimisation de la sécurité, des performances et des coûts de votre topologie cloud. Il fournit des recommandations intelligentes pour optimiser vos coûts et l'utilisation de vos budgets. Vous pouvez appliquer ces recommandations pour faire des économies immédiates et gagner en efficacité.

Vous trouverez ci-dessous des exemples de recommandations fournies par Active Assist :

• Redimensionnement de ressources Compute Engine : redimensionnez vos instances de VM pour optimiser les coûts et les performances en fonction de l'utilisation. Identifiez et supprimez ou sauvegardez les VM inactives et les disques persistants afin d'optimiser le coût de votre infrastructure.
• Remise sur engagement d'utilisation : Google Cloud analyse votre historique d'utilisation, trouve la quantité d'engagement optimale pour vos charges de travail et fournit des recommandations faciles à comprendre et à exploiter pour réduire les coûts. Pour en savoir plus, consultez la section Outil de recommandation de remises sur engagement d'utilisation.
• Projets dormants : découvrez les projets dormants dans votre organisation, et supprimez ou récupérez-les. Pour en savoir plus, consultez la section Outil de recommandation de projets dormants.

Pour connaître la liste complète, consultez la section Outils de recommandation.

Étape suivante

• Découvrir les concepts de Cloud Billing
• Définir des budgets et des alertes de budget
• Optimiser les coûts des services de calcul, du stockage, des bases de données, de la mise en réseau et des opérations :
  • Optimiser les coûts : calcul, conteneurs et sans serveur
  • Optimiser les coûts : stockage
  • Optimiser les coûts : Bases de données et analyses intelligentes
  • Optimiser les coûts : mise en réseau
  • Optimiser les coûts : opérations cloud
• Explorez les autres catégories du framework d'architecture Google Cloud

Optimiser les coûts : calcul, conteneurs et sans serveur

Ce document du framework d'architecture Google Cloud fournit des recommandations pour vous aider à optimiser le coût de vos machines virtuelles (VM), conteneurs et ressources sans serveur dans Google Cloud.

Les conseils de cette section sont destinés aux architectes, aux développeurs et aux administrateurs chargés du provisionnement et de la gestion des ressources de calcul pour les charges de travail dans le cloud.

Les ressources de calcul constituent la partie la plus importante de votre infrastructure cloud. Lorsque vous migrez vos charges de travail vers Google Cloud, le premier choix est bien souvent Compute Engine, qui vous permet de provisionner et de gérer efficacement les VM dans le cloud. Compute Engine est compatible avec de nombreux types de machines et est disponible dans toutes les régions Google Cloud. Les types de machines prédéfinis et personnalisés de Compute Engine vous permettent de provisionner des VM offrant une capacité de calcul semblable à celle de votre infrastructure sur site, ce qui vous permet d'accélérer le processus de migration. Avec Compute Engine, vous ne payez que l'infrastructure que vous utilisez et vous réalisez des économies considérables grâce à l'utilisation plus importante des ressources de calcul et aux remises automatiques proportionnelles à une utilisation soutenue.

En plus de Compute Engine, Google Cloud propose des conteneurs et des services de calcul sans serveur. L'approche sans serveur peut être plus rentable pour les nouveaux services qui ne sont pas toujours en cours d'exécution (par exemple, les API, le traitement de données et le traitement d'événements).

En plus des recommandations générales, ce document fournit des conseils pour vous aider à optimiser le coût de vos ressources de calcul lorsque vous utilisez les produits suivants :

• Compute Engine
• Google Kubernetes Engine (GKE)
• Cloud Run
• Cloud Functions
• App Engine

Recommandations générales

Les recommandations suivantes s'appliquent à tous les services de calcul et de conteneurs ainsi qu'aux services sans serveur de Google Cloud qui sont décrits dans cette section.

Suivre l'utilisation et les coûts

Vous pouvez surveiller l'utilisation des ressources et les coûts à l'aide des outils et techniques suivants :

• Affichez les recommandations d'optimisation des coûts et répondez-y dans le centre de recommandations.
• Recevez des notifications par e-mail en cas d'augmentation potentielle de l'utilisation des ressources et des coûts en configurant des alertes de budget.
• Gérez les alertes et répondez-y de manière automatisée à l'aide des services Pub/Sub et Cloud Functions.

Contrôler le provisionnement des ressources

Suivez les recommandations suivantes pour contrôler la quantité de ressources provisionnées dans le cloud et l'emplacement où les ressources sont créées :

• Pour vous assurer que la consommation de ressources et les coûts ne dépassent pas les prévisions, utilisez des quotas de ressources.
• Provisionnez des ressources dans la région la moins coûteuse qui répond aux exigences de latence de votre charge de travail. Pour contrôler l'emplacement de provisionnement des ressources, vous pouvez utiliser la contrainte de règle d'administration gcp.resourceLocations.

Obtenir des remises sur engagement d'utilisation

Les remises sur engagement d'utilisation sont idéales pour les charges de travail ayant des besoins en ressources prévisibles. Après avoir migré votre charge de travail vers Google Cloud, déterminez le niveau de ressources minimum requis et obtenez des remises plus importantes sur votre engagement d'utilisation. Par exemple, vous pouvez souscrire un engagement d'un ou trois ans et obtenir une remise importante sur les tarifs des VM Compute Engine.

Automatiser le suivi des coûts à l'aide de libellés

Définissez et attribuez des libellés de manière cohérente. Vous trouverez ci-dessous des exemples d'utilisation de libellés pour automatiser le suivi des coûts :

• Pour les VM utilisées exclusivement par les développeurs pendant les heures d'ouverture, attribuez le libellé env: development. Vous pouvez utiliser Cloud Scheduler pour configurer une fonction Cloud Functions sans serveur afin d'arrêter ces VM après les heures d'ouverture et les redémarrer si nécessaire.

• Pour une application comprenant plusieurs services Cloud Run et instances Cloud Functions, attribuez un libellé cohérent à toutes les ressources Cloud Run et Cloud Functions. Identifiez les domaines les plus coûteux et prenez les mesures nécessaires pour réduire les coûts.

Personnaliser les rapports de facturation

Configurez vos rapports Cloud Billing en configurant les filtres requis et en regroupant les données si nécessaire (par exemple, par projets, services ou libellés).

Promouvoir une culture de l'économie

Formez vos développeurs et vos opérateurs sur votre infrastructure cloud. Créez et faites la promotion de programmes de formation regroupant cours traditionnels ou en ligne, groupes de discussion, examens par les pairs, programmation en binôme et jeux en lien avec la culture de l'économie. Comme indiqué dans l'étude de l'équipe DORA de Google, la culture organisationnelle est un facteur clé pour améliorer les performances, réduire les retraitements et le surmenage ou encore pour optimiser les coûts. En offrant aux employés une visibilité sur le coût de leurs ressources, vous les aidez à aligner leurs priorités et leurs activités sur les objectifs et les contraintes de l'entreprise.

Compute Engine

Cette section fournit des conseils pour vous aider à optimiser le coût de vos ressources Compute Engine. En plus de ces conseils, nous vous recommandons de suivre les recommandations générales décrites précédemment.

Comprendre le modèle de facturation

Pour en savoir plus sur les options de facturation de Compute Engine, consultez la page Tarifs.

Analyser la consommation de ressources

Pour mieux comprendre la consommation de ressources dans Compute Engine, exportez les données d'utilisation vers BigQuery. Interrogez le datastore BigQuery pour analyser les tendances d'utilisation des processeurs virtuels de votre projet et déterminer le nombre de processeurs virtuels que vous pouvez récupérer. Si vous avez défini des seuils pour le nombre de cœurs par projet, analysez les tendances d'utilisation afin d'identifier les anomalies et de prendre des mesures correctives.

Récupérer des ressources inactives

Utilisez les recommandations suivantes pour identifier et récupérer les VM et les disques inutilisés, par exemple les VM des projets de démonstration de faisabilité qui ont depuis été abandonnés :

• Utilisez l'outil de recommandation de VM inactives pour identifier les VM inactives et les disques persistants, en fonction des métriques d'utilisation.
• Avant de supprimer des ressources, évaluez l'impact potentiel de l'action et envisagez de recréer les ressources si nécessaire.
• Avant de supprimer une VM, envisagez de prendre un instantané. Lorsque vous supprimez une VM, les disques associés sont supprimés sauf si vous avez sélectionné l'option Conserver le disque.
• Si possible, envisagez d'arrêter les VM au lieu de les supprimer. Lorsque vous arrêtez une VM, l'instance est arrêtée mais les disques et les adresses IP sont conservés jusqu'à ce que vous les dissociez de l'instance ou que vous les supprimiez.

Ajuster la capacité en fonction de la demande

Programmez vos VM pour qu'elles démarrent et s'arrêtent automatiquement. Par exemple, si une VM n'est utilisée que huit heures par jour pendant cinq jours par semaine (soit 40 heures dans la semaine), vous pouvez réduire les coûts de 75 % en arrêtant la VM pendant les 128 heures de la semaine pendant lesquelles elle n'est pas utilisée.

Procédez à un autoscaling de la capacité de calcul en fonction de la demande, à l'aide de groupes d'instances gérés. Vous pouvez procéder à un autoscaling de la capacité en fonction des métriques importantes pour votre entreprise (par exemple, l'utilisation du processeur ou la capacité d'équilibrage de charge).

Choisir les types de machines appropriés

Dimensionnez vos VM pour répondre aux exigences de calcul de votre charge de travail en utilisant l'outil de recommandation du type de machine d'une VM.

Pour les charges de travail ayant des besoins en ressources prévisibles, adaptez le type de machine à vos besoins et réalisez des économies en utilisant des VM personnalisées.

Pour les charges de travail de traitement par lot tolérantes aux pannes, envisagez d'utiliser des VM spot. Les calculs haute performance (HPC), le big data, le transcodage multimédia, les pipelines d'intégration et de diffusion continues (CI/CD) et les applications Web sans état sont des exemples de charges de travail pouvant être déployées sur des VM Spot. Pour obtenir un exemple de réduction des coûts d'analyse de Descartes Labs en utilisant des VM préemptives (l'ancienne version des VM Spot) pour traiter les images satellite, consultez l'étude de cas de Descartes Labs.

Évaluer les options d'attribution de licences

Lorsque vous migrez des charges de travail tierces vers Google Cloud, vous pouvez peut-être réduire les coûts en utilisant vos propres licences (BYOL). Par exemple, pour déployer des VM Microsoft Windows Server, vous pouvez créer et utiliser une image BYOL Windows personnalisée plutôt que d'utiliser une image payante qui entraîne des coûts supplémentaires pour la licence tierce. Vous ne payez alors que pour l'infrastructure de VM que vous utilisez sur Google Cloud. Cette stratégie vous permet de continuer à tirer profit de vos investissements existants en licences tierces.

Si vous décidez d'utiliser une approche BYOL, nous vous recommandons d'effectuer les opérations suivantes :

• Provisionnez le nombre de cœurs de processeur requis indépendamment de la mémoire, en utilisant les types de machines personnalisés et en limitant le coût des licences tierces au nombre de cœurs de processeur dont vous avez besoin.
• Réduisez le nombre de processeurs virtuels par cœur de 2 à 1 en désactivant le multithreading simultané pour réduire vos coûts de licence de 50 %.

Si vos charges de travail tierces nécessitent du matériel dédié pour répondre aux exigences de sécurité ou de conformité, vous pouvez utiliser vos propres licences sur des nœuds à locataire unique.

Google Kubernetes Engine

Cette section fournit des conseils pour vous aider à optimiser le coût de vos ressources GKE.

Outre les recommandations suivantes, consultez les recommandations générales décrites précédemment :

• Utilisez GKE Autopilot pour permettre à GKE de maximiser l'efficacité de l'infrastructure de votre cluster. Vous n'avez pas besoin de surveiller l'état des nœuds, de gérer le bin-packing ni de calculer la capacité dont vos charges de travail ont besoin.
• Ajustez l'autoscaling GKE à l'aide de l'autoscaler horizontal de pods (HPA), de l'autoscaler vertical de pods (VPA), de l'autoscaler de cluster (CA) ou du provisionnement automatique des nœuds en fonction des exigences de votre charge de travail.
• Pour les charges de travail par lots non sensibles à la latence de démarrage, utilisez le profil d'autoscaling optimisation-utilisation afin d'améliorer l'utilisation du cluster.
• Utilisez le provisionnement automatique des nœuds pour étendre l'autoscaler de cluster GKE afin de créer et supprimer efficacement des pools de nœuds en fonction des spécifications des pods en attente, sans surprovisionnement.
• Utilisez des pools de nœuds distincts : un pool de nœuds statiques pour le chargement statique et des pools de nœuds dynamiques avec des groupes d'autoscaling de cluster pour les chargements dynamiques.
• Utilisez des VM Spot pour les pools de nœuds Kubernetes lorsque vos pods sont tolérants aux pannes et peuvent s'arrêter en moins de 25 secondes. Associée à l'autoscaler de cluster GKE, cette stratégie vous permet de vous assurer que le pool de nœuds doté de VM moins coûteuses (dans ce cas, le pool de nœuds avec des VM spot) évolue en premier.
• Choisissez des types de machines économiques (par exemple, E2, N2D, T2D) qui offrent un rapport performance-prix entre 20 et 40 % plus élevé.
• Utilisez la mesure de l'utilisation de GKE pour analyser les profils d'utilisation de vos clusters par espace de noms et par libellé. Identifiez l'équipe ou l'application qui dépense le plus, l'environnement ou le composant à l'origine des pics d'utilisation ou de coûts, et l'équipe qui gaspille le plus de ressources.
• Utilisez des quotas de ressources dans les clusters mutualisés afin d'empêcher les locataires d'utiliser plus que la part de ressources du cluster qui leur est attribuée.
• Planifiez un scaling à la baisse automatique pour les environnements de développement et de test après les heures d'ouverture.
• Suivez les bonnes pratiques pour exécuter des applications Kubernetes à coût maîtrisé sur GKE.

Cloud Run

Cette section fournit des conseils pour vous aider à optimiser le coût de vos ressources Cloud Run.

Outre les recommandations suivantes, consultez les recommandations générales décrites précédemment :

• Ajustez le paramètre de simultanéité (par défaut : 80) pour réduire les coûts. Cloud Run détermine le nombre de requêtes à envoyer à une instance en fonction de l'utilisation du processeur et de la mémoire. En augmentant la simultanéité des requêtes, vous pouvez réduire le nombre d'instances requises.
• Définissez une limite pour le nombre d'instances pouvant être déployées.
• Estimez le nombre d'instances requises en vous basant sur la métrique Temps d'instance facturable. Par exemple, si la métrique affiche 100s/s, environ 100 instances ont été planifiées. Ajoutez à cela un tampon de 30 % pour préserver les performances. soit 130 instances pour 100 s/s de trafic.
• Pour réduire l'impact des démarrages à froid, configurez un nombre minimal d'instances. Lorsque ces instances sont inactives, elles sont facturées au dixième du prix.
• Suivez l'utilisation du processeur et ajustez les limites de processeur en conséquence.
• Utilisez la gestion du trafic pour déterminer une configuration optimale des coûts.
• Envisagez d'utiliser Cloud CDN ou Firebase Hosting pour diffuser les éléments statiques.
• Envisagez de déployer les applications Cloud Run qui gèrent des requêtes à l'échelle mondiale dans plusieurs régions, car le transfert de données intercontinental peut s'avérer coûteux. Cette conception est recommandée si vous utilisez un équilibreur de charge et un CDN.
• Réduisez les temps de démarrage de vos instances, car ce temps de démarrage est également facturable.
• Obtenez des remises sur engagement d'utilisation et bénéficiez d'une réduction pouvant atteindre 17 % sur le tarif à la demande pour un engagement d'un an.

Cloud Functions

Cette section fournit des conseils pour vous aider à optimiser le coût de vos ressources Cloud Functions.

Outre les recommandations suivantes, consultez les recommandations générales décrites précédemment :

• Observez le temps d'exécution de vos fonctions. Effectuez des tests et des analyses comparatives pour concevoir la plus petite fonction possible pour satisfaire le seuil de performances requis.
• Si vos charges de travail Cloud Functions s'exécutent en permanence, envisagez d'utiliser GKE ou Compute Engine pour les gérer. Les conteneurs ou les VM peuvent être des options moins coûteuses pour les charges de travail en cours d'exécution.
• Limitez le nombre d'instances de fonction pouvant coexister.
• Analysez les performances d'exécution des langages de programmation de Cloud Functions par rapport à la charge de travail de votre fonction. Les programmes dans les langages compilés présentent des démarrages à froid plus longs mais s'exécutent plus rapidement. Les programmes dans les langages interprétés sont plus lents mais ont des coûts de démarrage à froid inférieurs. Les fonctions simples et courtes qui s'exécutent fréquemment peuvent coûter moins cher dans un langage interprété.
• Supprimez les fichiers temporaires écrits sur le disque local, qui est en fait un système de fichiers en mémoire. Les fichiers temporaires consomment de la mémoire allouée à votre fonction et persistent parfois entre les appels. Si vous ne les supprimez pas, une erreur de mémoire insuffisante peut se produire et déclencher un démarrage à froid, ce qui augmente le temps d'exécution et les coûts.

App Engine

Cette section fournit des conseils pour vous aider à optimiser le coût de vos ressources App Engine.

Outre les recommandations suivantes, consultez les recommandations générales décrites précédemment :

• Définissez le nombre maximal d'instances en fonction de votre trafic et de la latence des requêtes. App Engine fait évoluer la capacité en fonction du trafic reçu par les applications. Vous pouvez contrôler les coûts en limitant le nombre d'instances qu'App Engine peut créer.
• Pour limiter la mémoire ou le nombre de processeurs disponibles pour votre application, définissez une classe d'instance. Pour les applications nécessitant une utilisation intensive du processeur, allouez plus de processeurs. Testez plusieurs configurations pour déterminer la taille optimale.
• Analysez votre charge de travail App Engine dans plusieurs langages de programmation. Par exemple, une charge de travail mise en œuvre dans un langage donné peut nécessiter moins d'instances et être moins coûteuse pour un volume de traitement identique à la même charge de travail programmée dans un autre langage.
• Optimisez pour réduire les démarrages à froid. Si possible, réduisez les tâches nécessitant une utilisation intensive du processeur ou les tâches de longue durée qui se produisent dans le champ d'application global. Essayez de décomposer la tâche en opérations plus petites pouvant être "chargées en différé" dans le contexte d'une requête.
• Si vous prévoyez un trafic intensif, configurez un nombre minimal d'instances inactives qui sont préalablement démarrées. Si vous ne prévoyez pas de trafic, vous pouvez configurer le nombre minimal d'instances inactives sur zéro.
• Pour équilibrer les performances et les coûts, effectuez un test A/B en répartissant le trafic entre deux versions, chacune avec une configuration différente. Surveillez les performances et les coûts de chaque version, ajustez-les selon vos besoins et décidez de la configuration vers laquelle envoyer le trafic.
• Configurez la simultanéité des requêtes et définissez un nombre de requêtes simultanées maximal supérieur à celui par défaut. Plus le nombre de requêtes que chaque instance peut traiter simultanément est important, plus vous pouvez utiliser les instances existantes efficacement pour diffuser le trafic.

Étape suivante

• Découvrez comment optimiser le coût des ressources GKE :
  • Exécuter des applications Kubernetes à coût maîtrisé sur GKE : bonnes pratiques
  • Bonnes pratiques pour réduire le surprovisionnement dans GKE
  • Optimiser l'utilisation des ressources dans un cluster GKE mutualisé à l'aide du provisionnement automatique des nœuds.
  • Réduire les coûts en procédant au scaling à la baisse des clusters GKE pendant les heures creuses
  • Exécuter des applications Web sur GKE à l'aide de VM Spot économiques
  • Estimer les coûts GKE dès le début du cycle de développement à l'aide de GitLab
  • Série de vidéos : Optimisation des coûts de GKE
  • Entraînement : Optimiser les coûts pour GKE
• Découvrez comment optimiser le coût des ressources Cloud Run et Cloud Functions :
  • Gérer les coûts et la fiabilité avec des applications entièrement gérées.
  • Optimiser la gestion des coûts à long terme dans des applications entièrement gérées.
  • Optimiser vos investissements Cloud Run avec les nouvelles remises sur engagement d'utilisation.
• Optimiser le coût du stockage, des bases de données, de la mise en réseau et des opérations :
  • Optimisation des coûts : Stockage
  • Optimiser les coûts : Bases de données et analyses intelligentes
  • Optimiser les coûts : mise en réseau
  • Optimiser les coûts : opérations cloud
• Explorez les autres catégories du framework d'architecture Google Cloud

Optimiser les coûts : stockage

Ce document présenté dans le framework d'architecture Google Cloud fournit des recommandations pour vous aider à optimiser l'utilisation et les coûts de vos ressources Cloud Storage, Persistent Disk et Filestore.

Les conseils de cette section sont destinés aux architectes et aux administrateurs responsables du provisionnement et de la gestion du stockage des charges de travail dans le cloud.

Remarque : Pour obtenir des conseils sur la sélection de services de stockage adaptés à votre charge de travail, consultez la page Concevez une stratégie de stockage optimale pour votre charge de travail cloud.

Cloud Storage

Lorsque vous planifiez Cloud Storage pour vos charges de travail, tenez compte de vos exigences en matière de performances, de conservation des données et de modèles d'accès.

Classe de stockage

Choisissez une classe de stockage répondant aux exigences de conservation des données et de fréquence d'accès de vos charges de travail, comme recommandé dans le tableau suivant :

Exigences de stockage	Recommandation
Données fréquemment consultées (analyse à haut débit ou lacs de données, sites Web, vidéos en streaming et applications mobiles).	Stockage standard
Stockage à faible coût pour les données rarement consultées, qui peuvent être stockées pendant au moins 30 jours (par exemple, des sauvegardes et des contenus multimédias à longue traîne)	Stockage Nearline
Données rarement consultées et pouvant être stockées pendant au moins 90 jours (par exemple, des copies de données pour la reprise après sinistre).	Stockage Coldline
Service de stockage le moins coûteux pour les données rarement consultées, qui peuvent être stockées pendant au moins 365 jours (par exemple, des archives juridiques et réglementaires).	Stockage Archive

Remarque : Les classes de stockage Nearline, Coldline et Archive coûtent moins cher que le stockage Standard, mais donnent lieu à des frais de récupération de données plus élevés et une pénalité de suppression anticipée.

Emplacement

Sélectionnez l'emplacement de vos buckets en fonction de vos exigences en termes de performances, de disponibilité et de redondance des données.

• Les régions sont recommandées lorsque la région est proche de vos utilisateurs finaux. Vous pouvez sélectionner une région spécifique et obtenir une redondance garantie au sein de la région. Les régions offrent un stockage rapide, redondant et abordable pour les ensembles de données auxquels les utilisateurs d'une zone géographique spécifique accèdent fréquemment.
• Les multirégions offrent une haute disponibilité aux utilisateurs distribués. Toutefois, le coût du stockage est plus élevé que pour les régions. Les buckets multirégionaux sont recommandés pour les cas d'utilisation de diffusion de contenu et pour les charges de travail d'analyse de bas niveau.
• Les birégions offrent une haute disponibilité et une redondance des données. Google recommande d'utiliser des buckets birégionaux pour les charges de travail d'analyse hautes performances et pour les cas d'utilisation nécessitant de véritables buckets actifs-actifs avec des ressources de calcul et de stockage colocalisées dans plusieurs emplacements. Les buckets birégionaux vous permettent de choisir l'emplacement de stockage de vos données, ce qui peut vous aider à répondre aux exigences de conformité. Par exemple, vous pouvez utiliser un bucket birégional pour répondre aux exigences spécifiques à un secteur d'activité concernant la distance physique entre les copies de vos données dans le cloud.

Règles de cycle de vie

Optimisez le coût de stockage de vos objets dans Cloud Storage en définissant des règles de cycle de vie. Ces règles vous aident à réduire les coûts en rétrogradant automatiquement la classe de stockage de certains objets ou en supprimant des objets en fonction de conditions que vous définissez.

Configurez des règles de cycle de vie en fonction de la fréquence d'accès aux objets et de la durée de conservation de ces objets. Voici des exemples de règles de cycle de vie :

• Règle de rétrogradation : vous prévoyez qu'un ensemble de données sera consulté fréquemment, mais uniquement pendant une période d'environ trois mois. Pour optimiser les coûts de stockage de cet ensemble de données, utilisez le stockage standard et configurez une règle de cycle de vie afin de rétrograder les objets de plus de 90 jours vers le stockage Coldline.

• Règle de suppression : un ensemble de données doit être conservé pendant 365 jours pour répondre à certaines obligations légales et peut être supprimé après cette période. Configurez une règles de suppression des objets après 365 jours.

  Pour vous assurer que les données qui doivent être conservées pendant une période spécifique (à des fins légales ou réglementaires) ne sont pas supprimées avant cette date ou cette heure, configurez des verrous des règles de conservation.

Remarque : Les classes de stockage à long terme (Nearline, Coldline et Archive) entraînent des frais plus élevés de récupération des données et une pénalité de suppression anticipée par rapport au stockage standard. Si les données stockées dans une classe de stockage à long terme doivent être consultées fréquemment, vous pouvez les copier dans un bucket Storage Standard pour éviter des frais d'accès plus élevés.

Responsabilité

Afin de responsabiliser les utilisateurs pour ce qui est des frais opérationnels, des frais de réseau et du coût de récupération des données, utilisez la configuration Paiements par le demandeur si nécessaire. Avec cette configuration, les coûts sont facturés au service ou à l'équipe qui utilise les données plutôt qu'au propriétaire.

Définissez et attribuez des étiquettes de suivi des coûts de manière cohérente pour l'ensemble de vos buckets et objets. Automatisez l'attribution des libellés lorsque cela est possible.

Redondance

Utilisez les techniques suivantes pour maintenir la redondance du stockage requise sans dupliquer les données :

• Pour maintenir la résilience des données avec une source de vérité unique, utilisez un bucket birégional ou multirégional plutôt que des copies redondantes des données dans différents buckets. Les buckets birégionaux et multirégionaux offrent une redondance entre les régions. Vos données sont répliquées de manière asynchrone sur au moins deux emplacements et sont protégées contre les pannes régionales.
• Si vous activez la gestion des versions des objets, envisagez de définir des règles de cycle de vie pour supprimer la version la plus ancienne d'un objet lorsque les plus récentes deviennent obsolètes. Chaque version archivée d'un objet est facturée au même tarif que sa version active.
• Désactivez les règles de gestion des versions d'objets lorsqu'elles ne sont plus nécessaires.
• Examinez régulièrement vos règles de conservation des sauvegardes et des instantanés, et ajustez-les afin d'éviter les sauvegardes et la conservation de données inutiles.

Persistent Disk

Chaque instance de VM que vous déployez dans Compute Engine possède un disque de démarrage et (éventuellement) un ou plusieurs disques de données. Chaque disque entraîne des frais en fonction de la taille provisionnée, de la région et du type de disque. Le fait de créer un instantané d'un de vos disques entraîne des frais qui sont fonction de la taille de l'instantané.

Utilisez les recommandations de conception et d'exploitation suivantes pour optimiser le coût de vos disques persistants :

• Ne surallouez pas l'espace disque. Vous ne pouvez pas réduire la capacité du disque après le provisionnement. Commencez avec un petit disque, puis augmentez sa taille si nécessaire. Les disques persistants sont facturés en fonction de la capacité provisionnée, et non en fonction de la quantité de données stockée sur les disques.

• Choisissez un type de disque correspondant aux caractéristiques de performances de votre charge de travail. Les disques SSD offrent un débit et des IOPS élevés, mais coûtent plus cher que les disques persistants standards.

• Utilisez des disques persistants régionaux uniquement lorsqu'il est essentiel de protéger les données contre les pannes zonales. Les disques persistants régionaux sont répliqués sur une autre zone de la région. Le coût est donc deux fois supérieur à celui des disques zonaux équivalents.

• Suivez l'utilisation de vos disques persistants en utilisant Cloud Monitoring et configurez des alertes pour les disques dont l'utilisation est faible.

• Supprimez les disques dont vous n'avez plus besoin.

• Pour les disques contenant des données dont vous pourriez avoir besoin à l'avenir, envisagez de les archiver dans Cloud Storage à faible coût, puis de les supprimer.

• Recherchez les recommandations dans le centre de recommandations.

Pensez également à utiliser des hyperdisques pour le stockage hautes performances et des disques éphémères (disques SSD locaux) pour le stockage temporaire.

Les instantanés de disque sont incrémentiels par défaut et compressés automatiquement. Tenez compte des recommandations suivantes pour optimiser le coût de vos instantanés de disque :

• Si possible, organisez vos données en disques persistants distincts. Vous pouvez ensuite choisir de sauvegarder les disques de manière sélective afin de réduire le coût des instantanés de disque.
• Lorsque vous créez un instantané, sélectionnez un emplacement en fonction de vos exigences de disponibilité et des coûts réseau associés.
• Si vous prévoyez d'utiliser un instantané de disque de démarrage pour créer plusieurs VM, créez une image à partir de l'instantané, puis utilisez cette image pour créer vos VM. Cette approche vous permet d'éviter des frais de réseau pour le transfert de données entre l'emplacement de l'instantané et celui où vous le restaurez.
• Envisagez de définir une règle de conservation afin de réduire les coûts de stockage à long terme des instantanés de disque.
• Supprimez les instantanés de disque dont vous n'avez plus besoin. Chaque instantané d'une chaîne peut dépendre des données stockées dans un instantané précédent. Ainsi, la suppression d'un instantané ne supprime pas nécessairement toutes les données qu'il contient. Pour supprimer définitivement les données des instantanés, vous devez supprimer tous les instantanés de la chaîne.

Filestore

Le coût d'une instance Filestore dépend de son niveau de service, de sa capacité provisionnée et de la région dans laquelle l'instance est provisionnée. Vous trouverez ci-dessous des recommandations de conception et d'exploitation pour optimiser le coût de vos instances Filestore :

• Sélectionnez un niveau de service et un type de stockage (HDD ou SSD) adaptés à vos besoins de stockage.
• Ne surprovisionnez pas la capacité. Commencez par une petite taille et augmentez-la ultérieurement si nécessaire. La facturation Filestore est basée sur la capacité provisionnée, et non sur la quantité de données stockées.
• Dans la mesure du possible, organisez vos données dans des instances Filestore distinctes. Vous pouvez ensuite choisir de sauvegarder les instances de manière sélective afin de réduire le coût des sauvegardes Filestore.
• Lorsque vous choisissez la région et la zone, pensez à créer des instances dans la même zone que les clients. Le trafic de transfert de données provenant de la zone de l'instance Filestore vous est facturé.
• Lorsque vous choisissez la région dans laquelle les sauvegardes Filestore doivent être stockées, tenez compte des frais de transfert de données liés au stockage des sauvegardes dans une région différente de celle de l'instance source.
• Suivez l'utilisation de vos instances Filestore à l'aide de Cloud Monitoring et configurez des alertes pour les instances avec une faible utilisation.
• Réduisez la capacité allouée aux instances Filestore qui sont peu utilisées. Vous pouvez réduire la capacité des instances, à l'exception du niveau de base.

Étapes suivantes

• Consulter les bonnes pratiques sur l'optimisation des coûts liés à Cloud Storage (article de blog)
• Optimiser les coûts des services de calcul, des bases de données, de la mise en réseau et des opérations :
  • Optimiser les coûts : calcul, conteneurs et sans serveur
  • Optimiser les coûts : bases de données et analyses intelligentes
  • Optimiser les coûts : mise en réseau
  • Optimiser les coûts : opérations cloud
• Explorez les autres catégories du framework d'architecture Google Cloud

Optimiser les coûts : bases de données et analyses intelligentes

Ce document du framework d'architecture Google Cloud fournit des recommandations pour vous aider à optimiser le coût de vos bases de données et de vos charges de travail d'analyse dans Google Cloud.

Ces conseils sont destinés aux architectes, aux développeurs et aux administrateurs responsables du provisionnement et de la gestion des bases de données et des charges de travail d'analyse dans le cloud.

Cette section présente les recommandations en matière d'optimisation des coûts pour les produits suivants :

• Cloud SQL
• Spanner
• Bigtable
• BigQuery
• Dataflow
• Dataproc

Cloud SQL

Cloud SQL est une base de données relationnelle entièrement gérée pour MySQL, PostgreSQL et SQL Server.

Surveiller l'utilisation

Examinez les métriques dans le tableau de bord de surveillance et vérifiez que votre déploiement répond aux exigences de votre charge de travail.

Optimisez les ressources

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser vos ressources Cloud SQL :

• Concevez une stratégie de haute disponibilité et de reprise après sinistre conforme à vos objectifs en termes de temps de récupération (RTO) et de point de récupération (RPO). En fonction de votre charge de travail, nous vous recommandons les solutions suivantes :
  • Pour les charges de travail nécessitant un RTO et un RPO courts, utilisez la configuration à haute disponibilité et les instances dupliquées pour le basculement régional.
  • Pour les charges de travail pouvant tolérer un RTO et un RPO plus longs, utilisez des sauvegardes automatiques et à la demande dont la restauration peut prendre un peu plus de temps après une défaillance.
• Provisionnez la base de données avec la capacité de stockage minimale requise.
• Pour faire évoluer automatiquement la capacité de stockage à mesure que la quantité de données augmente, activez la fonctionnalité d'augmentation automatique de l'espace de stockage.
• Choisissez un type de stockage adapté à votre cas d'utilisation (disques durs SSD ou HDD). Le SSD constitue le choix le plus efficace et le plus rentable dans la plupart des cas. Le HDD peut être approprié pour les grands ensembles de données (supérieurs à 10 To) qui ne sont pas sensibles à la latence ou rarement utilisés.

Optimiser les tarifs

Envisagez de souscrire des remises sur engagement d'utilisation pour les charges de travail ayant des besoins en ressources prévisibles. Vous pouvez économiser 25 % sur le tarif à la demande pour un engagement d'un an et 52 % pour un engagement de trois ans.

Spanner

Spanner est une base de données cloud native offrant une cohérence forte et une évolutivité illimitée avec jusqu'à 99,999 % de disponibilité.

Surveiller l'utilisation

Vous trouverez ci-dessous des recommandations pour vous aider à suivre l'utilisation de vos ressources Spanner :

• Surveillez votre déploiement et configurez le nombre de nœuds en fonction des recommandations de processeurs.
• Définissez des alertes sur vos déploiements pour optimiser les ressources de stockage. Pour déterminer la configuration appropriée, reportez-vous aux limites recommandées par nœud.

Optimisez les ressources

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser vos ressources Spanner :

• Exécutez des charges de travail plus petites sur Spanner à moindre coût en provisionnant des ressources avec des unités de traitement (PU) ou des nœuds (un nœud Spanner équivaut à 1 000 unités de traitement).
• Améliorez les performances d'exécution des requêtes à l'aide de l'optimiseur de requêtes.
• Rédigez des instructions SQL en suivant les bonnes pratiques pour créer des plans d'exécution efficaces.
• Gérez l'utilisation et les performances des déploiements Spanner à l'aide de l'outil Autoscaler. Cet outil surveille les instances, ajoute ou supprime automatiquement des nœuds et garantit que les instances respectent les limites recommandées de processeur et de stockage.
• Protégez-vous contre les suppressions ou les écritures accidentelles grâce à la récupération à un moment précis (PITR). Les bases de données avec des longues durées de conservation de version (en particulier celles qui écrasent des données fréquemment) utilisent davantage de ressources système et nécessitent plus de nœuds.
• Examinez votre stratégie de sauvegarde et choisissez l'une des options suivantes :
  • Sauvegarde et restauration
  • Exporter et importer

Optimiser les tarifs

Pour déterminer l'emplacement de vos nœuds Spanner, tenez compte des différences de coût entre les régions Google Cloud. Par exemple, un nœud déployé dans la région us-central1 coûte considérablement moins par heure qu'un nœud de la région southamerica-east1.

Bigtable

Bigtable est un magasin NoSQL cloud natif orienté colonnes pour des charges de travail à grande échelle et à faible latence.

Surveiller l'utilisation

Vous trouverez ci-dessous des recommandations pour vous aider à suivre l'utilisation de vos ressources Bigtable :

• Analysez les métriques d'utilisation pour identifier les possibilités d'optimisation des ressources.
• Identifiez les points d'accès et les clés de votre cluster Bigtable à l'aide de l'outil de diagnostic Key Visualizer.

Optimisez les ressources

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser vos ressources Bigtable :

• Pour garantir une utilisation du processeur et du disque qui permette d'équilibrer la latence et la capacité de stockage, vous devez évaluer et ajuster le nombre de nœuds et la taille de votre cluster Bigtable.
• Maintenez les performances au moindre coût possible en appliquant un scaling automatisé à votre cluster Bigtable pour ajuster automatiquement le nombre de nœuds.

• Évaluez le type de stockage le plus économique (HDD ou SSD) pour votre cas d'utilisation, en fonction des éléments suivants :

  • Le stockage HDD est moins cher que le stockage SSD, mais offre des performances inférieures.
  • Le stockage SSD coûte plus cher que le stockage HDD, mais offre des performances plus rapides et prévisibles.

  Les économies réalisées grâce au stockage HDD sont minimes par rapport au coût des nœuds du cluster Bigtable, à moins que vous ne stockiez de grandes quantités de données. Le stockage HDD est parfois approprié pour les grands ensembles de données (supérieurs à 10 To) qui ne sont pas sensibles à la latence ou qui sont rarement utilisés.

• Supprimez les données expirées et obsolètes à l'aide de la récupération de mémoire.

• Pour éviter la création de hotspots, appliquez les bonnes pratiques de conception des clés de ligne.

• Concevez un plan de sauvegarde économique et conforme à votre RPO.

• Pour réduire l'utilisation du cluster et réduire le nombre de nœuds, envisagez d'ajouter un cache de capacité pour les requêtes pouvant être mises en cache à l'aide de Memorystore.

Autres ressources

• Blog : Présentation de l'optimisation des coûts sur Bigtable.
• Blog : Bonnes pratiques concernant l'optimisation des coûts et des performances de Bigtable

BigQuery

BigQuery est un entrepôt de données multicloud sans serveur, hautement évolutif et économique, conçu pour optimiser l'agilité des entreprises.

Surveiller l'utilisation

Vous trouverez ci-dessous des recommandations pour vous aider à suivre l'utilisation de vos ressources BigQuery :

• Visualisez vos coûts BigQuery ventilés par projet et par utilisateur. Identifiez les requêtes les plus coûteuses et optimisez-les.
• Analysez l'utilisation des emplacements pour l'ensemble des projets, tâches et réservations à l'aide des tables de métadonnées INFORMATION_SCHEMA.

Optimisez les ressources

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser vos ressources BigQuery :

• Configurez des délais d'expiration pour les données au niveau de l'ensemble de données, de la table ou de la partition, en fonction de votre stratégie de conformité.
• Limitez les coûts des requêtes en limitant le nombre d'octets facturés par requête. Pour éviter les erreurs humaines accidentelles, activez le contrôle des coûts au niveau de l'utilisateur et du projet.
• Interrogez uniquement les données dont vous avez besoin. Évitez les analyses complètes des requêtes. Pour explorer et comprendre la sémantique des données, utilisez les options gratuites d'aperçu de données.
• Pour réduire les coûts de traitement et améliorer les performances, partitionnez vos tables et découpez-les en clusters lorsque cela est possible.
• Filtrez votre requête aussi tôt et aussi souvent que possible.
• Lorsque vous traitez des données à partir de plusieurs sources (telles que Bigtable, Cloud Storage, Google Drive et Cloud SQL), évitez la duplication de données en utilisant un modèle de données à accès fédéré et en interrogeant les données directement à partir des sources.
• Tirez parti de la sauvegarde BigQuery plutôt que de dupliquer les données. Consultez la section Scénarios de reprise après sinistre pour les données.

Optimiser les tarifs

Vous trouverez ci-dessous des recommandations pour vous aider à réduire les tarifs de facturation de vos ressources BigQuery :

• Évaluez la manière dont vous modifiez les données et profitez des tarifs de stockage à plus long terme.
• Passez en revue les différences entre les tarifs forfaitaires et à la demande puis choisissez une option adaptée à vos besoins.
• Déterminez si vous pouvez utiliser le chargement par lot plutôt que des insertions en flux continu pour vos workflows de données. Utilisez des insertions en flux continu si les données chargées dans BigQuery sont immédiatement utilisées.
• Pour améliorer les performances et réduire le coût de récupération des données, utilisez les résultats de requêtes mis en cache.

Autres ressources

• Contrôler les coûts BigQuery
• Bonnes pratiques pour l'optimisation des coûts liés à BigQuery.
• Maîtriser les principes de l'optimisation des coûts (PDF)

Dataflow

Dataflow est un service sans serveur rapide et économique pour le traitement unifié des données, par flux et par lot.

Surveiller l'utilisation

Vous trouverez ci-dessous des recommandations pour vous aider à suivre l'utilisation de vos ressources Dataflow :

• Prévoyez le coût des tâches Dataflow en exécutant des tests à faible charge, en obtenant des performances optimales pour votre tâche et en extrapolant le facteur de débit.
• Gagnez en visibilité sur le débit et l'utilisation du processeur à l'aide des tableaux de bord d'observabilité.
• Observez les métriques de performance, d'exécution et d'intégrité du pipeline à l'aide de l'interface de surveillance Dataflow.

Optimisez les ressources

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser vos ressources Dataflow :

• Envisagez d'utiliser Dataflow Prime pour traiter efficacement le big data.
• Réduisez les coûts de traitement par lot en utilisant la planification flexible des ressources (FlexRS) pour les pipelines par lots avec autoscaling. FlexRS utilise une planification avancée, le brassage Dataflow et une combinaison de VM préemptives et standards pour réduire le coût des pipelines par lot.
• Améliorez les performances en utilisant le service de brassage en mémoire plutôt que d'utiliser des disques persistants et des nœuds de calcul.
• Pour assurer un autoscaling plus réactif et réduire la consommation de ressources, utilisez Streaming Engine, qui transfère l'exécution du pipeline depuis les VM de nœud de calcul vers le backend du service Dataflow.
• Si le pipeline n'a pas besoin d'accéder à Internet ou à d'autres réseaux Google Cloud, désactivez les adresses IP publiques. La désactivation de l'accès à Internet vous permet de réduire les coûts réseau et d'améliorer la sécurité du pipeline.
• Suivez les bonnes pratiques pour obtenir un pipeline efficace avec Dataflow.

Dataproc

Dataproc est un service géré Apache Spark et Apache Hadoop pour le traitement, l'interrogation, le streaming et le machine learning par lot.

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser le coût de vos ressources Dataproc :

• Choisissez des types de machines adaptés à votre charge de travail.
• Appliquez un scaling automatique en fonction de la demande grâce à des clusters d'autoscaling afin de ne payer que les ressources dont vous avez besoin.
• Si un cluster peut être supprimé une fois la tâche terminée, envisagez de provisionner un cluster éphémère à l'aide d'un modèle de workflow de cluster géré.
• Pour éviter les frais liés à un cluster inactif, utilisez la suppression planifiée qui permet de supprimer un cluster après une période d'inactivité spécifiée, à une heure spécifiée ou après une période donnée.
• Suivez les bonnes pratiques pour créer des clusters de longue durée sur Dataproc.
• Obtenez des remises sur engagement d'utilisation pour les charges de travail permanentes.

Étape suivante

• Optimisez les coûts des services de calcul, du stockage, de la mise en réseau et des opérations :
  • Optimiser les coûts : calcul, conteneurs et sans serveur
  • Optimiser les coûts : stockage
  • Optimiser les coûts : mise en réseau
  • Optimiser les coûts : opérations cloud
• Explorez les autres catégories du framework d'architecture Google Cloud

Optimiser les coûts : mise en réseau

Ce document du framework d'architecture Google Cloud fournit des recommandations pour vous aider à optimiser le coût de vos ressources réseau dans Google Cloud.

Les conseils de cette section sont destinés aux architectes et aux administrateurs responsables du provisionnement et de la gestion du réseau pour les charges de travail dans le cloud.

Considérations de conception

Une différence fondamentale entre les réseaux sur site et les réseaux cloud réside dans le modèle cloud de coût dynamique, basé sur l'utilisation, par rapport au coût fixe des réseaux dans les centres de données traditionnels.

Lors de la planification des réseaux cloud, il est essentiel de comprendre le modèle de tarification, qui est basé sur le sens du trafic, comme suit :

• Le trafic entrant dans Google Cloud n'est soumis à aucuns frais. Les ressources qui traitent le trafic entrant, telles que Cloud Load Balancing, engendrent des coûts.
• Pour le trafic de transfert de données, qui inclut à la fois le trafic entre les machines virtuelles (VM) de Google Cloud et le trafic de Google Cloud vers Internet et les hôtes sur site, les tarifs sont basés sur les facteurs suivants :
  • Trafic transitant par une adresse IP interne ou externe
  • Dépassement des limites de zone ou de région
  • Trafic quittant Google Cloud
  • Distance parcourue par le trafic avant de quitter Google Cloud

Lorsque deux VM ou ressources cloud de Google Cloud communiquent, le trafic dans chaque direction est désigné comme transfert de données sortantes au niveau de la source et comme transfert de données entrantes au niveau de la destination, et est facturé en conséquence.

Tenez compte des facteurs suivants pour concevoir des réseaux cloud économiques :

• Géolocalisation
• Structure du réseau
• Options de connectivité
• Niveaux de service réseau
• Logging

Ces facteurs sont décrits plus en détail dans les sections suivantes.

Géolocalisation

Les coûts de mise en réseau peuvent varier en fonction de la région Google Cloud dans laquelle vos ressources sont provisionnées. Pour analyser la bande passante réseau entre les régions, vous pouvez utiliser les journaux de flux VPC, ainsi que Network Intelligence Center. Pour le trafic entre les régions Google Cloud, le coût peut varier en fonction de la localisation des régions, même si le trafic ne passe pas par Internet.

Outre la région Google Cloud, tenez compte des zones dans lesquelles vos ressources sont déployées. En fonction des exigences de disponibilité, vous pouvez concevoir vos applications de manière à communiquer gratuitement au sein d'une zone via des adresses IP internes. Lorsque vous envisagez une architecture à zone unique, vous devez contrebalancer les économies potentielles sur les coûts de mise en réseau avec l'impact sur la disponibilité.

Structure du réseau

Analysez la structure de votre réseau, la manière dont le trafic circule entre vos applications et utilisateurs, ainsi que la bande passante utilisée par chaque application ou utilisateur. L'outil Network Topology offre une visibilité complète sur votre déploiement global Google Cloud et son interaction avec l'Internet public, y compris une vue de la topologie à l'échelle de l'organisation, ainsi que les métriques de performance du réseau associées. Vous pouvez identifier les déploiements inefficaces et prendre les mesures nécessaires pour optimiser les coûts de transfert de données régional et intercontinental.

Options de connectivité

Lorsque vous devez transférer fréquemment un grand volume de données (plusieurs To ou Po) depuis des environnements sur site vers Google Cloud, envisagez d'utiliser une interconnexion dédiée ou une interconnexion partenaire. Une connexion dédiée peut se révéler moins onéreuse, par rapport aux coûts associés au transit par l'Internet public ou à l'utilisation d'un VPN.

Utilisez l'accès privé à Google lorsque cela est possible pour réduire les coûts et améliorer votre stratégie de sécurité.

Niveaux de service réseau

L'infrastructure réseau premium de Google (niveau Premium) est utilisée par défaut pour tous les services. Pour les ressources qui n'ont pas besoin des hautes performances et de la faible latence offertes par le niveau Premium, vous pouvez choisir le niveau Standard, plus économique.

Lorsque vous choisissez un niveau de service, tenez compte des différences entre les niveaux et des limites du niveau Standard. Ajustez le réseau aux besoins de votre application et réduisez ainsi potentiellement les coûts de mise en réseau des services pouvant tolérer une plus grande latence et ne nécessitant pas de contrat de niveau de service.

Logging

Les journaux de flux VPC, la journalisation des règles de pare-feu et la journalisation Cloud NAT vous permettent d'analyser les journaux réseau et d'identifier les opportunités de réduction des coûts.

Pour les journaux de flux VPC et Cloud Load Balancing, vous pouvez également activer l'échantillonnage, qui permet de réduire le volume de journaux écrits dans la base de données. Vous pouvez faire varier le taux d'échantillonnage de 1,0 (toutes les entrées de journal sont conservées) à 0,0 (aucun journal n'est conservé). Pour le dépannage ou les cas d'utilisation personnalisés, vous pouvez choisir de toujours collecter la télémétrie pour un réseau ou un sous-réseau VPC particulier, ou de surveiller une instance de VM ou une interface virtuelle spécifique.

Recommandations en matière de conception

Pour optimiser le trafic réseau, nous vous recommandons de suivre les conseils ci-dessous :

• Concevez vos solutions pour rapprocher vos applications de votre base d'utilisateurs. Utilisez Cloud CDN pour réduire le volume de trafic et la latence, et profitez des tarifs réduits de CDN pour diffuser du contenu auquel vos utilisateurs vont vraisemblablement accéder fréquemment.
• Évitez de synchroniser des données à l'échelle mondiale dans des régions éloignées de l'utilisateur final, ou pouvant entraîner des coûts de mise en réseau élevés. Si une application n'est utilisée que dans une région, évitez le traitement de données interrégional.
• Assurez-vous que la communication entre les VM d'une zone est acheminée via leurs adresses IP internes, plutôt que par un routage en externe.
• Réduisez les coûts de transfert de données et la latence du client en compressant la sortie des données.
• Analysez les modèles de dépenses et identifiez des opportunités de maîtrise des coûts, en observant les flux de trafic sortant et entrant pour les projets critiques à l'aide des journaux de flux VPC.
• Lors de la conception de vos réseaux dans le cloud, tenez compte du compromis entre la haute disponibilité d'un réseau distribué et les économies liées à la centralisation du trafic dans une seule zone ou région.

Pour optimiser le prix des services de mise en réseau, nous vous recommandons de procéder comme suit :

• Si l'emplacement du serveur ne constitue pas une contrainte, évaluez les coûts dans différentes régions et sélectionnez la région présentant la meilleure efficience économique. Pour le trafic sortant général, tel que le contenu diffusé par un groupe de serveurs Web, les prix peuvent varier en fonction de la région où les serveurs sont provisionnés.
• Pour réduire le coût de la migration fréquente d'importants volumes de données dans le cloud, utilisez une connexion directe entre le réseau sur site et le réseau Google Cloud. Vous pouvez envisager d'utiliser une interconnexion dédiée ou partenaire.
• Choisissez un niveau de service approprié pour chaque environnement, à savoir le niveau Standard pour les environnements de développement et de test, et le niveau Premium pour la production.

Étape suivante

• Consultez les informations sur les tarifs du réseau.
• Consulter les bonnes pratiques pour optimiser les coûts de mise en réseau
• Optimiser les coûts des services de calcul, du stockage, des bases de données et des opérations :
  • Optimiser les coûts : calcul, conteneurs et sans serveur
  • Optimiser les coûts : stockage
  • Optimiser les coûts : bases de données et analyses intelligentes
  • Optimiser les coûts : opérations cloud
• Explorez les autres catégories du framework d'architecture Google Cloud

Optimiser les coûts : opérations cloud

Le présent document du framework d'architecture Google Cloud fournit des recommandations pour vous aider à optimiser les coûts de surveillance et de gestion de vos ressources dans Google Cloud.

Les conseils de cette section sont destinés aux utilisateurs cloud chargés de surveiller et de contrôler l'utilisation et les coûts des ressources de leur organisation dans le cloud.

Google Cloud Observability est un ensemble de services gérés que vous pouvez utiliser pour surveiller, dépanner et améliorer les performances de vos charges de travail dans Google Cloud. Ces services incluent Cloud Monitoring, Cloud Logging, Error Reporting, Cloud Trace et Cloud Profiler. L'un des avantages des services gérés dans Google Cloud est la facturation basée sur l'utilisation. Vous ne payez que pour les capacités et le volume de données utilisés, avec des allocation mensuelle gratuite de consommation de données et un accès illimité aux métriques et journaux d'audit de Google Cloud.

Cloud Logging

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser le coût de vos opérations Logging :

• Filtrez les rapports de facturation pour afficher les coûts de Logging.
• Réduisez le volume des journaux ingérés et stockés en excluant ou en filtrant les entrées de journal inutiles.
• Vérifiez si les filtres d'exclusion sont appropriés en surveillant les métriques billing/bytes_ingested et billing/monthly_bytes_ingested dans la console Google Cloud.
• Déchargez et exportez les journaux vers un stockage à moindre coût.
• Lors de la diffusion de journaux à partir d'applications tierces, réduisez les volumes de journaux en n'utilisant l'agent de journalisation que sur les instances de production ou en le configurant pour envoyer moins de données.

Cloud Monitoring

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser le coût de vos opérations Monitoring :

• Optimisez les métriques et l'utilisation des libellés en limitant le nombre de libellés. Évitez les libellés à cardinalité élevée. Par exemple, si vous utilisez une adresse IP comme libellé, chaque adresse IP aura une série de libellés ne comportant qu'un seul élément, ce qui entraînera la génération de nombreuses étiquettes si vous utilisez plusieurs VM.
• Réduisez le volume de métriques détaillées pour les applications qui n'en ont pas besoin ou supprimez l'agent de surveillance, en particulier pour les environnements non essentiels.
• Réduisez le volume d'ingestion en réduisant le nombre de métriques personnalisées envoyées par votre application.

Cloud Trace

Vous trouverez ci-dessous des recommandations pour vous aider à optimiser le coût de vos opérations Trace :

• Si vous utilisez Trace comme destination d'exportation pour vos traces OpenCensus, réduisez le volume de traces ingérées à l'aide de la fonctionnalité d'échantillonnage d'OpenCensus.
• Limitez l'utilisation de Trace et contrôlez les coûts à l'aide de quotas. Vous pouvez appliquer des quotas de délais à l'aide de la page des quotas spécifiques à l'API dans la console Google Cloud.

Étapes suivantes

• Optimiser les coûts pour Google Cloud Observability
• Vidéo : Gérer les coûts pour Google Cloud Observability
• Optimisez les coûts des services de calcul, de stockage, de bases de données et de mise en réseau :
  • Optimiser les coûts : calcul, conteneurs et sans serveur
  • Optimiser les coûts : stockage
  • Optimiser les coûts : Bases de données et analyses intelligentes
  • Optimiser les coûts : mise en réseau
• Explorez les autres catégories du framework d'architecture Google Cloud

Framework d'architecture Google Cloud : optimisation des performances

Cette catégorie du framework d'architecture de Google Cloud décrit le processus d'optimisation des performances et les bonnes pratiques à suivre pour optimiser les performances des charges de travail dans Google Cloud.

Les informations de ce document sont destinées aux architectes, aux développeurs et aux administrateurs qui planifient, conçoivent, déploient et gèrent des charges de travail dans Google Cloud.

L'optimisation des performances des charges de travail dans le cloud peut aider votre organisation à fonctionner efficacement, à améliorer la satisfaction des clients, à augmenter les revenus et à réduire les coûts. Par exemple, lorsque le temps de traitement backend d'une application diminue, les utilisateurs bénéficient de temps de réponse plus rapides, ce qui peut augmenter la rétention des utilisateurs et améliorer les revenus.

Il peut y avoir des compromis entre performance et coût. Parfois, l'optimisation des performances peut vous aider à réduire les coûts. Par exemple, l'autoscaling offre des performances prévisibles lorsque la charge augmente en garantissant que les ressources ne sont pas surchargées. L'autoscaling vous permet également de réduire les coûts pendant les périodes de faible charge en supprimant les ressources inutilisées.

Dans cette catégorie du framework d'architecture, vous allez apprendre à effectuer les opérations suivantes :

• Mettre en œuvre le processus d'optimisation des performances.
• Surveiller et analyser les performances.
• Optimiser les performances de calcul.
• Optimiser les performances de stockage.
• Optimiser les performances du réseau.
• Optimiser les performances de la base de données.
• Optimiser les performances des analyses.

Processus d'optimisation des performances

Ce document du framework d'architecture de Google Cloud présente le processus d'optimisation des performances.

L'optimisation des performances est un processus continu, et non une activité ponctuelle. Le diagramme suivant illustre les étapes du processus d'optimisation des performances :

Vous trouverez ci-dessous un aperçu des étapes du processus d'optimisation des performances :

Définir les exigences de performances

Avant de commencer à concevoir et à développer les applications que vous avez l'intention de déployer ou de migrer vers le cloud, déterminez les exigences de performances. Définissez les exigences de manière aussi précise que possible pour chaque couche de la pile d'applications : équilibrage de charge de l'interface, serveurs Web ou d'applications, base de données et stockage. Par exemple, pour la couche de stockage de la pile, choisissez le débit et les opérations d'E/S par seconde (IOPS) dont vos applications ont besoin.

Concevoir et déployer vos applications

Concevez vos applications en utilisant des modèles de conception élastiques et évolutifs qui peuvent vous aider à répondre aux exigences de performances. Tenez compte des consignes suivantes concernant la conception d'applications élastiques et évolutives :

• Structurez les charges de travail pour optimiser l'emplacement du contenu.
• Isolez le trafic de lecture et d'écriture.
• Isolez le trafic statique et dynamique.
• Mettez en œuvre le cache de contenu. Utilisez des caches de données pour les couches internes.
• Utilisez des services gérés et des architectures sans serveur.

Google Cloud fournit des outils Open Source que vous pouvez utiliser pour effectuer des analyses comparatives des performances des services Google Cloud avec d'autres plates-formes cloud.

Surveiller et analyser les performances

Une fois vos applications déployées, surveillez en continu les performances à l'aide des journaux et alertes, analysez les données et identifiez les problèmes de performances. À mesure que vos applications se développent et évoluent, réévaluez vos exigences en termes de performances. Vous devrez peut-être modifier certaines parties des applications pour maintenir ou améliorer les performances.

Optimiser les performances

En fonction des performances de vos applications et des changements d'exigences, configurez les ressources cloud pour répondre à vos exigences de performances actuelles. Par exemple, redimensionnez les ressources ou configurez l'autoscaling. Lorsque vous configurez les ressources, évaluez les opportunités d'utilisation des fonctionnalités et services Google Cloud récemment publiés qui peuvent vous aider à optimiser davantage les performances.

Le processus d'optimisation des performances ne se termine pas à ce stade. Continuez le cycle de surveillance des performances, réévaluation des exigences (si nécessaire) et ajustement des ressources cloud pour maintenir et améliorer les performances.

Étapes suivantes

• Surveiller et analyser les performances.
• Optimiser les performances de calcul.
• Optimiser les performances de stockage.
• Optimiser les performances du réseau.
• Optimiser les performances de la base de données.
• Optimiser les performances des analyses.

Surveiller et analyser les performances

Ce document du framework d'architecture de Google Cloud décrit les services de Google Cloud Observability que vous pouvez utiliser pour enregistrer, surveiller et analyser les performances de vos charges de travail.

Surveiller les métriques de performances

Utilisez Cloud Monitoring pour analyser les tendances des métriques de performances, analyser les effets de tests, définir des alertes pour les métriques critiques et effectuer des analyses rétrospectives.

Consigner les données et événements critiques

Cloud Logging est un service de journalisation intégré qui vous permet de stocker, d'analyser, de surveiller et définir des alertes pour les données et les événements des journaux. Cloud Logging peut collecter des journaux à partir des services de Google Cloud et d'autres fournisseurs cloud.

Analyser les performances du code

Un code peu performant peut augmenter la latence de vos applications et les coûts d'exécution. Cloud Profiler vous permet d'identifier et de résoudre les problèmes de performances en analysant en continu les performances des fonctions à haute capacité de mémoire ou de processeur utilisées par une application.

Collecter les données de latence

Dans les piles d'applications complexes et les architectures basées sur des microservices, il peut être difficile d'évaluer la latence dans la communication inter-service et d'identifier les goulots d'étranglement. Les outils Cloud Trace et OpenTelemetry vous aident à collecter les données de latence de vos déploiements à grande échelle. Ces outils vous aident également à analyser efficacement les données de latence.

Surveiller les performances du réseau

Le Performance Dashboard de Network Intelligence Center vous offre une vue complète des métriques de performances du réseau Google et des ressources de votre projet. Ces métriques peuvent vous aider à déterminer la cause des problèmes de performances liés au réseau. Par exemple, vous pouvez déterminer si un problème de performances est le résultat d'un problème dans votre projet ou sur le réseau Google.

Étapes suivantes

• Découvrez les bonnes pratiques pour surveiller vos ressources cloud.
• Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources Google Cloud :
  • Optimiser les performances de calcul.
  • Optimiser les performances de stockage.
  • Optimiser les performances du réseau.
  • Optimiser les performances de la base de données.
  • Optimiser les performances des analyses.

Optimiser les performances de calcul

Ce document présenté dans le framework d'architecture de Google Cloud fournit des recommandations pour vous aider à optimiser les performances de vos ressources Compute Engine, Google Kubernetes Engine (GKE) et sans serveur.

Compute Engine

Cette section fournit des conseils pour vous aider à optimiser les performances de vos ressources Compute Engine.

Ressources d'autoscaling

Les groupes d'instances gérés (MIG) vous permettent de faire évoluer efficacement vos applications sans état déployées sur des VM Compute Engine. L'autoscaling permet à vos applications de maintenir des performances prévisibles lorsque la charge augmente. Dans un MIG, un groupe de VM Compute Engine est lancé en fonction d'un modèle que vous définissez. Dans le modèle, vous configurez une règle d'autoscaling qui spécifie un ou plusieurs signaux que l'autoscaler utilise pour procéder au scaling du groupe. Les signaux d'autoscaling peuvent être basés sur des planifications, telles que l'heure de début ou la durée, ou sur des métriques cibles, telles que l'utilisation moyenne du processeur. Pour en savoir plus, consultez la page Effectuer l'autoscaling des groupes d'instances.

Désactiver le SMT

Chaque processeur virtuel que vous allouez à une VM Compute Engine est mis en œuvre sous la forme d'un multithread matériel unique. Par défaut, deux processeurs virtuels partagent un cœur physique de processeur. Cette architecture est appelée multithreading simultané (SMT).

Pour les charges de travail hautement parallèles ou qui effectuent des calculs à virgule flottante (tels que le transcodage, les simulations de Monte-Carlo, l'analyse de séquences génétiques et la modélisation des risques financiers), vous pouvez améliorer les performances en désactivant le SMT. Pour en savoir plus, consultez la section Définir le nombre de threads par cœur.

Utiliser les GPU

Pour les charges de travail telles que le machine learning et la visualisation, vous pouvez ajouter des processeurs graphiques (GPU) à vos VM. Compute Engine fournit des GPU NVIDIA en mode passthrough, pour permettre à vos VM de contrôler directement les GPU et la mémoire associée. Pour les charges de travail avec traitement graphique intensif telles que la visualisation 3D, vous pouvez utiliser les postes de travail virtuels NVIDIA RTX. Après avoir déployé les charges de travail, surveillez l'utilisation du GPU et examinez les options permettant d'optimiser les performances des GPU.

Utiliser des types de machines optimisés pour le calcul

Les charges de travail telles que les jeux, le transcodage multimédia et le calcul hautes performances (HPC) nécessitent des performances élevées, cohérentes et régulières sur chaque cœur de processeur. Nous vous recommandons d'utiliser des types de machines optimisés pour le calcul pour les VM qui exécutent de telles charges de travail. Les VM optimisées pour le calcul sont basées sur une architecture qui utilise des fonctionnalités telles que l'accès non uniforme à la mémoire (NUMA) pour des performances optimales et fiables.

Les charges de travail HPC à couplage fort présentent un ensemble unique d'exigences pour optimiser l'efficacité et les performances. Pour en savoir plus, consultez la documentation suivante :

• Systèmes de fichiers parallèles pour les charges de travail HPC
• Architecture : système de fichiers Lustre dans Google Cloud avec DDN EXAScaler

Choisir le stockage approprié

Google Cloud propose de nombreuses options de stockage pour les VM Compute Engine : disques persistants, disques durs SSD locaux, Filestore et Cloud Storage. Pour obtenir des recommandations de conception et des bonnes pratiques afin d'optimiser les performances de chacune de ces options de stockage, consultez la page Optimiser les performances des espaces de stockage.

Google Kubernetes Engine

Cette section fournit des conseils pour vous aider à optimiser les performances de vos ressources Google Kubernetes Engine (GKE).

Ressources d'autoscaling

Vous pouvez redimensionner automatiquement les pools de nœuds d'un cluster GKE en fonction de la charge actuelle à l'aide de la fonctionnalité d'autoscaler de cluster. L'autoscaling permet à vos applications de continuer à fournir des performances prévisibles lorsque la charge augmente. L'autoscaler de cluster redimensionne automatiquement les pools de nœuds en fonction des demandes en ressources (et non de l'utilisation réelle des ressources) des pods exécutés sur les nœuds. L'utilisation de l'autoscaling peut présenter un compromis entre performances et coût. Passez en revue les bonnes pratiques pour configurer efficacement l'autoscaling des clusters.

Remarque : Avec les clusters Autopilot, vous n'avez pas à vous soucier du provisionnement des nœuds ni de la gestion des pools de nœuds. Les pools de nœuds sont automatiquement provisionnés et mis à l'échelle en fonction des exigences de vos charges de travail.

Utiliser des VM C2D

Vous pouvez améliorer les performances des charges de travail conteneurisées qui nécessitent beaucoup de ressources de calcul en utilisant les types de machines C2D. Vous pouvez ajouter des nœuds C2D à vos clusters GKE en choisissant un type de machine C2D dans vos pools de nœuds.

Désactiver le SMT

Le multithreading simultané (SMT) peut augmenter considérablement le débit des applications pour les tâches de calcul générales et pour les charges de travail nécessitant des E/S élevées. Toutefois, pour les charges de travail dans lesquelles les deux cœurs virtuels sont liés au calcul, le SMT peut provoquer des performances inégales. Pour obtenir des performances supérieures et plus prévisibles, vous pouvez désactiver le SMT pour vos nœuds GKE en définissant le nombre de processeurs virtuels par cœur sur 1.

Utiliser les GPU

Pour les charges de travail nécessitant beaucoup de ressources de calcul, telles que la reconnaissance d'images et le transcodage vidéo, vous pouvez accélérer les performances en créant des pools de nœuds qui utilisent des GPU. Pour en savoir plus, consultez la page Exécuter des GPU.

Utiliser l'équilibrage de charge natif en conteneurs

L'équilibrage de charge natif en conteneurs permet aux équilibreurs de charge de répartir le trafic directement et de manière uniforme entre les pods. Cette approche offre de meilleures performances réseau et une visibilité accrue sur la latence réseau entre l'équilibreur de charge et les pods. Compte tenu de ces avantages, l'équilibrage de charge natif en conteneurs est la solution recommandée pour l'équilibrage de charge via Ingress.

Définir une stratégie d'emplacement compact

Les charges de travail par lot à couplage fort nécessitent une latence réseau faible entre les nœuds du pool GKE. Vous pouvez déployer ces charges de travail sur des pools de nœuds à zone unique et vous assurer que les nœuds sont physiquement proches les uns des autres en définissant une stratégie d'emplacement compact. Pour en savoir plus, consultez la section Définir un emplacement compact pour les nœuds GKE.

Services de calcul sans serveur

Cette section fournit des conseils pour vous aider à optimiser les performances de vos services de calcul sans serveur dans Google Cloud : Cloud Run et Cloud Functions. Ces services offrent des fonctionnalités d'autoscaling, où l'infrastructure sous-jacente gère automatiquement le scaling. En utilisant ces services sans serveur, vous pouvez réduire les efforts nécessaires pour faire évoluer vos microservices et vos fonctions afin de vous concentrer sur l'optimisation des performances au niveau de l'application.

Pour en savoir plus, consultez la documentation suivante :

• Optimiser les performances des services Cloud Run
• Optimiser les applications Java pour Cloud Run
• Optimiser les performances dans Cloud Functions

Étapes suivantes

Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources de stockage, de mise en réseau, de base de données et d'analyse :

• Optimiser les performances de stockage.
• Optimiser les performances du réseau.
• Optimiser les performances de la base de données.
• Optimiser les performances des analyses.

Optimiser les performances de stockage

Ce document du framework d'architecture Google Cloud fournit des recommandations pour vous aider à optimiser les performances de vos ressources réseau dans Google Cloud.

Cloud Storage

Cette section présente les bonnes pratiques pour vous aider à optimiser les performances de vos opérations Cloud Storage.

Évaluer les performances des buckets

Évaluez les performances de vos buckets Cloud Storage en utilisant la commande gsutil perfdiag. Cette commande teste les performances du bucket spécifié en envoyant une série de requêtes de lecture et d'écriture avec des fichiers de tailles différentes. Vous pouvez ajuster le test pour qu'il corresponde au modèle d'utilisation de vos applications. Utilisez le rapport de diagnostic généré par la commande pour définir les attentes en termes de performances et identifier les goulots d'étranglement potentiels.

Mettre en cache les objets fréquemment consultés

Pour améliorer la latence de lecture des objets fréquemment consultés qui sont accessibles au public, vous pouvez configurer la mise en cache de ces objets. Bien que la mise en cache puisse améliorer les performances, un contenu obsolète peut être diffusé si un cache dispose de l'ancienne version d'un objet.

Effectuer un scaling efficace des requêtes

À mesure que le taux de demandes sur un bucket augmente, Cloud Storage en augmente automatiquement la capacité d'E/S en répartissant la charge de requêtes sur plusieurs serveurs. Pour obtenir des performances optimales lors du scaling des requêtes, suivez les bonnes pratiques pour augmenter les taux de requêtes et répartir la charge de manière uniforme.

Activer le multithreading et le multitraitement

Lorsque vous utilisez gsutil pour importer de nombreux petits fichiers, vous pouvez améliorer les performances de l'opération en utilisant l'option -m. Cette option entraîne la mise en œuvre de la requête d'importation sous forme d'opération par lot parallèle (c'est-à-dire avec multithreading et multitraitement). N'utilisez cette option que si vous effectuez des opérations sur une connexion réseau rapide. Pour en savoir plus, consultez la documentation de l'option -m dans la section Options de ligne de commande globales.

Importer des fichiers volumineux en tant que fichiers composites

Pour importer des fichiers volumineux, vous pouvez utiliser une stratégie appelée importations composites parallèles. Avec cette stratégie, le fichier volumineux est divisé en fragments qui sont importés en parallèle puis recomposés dans le cloud. Les importations composites parallèles peuvent être plus rapides que les opérations d'importation standards lorsque la bande passante réseau et la vitesse des disques ne sont pas des facteurs limitants. Cependant, cette stratégie présente certaines limites et implications en termes de coûts. Pour en savoir plus, consultez la section Importations composites parallèles.

Disques persistants et disques SSD locaux

Cette section présente les bonnes pratiques pour vous aider à optimiser les performances de vos disques persistants et de vos disques SSD locaux associés aux VM Compute Engine.

Les performances des disques persistants et des disques SSD locaux dépendent du type et de la taille du disque, du type de machine de la VM et du nombre de processeurs virtuels. Suivez les instructions ci-dessous pour gérer les performances de vos disques persistants et disques SSD locaux :

• Lorsque vous provisionnez un stockage de blocs pour vos VM, choisissez des types et des tailles de disques adaptés à votre charge de travail. Pour en savoir plus, consultez la page Configurer les disques pour répondre aux exigences de performances.
• Effectuez une analyse comparative des performances du stockage de blocs. Pour en savoir plus, consultez la documentation suivante :
  • Effectuer l'analyse comparative des performances des disques persistants
  • Effectuer l'analyse comparative des performances d'un disque SSD local
• Optimisez les performances de vos disques persistants et disques SSD locaux. Pour en savoir plus, consultez la documentation suivante :
  • Optimiser les performances des disques persistants
  • Optimiser les performances des disques SSD locaux

Filestore

Cette section présente les bonnes pratiques pour vous aider à optimiser les performances de vos instances Filestore. Vous pouvez utiliser Filestore pour provisionner des serveurs de fichiers NFS (Network File System) entièrement gérés pour les VM Compute Engine et les clusters GKE.

• Lorsque vous provisionnez une instance Filestore, choisissez un niveau de service répondant aux exigences de performances et de capacité de votre charge de travail.
• Pour les VM clientes qui exécutent des charges de travail dépendantes du cache, utilisez un type de machine qui permet d'optimiser les performances réseau de l'instance Filestore. Pour en savoir plus, consultez la section Type de machine cliente recommandé.
• Pour optimiser les performances des instances Filestore pour les VM clientes exécutant Linux, Google recommande des paramètres d'installation NFS spécifiques. Pour en savoir plus, consultez la page Options d'installation des clients Linux.
• Pour minimiser la latence réseau, provisionnez vos instances Filestore dans des régions et zones proches de l'endroit où vous prévoyez d'utiliser ces instances.
• Surveillez les performances de vos instances Filestore et configurez des alertes à l'aide de Cloud Monitoring.

Étapes suivantes

Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources de calcul, de mise en réseau, de base de données et d'analyse :

• Optimiser les performances de calcul.
• Optimiser les performances du réseau.
• Optimiser les performances de la base de données.
• Optimiser les performances des analyses.

Optimiser la mise en réseau et les performances des API

Ce document du framework d'architecture de Google Cloud fournit des recommandations pour vous aider à optimiser les performances de vos ressources réseau et de vos API dans Google Cloud.

Niveaux de service réseau

Les niveaux de service réseau vous permettent d'optimiser le coût et les performances réseau de vos charges de travail. Vous pouvez choisir parmi les niveaux suivants :

• Le niveau Premium utilise le réseau backbone mondial extrêmement fiable de Google pour vous aider à réduire au minimum la perte de paquets et la latence. Le trafic entre et sort du réseau Google au niveau d'un point of presence (POP) périphérique global, qui est celui le plus proche de votre utilisateur final. Nous vous recommandons d'utiliser le niveau Premium comme niveau par défaut pour des performances optimales. Le niveau Premium est compatible avec les adresses IP externes régionales et globale, pour les VM et les équilibreurs de charge.
• Le niveau Standard n'est disponible que pour les ressources utilisant des adresses IP externes régionales. Le trafic entre et sort du réseau Google au niveau du POP périphérique le plus proche de l'emplacement Google Cloud dans lequel votre charge de travail est exécutée. Le prix du niveau Standard est inférieur à celui du niveau Premium. Le niveau Standard convient au trafic non sensible à la perte de paquets et qui ne présente pas d'exigences de faible latence.

Vous pouvez afficher la latence du réseau pour les niveaux Standard et Premium pour chaque région cloud dans le Performance Dashboard Network Intelligence Center.

Trames géantes

Les réseaux de cloud privé virtuel (VPC) ont par défaut une unité de transmission maximale (MTU) de 1 460 octets. Vous pouvez cependant configurer vos réseaux VPC pour qu'ils acceptent une MTU allant jusqu'à 8896 (trames géantes).

Avec une MTU plus élevée, le réseau a besoin de moins de paquets pour envoyer la même quantité de données, ce qui réduit la bande passante utilisée par les en-têtes TCP/IP. La bande passante disponible pour le réseau est ainsi plus élevée.

Pour en savoir plus sur la MTU intra-VPC et la MTU maximale des autres connexions, consultez la page Unité de transmission maximale dans la documentation sur les VPC.

Performances des VM

Les VM Compute Engine ont une bande passante de sortie maximale qui dépend en partie du type de machine. L'un des aspects entrant en ligne de compte dans le choix d'un type de machine approprié est le trafic que la VM doit générer.

La page Bande passante réseau contient des informations détaillées et un tableau des bandes passantes réseau selon les différents types de machines Compute Engine.

Si vos besoins en bande passante inter-VM sont très élevés, envisagez d'opter pour des VM compatibles avec la mise en réseau de niveau 1.

Cloud Load Balancing

Cette section présente les bonnes pratiques pour vous aider à optimiser les performances de vos instances Cloud Load Balancing.

Déployer les applications à proximité de vos utilisateurs

Provisionnez vos backends d'application à proximité de l'emplacement où le trafic utilisateur atteint l'équilibreur de charge. Plus vos utilisateurs ou applications clientes sont proches de vos serveurs de charge de travail, plus la latence réseau entre les utilisateurs et la charge de travail est faible. Pour minimiser la latence vers les clients des différentes parties du monde, vous devrez peut-être déployer les backends dans plusieurs régions. Pour plus d'informations, consultez la section Bonnes pratiques pour la sélection des régions Compute Engine.

Choisir un type d'équilibreur de charge approprié

Le type d'équilibreur de charge que vous choisissez pour votre application peut déterminer la latence ressentie par vos utilisateurs. Pour en savoir plus sur la mesure et l'optimisation de la latence des applications pour différents types d'équilibreurs de charge, consultez la page Optimiser la latence des applications avec l'équilibrage de charge.

Activer la mise en cache

Pour accélérer la diffusion de contenu, activez la mise en cache et Cloud CDN dans la configuration de votre équilibreur de charge HTTP externe par défaut. Assurez-vous que les serveurs de backend sont configurés pour envoyer les en-têtes de réponse nécessaires à la mise en cache des réponses statiques.

Utiliser HTTP lorsque HTTPS n'est pas nécessaire

Google chiffre automatiquement le trafic entre les équilibreurs de charge proxy et les backends au niveau des paquets. Dans la plupart des cas, le chiffrement au niveau des paquets rend redondant le chiffrement HTTPS de couche 7 entre l'équilibreur de charge et les backends. Pensez à utiliser HTTP plutôt que HTTPS ou HTTP/2 pour le trafic entre l'équilibreur de charge et vos backends. En utilisant le protocole HTTP, vous pouvez également réduire l'utilisation de processeur de vos VM de backend. Toutefois, lorsque le backend est un groupe de points de terminaison du réseau (NEG) Internet, utilisez HTTPS ou HTTP/2 pour le trafic entre l'équilibreur de charge et le backend. Cela permet de garantir que votre trafic est sécurisé sur l'Internet public. Pour des performances optimales, nous vous recommandons d'effectuer une analyse comparative des modèles de trafic de votre application.

Network Intelligence Center

Le Network Intelligence Center de Google Cloud fournit une vue complète des performances du réseau Google Cloud dans toutes les régions. Network Intelligence Center vous aide à déterminer si les problèmes de latence sont dus à des problèmes au sein de votre projet ou sur le réseau. Vous pouvez également utiliser ces informations pour choisir les régions et les zones dans lesquelles déployer vos charges de travail afin d'optimiser les performances réseau.

Utilisez les outils fournis par Network Intelligence Center pour surveiller et analyser les performances réseau de vos charges de travail dans Google Cloud :

• Performance Dashboard indique la latence entre les régions Google Cloud et entre les différents emplacements et régions sur Internet. Le module Performance Dashboard peut vous aider à déterminer où placer les charges de travail pour atteindre une latence optimale, et à identifier de probables problèmes de réseau sous-jacents en cas de problème sur une application.

• Network Topology affiche une vue de vos réseaux VPC (Virtual Private Cloud), de la connectivité hybride avec vos réseaux sur site et de la connectivité aux services gérés par Google. Network Topology fournit des métriques opérationnelles en temps réel que vous pouvez utiliser pour analyser et comprendre les performances réseau et identifier des schémas de trafic inhabituels.

• Network Analyzer est un outil automatique de surveillance et de diagnostic de configuration. Il vérifie les règles de pare-feu, les routes, les dépendances de configuration et la connectivité des services et applications définis dans les configurations de réseau VPC. Il vous aide à identifier les défaillances réseau et fournit une analyse des causes fondamentales ainsi que des recommandations. Network Analyzer fournit des insights prioritaires pour vous aider à analyser les problèmes de configuration réseau, tels que l'utilisation intensive d'adresses IP dans un sous-réseau.

API Gateway et Apigee

Cette section fournit des recommandations pour vous aider à optimiser les performances des API que vous déployez dans Google Cloud en utilisant API Gateway et Apigee.

API Gateway vous permet de créer et de gérer des API pour les backends sans serveur de Google Cloud, y compris Cloud Functions, Cloud Run et App Engine. Ces services sont des services gérés qui évoluent automatiquement. Toutefois, à mesure que les applications déployées sur ces services évoluent, vous devrez peut-être augmenter les quotas et les limites de débit pour API Gateway.

Remarque : L'exposition de vos applications ou de votre infrastructure à un trafic plus élevé peut entraîner des goulots d'étranglement qui affectent les performances au niveau de la couche suivante de la pile d'applications.

Apigee fournit les tableaux de bord analytiques suivants pour vous aider à surveiller les performances de vos API gérées :

• Tableau de bord des performances de proxy d'API : surveillez les modèles de trafic et les temps de traitement des proxys d'API.
• Tableau de bord des performances de cible : visualisez les modèles de trafic et les métriques de performances pour les cibles de backend de proxy d'API.
• Tableau de bord des performances de cache : surveillez les métriques de performances du cache Apigee, telles que le taux d'accès au cache moyen et la durée moyenne en cache.

Si vous utilisez Apige Integration, tenez compte des limites de configuration du système lorsque vous créez et gérez vos intégrations.

Étapes suivantes

Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources de calcul, de stockage, de base de données et d'analyse :

• Optimiser les performances de calcul.
• Optimiser les performances de stockage.
• Optimiser les performances de la base de données.
• Optimiser les performances des analyses.

Optimiser les performances de la base de données

Ce document du framework d'architecture de Google Cloud fournit des recommandations pour vous aider à optimiser les performances de vos bases de données dans Google Cloud.

Cloud SQL

Les recommandations suivantes vous permettent d'optimiser les performances de vos instances Cloud SQL exécutant des bases de données SQL Server, MySQL et PostgreSQL.

• Pour les bases de données SQL Server, Google vous recommande de modifier certains paramètres et de conserver les valeurs par défaut de certains paramètres.
• Lorsque vous choisissez le type de stockage pour les bases de données MySQL ou PostgreSQL, tenez compte du compromis en termes de coûts et de performances entre le stockage SSD et HDD.
• Pour identifier et analyser les problèmes de performances des bases de données PostgreSQL, utilisez le tableau de bord Cloud SQL Insights.
• Pour diagnostiquer les mauvaises performances lors de l'exécution de requêtes SQL, utilisez l'instruction EXPLAIN.

Pour en savoir plus, consultez la documentation suivante :

• Optimiser les performances : SQL Server
• Optimiser les performances : MySQL
• Optimiser les performances : PostgreSQL

Bigtable

Cette section fournit des recommandations pour vous aider à optimiser les performances de vos instances Bigtable.

Planifier la capacité en fonction des exigences de performances

Vous pouvez utiliser Bigtable dans un large éventail d'applications, avec un objectif d'optimisation différent pour chacune d'entre elles. Par exemple, pour les tâches de traitement de données par lots, le débit peut être plus important que la latence. Pour un service en ligne qui traite les requêtes des utilisateurs, vous devrez peut-être donner la priorité à une latence plus faible. Lorsque vous planifiez la capacité de vos clusters Bigtable, tenez compte des compromis entre débit et latence. Pour en savoir plus, consultez la section Planifier la capacité Bigtable.

Suivre les bonnes pratiques liées à la conception de schémas

Vos tables peuvent contenir jusqu'à plusieurs milliards de lignes et des milliers de colonnes, ce qui vous permet de stocker des pétaoctets de données. Lorsque vous concevez le schéma de vos tables Bigtable, tenez compte des bonnes pratiques liées à la conception de schémas.

Surveiller les performances et effectuer des ajustements

Surveillez l'utilisation de processeur et de disque de vos instances, analysez les performances de chaque cluster et examinez les recommandations de dimensionnement affichées dans les graphiques de surveillance.

Spanner

Cette section fournit des recommandations pour vous aider à optimiser les performances de vos instances Spanner.

Choisir une clé primaire qui empêche un hotspot

Un hotspot est un serveur unique qui est contraint de traiter de nombreuses requêtes. Lorsque vous choisissez la clé primaire de votre base de données, suivez les bonnes pratiques liées à la conception de schémas pour éviter ce problème.

Suivre les bonnes pratiques de codage SQL

Le compilateur SQL de Spanner convertit chaque instruction SQL déclarative que vous écrivez en plan d'exécution de requêtes impératif. Spanner utilise le plan d'exécution pour exécuter l'instruction SQL. Lorsque vous créez des instructions SQL, suivez les bonnes pratiques SQL pour vous assurer que Spanner utilise des plans d'exécution offrant des performances optimales.

Utiliser les options de requête pour gérer l'optimiseur de requête SQL

Spanner utilise un optimiseur de requête SQL pour transformer les instructions SQL en plans d'exécution de requêtes efficaces. Le plan d'exécution de requêtes produit par l'optimiseur peut varier légèrement lorsque l'optimiseur lui-même évolue ou lorsque les statistiques de base de données sont mises à jour. Vous pouvez minimiser le risque de régression des performances lorsque l'optimiseur de requêtes ou les statistiques de la base de données changent en utilisant les options de requête.

Visualiser et ajuster la structure des plans d'exécution de requêtes

Pour analyser les problèmes de performances des requêtes, vous pouvez visualiser et ajuster la structure des plans d'exécution de requêtes en utilisant le visualiseur du plan de requête.

Utiliser des API d'opérations pour gérer les opérations de longue durée

Pour certains appels de méthode, Spanner crée des opérations de longue durée qui peuvent prendre un temps considérable. Par exemple, lorsque vous restaurez une base de données, Spanner crée une opération de longue durée pour suivre l'avancement de la restauration. Pour vous aider à surveiller et à gérer les opérations de longue durée, Spanner fournit des API d'opérations. Pour en savoir plus, consultez la page Gérer les opérations de longue durée.

Suivre les bonnes pratiques pour le chargement groupé

Spanner propose plusieurs options pour le chargement groupé de grandes quantités de données. Les performances d'une opération de chargement groupé dépendent de facteurs tels que le partitionnement, le nombre de requêtes d'écriture et la taille de chaque requête. Pour charger efficacement de grandes quantités de données, suivez les bonnes pratiques de chargement groupé.

Surveiller et contrôler l'utilisation du processeur

L'utilisation de processeur de votre instance Spanner peut affecter la latence des requêtes. Un serveur backend surchargé peut entraîner une latence plus élevée pour les requêtes. Spanner fournit des métriques d'utilisation du processeur pour vous aider à identifer la cause de l'utilisation élevée du processeur. Pour les applications sensibles aux performances, vous devrez peut-être réduire l'utilisation du processeur en augmentant la capacité de calcul.

Analyser et résoudre les problèmes de latence

Lorsqu'un client effectue un appel de procédure à distance vers Spanner, la requête d'API est d'abord préparée par les bibliothèques clientes. La requête passe ensuite par Google Front End et par l'interface de l'API Cloud Spanner avant d'atteindre la base de données Spanner. Pour analyser et résoudre les problèmes de latence, vous devez mesurer et analyser la latence pour chaque segment du chemin traversé par la requête d'API. Pour plus d'informations, consultez le guide de latence de bout en bout Spanner.

Lancer les applications une fois que la base de données est à l'état chaud

Au fur et à mesure que votre base de données Spanner s'agrandit, elle divise l'espace clé de vos données en divisions. Chaque division est une plage de lignes contenant un sous-ensemble de votre table. Pour équilibrer la charge globale de la base de données, Spanner déplace les divisions de manière indépendante et les attribue à différents serveurs. Lorsque les divisions sont réparties sur plusieurs serveurs, la base de données est considérée comme à l'état chaud. Une base de données à l'état chaud peut maximiser le parallélisme et offrir des performances améliorées. Avant de lancer vos applications, nous vous recommandons de préchauffer votre base de données avec des charges de données de test.

Étapes suivantes

Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources de calcul, de stockage, de mise en réseau et d'analyse :

• Optimiser les performances de calcul.
• Optimiser les performances de stockage.
• Optimiser les performances du réseau.
• Optimiser les performances des analyses.

Optimiser les performances des analyses

Ce document du framework d'architecture de Google Cloud fournit des recommandations pour vous aider à optimiser les performances de vos charges de travail d'analyse dans Google Cloud.

BigQuery

Cette section fournit des recommandations pour vous aider à optimiser les performances des requêtes dans BigQuery.

Optimiser la conception des requêtes

Les performances des requêtes dépendent de facteurs tels que le nombre d'octets lus et écrits par vos requêtes ainsi que le volume de données transmis entre les emplacements. Pour optimiser les performances de vos requêtes dans BigQuery, suivez les bonnes pratiques décrites dans la documentation suivante :

• Présentation de l'optimisation des performances des requêtes
• Gérer les données d'entrée et les sources de données
• Optimiser la communication entre les emplacements
• Optimiser le calcul des requêtes
• Gérer les données de sortie de requêtes
• Éviter les antimodèles SQL

Définir et utiliser efficacement les vues matérialisées

Pour améliorer les performances des charges de travail utilisant des requêtes courantes et répétées, vous pouvez utiliser des vues matérialisées. Le nombre de vues matérialisées que vous pouvez créer est limité. Ne créez pas de vue matérialisée distincte pour chaque permutation d'une requête. Définissez plutôt des vues matérialisées que vous pouvez utiliser pour plusieurs modèles de requêtes.

Performances améliorées pour l'opération JOIN

Vous pouvez utiliser des vues matérialisées pour réduire le coût et la latence d'une requête qui effectue une agrégation en plus d'une opération JOIN. Imaginons que vous joignez une grande table de faits à plusieurs tables de dimensions plus petites, puis que vous effectuez une agrégation en plus de la jointure. Il peut s'avérer pratique de réécrire la requête pour effectuer d'abord l'agrégation sur la table de faits, en utilisant des clés étrangères comme clés de regroupement. Ensuite, joignez le résultat de l'opération aux tables de dimensions. Pour finir, effectuez une post-agrégation.

Dataflow

Cette section fournit des recommandations pour vous aider à optimiser les performances des requêtes de vos pipelines Dataflow.

Lorsque vous créez et déployez des pipelines, vous pouvez configurer des paramètres d'exécution, tels que le type de machine Compute Engine à utiliser pour les VM de nœuds de calcul Dataflow. Pour en savoir plus, consultez la section Options de pipeline.

Une fois les pipelines déployés, Dataflow gère les ressources Compute Engine et Cloud Storage nécessaires à l'exécution de vos tâches. En outre, les fonctionnalités suivantes de Dataflow aident à optimiser les performances des pipelines :

• Chargement en parallèle : Dataflow partitionne automatiquement vos données et distribue votre code de nœud de calcul aux instances Compute Engine pour un traitement parallèle. Pour en savoir plus, consultez la section Parallélisation et distribution.
• Optimisation : Dataflow utilise votre code de pipeline pour créer un graphique d'exécution représentant les objets PCollection et les transformations dans le pipeline. Il optimise ensuite le graphique afin d'obtenir des performances et une utilisation des ressources optimales. Le service optimise également automatiquement les opérations potentiellement coûteuses, telles que les agrégations de données. Pour en savoir plus, consultez les sections Optimisation de la fusion et Combiner l'optimisation.
• Réglages automatiques : Dataflow optimise dynamiquement les tâches pendant leur exécution en utilisant l'Autoscaling horizontal, l'Autoscaling vertical et le Rééquilibrage dynamique des tâches.

Vous pouvez surveiller les performances des pipelines Dataflow en utilisant l'interface de surveillance Web ou la gcloud CLI de Dataflow.

Remarque : Vous pouvez également utiliser Cloud Profiler pour identifier les parties du code de pipeline qui consomment le plus de ressources. Pour en savoir plus, consultez la page Surveiller les performances du pipeline.

Dataproc

Cette section décrit les bonnes pratiques relatives à l'optimisation des performances de vos clusters Dataproc.

Effectuer l'autoscaling des clusters

Pour vous assurer que vos clusters Dataproc offrent des performances prévisibles, vous pouvez activer l'autoscaling. Dataproc se sert des métriques de mémoire Hadoop YARN et d'une règle d'autoscaling que vous définissez pour ajuster automatiquement le nombre de VM de nœud de calcul dans un cluster. Pour en savoir plus sur l'utilisation et la configuration de l'autoscaling, consultez la page Procéder à l'autoscaling des clusters.

Provisionner le stockage approprié

Choisissez une option de stockage appropriée pour votre cluster Dataproc en fonction de vos exigences en termes de performances et de coûts :

• Si vous avez besoin d'un système de fichiers (HCFS) économique et compatible avec Hadoop, dans lequel les tâches Hadoop et Spark peuvent lire et écrire avec des modifications minimales, utilisez Cloud Storage. Les données stockées dans Cloud Storage sont persistantes et sont accessibles aux autres clusters Dataproc ainsi qu'à d'autres produits comme BigQuery.
• Si vous avez besoin d'un système de fichiers distribué Hadoop (HDFS, Hadoop Distributed File System) à faible latence pour votre cluster Dataproc, utilisez des disques persistants Compute Engine associés aux nœuds de calcul. Les données stockées dans l'espace de stockage HDFS sont temporaires et le coût de stockage est supérieur à celui de l'option Cloud Storage.
• Pour bénéficier des avantages de performances des disques persistants Compute Engine et des avantages de Cloud Storage en termes de coût et de durabilité, vous pouvez combiner les deux options de stockage. Par exemple, vous pouvez stocker vos ensembles de données source et final dans Cloud Storage, et provisionner une capacité HDFS limitée pour les ensembles de données intermédiaires. Lorsque vous décidez de la taille et du type des disques pour le stockage HDFS, tenez compte des recommandations de la section Disques persistants et disques SSD locaux.

Réduire la latence lors de l'utilisation de Cloud Storage

Pour réduire la latence lorsque vous accédez à des données stockées dans Cloud Storage, nous vous recommandons de procéder comme suit :

• Créez votre bucket Cloud Storage dans la même région que le cluster Dataproc.
• Désactivez auto.purge pour les tables gérées par Apache Hive qui sont stockées dans Cloud Storage.
• Si vous utilisez Spark SQL, envisagez de créer des clusters Dataproc avec les dernières versions d'images disponibles. En utilisant la dernière version, vous pouvez éviter les problèmes de performances toujours présents dans des versions plus anciennes, tels que les performances ralenties de INSERT OVERWRITE dans Spark 2.x.
• Pour réduire le risque d'écrire de nombreux fichiers de taille variable ou faible dans Cloud Storage, vous pouvez configurer les paramètres Spark SQL spark.sql.shuffle.partitions et spark.default.parallelism, ou le paramètre Hadoop mapreduce.job.reduces.

Surveiller et ajuster la charge et la capacité de stockage

Les disques persistants associés aux nœuds de calcul d'un cluster Dataproc contiennent des données de brassage. Pour atteindre des performances optimales, les nœuds de calcul nécessitent un espace disque suffisant. Si les nœuds ne disposent pas d'un espace disque suffisant, ils sont marqués comme UNHEALTHY dans le journal de YARN NodeManager. Si ce problème survient, augmentez la taille de disque pour les nœuds concernés ou exécutez moins de tâches simultanément.

Activer l'EFM

Lorsque des nœuds de calcul sont supprimés d'un cluster Dataproc en cours d'exécution, par exemple en raison d'un scaling à la baisse ou d'une préemption, les données de brassage peuvent être perdues. Pour minimiser les retards de tâche dans de tels scénarios, nous vous recommandons d'activer le Mode de flexibilité améliorée (EFM) pour les clusters qui utilisent des VM préemptives ou qui n'appliquent un autoscaling qu'au groupe de nœuds de travail secondaire.

Étapes suivantes

Passez en revue les bonnes pratiques pour optimiser les performances de vos ressources de calcul, de stockage, de mise en réseau et de base de données :

• Optimiser les performances de calcul.
• Optimiser les performances de stockage.
• Optimiser les performances du réseau.
• Optimiser les performances de la base de données.

Nouveautés du framework d'architecture

Ce document répertorie les modifications importantes apportées au framework d'architecture Google Cloud.

28 novembre 2023

• Catégorie de fiabilité :
  • Le contenu a été réorganisé pour améliorer la lisibilité et la cohérence :
  • Définir des SLO : Section "Terminologie" déplacée vers une nouvelle page : Terminologie
  • Adopter des SLO : Section "SLO et alertes" déplacée vers une nouvelle page : SLO et alertes

9 novembre 2023

• Catégorie de conception du système :
  • Ajout de conseils pour aider les architectes cloud à choisir des archétypes de déploiement pour les charges de travail dans Google Cloud.

Septembre 2022

• Catégorie d'optimisation des coûts :

  • Ajout d'informations sur l'utilisation des tags pour l'allocation et la gouvernance des coûts.
  • Mise à jour des conseils pour l'identification des anomalies d'étiquetage.

  Pour en savoir plus, consultez la section Suivre et allouer les coûts à l'aide de tags ou de libellés.

28 août 2023

• Catégorie de conception du système :
  • Mise à jour de la liste des services d'IA et de ML dans Google Cloud.

23 août 2023

• Catégorie d'optimisation des coûts :
  • Ajout de conseils sur l'optimisation de l'utilisation des ressources Spanner pour les petites charges de travail en utilisant les unités de traitement en lieu et place des nœuds.

18 août 2023

• Catégorie sécurité, confidentialité et conformité :
  • Ajout de conseils liés à la loi HIPAA.
• Catégorie d'excellence opérationnelle :
  • Mise à jour des bonnes pratiques pour planifier les événements de pic de trafic.

9 août 2023

• Catégorie de fiabilité :
  • Ajout de liens vers la documentation sur la fiabilité pour les produits suivants :
    • Dataproc
    • Bigtable
    • Cloud SQL
    • Spanner

13 juillet 2023

• Conception du système :
  • Ajout d'AlloyDB pour PostgreSQL à la liste des services de base de données dans Google Cloud.
• Optimisation des coûts :
  • Ajout de conseils sur Google Cloud Hyperdisk et les disques SSD locaux dans la section Disque persistant.

23 juin 2023

• Optimisation des performances :
  • Ajout de conseils sur l'optimisation de la bande passante utilisée avec les trames géantes et des types de machines appropriés pour les VM.

15 juin 2023

• Sécurité, confidentialité et conformité :
  • Ajout de conseils sur la sécurisation des connexions aux environnements sur site et multicloud à l'aide de Cross-Cloud Interconnect.
  • Ajout de conseils sur la sécurisation du périmètre des charges de travail cloud à l'aide de stratégies, de règles de pare-feu et d'un proxy Web sécurisé.

30 mars 2023

• Ajout de deux articles supplémentaires sur le SLO au framework :
  • Définir des SLO
  • Adopter des SLO

16 septembre 2022

• Expansion majeure de la catégorie d'optimisation des performances.

10 août 2022

• Modifications apportées à la catégorie Conception système :
  • Ajout de principes fondamentaux de la conception de systèmes
  • Ajout de recommandations concernant l'utilisation des services de conseil Google Cloud et l'interaction avec nos partenaires

4 août 2022

• Ajout d'informations sur les fonctionnalités suivantes dans la catégorie d'optimisation des coûts :

  • Prévenir les interruptions dues à des problèmes de facturation en verrouillant la liaison entre un projet et son compte de facturation. Pour en savoir plus, consultez la section Configurer le contrôle des accès à la facturation.

  • Réduire les quotas à l'aide de l'API Service Usage. Pour en savoir plus, consultez la page Budgets, alertes et quotas.

  • Identifier et supprimer les projets dormants. Pour en savoir plus, consultez la section Recommandations Active Assist.

13 juillet 2022

• Changements dans la catégorie d'excellence opérationnelle :

  • Ajout d'une bonne pratique concernant le création d'un centre d'excellence.
  • Ajout d'une bonne pratique concernant la configuration d'un outil d'audit.

27 juin 2022

• Ajout d'informations sur les responsabilités partagées et le destin partagé dans Google Cloud dans la catégorie Sécurité.

13 juin 2022

• Ajout de recommandations pour vous aider à concevoir des charges de travail cloud en phase avec la protection de l'environnement dans la catégorie conception du système.

1er juin 2022

• Ajout d'informations sur les VM spot dans la section Optimiser les coûts : Compute, conteneurs et sans serveur.

7 mai 2022

• Ajout d'informations sur les emplacements birégionaux dans les bonnes pratiques pour l'optimisation des coûts pour Cloud Storage.

4 mai 2022

• Ajout de guides de fiabilité de produits. Ces guides incluent les bonnes pratiques concernant la fiabilité des produits suivants :

  • Calcul : Compute Engine, Cloud Run, Cloud Functions, et Google Kubernetes Engine

  • Stockage et bases de données : Cloud Storage, Firestore

  • Mise en réseau : Cloud DNS et Cloud Load Balancing

  • Analyse de données : BigQuery

25 février 2022

• Modifications apportées à la catégorie sécurité :

  • Mise à jour des bonnes pratiques de conformité pour discuter de l'automatisation.

15 décembre 2021

• Lancement de l'espace du framework d'architecture dans la communauté Google Cloud.

25 octobre 2021

• Modifications apportées à la catégorie fiabilité :

  • Ajout des bonnes pratiques de réplication des données entre régions pour la reprise après sinistre et de conception d'une architecture multirégionale pour la résilience aux pannes régionales.
  • Ajout d'un exemple de calcul des marges d'erreur.
  • Ajout de bonnes pratiques pour choisir des noms appropriés pour les applications et les services.

7 octobre 2021

• Actualisation majeure de toutes les catégories.

---

1. Anna Berenberg and Brad Calder, Deployment Archetypes for Cloud Applications, ACM Computing Surveys, Volume 55, Issue 3, Article No.: 61, pp 1-48 ↩