Pourquoi la performance s'effondre après une migration vers AWS
Après une migration vers AWS, il est courant qu'une application performe moins bien qu'attendu, même si l'infrastructure semble correctement configurée en théorie. Ce phénomène découle rarement d'une panne unique mais plutôt d'une combinaison de facteurs souvent négligés durant la phase de transition. En first place, beaucoup de projets de migration conservent le dimensionnement de l'environnement source sans l'adapter aux capacités réelles du cloud. Une base de données qui tournait sur un serveur physique avec 256 GB de RAM bénéficiait de caches de système d'exploitation et de comportements réseau prévisibles. Dès qu'elle s'exécute sur une instance AWS (même sur du bare metal), les latences de réseau, la contention de ressources partagées et l'absence de préchauffage des caches créent des goulots d'étranglement inattendus. Deuxièmement, les architectures héritées conçues pour des data centers centralisés ne tirent pas parti de la distribution géographique et des capacités natives d'AWS. Une application qui émet 500 requêtes réseau par requête utilisateur sur-site, parce qu'elle dialoguait via des bus privés très rapides, devient soudain vulnérable aux latences inter-services en cloud. Enfin, pendant la migration, l'énergie se concentre sur la continuité de service et la validation fonctionnelle, pas sur le tuning de performance. Les configurations par défaut d'AWS (connexions pooled, timeouts, cache TTL) ne correspondent presque jamais aux profils de charge réels. Comprendre cette transition exige une analyse méthodique plutôt que des ajustements au hasard.
Identifier les véritables goulots d'étranglement de performance
Avant de modifier quoi que ce soit, il faut établir un diagnostic précis. La plupart des équipes se demandent « pourquoi c'est lent ? » sans savoir où investiguer. La réponse réside dans quatre axes d'observation : CPU, mémoire, réseau et disque. Pour le CPU, CloudWatch Metrics fournit les données brutes (CPU utilization, CPU credit balance si vous utilisez des instances T3), mais elles ne suffisent pas. Une instance avec 25% d'utilisation CPU moyenne peut être complètement bouchée si ce 25% se concentre sur un seul cœur. Utilisez AWS Systems Manager Session Manager pour accéder aux instances et lancer des outils comme top, htop ou, mieux, perf ou flamegraph pour identifier les fonctions qui consomment le plus de CPU. Pour la mémoire, CloudWatch ne remonte pas la métrique de pression mémoire native du système d'exploitation. Installez CloudWatch Agent avec la configuration Custom Metrics et envoyez mem_available, mem_used_percent et swap_usage. Des pics de pressure sans augmentation visible du CPU indiquent une fuite mémoire applicative ou une concurrence excessive de processus. Le réseau est souvent le coupable oublié. Vérifiez dans CloudWatch EC2 metrics les packets perdu (PacketsIn/Out, NetworkPacketsIn/Out) et le Network throughput réel. Utilisez iftop ou nethogs pour tracer la provenance des connexions réseau. Une application qui ouvre une nouvelle connexion TCP pour chaque requête (au lieu de réutiliser un connection pool) peut suffoquer le réseau, surtout entre zones de disponibilité. Enfin, pour le disque, EBS CloudWatch metrics (VolumeReadBytes, VolumeWriteLatency, VolumeQueueLength) révèlent si le stockage devient un goulot. Si la latence d'écriture EBS dépasse 100ms régulièrement, ou si la queue s'accumule, le disque est saturé. Certains cas réclament une profonde analyse applicative. Si votre application est multilingue, utilisez X-Ray pour tracer la latence par service, identifiant ainsi les étapes qui prennent anormalement longtemps (appel réseau bloquant, requête base de données inefficace, ou logique métier inefficace). Une analyse sans biais suppose de consulter les logs applicatives (via CloudWatch Logs ou un agrégateur tiers) pour repérer les erreurs cachées, les retries ou les timeout qui ralentissent en cascade.
Dimensionnement compute et sélection d'instance optimale
Une fois les goulots identifiés, l'étape suivante est d'ajuster le compute. En entreprise, trois erreurs courantes sabotent cette phase. D'abord, augmenter la taille d'instance n'est jamais la seule solution, mais c'est souvent la première tentée. Si une application CPU-bound consomme 80% des ressources d'une t3.xlarge, passer à une t3.2xlarge doublera temporairement la capacité mais n'adressera pas la racine : pourquoi l'algorithme est-il inefficace ? Deuxièmement, confondre instances stateless et stateful crée des désastres au scaling. Une base de données avec état en mémoire ne peut pas simplement passer à un auto-scaling group; chaque instance perd ses données. Troisièmement, ignorer les réductions AWS (Reserved Instances, Savings Plans) mène à des coûts injustifiés après optimisation. Pour dimensionner correctement, suivez cette démarche : mesurez la charge réelle avec du profiling applicatif (Apache JMeter pour les web apps, sysbench pour les bases de données, ou des traces X-Ray pour les services distribuées). Détermine le nombre de requêtes par seconde, la latence cible et le pourcentage de CPU/mémoire que votre application peut consommer sans dégradation. Ensuite, mappiez ces besoins à une famille d'instances AWS. Si votre charge est CPU-intensive, les instances c6i ou c7g (compute-optimized) offrent le meilleur rapport. Si elle est RAM-intensive (cache en mémoire, data warehousing), préférez les r6i ou r7g (memory-optimized). Pour les workloads très parallèles avec accès réseau fréquent, les instances d6i ou m6i (general purpose) sont polyvalentes. Ne vous arrêtez pas à la génération. Les dernières générations (c7, m7, r7) consomment moins d'énergie, offrent des processeurs plus rapides et réduisent les coûts. Comparez toujours le coût annuel total (TCO) sur une feuille de calcul : une c7i.2xlarge plus chère initialement peut coûter moins cher qu'une c6i.4xlarge sur un an si elle réduit la scalabilité nécessaire. Enfin, testez votre candidat sur une instance unique en charge réelle (pas synthétique) pendant au moins une heure. Observez CPU, mémoire, réseau et latence applicative. Si les métriques restent dans les marges acceptables et l'application répond dans les SLA, vous avez votre réponse. Si les pics de charge font décoller une métrique au-delà des seuils, essayez la taille supérieure ou investiguer un vrai problème d'architecture applicative.
Optimisation de la configuration réseau et latence inter-services
Le réseau est l'une des sources de ralentissement les plus sous-estimées après migration. Les équipes provisionnent souvent des instances dans une seule zone de disponibilité (AZ) pour simplifier, sans réaliser que cela crée un point unique de défaillance et une latence accrue si le trafic doit traverser un routeur spinal. Un diagnostic du réseau commence par vérifier la topologie VPC. Utilisez VPC Flow Logs (CloudWatch) pour observer les patterns de connexion. Si 90% du trafic sort du VPC vers Internet Gateway, alors revient en NAT (pattern inefficace), reconsidérez votre design. La configuration du Security Group mérite attention : des règles trop permissives ralentissent le firewall applicatif ; des règles trop restrictives font rejeter des requêtes légitimes. Validez que tous les flux attendus (bases de données, caches, services internes) sont autorisés avec les CIDR ou security groups corrects. Pour les applications distribuées, réduire la latence inter-services est critique. Si votre application frontend appelle via Internet un service backend, vous traversez Internet Gateway, puis reveniez en via NAT. La bonne pratique est le placement dans la même AZ ou VPC (même région de préférence) avec des security groups qui s'autorisent mutuellement, plutôt qu'en passant par IP publique. Utilisez AWS Systems Manager VPC Endpoints pour les services AWS (S3, DynamoDB, CloudWatch) afin d'éviter Internet Gateway. Un endpoint VPC pour S3 réduit la latence de 50-100ms (aller-retour) dans les cas typiques. Pour les services tiers (APIs externes), si possible, mettez en cache les réponses localement ou utilisez un CDN (CloudFront pour AWS) plutôt que d'appeler le service externe sur chaque requête utilisateur. La taille MTU (Maximum Transmission Unit) des paquets réseau affecte aussi la bande passante efficace. Par défaut, AWS utilise 1500 bytes (MTU standard internet), mais les instances dans le même VPC peuvent utiliser Jumbo Frames (MTU 9000) pour réduire le nombre de paquets et augmenter le throughput. Si votre application fait de gros transferts (replication base de données, backup), testez cette configuration. Enfin, Enhanced Networking (type EN, ex : Intel 82599 ou ENA) double ou triple le throughput réseau comparé au virtuel réseau standard. Assurez-vous que votre type d'instance supporte ENA et activez-le via les attributs réseau de l'instance.
Ajustement des caches et allocation mémoire pour réduire les appels base de données
Après migration, les patterns d'accès aux données changent. En environnement physique, les data centers centralisés offrent des latences de disque très prévisibles (sous 10ms pour SSD local). En cloud, les données stockées sur EBS vivent sur un réseau virtualisé, ce qui ajoute 5-20ms de latence supplémentaire selon la configuration et la contention. Cette latence se multiplie à chaque requête base de données. Si une application lance 50 requêtes pour afficher une page, et que chaque requête prend 20ms (10ms réseau + 10ms disque), la page prend au minimum 1 seconde à charger, avant même de compter le temps applicatif. La solution classique est le caching. ElastiCache (Redis ou Memcached) peut réduire cette latence à 1-5ms pour une lecture cache hit. Redis est préféré pour les données complexes (structures, classements), Memcached pour le simple key-value très haute performance. Dimensionnez votre cluster cache en fonction du working set réel, c'est-à-dire la fraction des données accédées régulièrement. Si votre base de données est 100GB mais seuls 10GB sont demandés par heure, un cache Redis de 15GB (avec 50% headroom) suffit. Mesurez le hit rate : si moins de 80% des requêtes cache hit, augmentez la taille ou revoyez votre stratégie d'invalidation. Pour les bases de données elles-mêmes, le tuning des paramètres est critique. RDS offre des groupes de paramètres (parameter groups) qui contrôlent cache buffer, timeout de requête, parallelism, etc. Une RDS MySQL mal configurée avec un buffer_pool_size par défaut (128MB) sur une r5.2xlarge (512GB RAM) gaspille 95% de votre RAM. Augmentez le buffer pool à 80% de la RAM disponible et observez les hit ratios de cache (par exemple, InnoDB_Buffer_Pool_Reads vs InnoDB_Buffer_Pool_Read_Requests). Des ratios sous 95% indiquent que votre cache est surchargé. Enfin, la structure des requêtes importe. Une requête qui scanne une table entière et filtre en mémoire plutôt que d'utiliser un index adéquat consomme énormément de ressources. Passez du temps à analyser les requêtes lentes (via Performance Insights de RDS) et créez les index manquants. Souvent, indexer 2-3 colonnes clé réduit les temps de requête de 10x et diminue la charge CPU/RAM de la base de données proportionnellement.
Suivi et ajustement continu des SLA de performance
Optimiser une fois n'est jamais suffisant. Les patterns de charge changent, de nouvelles fonctionnalités ralentissent l'application, ou un colleague déploie un requête inefficace. Un processus de suivi continu avec des SLA clairs (Service Level Agreements) est donc indispensable. Définissez d'abord les SLA applicatifs concrets : pourcentage de requêtes web qui doivent répondre sous 200ms (p95), durée maximale d'une requête base de données critique (500ms), temps de réplication de données (RTO, Recovery Time Objective). Ces chiffres doivent être réalistes (pas 10ms si votre réseau a 50ms de latence) et partagés avec le business pour que tout le monde comprenne l'objectif. Ensuite, instrumentez votre application et infrastructure pour mesurer ces SLA. CloudWatch Synthetics crée des tests artificiels (canaries) qui simulent des utilisateurs réels et alertent si un SLA s'écarte. Pour les bases de données RDS, activez Performance Insights (inclus en RDS) et examinez les slow query logs (slow_query_log en MySQL, long_query_time threshold). Configurez des alarmes CloudWatch pour : CPU > 80%, mémoire > 85%, latence p99 > seuil SLA, packet loss > 0%, EBS queue length > 1. Ces alarmes doivent déclencher une action (email, SNS topic, ou appel au processus d'escalade). Établissez une routine hebdomadaire ou mensuelle (selon la cadence de change) pour revoir les métriques. Posez les questions : « Avons-nous atteint tous les SLA le mois dernier ? », « Quelles requêtes sont devenues lentes ? », « Quel code a été déployé qui explique un changement ? ». Si un SLA n'est pas atteint, cherchez la cause systématiquement (utiliser les logs d'application, X-Ray traces, ou profilers applicatifs) plutôt que de blâmer l'infrastructure. Enfin, planifiez les optimisations futures : si vous approchez 80% de capacité CPU, prévoir le scaling avant une crise. Si le coût de cache explose, investiguer pourquoi le working set grandit. Cette approche itérative et basée sur les données prévient les dégradations et maintient la performance à long terme.