cloud / systèmes
Un problème Amazon EFS peut exister longtemps avant de se voir. Un petit système de fichiers peut tenir des semaines ou des mois tout en puisant dans une réserve finie de crédits. L’application semble saine, les tableaux restent au vert et la confiance s’installe. Puis la réserve atteint zéro et la même charge rencontre un plafond soutenable bien plus bas.
Ce décalage donne une impression de panne soudaine. En exploitation, elle ne l’est pas du tout.
Le décalage caché
Avec Bursting Throughput, le débit de référence augmente avec le volume stocké dans EFS Standard. AWS documente 50 Kio/s par Gio, avec au moins 1 Mio/s de débit comptabilisé pour chaque système de fichiers. Une activité sous le débit de référence gagne des crédits ; au-dessus, elle en consomme.
Le cas dangereux est une moyenne durable légèrement supérieure au débit de référence. Les crédits accumulés paient la différence et évitent l’incident immédiat, mais le solde diminue chaque jour.
Pourquoi les symptômes orientent mal le diagnostic
Quand le stockage ralentit, les workers attendent. Sous Linux, les processus bloqués en attente d’E/S non interruptible contribuent à la charge moyenne. Le stockage peut donc sembler être un problème de calcul : files d’attente, workers saturés et délais dépassés, même lorsque le processeur n’est pas la cause.
Ajouter des instances peut aggraver la situation si chaque nouveau worker sollicite le même stockage partagé limité. Le goulot est commun, et la concurrence supplémentaire accroît la pression.
Pourquoi six mois sans panne prouvent peu de chose
Une longue période sans incident ne valide que la combinaison de demande, de débit de référence et de crédits disponibles pendant cette période. Elle ne garantit pas la tenue une fois les crédits épuisés. Un solde BurstCreditBalance en baisse n’est donc pas un simple détail de capacité : c’est un signal précoce de fiabilité.
Les tests doivent couvrir le régime permanent, pas seulement un pic bref. Dix minutes peuvent montrer que le plafond de burst suffit, sans rien dire d’un déficit qui s’accumule sur des milliers d’heures.
Une meilleure démarche de diagnostic
- Comparer l’utilisation du processeur, la charge moyenne et l’attente d’E/S.
- Examiner la métrique EFS
BurstCreditBalancesur plusieurs semaines ou mois. - Comparer
MeteredIOBytesavecPermittedThroughput. - Corréler les contraintes de stockage avec la latence applicative et la saturation des workers.
- Vérifier le volume réellement stocké en classe Standard, qui détermine le débit de référence du mode Bursting.
- Décider si la charge relève de Bursting, Elastic ou Provisioned Throughput.
L’enseignement technique
Le burst est un tampon, pas un plan de capacité. Pour tout service à crédits, regardez le sens et la vitesse d’évolution du solde, pas seulement sa présence au-dessus de zéro. L’article précédent raconte l’incident réel ; le suivant traduit cet enseignement en supervision CloudWatch concrète.