Pourquoi mesurer les performances en production AWS après migration
Après une migration d'infrastructure vers AWS, les performances observées en environnement de test ou staging diffèrent souvent des conditions réelles de production. Les vrais utilisateurs, le trafic imprévisible, la charge distribution géographique et les patterns d'accès réels créent des scénarios que aucun test pré-migration ne peut reproduire entièrement. Mesurer les performances en production AWS n'est donc pas facultatif : c'est la seule façon de valider que votre migration n'a pas introduit de régressions cachées, que les services externalisés répondent aux attentes métier, et que l'architecture déployée supporte réellement la charge sans dégradation. Cette étape, souvent négligée par empressement de clôturer le projet, évite des découvertes désagréables trois mois après le go-live, quand la charge augmente ou qu'un pic saisonnier révèle un goulot d'étranglement imperceptible en conditions normales. C'est aussi en production que vous pouvez mesurer l'impact financier réel de votre migration : une latence réduite de 200 ms à 50 ms n'est utile que si elle se traduit par une meilleure conversion client ou une satisfaction utilisateur observée. Enfin, ces mesures de production deviennent les baselines de référence contre lesquelles vous comparerez tous les futurs changements, alertes et optimisations.
Définir les métriques clés à mesurer en production AWS
Mesurer les performances en production AWS exige de focaliser sur les bonnes métriques, celles qui reflètent vraiment l'expérience utilisateur et la santé du système. Les trois piliers sont la latence, le débit et la charge. La latence se décline en plusieurs niveaux : le temps de réponse end-to-end perçu par l'utilisateur final, la latence du backend (API, base de données, calcul), et la latence réseau (notamment vers le front, CDN inclus). En production, vous mesurez généralement le P50 (médiane), le P95 et le P99 pour détecter les comportements de queue, car une moyenne seule masque les pics qui frustreront 1 % de vos utilisateurs. Le débit, ou throughput, est le nombre de requêtes traitées par seconde (RPS) ou d'opérations complétées par minute selon votre domaine : il doit être mesuré globalement et par point de terminaison critique. La charge CPU, mémoire et I/O disque sur vos instances EC2 ou conteneurs ECS indiquent votre capacité de réserve : une utilisation moyenne de 70 % en charge nominale signifie que vous avez 30 % d'amortisseur avant saturation, ce qui est généralement sain. Ajoutez aussi le taux d'erreur (4xx, 5xx) et la disponibilité observée (uptime réel pendant la semaine de mesure), car une latence basse n'a aucune valeur si le service tombe. Pour les données, mesurez la latence de lecture et écriture en base de données, la capacité de la base (IOPS, connexions actives) et la taille réelle des données, qui validera votre dimensionnement AWS. Ces métriques doivent être collectées continuellement durant au moins une à deux semaines de production réelle, pour capturer un cycle complet d'activité et au moins un pic.
Outils et services AWS pour capturer les performances en production
AWS fournit plusieurs services natifs pour mesurer les performances sans ajouter de surcharge significative. CloudWatch est le socle : ses métriques standard (CPU, mémoire, I/O disque, trafic réseau) sont gratuites et collectées automatiquement pour EC2, RDS, ECS, ALB et presque tous les services AWS. Créez des dashboards personnalisés dans CloudWatch pour afficher latence, débit et erreurs côte à côte. CloudWatch Logs Insights permet de requêter les logs d'application pour extraire des statistiques de performance : filtrez les requêtes de votre API, calculez les percentiles de latence, agrégez par endpoint ou par utilisateur. C'est utile quand vous avez des logs structurés (JSON). X-Ray, le service de tracing distribué d'AWS, capture les appels entre vos services (EC2, Lambda, RDS, tiers externes) et calcule automatiquement les latences en cascade, révélant quel composant ralentit : très puissant pour déboguer une latence inattendue, mais demande une instrumentation du code (SDK X-Ray) et génère des coûts marginaux. Pour les applications web et API, activez les métrques fines de votre Application Load Balancer (ALB) dans CloudWatch : vous verrez la latence côté target, le nombre de nouvelles connexions, les réinitialisations de connexion. Si vous avez une RDS, activez Enhanced Monitoring pour accéder à des métriques du système d'exploitation dans la base : I/O, locks, transactions par seconde. Enfin, intégrez des tests synthétiques (CloudWatch Synthetic Canaries) : ces petits scripts simulent des transactions réelles à intervalle régulier et alertent si elles échouent ou ralentissent, complétant votre vision en production réelle. La plupart de ces services ont un coût négligeable ou sont inclus dans votre réserve d'utilisation AWS.
Conduire un test de charge réaliste avant d'affirmer que tout va bien
Les métriques passives collectées en production vous montrent l'état actuel, mais elles ne vous disent pas ce qui se passe lors du pic de charge suivant ou lors d'une épidémie virale de votre application. C'est pourquoi, durant les premiers jours suivant la migration, avant de considérer le projet clôturé, vous devez simuler une charge qui reproduit votre utilisation métier réelle : non pas un test générique, mais un test basé sur les patterns réels que vous avez observés sur votre ancien système ou que vous projetez pour les mois à venir. Procédez par étapes : commencez par 20 % de votre charge de pointe estimée, observez les métriques pendant 10 à 15 minutes, puis montez à 40 %, puis 60 %, jusqu'à atteindre 100 % ou dépasser légèrement pour identifier votre point de rupture. Un test charge brutale à 100 % sans montée en puissance risque de causer des timeouts et des cascades d'erreurs qui masquent les vrais goulots. Utilisez un outil comme JMeter (gratuit, open-source, configuré pour votre API) ou Locust (Python-based) pour générer la charge depuis un ou plusieurs points externes, de préférence depuis une région AWS proche de votre infrastructure pour réduire la latence réseau du test lui-même. Ne générez jamais une charge de test depuis votre propre datacenter si vous avez migré en cloud, car la latence WAN biaiserait vos mesures. Durant le test, observez non seulement la latence et le débit, mais aussi l'auto-scaling : vos groupes Auto Scaling EC2 ou vos réplicas ECS montent-ils comme prévu? Y a-t-il des délais de démarrage d'instance qui dégradent transitoirement le service? Les connexions de base de données explosent-elles ou restent-elles sous contrôle? Un résultat typique : vous constatez que votre latence P99 reste sous 500 ms jusqu'à 80 % de charge, puis grimpe à 2 secondes au-delà. C'est votre seuil d'alerte réel, plus utile qu'une hypothèse théorique. Si ces tests révèlent une capacité insuffisante, notez-le immédiatement et ajustez vos instances ou votre architecture avant de déclarer le projet succès.
Établir les seuils d'alerte basés sur les observations réelles
Une fois que vous avez mesuré votre production réelle durant au least une semaine, et que vous avez conduit au moins un test de charge contrôlé, vous avez assez de données pour définir les seuils d'alerte significatifs. Ne copier pas des thresholds génériques trouvés sur Internet (« ALB latency > 200 ms = alerte rouge ») : votre métier a ses propres exigences. Si votre application est une API back-office pour des opérateurs internes, une latence de 1 seconde n'est peut-être acceptable; si c'est un site e-commerce où chaque centième de seconde d'amélioration augmente la conversion, vous voudrez une alerte à 300 ms. Les seuils d'alerte doivent être définis en trois niveaux : avertissement (yellow), critique (red), et catastrophe (pages). Pour la latence, fixez votre seuil d'avertissement au P95 observé en charge nominale (pas le P50, qui est généralement stable), et critique à votre P99 + 20 %. Pour le débit, avertissement = 85 % de votre capacité maximale démontrée, critique = 95 %. Pour l'utilisation CPU, 70 % d'avertissement et 85 % de critique laisse un amortisseur avant que l'auto-scaling ne rattrape. Pour le taux d'erreur, tout ce qui est supérieur à 0,5 % doit générer une alerte, car même une dégradation légère suggère un problème à investiguer. N'oubliez pas les alertes de business logic : la latence de l'API est peut-être normale, mais si votre base de données s'arrête de synchroniser, c'est un désastre silent. Documentez chaque seuil avec sa justification (« P95 latence en charge nominale + 20 % pour les variations quotidiennes »), car vous devrez l'expliquer à votre équipe et l'ajuster régulièrement à mesure que votre trafic croît. Enfin, testez vos alertes : déclenchez-les manuellement, vérifiez qu'elles arrivent aux bons canaux (Slack, PagerDuty, e-mail), et que votre équipe sait comment les interpréter. Une alerte qui génère trop de faux positifs sera désactivée par frustration, donc mieux vaut quelques alertes pertinentes que beaucoup de bruit.
Documenter et partager les résultats de performance pour l'équipe et les stakeholders
Les mesures de performance que vous avez collectées ne servent que si elles sont documentées clairement et accessibles à votre équipe en permanence. Créez un document de rapport de baseline de performance qui consolidate les résultats observés : latence P50/P95/P99 par endpoint ou service, débit maximal soutenu avant dégradation, utilisation des ressources en charge nominale et en pic, capacité de la base de données (connexions actives maximales, taille réelle), taux d'erreur observé en conditions normales, et uptime mesuré sur la semaine d'observation. Ce rapport doit inclure la date de mesure, la durée, les conditions (trafic réel vs test de charge, région, utilisateurs actifs estimés), et surtout les hypothèses et limites : « Ces chiffres reflètent une charge de 500 RPS simultanés; nous n'avons pas testé au-delà, donc nous ne savons pas comment l'infra se comporte à 1000 RPS ». Joignez des captures de vos dashboards CloudWatch et les courbes de vos tests de charge, car une image vaut mille chiffres. Partagez ce rapport avec la DSI, le CTO et l'équipe de développement, et utilisez-le comme point d'ancrage pour justifier les investissements futurs en scalabilité. Pour les stakeholders non-techniques (direction, métier), résumez en trois points : « La migration est réussie; les utilisateurs voient une latence réduite de 45 %, et le système supporte 3x sa charge actuelle avant saturation. Voici le plan de monitoring pour qu'on détecte tout problème avant que ça n'impacte les clients ». Enfin, cette baseline devient le gold standard pour les tests de régression futurs : chaque changement d'architecture, chaque déploiement majeur, doit être validé contre ces chiffres pour s'assurer qu'il n'introduit pas de régression silencieuse.