Google ACE: Compute Engine et opérations sur les machines virtuelles — Guide d'étude

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fait partie du Google Associate Cloud Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

Compute Engine fournit des machines virtuelles flexibles et performantes ainsi que des primitives d’orchestration pour exécuter des charges de travail généralistes et spécialisées. L’excellence opérationnelle sur Compute Engine implique de sélectionner la bonne famille de machines et le bon disque, de façonner le cycle de vie des instances avec des modèles et des groupes d’instances, d’établir un auto-rétablissement (autohealing) et un autoscaling robustes, de renforcer les chemins d’accès et de se préparer aux modes de défaillance avec des procédures de récupération reproductibles. Cette section explique les choix de conception, les compromis et les modèles opérationnels qui minimisent les tâches répétitives (toil) et maximisent la fiabilité et la rentabilité.

Types de machines, dimensionnement et cycle de vie des instances

Familles de machines

Usage général : E2 (optimisées pour le coût), N2 (équilibrées), N2D (basées sur AMD), Tau T2D/T2A (rapport prix/performance élevé pour le scale-out), adaptées à la plupart des charges de travail.
Optimisées pour le calcul : C3 pour les tâches limitées par le CPU ; à choisir lorsque vous avez besoin de hautes performances par cœur.
Optimisées pour la mémoire : série M pour les bases de données en mémoire et l’analytique.
GPU et accélérateurs : à attacher aux familles compatibles lorsque vous avez besoin d’une accélération CUDA ou ML ; assurez-vous que l’initialisation des pilotes est capturée dans les processus de démarrage.

Types de machines personnalisés

Utilisez des vCPU et une mémoire personnalisés pour dimensionner correctement les charges de travail et réduire le gaspillage, en particulier pour les besoins asymétriques (par exemple, beaucoup de mémoire mais un CPU modéré).
Pour les services limités par le CPU, privilégiez un nombre de vCPU plus élevé ; pour ceux limités par la mémoire, augmentez la RAM et assurez-vous que les garbage collectors et les caches sont bien réglés.
Surveillez les modèles de licence liés au nombre de cœurs ; les types personnalisés aident à éviter les cœurs sous licence inutiles.

Dimensionnement de la charge de travail

Partez des profils de ressources mesurés dans les environnements de développement ou précédents : utilisation du CPU à P95, pic de consommation mémoire (high-water mark), débit/IOPS du disque, bande passante réseau.
Pour un trafic en rafales, prévoyez une marge de manœuvre ou utilisez l’autoscaling ; pour un état stable, visez une utilisation de 60 à 70 % en période de pointe pour équilibrer coût et résilience.
Évaluez les VM Spot (préemptives) pour les tâches de traitement par lots (batch) et tolérantes aux pannes ; elles peuvent être arrêtées à tout moment, donc concevez avec des points de contrôle (checkpointing) et des tentatives.

Ressources du cycle de vie des instances

Instances de VM : la ressource de calcul atomique. Utilisez des libellés et une convention de nommage cohérente pour piloter l’automatisation.
Modèles d’instance : des plans immuables (blueprints) capturant le type de machine, les disques, les comptes de service, les métadonnées et les scripts de démarrage ; ils constituent la base des groupes d’instances gérés et garantissent des déploiements reproductibles.
Groupes d’instances gérés (MIG) : fournissent une taille déclarative, l’autoscaling, l’auto-rétablissement (autohealing), les mises à jour progressives (rolling updates), le placement régional (multizone) et la configuration par instance. Privilégiez les MIG pour les modèles stateless et stateful (les MIG stateful préservent les disques/IP sélectionnés).
Groupes d’instances non gérés : de simples collections pour la répartition de charge d’ensembles existants (legacy) ; ne disposent pas de l’autoscaling/auto-rétablissement. À n’utiliser que lorsque vous devez enregistrer des VM gérées indépendamment.

Disponibilité, autoscaling et maintenance

Autoscaling

Signaux : utilisation du CPU, requêtes par seconde par instance du répartiteur de charge HTTP, métriques Cloud Monitoring et profondeur de la file d’attente. Choisissez un signal étroitement corrélé à la saturation ; le CPU est une bonne base pour les charges de travail homogènes limitées par le CPU.
Périodes de stabilisation (cooldowns) : à configurer pour éviter l’instabilité (thrashing). Si votre application met plusieurs minutes à démarrer, augmentez le délai initial du MIG et définissez une période de stabilisation d’autoscaling appropriée.
Modèles à instance unique : pour forcer l’exécution d’une seule VM, définissez min=1 et max=1 pour l’autoscaling sur un MIG. Cela préserve la santé tout en activant l’auto-rétablissement.

Auto-rétablissement (autohealing) et vérifications de l’état (health checks)

Vérifications de l’état : utilisez des vérifications HTTP(S) pour la vivacité (liveness) de l’application ; le TCP ne valide que l’acceptation du socket. Implémentez un point de terminaison de santé qui sollicite les dépendances critiques.
Seuils et intervalles : ajustez l’intervalle de vérification et les seuils pour détecter rapidement les défaillances sans faux positifs.
Délai initial : définissez le délai initial d’auto-rétablissement du MIG suffisamment long pour le démarrage et la montée en charge afin d’éviter le remplacement prématuré d’instances saines en cours de démarrage.
Modes de défaillance : des points de terminaison de santé mal configurés et des délais initiaux trop courts provoquent de l’instabilité (flapping) et du surprovisionnement.

MIG régionaux et placement

Les MIG régionaux répartissent les instances sur plusieurs zones d’une région, offrant une tolérance aux pannes de zone. Choisissez le nombre de réplicas cibles par zone en fonction de la planification de la capacité.
Utilisez des configurations par instance et des politiques stateful lorsque la préservation des disques ou des IP est requise ; comprenez que le remplacement des VM peut être plus lent en raison de la réconciliation de l’état.

Maintenance, migration à chaud et réservations

Migration à chaud (Live migration) : comportement par défaut pour la plupart des VM ; les instances sont déplacées pendant la maintenance de l’hôte sans redémarrage. Pour les charges de travail qui ne tolèrent pas la migration (par ex., HFT sensible à la latence), définissez la politique de maintenance sur ’terminate’ (arrêter) et fiez-vous à l’auto-rétablissement.
Les fenêtres de maintenance de l’hôte sont transparentes avec la migration à chaud mais génèrent tout de même des événements ; surveillez et testez.
Réservations : créez des réservations zonales pour garantir la capacité pour les lancements critiques ou les SLO stricts. Appliquez une consommation de réservation « spécifique » ou « quelconque » (any) en fonction de votre gouvernance. Les réservations sont des garanties de capacité ; associez-les à des remises pour usage soutenu (committed use discounts) pour la planification des coûts.

Stockage, images et performances

Disques persistants

Types : Standard (HDD) pour un débit séquentiel à faible coût ; Balanced (pd-balanced) pour un usage général ; SSD (pd-ssd) pour des IOPS élevés/une faible latence ; Extreme (pd-extreme) pour des IOPS et un débit provisionnés à des niveaux de haute performance. Les Regional PDs fournissent une réplication synchrone entre les zones pour une disponibilité accrue.
Les performances évoluent avec la taille du disque pour les types Standard, Balanced et SSD ; pré-dimensionnez pour répondre aux pics d’IOPS/débit ou utilisez Extreme pour un provisionnement explicite.
Le mode lecture seule multi-attachement (multi-attach read-only) permet de partager des jeux de données entre plusieurs VM ; coordonnez l’accès et les couches de mise en cache en conséquence.

Local SSD

Éphémère, attaché directement à l’hôte, IOPS très élevés/faible latence. Les données sont perdues lors de l’arrêt, de la suppression ou de la migration. À utiliser pour l’espace de travail temporaire (scratch), les caches et les couches de données répliquées. Assurez une réplication ou des points de contrôle au niveau de l’application.

Instantanés et images

Les instantanés (snapshots) sont des sauvegardes incrémentielles et à un instant T des disques persistants ; planifiez-les avec Resource Manager ou gcloud pour respecter le RPO. Le stockage interrégional prend en charge la reprise après sinistre (DR).
Les images capturent les disques de démarrage ainsi que la configuration. Maintenez un pipeline d’images sécurisées (hardened) et gérées par correctifs. Validez les agents invités (guest agents) (pour la journalisation/surveillance) au sein de vos images de référence (golden images).
Modèles de restauration : Pour une récupération rapide, conservez des images de base de petite taille et configurez le reste via des scripts de démarrage ou cloud-init ; cela réduit la dérive (drift) et accélère les mises à jour.

Choix de disques : compromis et modes de défaillance

Les disques sous-provisionnés brident le débit de l’application ; le sur-provisionnement gaspille des coûts. Mesurez les caractéristiques d’E/S réelles et choisissez le plus petit disque répondant aux besoins de pointe avec une marge.
Pour les bases de données, envisagez les Regional PDs et les pd-ssd/pd-extreme ; validez le comportement de fsync et les profondeurs de file d’attente (queue depths). Évitez les Local SSD pour l’état durable, sauf s’il est répliqué.

Accès, sécurité, réseau et charges de travail spécialisées

Administration Linux et Windows

SSH Linux : Préférez OS Login pour centraliser l’autorisation SSH et attribuer l’accès aux identités. Accordez les rôles compute.osLogin ou compute.osAdminLogin à des groupes, pas à des individus.
RDP Windows : Définissez les informations d’identification Windows dans la console ou via gcloud ; assurez-vous que les règles de pare-feu n’autorisent le port TCP 3389 qu’à partir d’adresses IP de confiance. Utilisez IAP TCP forwarding pour éviter l’exposition publique.
Console série : Activez-la comme chemin d’accès d’urgence (break-glass) ; utilisez gcloud compute connect-to-serial-port pour le débogage du démarrage. Restreignez l’accès avec IAM et auditez les accès.

SSH, OS Login et gestion des clés

Activez OS Login au niveau du projet ou de l’instance avec la métadonnée enable-oslogin=TRUE. Les utilisateurs ajoutent leur clé publique SSH à leur compte Google ; IAM contrôle l’accès basé sur les rôles.
Pour sudo/root, utilisez compute.osAdminLogin. Désactivez les clés SSH à l’échelle du projet si vous utilisez OS Login pour éviter la dérive.

Métadonnées, scripts de démarrage et cloud-init

Le serveur de métadonnées fournit les données de l’instance/du projet et les jetons de compte de service. N’utilisez que des jetons à portée bien définie (well-scoped) ; ne codez jamais de secrets en dur.
Scripts de démarrage et cloud-init : Amorcent les agents, récupèrent les configurations et enregistrent les services. Rendez les scripts idempotents et écrivez les journaux sur la console série pour le diagnostic.
Les métadonnées par instance peuvent remplacer les paramètres du modèle ; utilisez-les avec précaution pour éviter les décalages de configuration (configuration skew).

Comptes de service et niveaux d’accès (scopes)

Attribuez un compte de service dédié par charge de travail avec les rôles IAM du moindre privilège sur les ressources requises (par ex., storage.objectCreator sur un bucket spécifique).
Préférez des niveaux d’accès (scopes) Cloud API larges uniquement lorsque IAM contrôle étroitement l’accès ; sinon, restreignez les scopes aux API minimales.

Réseau et adresses

Les cartes réseau (NICs) peuvent avoir des adresses IP internes uniquement ou externes. Préférez les VM privées avec Cloud NAT ou IAP pour l’accès sortant et l’administration.
Réservez des adresses IP internes statiques pour les points de terminaison stables comme les serveurs de licences ; évitez de dépendre des adresses éphémères.
L’External HTTP(S) Load Balancing termine la connexion TLS en périphérie (at the edge) ; utilisez des certificats gérés et des vérifications de l’état (health checks) vers les MIGs backend. Maintenez la disponibilité (readiness) du backend alignée sur la vérification de l’état et le délai initial du MIG.

Charges de travail spécialisées et isolation

Shielded VMs : Le démarrage sécurisé (Secure boot), le vTPM et la surveillance de l’intégrité atténuent les rootkits ; activez-les par défaut, sauf si des pilotes incompatibles l’exigent autrement.
Confidential VMs : Le chiffrement de la mémoire avec AMD SEV protège les données en cours d’utilisation ; la surcharge de performance est généralement minimale, mais validez-la pour les applications sensibles à la latence.
Sole-tenant nodes : Hôtes physiques dédiés pour la conformité, l’isolation contre les “voisins bruyants” (noisy-neighbor) et l’affinité de licence. Planifiez la fragmentation de la capacité et un coût plus élevé.

Dépannage et opérations de récupération

Diagnostics courants

Connectivité : Vérifier les règles de pare-feu, les autorisations des comptes de service et les routes. Utiliser les tests de connectivité de Network Intelligence Center.
Problèmes de démarrage : Inspecter les journaux de la console série, prendre une capture d’écran et vérifier la sortie du script de démarrage. Désactiver temporairement le démarrage sécurisé (secure boot) si des pilotes non signés bloquent le démarrage, puis corriger.
Verrouillage de l’accès : Pour les problèmes SSH avec OS Login, confirmer les rôles IAM et la présence des clés sur les comptes utilisateur ; utiliser la console série pour ajouter un utilisateur en cas d’urgence (break-glass).
Corruption de disque : Détacher le disque de démarrage, l’attacher à une VM de secours, réparer les systèmes de fichiers, effectuer une rotation des identifiants et capturer une image après correction.

Comportements des MIG et des équilibreurs de charge

Surprovisionnement : Si les instances nécessitent une longue phase de chauffe, augmenter le délai initial du MIG et le délai de récupération (cooldown) de l’autoscaler ; sinon, vous risquez un scale-out à cause d’erreurs 4xx/5xx pendant que l’application est encore en cours d’initialisation.
Boucles d’autoréparation : Confirmer la sémantique du point de terminaison de santé et la disponibilité des dépendances ; échelonner le démarrage des dépendances ou ajouter des tentatives.

Modèles de récupération

Recréer l’instance à partir d’un modèle ou d’une image ; les modèles immuables réduisent le MTTR.
Restaurer les données à partir du dernier snapshot réussi ; valider le RPO/RTO par rapport aux exigences métier.
Pour les pannes régionales, basculer vers une autre zone ou région en utilisant des MIG régionaux et la réplication interrégionale de snapshots.

Garanties opérationnelles

Réservations pour la capacité critique ; utiliser des alertes basées sur la surveillance pour la consommation des réservations et les quotas.
Audit et journalisation : Activer les journaux d’activité d’administration et d’accès aux données pour les services critiques. Attribuer l’accès via OS Login et les comptes de service.

Exemples courts

Réserver une adresse IP interne statique :

undefined

Activer OS Login au niveau du projet :

undefined

Créer une vérification de santé HTTP et l’attacher à un MIG avec autoréparation :

undefined

Scénario de problème pratique

Northwind Analytics exécute une API sensible à la latence sur Compute Engine. Les incidents révèlent un surprovisionnement fréquent lors des déploiements, une confusion occasionnelle concernant l’accès SSH parmi les administrateurs, et un serveur de télémétrie sous licence qui doit rester joignable à l’adresse 10.0.3.21. L’objectif est de stabiliser le scaling, de renforcer la sécurité des accès et de garantir la stabilité du point de terminaison de la licence.

Approche

Créer un modèle d’instance avec un type de machine personnalisé et bien dimensionné, et un bootstrapping au démarrage

Justification : Le modèle impose l’immuabilité. Une configuration personnalisée de 6 vCPU/20 Go de RAM correspond aux mesures P95 de CPU et de mémoire, tout en évitant les cœurs excédentaires qui augmentent les coûts de licence. Un script de démarrage enregistre l’API auprès de l’équilibreur de charge uniquement après que les vérifications de santé sont réussies, réduisant ainsi l’impact de la phase de chauffe.

Déployer un groupe d’instances géré (MIG) régional derrière un External HTTP(S) Load Balancer

Justification : Un MIG régional répartit les instances sur plusieurs zones pour une tolérance aux pannes de zone. L’équilibreur de charge HTTP(S) termine la connexion TLS en périphérie et effectue des vérifications de santé par instance, ne dirigeant le trafic que vers les backends prêts.

Configurer l’autoscaling sur le CPU avec un délai de récupération (cooldown) et l’autoréparation avec un délai initial réaliste

Justification : Le CPU est fortement corrélé à la saturation de cette API. Un délai de récupération de 90 secondes évite les fluctuations excessives (thrash) lors de pics transitoires. Un délai initial de 200 secondes correspond à la phase de chauffe du conteneur et à la compilation JIT, empêchant l’autoscaler d’interpréter les démarrages à froid comme un manque de capacité.

Ajuster la vérification de santé et ajouter un point de terminaison /healthz au niveau de l’application

Justification : Une vérification de santé HTTP qui valide les dépendances (cache, connectivité à la base de données) détecte les pannes grises (gray failures). L’utilisation d’intervalles de 10 secondes et de 3 seuils d’échec (unhealthy thresholds) équilibre la vitesse de détection et le risque de faux positifs.

Activer OS Login et accorder l’accès administrateur à un groupe IAM

Justification : OS Login centralise l’autorisation et l’attribution des accès SSH. Les administrateurs ajoutent leurs clés publiques SSH à leurs comptes Google ; accorder le rôle compute.osAdminLogin au groupe d’astreinte fournit un accès sudo tout en préservant les pistes d’audit. Cela élimine la dérive des clés par VM.

Réserver l’adresse IP interne statique du serveur de licences et l’attacher à une petite VM dédiée

Justification : La réservation de l’adresse 10.0.3.21 garantit sa disponibilité et empêche sa réutilisation accidentelle. L’assigner à la carte réseau (NIC) de la VM de licence évite toute modification de configuration pour les applications dépendantes. Limiter la portée des règles de pare-feu aux seuls sous-réseaux sources autorisés.

Assigner un compte de service dédié au modèle d’API avec des autorisations IAM de moindre privilège

Justification : Le principe du moindre privilège réduit le rayon d’impact (blast radius). Le compte de service ne se voit accorder que les rôles nécessaires (par exemple, l’accès en lecture à des secrets spécifiques et à des sujets Pub/Sub). L’utilisation d’un modèle garantit que toutes les instances héritent de la bonne identité.

Renforcer la sécurité des instances avec Shielded VM et imposer un accès d’urgence via la console série

Justification : Le démarrage sécurisé (Secure Boot) et la surveillance de l’intégrité atténuent les risques de falsification du noyau/chargeur de démarrage. Restreindre l’accès à la console série avec IAM et journaliser les accès pour les audits ; la conserver pour la récupération en cas d’échec de SSH.

Mettre en œuvre des planifications de snapshots pour les disques avec état (stateful) et tester la restauration

Justification : Bien que l’API soit sans état (stateless), créer une planification de snapshots pour le serveur de licences et tout disque de configuration afin de respecter le RPO. Des tests de restauration périodiques valident l’outillage et les procédures (runbooks).

Valider et déployer

Justification : Les mises à jour Blue/green ou canary avec les paramètres de mise à jour progressive du MIG réduisent les risques. Les tableaux de bord de surveillance confirment la stabilisation du nombre d’instances pendant les déploiements, une meilleure attribution des accès administrateur et la joignabilité ininterrompue de l’adresse 10.0.3.21.

← Hiérarchie des ressources · Tous les domaines · Conteneurs →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →