Image de dennizn sur Shutterstock
L'un de nos clients a récemment rencontré un problème sur son bucket S3 lors du transfert d'objets du stockage Standard vers Glacier Deep Archive : malgré le déplacement, les objets continuaient d'apparaître dans le stockage Standard.
En examinant le bucket S3 du client, j'ai effectivement constaté que le stockage Standard n'avait pas baissé par rapport à sa taille initiale de 4,9 To. C'est ce que montre l'image ci-dessous, extraite de la métrique de stockage du bucket.
Métrique S3 Total Bucket Size
La métrique S3 Total Bucket Size indique 4,9 To pour le stockage Standard, représenté par la ligne orange. Le client avait lancé le transfert vers Glacier Deep Archive le 6 mai, mais au 10 mai la métrique ne reflétait toujours pas ce changement.
Métrique S3 du stockage Standard
En ouvrant la métrique Total Bucket Size dans CloudWatch, j'ai relevé un écart entre les métriques S3 et CloudWatch : la métrique S3 affichait 4,9 To de stockage Standard pour le bucket, contre 5,3 To côté CloudWatch.
Métriques CloudWatch des buckets par classe de stockage
Détail des métriques par classe de stockage
Mon analyse a révélé deux problèmes liés à la transition des objets entre classes de stockage :
(1) La métrique du stockage S3 Standard n'avait pas diminué après le déplacement des objets vers une autre classe.
(2) La métrique S3 et la métrique CloudWatch présentaient un écart significatif sur le total du stockage Standard.
Résoudre les problèmes
En examinant la façon dont le client avait transféré les objets de Standard vers Glacier Deep Archive, j'ai découvert qu'il avait procédé manuellement depuis la console S3. Après avoir ouvert l'objet, il avait sélectionné Action, Edit actions, Edit storage class.
Modification manuelle de la classe de stockage d'un objet
Modifier la classe de stockage d'un objet via la console crée en réalité une copie de l'objet et conserve l'original comme version antérieure (si la gestion des versions est activée sur le bucket).
Lorsque vous modifiez la classe de stockage d'un objet via la console, celle-ci ne change pas la classe de l'objet : elle crée un nouveau fichier dans la classe sélectionnée.
La gestion des versions étant activée sur le bucket, il existe désormais deux versions du fichier : une dans Glacier Deep Archive (version actuelle) et une dans Standard (version non actuelle). D'où l'absence de diminution du stockage Standard.
Règle de cycle de vie
En analysant l'écart entre les métriques S3 et CloudWatch pour la classe Standard, j'ai constaté que les métriques S3 affichées sur la page du bucket ne reflètent que la taille cumulée des fichiers actuels, tandis que CloudWatch comptabilise également les fichiers non actuels et les uploads multipart échoués.
Le client ayant modifié manuellement la classe de stockage des objets, une nouvelle copie avait été placée dans Glacier Deep Archive comme version actuelle, l'objet d'origine dans Standard devenant la version non actuelle.
Comme le client n'avait pas besoin de conserver cette version non actuelle dans Standard, je lui ai recommandé de créer une règle de cycle de vie pour nettoyer le bucket et supprimer les versions non actuelles de Standard.
Le client a mis en place la règle de cycle de vie suivante : deux jours après qu'un objet devient non actuel (c'est-à-dire qu'il est remplacé par une version plus récente), toutes ses versions non actuelles sont définitivement supprimées.
Règle de cycle de vie pour supprimer les versions non actuelles
**Le résultat**
Après la mise en place de la règle de cycle de vie le 14 mai, S3 a commencé à supprimer automatiquement les versions non actuelles.
Diminution du stockage Standard après mise en place de la règle de cycle de vie
La règle a fortement réduit le volume du bucket S3, qui est passé de 4,9 To à 1,3 To. Résultat : des économies sur les coûts du bucket et de meilleures performances.
Cette action toute simple a permis non seulement de réduire les frais de stockage, mais aussi d'optimiser les performances du bucket. Le graphique ci-dessous illustre la hausse des coûts S3 du client lors de la transition manuelle vers Glacier Deep Archive le 6 mai, puis la baisse des coûts de stockage après la mise en place de la règle de cycle de vie le 14 mai. Ce graphique provient de DoiT Cloud Navigator — Cloud Analytics.
À retenir
Ce cas illustre l'importance des règles de cycle de vie S3 pour bien gérer les buckets et les transitions entre classes de stockage. La modification manuelle effectuée par le client a entraîné une duplication inutile entre Glacier Deep Archive et Standard, qui aurait pu être évitée avec une règle de cycle de vie.
Par ailleurs, exploiter conjointement les métriques S3 et CloudWatch est indispensable pour bien comprendre le contenu de ses buckets S3 et faciliter aussi bien la maîtrise des coûts que l'optimisation des performances.
Nous contacter
Pour toute question sur l'optimisation de S3 ou pour un audit de votre architecture AWS, contactez-nous chez DoiT International. Notre équipe d'experts se tient à votre disposition.