Amazon SOA-C02: Bases de données et mise en cache — Guide d'étude

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

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

Les bases de données et la mise en cache sont des responsabilités opérationnelles fondamentales pour un administrateur SysOps : elles fournissent un stockage persistant, la disponibilité et des lectures à faible latence pour les applications. Ce domaine couvre l’exécution de bases de données relationnelles gérées (RDS et Aurora), la mise à l’échelle de la capacité de lecture/écriture, le comportement de la réplication et du basculement, et l’utilisation d’ElastiCache pour réduire la charge sur la base de données. Une configuration adéquate des sauvegardes, des groupes de paramètres, de la surveillance et des stratégies d’invalidation du cache prévient la perte de données et réduit les incidents opérationnels.

Opérations RDS et Aurora, sauvegardes et Multi-AZ

RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) et Amazon Aurora (compatible avec MySQL et PostgreSQL) sont des moteurs relationnels gérés avec des sémantiques opérationnelles différentes. Le Multi-AZ pour RDS crée une instance de secours synchrone dans une autre AZ — gérée par AWS, avec un basculement automatisé en quelques minutes, sans promotion manuelle, et l’instance de secours n’est pas accessible pour les lectures. Aurora sépare les points de terminaison d’écriture et de lecture : l’écrivain est un point de terminaison de cluster soutenu par une instance principale, et Aurora utilise un stockage distribué qui se réplique automatiquement entre les AZ et peut généralement basculer plus rapidement que RDS car le stockage est partagé.

Configurez les sauvegardes et la rétention en utilisant :

Sauvegardes automatisées : activez-les avec une période de rétention (par ex., modify-db-instance –backup-retention-period 7). Celles-ci permettent une restauration à un instant T (PITR) à n’importe quelle seconde dans la fenêtre de rétention pour les moteurs pris en charge.
Snapshots manuels : create-db-snapshot (ou create-db-cluster-snapshot pour Aurora) pour capturer un snapshot conservé ; les snapshots persistent jusqu’à ce que vous les supprimiez.
Restauration PITR : aws rds restore-db-instance-to-point-in-time pour RDS, ou restore-db-cluster-from-snapshot puis création d’instances pour Aurora.

Critères de décision :

Utilisez le Multi-AZ pour la haute disponibilité et le basculement automatisé lorsque la disponibilité en écriture est critique et que les lectures sur l’instance de secours ne sont pas nécessaires.
Utilisez Aurora (stockage en cluster) lorsque vous avez besoin d’IOPS élevés, d’un basculement rapide et d’une mise à l’échelle automatique du stockage.
Utilisez des réplicas en lecture pour la mise à l’échelle des lectures et la reprise après sinistre inter-régions (ils sont asynchrones et peuvent être promus).

Exemples de CLI opérationnels :

Activer le Multi-AZ : aws rds modify-db-instance –db-instance-identifier mydb –multi-az –apply-immediately
Créer un snapshot automatisé : aws rds create-db-snapshot –db-snapshot-identifier snap1 –db-instance-identifier mydb
Restaurer PITR : aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –restore-time “YYYY-MM-DDTHH:MM:SSZ”

Réplicas en lecture, basculement et stratégies de réplication

Les réplicas en lecture sont des copies asynchrones (instances en lecture RDS ou Aurora) utilisées principalement pour mettre à l’échelle le trafic de lecture et décharger les tâches de reporting. Elles subissent un décalage de réplication (surveillez la métrique ReplicaLag) et ne sont pas adaptées à une cohérence forte. Les réplicas en lecture peuvent être promus en instances de base de données autonomes pour prendre en charge la reprise après sinistre.

Stratégies de réplication et choix :

Synchrone (instance de secours RDS Multi-AZ) — garantie d’aucune dérive de données, pas de capacité de lecture sur l’instance de secours.
Réplicas en lecture asynchrones — mettent à l’échelle les lectures, permettent des copies inter-régions, risque de décalage du réplica et de perte potentielle de données lors du basculement.
Lecteurs Aurora — fournissent des points de terminaison de lecture en cluster, un basculement à faible latence via le réacheminement des points de terminaison et un équilibrage automatique des points de terminaison de lecture.

Modèles opérationnels :

Créer un réplica en lecture : aws rds create-db-instance-read-replica –db-instance-identifier read1 –source-db-instance-identifier primary
Promouvoir un réplica : aws rds promote-read-replica –db-instance-identifier read1
Surveiller : DatabaseConnections, ReplicaLag, ReadIOPS, WriteIOPS de CloudWatch et Performance Insights pour décider quand ajouter ou supprimer des réplicas.

Critères de décision :

Si vous avez besoin de haute disponibilité pour les écritures, choisissez le Multi-AZ. Si vous avez besoin de débit en lecture et de décharger les analyses, choisissez des réplicas en lecture ou des lecteurs Aurora.
Pour la reprise après sinistre inter-régions, créez des réplicas en lecture dans la région cible et envisagez la copie automatisée de snapshots ou DMS pour la migration.

Mise en cache avec ElastiCache et invalidation du cache

ElastiCache propose Redis et Memcached pour réduire la charge sur la base de données et la latence. Choisissez Redis lorsque vous avez besoin de persistance, de réplication, de structures de données et de haute disponibilité avec Multi-AZ et basculement automatique. Choisissez Memcached pour une mise en cache horizontale simple où le partitionnement (sharding) et les performances multithread sont des priorités.

Configuration et modèles clés :

Créer un cluster Redis avec des réplicas et Multi-AZ : aws elasticache create-replication-group –replication-group-id rg1 –replication-group-description “rg” –engine redis –num-cache-clusters 3 –automatic-failover-enabled
Utilisez le mode cluster activé pour Redis pour mettre à l’échelle les partitions (shards) ; Memcached nécessite un hachage côté client pour le partitionnement.
Politiques d’éviction : volatile-lru, allkeys-lru, noeviction — ajustez selon que vous préférez expulser uniquement les clés expirées ou n’importe quelle clé lorsque la mémoire est pleine.
Surveillez CacheHits et CacheMisses pour calculer le taux de succès du cache (cache hit ratio) : hit_ratio = CacheHits / (CacheHits + CacheMisses). Visez un taux de succès élevé pour réduire les lectures sur la base de données.

Stratégies d’invalidation du cache :

Cache-aside : l’application vérifie d’abord le cache, en cas d’échec (miss), elle lit la base de données et remplit le cache ; expirez ou supprimez explicitement le cache lors des écritures.
Write-through/write-behind : les écritures dans le cache se propagent à la base de données ; le write-behind regroupe les écritures vers la base de données par lots (ajoute de la complexité).
Time-to-live (TTL) : définissez des TTL conservateurs pour les données qui peuvent devenir obsolètes ; combinez avec le versionnement du cache ou des clés d’invalidation pour les changements de schéma ou l’invalidation en masse.
Utilisez Redis pub/sub ou des événements Lambda pour notifier les instances d’application afin de réaliser une invalidation distribuée si nécessaire.

Groupes de paramètres de base de données, mise à l’échelle et surveillance

Les groupes de paramètres contrôlent les réglages spécifiques au moteur (par ex., max_connections, innodb_buffer_pool_size). RDS utilise des groupes de paramètres de base de données (DB parameter groups) pour les instances et des groupes de paramètres de cluster de bases de données (DB cluster parameter groups) pour Aurora. Les modifications de certains paramètres nécessitent un redémarrage (appliquées après un redémarrage en attente), d’autres s’appliquent immédiatement.

Modèles de gestion :

Créer et modifier un groupe de paramètres : aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”; puis aws rds modify-db-parameter-group –db-parameter-group-name pg1 –parameters “ParameterName=max_connections,ParameterValue=500,ApplyMethod=immediate”
Mettre à l’échelle la classe d’instance : aws rds modify-db-instance –db-instance-identifier mydb –db-instance-class db.r5.large –apply-immediately (ou pendant la fenêtre de maintenance pour éviter un redémarrage).
Mise à l’échelle automatique du stockage : à activer pour les types de moteurs pris en charge ; Aurora met automatiquement à l’échelle le stockage.

Signaux de surveillance et de mise à l’échelle :

Utiliser CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) et Performance Insights pour les requêtes SQL lentes et les principales attentes (waits).
Activer la Surveillance améliorée (Enhanced Monitoring) et définir la granularité (par ex., 1s pour le dépannage).
Utiliser RDS Proxy pour gérer le regroupement de connexions (connection pooling) et réduire les tempêtes de connexions pour les applications sans serveur ou à forte concurrence.

Procédures de sauvegarde/restauration et considérations sur la migration

Les sauvegardes et les restaurations doivent être explicites et testées. Les sauvegardes automatisées fournissent une restauration à un instant T (PITR) pendant la période de rétention ; les snapshots manuels sont conservés jusqu’à leur suppression et peuvent être copiés entre les régions et vers différentes clés KMS. Soyez explicite sur la région et l’horodatage lors de la restauration.

Commandes de restauration courantes :

Restaurer à un instant T (RDS) : aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –use-latest-restorable-time / ou spécifier –restore-time
Restaurer un snapshot (inter-régions) : d’abord copy-db-snapshot vers la région de destination, puis restaurer.

Considérations sur la migration :

AWS DMS pour les migrations avec un temps d’arrêt minimal (hétérogènes/homogènes). DMS prend en charge la réplication continue ; assurez-vous que les paramètres du moteur source sont corrects (binlog activé pour MySQL).
Migration logique (mysqldump, pg_dump) pour les exports simples ; restauration de snapshot physique pour les grands ensembles de données.
Valider les jeux de caractères, les différences de groupes de paramètres et les clés KMS pour les snapshots chiffrés.

Pièges courants et critères de décision

Restauration de sauvegardes dans la mauvaise région ou au mauvais moment : toujours vérifier –region et –restore-time avant la restauration ; utiliser le snapshot copié dans la région cible et tester les restaurations en pré-production (staging).
Supposer que les réplicas en lecture fournissent une haute disponibilité : n’oubliez pas que les réplicas sont asynchrones ; utilisez Multi-AZ ou Aurora pour la HA en écriture et la réplication synchrone.
Négliger l’invalidation du cache : concevoir des TTL, des clés versionnées ou une invalidation pilotée par les événements ; éviter de se fier uniquement à des TTL courts pour garantir l’exactitude.
Ne pas activer correctement les sauvegardes automatisées ou la rétention : définir backup-retention-period >0 et valider la restauration à un instant T (PITR) avec des tests de restauration ; s’assurer que les clés KMS sont disponibles dans la région cible pour la copie de snapshot.
Modification des groupes de paramètres sans redémarrage : vérifier ApplyMethod ; planifier les redémarrages dans les fenêtres de maintenance pour les paramètres qui le nécessitent afin d’éviter des temps d’arrêt imprévus.
Mise à l’échelle sans gestion des connexions : augmenter la classe d’instance sans utiliser RDS Proxy ou le regroupement de connexions (connection pooling) peut ne pas résoudre les tempêtes de connexions ; implémentez le pooling pour gérer de nombreuses connexions de courte durée.

Problème pratique : Scénario d’utilisation

Acme Retail exploite une base de données primaire MySQL RDS avec un trafic de lecture intense et des pics d’activité analytique occasionnels ; ils sont confrontés à un retard de réplication (replica lag) pendant l’ETL nocturne et observent une rotation élevée des connexions provoquant des pics de CPU.

Activer un groupe de réplicas en lecture supplémentaire pour l’analytique, isolé des lecteurs de l’application, et le placer dans une autre AZ ou région pour la reprise après sinistre (DR).
Configurer la surveillance des réplicas (métrique ReplicaLag) et ajouter une logique de mise à l’échelle automatique pour ajouter des lecteurs lorsque le retard ou la ReadLatency dépasse les seuils.
Déployer RDS Proxy devant l’application pour multiplexer les connexions et réduire leur rotation ; ajuster max_connections de manière appropriée dans le groupe de paramètres.
Déplacer les tâches analytiques pour qu’elles utilisent le réplica dédié à l’analytique et adopter une mise en cache de type cache-aside via ElastiCache for Redis avec des TTL appropriés pour réduire les requêtes répétées.
Tester les procédures de basculement (failover) et de restauration : effectuer une restauration à un instant T (PITR) sur une instance de pré-production (staging) et valider les étapes de promotion d’un réplica.

Cette approche sépare les charges de travail de lecture, réduit la pression sur les connexions au niveau de l’instance primaire et utilise la mise en cache pour diminuer le volume de lecture de la base de données. Elle suit les meilleures pratiques AWS en combinant la mise à l’échelle en lecture, le regroupement de connexions (connection pooling) et des processus de sauvegarde/restauration testés pour maintenir la disponibilité et la résilience opérationnelle.

← Calcul et Auto Scaling · Tous les domaines · Serverless et intégration d’applications →

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