Un cluster Aurora MySQL de production est un nœud d'écriture unique et est fortement sollicité pour le reporting. Le cluster souffre de problèmes de performance intermittents dus à une utilisation élevée du CPU et à l'atteinte du nombre maximal de connexions. Un administrateur SysOps doit stabiliser les performances. Quelle solution répondra à cette exigence ?

La création d'un réplica Aurora et la configuration d'une politique de mise à l'échelle automatique pour les réplicas en fonction de l'utilisation du CPU, avec redirection des requêtes de reporting vers le point de terminaison en lecture seule, est la solution la plus efficace. Les réplicas Aurora sont conçus pour la lecture et ne consomment pas de ressources du nœud d'écriture principal, ce qui réduit la charge CPU et les problèmes de connexion sur le nœud d'écriture. La mise à l'échelle automatique assure une capacité adéquate pendant les pics de charge. Provisionner un second cluster ne résout pas le problème de charge sur le cluster principal et est plus coûteux. Une fonction Lambda de mise en cache ou un cluster ElastiCache pourraient améliorer les performances de reporting, mais ne résolvent pas directement les problèmes de CPU et de connexions maximales sur la base de données Aurora elle-même, et nécessitent une refonte de l'application.