Aller au contenu

AWS Mis à jour le 2026-07-04

Optimisation de la performance AWS : localiser le vrai goulot d'étranglement entre le calcul, la base de données et le réseau

L'optimisation de la performance AWS commence par trouver la contrainte réellement lente — crédits d'éclatement, limites EBS, une mauvaise requête ou des sauts inter-AZ — pas par tout redimensionner. Voici l'ordre de diagnostic.

La plupart des plaintes « AWS est lent » remontent à un seul goulot d’étranglement, pas à une lenteur générale — une instance à éclatement qui a épuisé ses crédits CPU, un volume EBS à son plafond d’IOPS, une requête sans index, ou un service bavard qui fait cinquante allers-retours inter-AZ par requête. L’optimisation de la performance AWS est donc un problème de diagnostic avant d’être un problème de réglage : mesurez le p95 à la bordure, répartissez le temps entre répartiteur de charge, application et base de données, et corrigez la plus grosse contrainte avant de toucher à quoi que ce soit d’autre. Redimensionner des instances sans cette mesure est la façon la plus chère de ne rien changer.

Ce qui se passe

Une requête traverse des couches distinctes — DNS et CDN, répartiteur de charge, calcul applicatif, palier de données, et les chemins réseau entre eux — et chaque couche a sa propre signature de panne et ses propres métriques. Si l’optimisation sans mesure échoue, c’est que ces signatures sont invisibles du point de vue de l’application. Trois mécaniques propres à AWS causent une grande part des cas réels :

Les instances à éclatement épuisent leurs crédits. Les instances de famille T (t3, t3a, t4g) gagnent des crédits CPU à un taux de base et les dépensent pour éclater. Quand CPUCreditBalance touche zéro en mode standard, l’instance est bridée à son niveau de base — 20 à 40 % du CPU pour les tailles courantes — et tout ce qu’elle héberge devient de la mélasse pendant que le graphique CPU affiche trompeusement une « utilisation élevée ». Le mode unlimited troque la falaise contre des frais supplémentaires.

Le stockage a des plafonds séparés du calcul. Les volumes gp3 portent des chiffres d’IOPS et de débit provisionnés indépendants de la taille; gp2 fait croître les IOPS avec la taille et donne aux petits volumes un réservoir d’éclatement dont le BurstBalance peut se vider en silence. Une instance a aussi sa propre limite de bande passante EBS selon sa taille : un volume rapide derrière une petite instance reste lent. Les détails sont dans la documentation EC2.

Le réseau facture et retarde selon la géométrie. Chaque saut inter-AZ ajoute de la latence et des frais de transfert; une requête qui s’éparpille vers des services dans d’autres AZ multiplie les deux. La passerelle NAT ajoute un saut de plus pour tout ce qui sort des sous-réseaux privés.

La base de données trône au-dessus des trois et ajoute ses classiques : index manquants, tempêtes de connexions et contention de verrous — visibles dans Performance Insights de RDS, pas dans les graphiques de CPU.

Quoi vérifier en premier

  • Le p95 de TargetResponseTime à l’ALB contre ce que l’application journalise à l’interne — l’écart entre les deux, c’est de la file d’attente et du réseau, pas du code.
  • CPUCreditBalance sur chaque instance de famille T dans le chemin de la requête. Zéro, c’est l’arme du crime.
  • BurstBalance sur les volumes gp2 et l’utilisation IOPS/débit sur gp3.
  • Le top SQL de Performance Insights sur RDS — une seule requête mange habituellement la moitié de la charge.
  • Si l’application et la base de données vivent dans les mêmes paires d’AZ, ou si le trafic zigzague entre les zones.

Comment vérifier

Partez de la bordure et avancez vers l’intérieur :

# Latence p95 au répartiteur de charge, 3 dernières heures
aws cloudwatch get-metric-statistics \
  --namespace AWS/ApplicationELB --metric-name TargetResponseTime \
  --dimensions Name=LoadBalancer,Value=app/prod-alb/50dc6c495c0c9188 \
  --start-time 2026-07-04T09:00:00Z --end-time 2026-07-04T12:00:00Z \
  --period 300 --extended-statistics p95

# Épuisement des crédits sur une instance suspecte
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUCreditBalance \
  --dimensions Name=InstanceId,Value=i-0abc123def456 \
  --start-time 2026-07-04T09:00:00Z --end-time 2026-07-04T12:00:00Z \
  --period 300 --statistics Minimum

# Réservoir d'éclatement d'un volume gp2
aws cloudwatch get-metric-statistics \
  --namespace AWS/EBS --metric-name BurstBalance \
  --dimensions Name=VolumeId,Value=vol-0abc123def456 \
  --start-time 2026-07-04T09:00:00Z --end-time 2026-07-04T12:00:00Z \
  --period 300 --statistics Minimum

Dans la console : EC2 > Instances > Monitoring pour les soldes de crédits, RDS > Databases > Monitoring et Performance Insights pour le palier de données, et l’onglet Monitoring du répartiteur pour le portrait latence et 5xx à la bordure.

Le plan d’exécution

  1. Fixer d’abord le chiffre de référence. Un seul p95 pour le point de terminaison principal, mesuré à l’ALB sur une fenêtre représentative. Chaque étape suivante est jugée contre lui; sans lui, vous devinez avec une carte de crédit.
  2. Répartir le temps. TargetResponseTime à l’ALB couvre application plus base de données; les journaux applicatifs ou un APM séparent les deux. Le segment qui détient la majorité du p95 est le seul qui mérite du travail cette semaine.
  3. Lever les bridages de calcul. Des soldes de crédits épuisés signifient passer en mode unlimited (en surveillant les frais) ou vers des familles m/c. Vérifiez aussi la pression mémoire — l’échange sur disque ressemble à de la latence mystérieuse, et CloudWatch n’affiche pas la mémoire sans l’agent installé.
  4. Lever les plafonds de stockage. Les volumes gp2 au BurstBalance qui s’affaisse migrent vers gp3 avec des IOPS explicites — souvent moins cher et strictement plus rapide. Confirmez que la limite de bande passante EBS de l’instance elle-même n’est pas le vrai plafond avant de payer des IOPS de volume.
  5. Travailler la base de données de haut en bas. Performance Insights, top SQL par charge, puis le trio standard : indexer la pire requête, mutualiser les connexions (RDS Proxy si l’application les recycle mal), et seulement ensuite considérer la classe d’instance. Le travail au niveau des paramètres est couvert dans le réglage des groupes de paramètres RDS.
  6. Redresser le chemin réseau. Gardez l’éventail de chaque requête dans une seule AZ quand l’architecture le permet, placez S3 et DynamoDB derrière des points de terminaison de passerelle VPC plutôt que la NAT, et mettez en cache les lectures que Performance Insights montre comme répétées.
  7. Re-mesurer et redimensionner. Ce n’est qu’après le déplacement du goulot que les décisions de taille veulent dire quelque chose. Les recommandations de redimensionnement de Compute Optimizer sont la façon disciplinée de fermer la boucle — y compris réduire ce que l’étape 3 a prouvé surdimensionné.

Quand c’est la mauvaise approche

Si le p95 est correct et qu’un seul client sur un seul continent est lent, c’est une conversation de CDN et de géographie, pas une chasse d’infrastructure. Si la latence ne grimpe qu’au moment des déploiements, regardez la stratégie de déploiement et le drainage des connexions, pas la capacité en régime permanent. Et si l’application fait 200 requêtes de base de données par page, aucun réglage AWS ne rattrape ça — le correctif est dans le code, et prétendre le contraire ne fait qu’acheter une plus grosse instance pour exécuter le même gaspillage plus vite.

Erreurs fréquentes

  • Redimensionner l’instance en premier parce que c’est le bouton le plus facile — masquer la vraie contrainte pendant un mois au double du coût.
  • Se fier aux graphiques de CPU sur les instances à éclatement : 100 % de CPU bridé au niveau de base et 100 % de CPU sous vraie charge sont identiques à l’œil, sauf si on vérifie les crédits.
  • Ignorer le plafond de bande passante EBS de l’instance et payer des IOPS provisionnés qu’elle ne peut physiquement pas consommer.
  • Étalonner contre l’environnement de test, qui a d’autres types d’instances, des caches vides et le dixième des données.

Prévention

  • Alerter sur les indicateurs avancés : minimum de CPUCreditBalance, BurstBalance, DatabaseConnections de RDS et latence p95 — pas seulement des moyennes.
  • Consigner le p95 de référence par point de terminaison après chaque version significative, pour que les régressions soient attribuées à un changement au lieu d’être découvertes en légende orale.
  • Tester en charge avant les événements de trafic, avec des volumes de données à l’échelle de la production.
  • Réviser le dimensionnement chaque trimestre dans les deux sens; les flottes surdimensionnées cachent les goulots et brûlent le budget avec le même enthousiasme.

Le motif derrière tout ça : mesurer à la bordure, répartir le temps, corriger la contrainte unique, re-mesurer. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.