Une application utilise un cluster Aurora MySQL avec un seul réplica en lecture. Les performances en lecture se dégradent lorsque les connexions dépassent 200 ; la charge normale est d'environ 180 connexions, mais elle dépasse parfois 200. L'administrateur a besoin que le système s'adapte automatiquement à la hausse et à la baisse des connexions utilisateur. Quelle approche répond à cette exigence ?

La création d'une politique de mise à l'échelle automatique qui cible une valeur de métrique DatabaseConnections de 195 est la solution la plus appropriée. Cela permet au cluster Aurora d'ajouter ou de supprimer automatiquement des réplicas en lecture en fonction de la charge de connexion, garantissant ainsi que les performances de lecture restent optimales même lors des pics. La valeur de 195 est choisie pour déclencher la mise à l'échelle avant que les performances ne se dégradent à 200 connexions. Augmenter la taille de l'instance du réplica existant pourrait améliorer les performances, mais ne résoudrait pas le problème de l'élasticité et pourrait être surdimensionné pendant les périodes de faible charge. Basculer en mode serverless n'est pas une option pour un cluster Aurora existant avec des réplicas en lecture et n'est pas conçu pour une commutation dynamique basée sur les connexions. Migrer vers un cluster avec plusieurs instances d'écriture n'est pas pertinent pour améliorer les performances en lecture et complexifierait inutilement l'architecture.