Une entreprise exécute un logiciel d'analyse sur des instances Amazon EC2 qui traitent des tâches pour des données téléchargées sur Amazon S3. Les utilisateurs signalent que certaines données soumises ne sont pas traitées. Amazon CloudWatch indique que l'utilisation du CPU des instances EC2 est constamment à 100 % ou presque. L'entreprise souhaite améliorer les performances et la mise à l'échelle en fonction de la charge utilisateur. Que doit faire un architecte de solutions ?

La solution correcte consiste à utiliser Amazon SQS et un groupe Auto Scaling basé sur la taille de la file d'attente. Lorsque les requêtes entrantes sont acheminées vers SQS, elles sont mises en file d'attente, ce qui découple la réception des tâches de leur traitement. Le groupe Auto Scaling peut alors ajuster dynamiquement le nombre d'instances EC2 en fonction du nombre de messages dans la file d'attente SQS. Cela garantit que les ressources de calcul sont mises à l'échelle en fonction de la charge, évitant ainsi la saturation du CPU et le non-traitement des données. Les autres options sont moins efficaces : Copier l'instance et utiliser un ALB n'améliore pas la mise à l'échelle dynamique en fonction de la charge de traitement et ne résout pas le problème de saturation du CPU si la charge augmente. Un point de terminaison S3 VPC améliore la connectivité privée à S3 mais n'a aucun impact direct sur la saturation du CPU des instances EC2 ou sur la mise à l'échelle du traitement. Modifier le type d'instance pour un CPU plus puissant est une solution ponctuelle qui ne résout pas le problème de la mise à l'échelle dynamique et peut entraîner des coûts inutiles si la charge diminue.