Dernièrement, nous avons remarqué que notre facture AWS était plus élevée que d'habitude. Cela est dû à l'ajout d'une tâche aws s3 sync à notre processus de construction régulier. Le processus de construction génère quelque 3 000 fichiers. Après la compilation, nous exécutons aws s3 sync pour les télécharger en masse dans un bucket. Le problème est que cela coûte financièrement cher. Chaque mise en ligne nous coûte ~ 2 $ (nous pensons) et cela s'ajoute à une facture mensuelle qui fait sourciller.
Tous ces fichiers, sauf peut-être 1 ou 2, changent en fait d'une construction à l'autre. Les autres sont toujours les mêmes. Pourtant, aws s3 sync voit qu'ils ont tous changé et télécharge le tout.
La documentation indique que aws s3 sync compare la date de la dernière modification du fichier et sa taille d'octet pour déterminer s'il doit être téléchargé. Le serveur de compilation crée tous ces fichiers à chaque fois neufs, de sorte que la date de la dernière modification est toujours changée.
Ce que j'aimerais faire, c'est lui faire calculer une somme de contrôle ou un hachage sur chaque fichier, puis utiliser ce hachage pour comparer les fichiers. Amazon s3 a déjà le champ etag qui peut être un hachage MD5 du fichier. Mais la commande aws s3 sync n'utilise pas etag.
Existe-t-il un moyen d'utiliser etag? Existe-t-il une autre façon de procéder?
Le résultat final est que je ne voudrais télécharger que les 1 ou 2 fichiers qui sont réellement différents (et économiser des coûts énormes)
4 Réponses :
S3 facture 0,005 USD pour 1 000 requêtes PUT ( doc ), donc c'est Il est extrêmement peu probable que le téléchargement de 3 000 fichiers vous coûte 2 $ par build. Peut-être 2 $ par jour si vous exécutez 50-100 builds par jour, mais ce n'est toujours pas beaucoup.
Si vous payez vraiment autant par build, vous devriez activer les événements CloudTrail et voir ce qui est en train d'écrire autant (d'ailleurs, vous avez peut-être créé une sorte de journal d'événements CloudTrail récursif).
Le résultat final est que je ne souhaite télécharger que les 1 ou 2 fichiers réellement différents
Ces fichiers sont-ils les artefacts produits par votre build? Si oui, pourquoi ne pas simplement ajouter une étape de construction qui les copie explicitement?
La commande aws s3 sync a un paramètre --size-only .
Depuis options de synchronisation aws s3 :
--size-only(boolean) Fait de la taille de chaque clé le seul critère utilisé pour décider de la synchronisation de la source vers la destination.
Cela évitera probablement de copier tous les fichiers s'ils sont mis à jour avec le même contenu.
Comme alternative à s3 sync ou cp, vous pouvez utiliser s5cmd
https://github.com/ peak / s5cmd
Ceci est capable de synchroniser les fichiers sur la taille et la date si différentes, et a également des vitesses allant jusqu'à 4,6 Go / s
Exemple de synchronisation commande:
AWS_REGION=eu-west-1 /usr/local/bin/s5cmd -stats cp -u -s --parents s3://bucket/folder/* /home/ubuntu
Le problème que j'ai rencontré était l'utilisation du caractère générique * dans l'option --include. Utiliser un caractère générique était bien, mais quand j'ai ajouté le deuxième * tel que / log. , il semblait que la synchronisation avait essayé de tout télécharger pour comparer, ce qui prenait beaucoup de CPU et de bande passante réseau.
S3 facture le stockage, les demandes d'API et éventuellement le transfert de données en fonction de la destination, mais il ne facture pas le transfert de données. Savez-vous avec certitude ce qui cause l'augmentation des coûts?
La commande "aws s3 sync" ne remplace que les fichiers qui sont différents, donc je ne vois pas comment cela pourrait en être la cause. C'est certainement quelque chose d'autre qui cause le coût élevé, et à 2 $ par construction, il y a quelque chose qui ne va pas dans la configuration qui doit être étudiée. Comme l'a mentionné l'autre personne qui a répondu, passez par CloudTrail pour identifier les événements ou regardez de plus près ce que fait réellement votre build.