La bombe à retardement de six mois : quand EFS a épuisé ses crédits de burst

Pendant près de six mois, tout semblait fonctionner parfaitement. C’est justement ce long calme qui était dangereux.

Une application Web utilisait Amazon Elastic File System (EFS) comme stockage partagé. Plusieurs instances pouvaient accéder aux mêmes fichiers, le déploiement était simple et rien n’incitait à remettre l’architecture en question.

Puis, apparemment sans prévenir, le site est devenu extrêmement lent, jusqu’à sembler complètement bloqué. La charge système était anormalement élevée, les requêtes expiraient et les processus applicatifs s’accumulaient.

À première vue, on aurait dit un manque de puissance de calcul. Ce n’était pas le cas. Le véritable problème était l’épuisement des crédits de burst EFS.

Pourquoi cela ressemblait à un problème de processeur

L’un des symptômes trompeurs était la forte charge moyenne Linux. Une charge élevée ne signifie pas forcément que les processeurs sont saturés. Elle inclut aussi les processus en attente non interruptible, souvent bloqués sur les entrées-sorties du stockage.

Les workers attendaient la fin des opérations EFS. De nouvelles requêtes continuaient d’arriver, d’autres workers se bloquaient et la file d’attente grossissait :

1. Le débit EFS était limité.
2. Les opérations sur les fichiers prenaient plus de temps.
3. Les workers restaient occupés à attendre les E/S.
4. Les requêtes entrantes s’accumulaient.
5. La charge système augmentait.
6. Le site finissait par devenir pratiquement indisponible.

Ajouter des processeurs n’aurait pas résolu le problème de fond.

Pourquoi la panne a mis six mois à se manifester

Le système de fichiers EFS utilisait le mode Bursting Throughput . Dans ce mode, le débit de référence soutenable dépend du volume stocké dans la classe EFS Standard. Lorsque la charge reste sous ce seuil, les crédits s’accumulent. Au-dessus, ils sont consommés.

Cela peut donner une image trompeuse sur les petits systèmes de fichiers :

• Un faible volume stocké donne un débit de référence soutenable peu élevé.
• Le solde de crédits autorise temporairement un débit bien supérieur.
• L’application fonctionne normalement, alors que sa charge durable dépasse le débit de référence.
• Le déséquilibre reste invisible tant qu’il reste des crédits.
• Quand le solde atteint zéro, les performances chutent brutalement.

Dans ce cas, les crédits accumulés ont tenu environ six mois. L’architecture était déjà sous-dimensionnée en débit, mais le solde masquait le problème. C’était un défaut de capacité qui progressait lentement : une bombe à retardement de six mois.

Il ne faut jamais confondre une performance de burst temporaire avec un débit durablement disponible.

Choisir le bon mode de débit EFS

Bursting Throughput

Bursting Throughput peut convenir lorsque le débit augmente naturellement avec le volume stocké et que les périodes actives alternent avec des périodes calmes. Une surveillance attentive reste indispensable. Un solde en baisse continue révèle une charge que ce mode ne peut pas soutenir.

Elastic Throughput

Elastic Throughput convient généralement mieux aux charges imprévisibles ou très variables. Le débit suit automatiquement la demande, sans dépendre d’une réserve finie de crédits. Cela améliore la résilience opérationnelle, mais son coût à l’usage mérite d’être étudié pour un débit durablement élevé.

Provisioned Throughput

Provisioned Throughput est utile quand le débit nécessaire est connu et dépasse ce que le volume stocké permettrait. La capacité est prévisible, indépendamment de la taille du système de fichiers, mais il faut revoir le niveau configuré lorsque la demande change.

Il faut aussi distinguer le mode de débit du mode de performanceEFS. Le premier détermine comment la capacité de débit est fournie ; le second concerne notamment la latence et le parallélisme.

La supervision qui aurait dû être en place

La métrique CloudWatch essentielle pour un système EFS en mode Bursting Throughput est BurstCreditBalance. Une supervision utile doit aussi suivre :

• BurstCreditBalance pour détecter une consommation durable des crédits
• PercentIOLimit pour voir si le système de fichiers approche sa limite d’E/S
• PermittedThroughput pour connaître le débit actuellement disponible
• MeteredIOBytes et les TotalIOBytes pour observer la consommation d’E/S
• la latence applicative, la durée des requêtes, les délais dépassés et les taux d’erreur
• les processus en attente d’E/S, en les rapprochant de la charge et de l’utilisation réelle du processeur

Surveiller uniquement le processeur, la mémoire et les codes HTTP ne suffit pas. Le stockage partagé est une dépendance critique de l’application : il doit être supervisé comme une composante du service, pas seulement comme un élément d’infrastructure.

Une alarme doit se déclencher bien avant l’épuisement des crédits. Surtout, il faut examiner la tendance. Un solde qui diminue régulièrement pendant plusieurs semaines révèle déjà un déficit structurel de débit, même si sa valeur absolue semble encore confortable.

Ce que je ferais autrement

1. Estimer le débit soutenable dès la conception.
2. Choisir le mode de débit d’après le profil d’accès réel.
3. Considérer les crédits comme une marge temporaire, pas comme la capacité normale.
4. Créer des alarmes CloudWatch sur le solde et les limites d’E/S.
5. Suivre la vitesse de consommation des crédits.
6. Inclure le débit et la latence EFS dans les tests de charge.
7. Corréler la charge Linux avec l’utilisation du processeur et l’attente d’E/S.
8. Se demander si les fichiers fréquemment utilisés nécessitent vraiment un stockage réseau partagé.
9. Tester l’application lorsque le stockage est bridé ou que sa latence augmente.
10. Documenter la procédure de changement de mode de débit.

Ce qu’il faut retenir

EFS peut être une excellente solution de stockage partagé, mais son comportement dépend fortement du mode de débit choisi et du profil de charge.

Le danger de cet incident n’était pas seulement la dégradation des performances. C’était le bon fonctionnement apparent pendant six mois avant cette dégradation. Le solde de crédits a retardé le problème visible assez longtemps pour inspirer confiance dans une architecture non soutenable.

La meilleure protection n’est pas une réserve de crédits plus importante. C’est le bon mode de débit, une compréhension du débit soutenable et des métriques qui révèlent un déséquilibre croissant avant que les utilisateurs n’en subissent les effets.

Références

• Documentation des performances Amazon EFS
• Métriques CloudWatch d’Amazon EFS