Cache et mise à l'échelle des bases de données

Ajouter de la capacité de calcul ne sert à rien si toutes les instances tapent sur la même base de données. Ce sujet traite l'autre moitié du problème : d'abord enlever les lectures qui se répètent en les mettant en cache, puis mettre à l'échelle la base qui reçoit ce qui reste. Les trois leçons couvrent la compétence 2.1.2 du SOA-C03 (le cache avec CloudFront et ElastiCache) et la compétence 2.1.3 (la mise à l'échelle des bases managées RDS, Aurora et DynamoDB).

Ce que couvre ce sujet

• Choisir entre un cache de périphérie et un cache applicatif selon ce qui se répète : des réponses HTTP ou des résultats de requêtes
• La cache key CloudFront, les cache policies managées, et le recadrage des TTL qui décide combien de temps un objet reste à la périphérie
• Les leviers de hit ratio, les directives de contenu périmé, et l'arbitrage entre invalidation et noms de fichiers versionnés
• Le lazy loading, le write-through et le TTL dans ElastiCache, avec la faiblesse propre à chaque stratégie
• Le choix du moteur ElastiCache et les métriques CloudWatch qui décident entre monter en gamme, ajouter des réplicas et ajouter des shards
• La frontière entre standby Multi-AZ, read replica RDS et Aurora Replica, et le replica lag qui va avec l'asynchrone
• Le storage autoscaling RDS avec ses trois conditions, RDS Proxy pour les problèmes de connexions, et le cluster volume partagé d'Aurora
• Aurora Auto Scaling, ses reader endpoints, et la capacité en ACU d'Aurora Serverless v2
• Les RCU et WCU avec leurs arrondis, on-demand face au provisionné, la burst et l'adaptive capacity, et les deux caches de DAX

Pourquoi c'est important

Les questions de ce sujet sont presque toutes des questions de diagnostic. Une table throttle alors qu'il lui reste de la capacité, une page personnalisée est servie au mauvais visiteur, un cluster Aurora refuse de faire un scale out avec deux readers cloués à 90 %, un cluster Valkey semble tranquille à 46 % de CPU. Chacun de ces symptômes a une explication précise et une seule bonne action, et les distracteurs de l'examen proposent la bonne action appliquée à la mauvaise couche.

En exploitation, ce sont aussi les décisions les plus chères à reprendre après coup. Un TTL trop long expose des données périmées, un mode de capacité mal choisi double la facture, et une partition key mal dessinée ne se corrige pas en achetant du débit.