Dois-je persister images sur EBS ou S3?

Question

Je suis de la migration de mon Java,Tomcat, Mysql server pour AWS EC2.

J'ai déjà attaché volume EBS pour le stockage de données MySql. Dans mon application web les gens peuvent télécharger des images. Donc je devrait persister. Il y a 2 solutions de rechange dans mon esprit:

1. Enregistrer les images téléchargées à volume EBS.
2. Utilisez le service S3.

Ce qui suit sont mes notes, s'il vous plaît être sceptique sur eux, comme mon expertise n'est pas sur les serveurs, mais le développement de logiciels.

• EBS plus: stockage S3 est plus cher. (De 0,15 $/Go > 0.1$/Go)

• S3 plus: au service de la statique de l'EBS peut avoir une influence sur mon serveur web négativement les performances. Est-ce vrai? Ne Servir les images affecter les performances du serveur particulier? Pour les S3 mon serveur ne sera pas responsable pour servir la statique.

• S3 plus: au service de la statique de l'EBS peut entraîner des I/O du coût, il sera probablement être mineur.

• EBS plus: les Gens disent EBS est plus rapide.

• S3 plus: les Gens disent S3 est plus sûr pour la persistance.

• EBS plus: Pas besoin d'apprendre l'API, c'est tout droit pour enregistrer les images de volume EBS.

À savoir je ne peux pas décider, sera heureux si vous guider.

Merci

Answer 1

La comparaison des prix n'est pas tout à fait juste: S3 les frais sont de $0,14 $ par GO UTILISÉS, tandis que les frais EBS sont 0,10 $par GO CONFIGURÉS (de la taille de votre volume EBS), si vous l'utilisez ou pas. En conséquence, S3 peut ou ne peut pas être moins cher que de l'EBS.

Answer 2

Je suis actuellement à l'aide S3 pour un projet, et ça fonctionne très bien.

EBS signifie que vous avez besoin de gérer un volume de + machines pour le fixer. Vous avez besoin d'ajouter de l'espace comme s'il se remplit et effectuer des sauvegardes (ne dites pas que vous ne devriez pas sauvegarder vos S3 données, juste qu'il n'est pas critique).

Il rend également plus difficile l'échelle: lorsque vous souhaitez ajouter d'autres machines, vous avez besoin soit de retirer les images sur une machine séparée ou dupliquer les images dans tous les. Cela signifie également que vous êtes en train d'ajouter un goulot d'étranglement: vous aurez à gérer votre propre processus de téléchargement qui sera soit de les télécharger pour toutes les machines ou d'avoir une seule machine à la gérer.

Je recommande S3: c'est régler et oublier. N'importe quel nombre de machines peuvent effectuer des téléchargements en parallèle et vous n'avez pas vraiment besoin d'avertir les autres machines sur le téléchargement.

En outre, vous pouvez utiliser Amazon Cloudfront comme un bon marché CDN devant les images au lieu de les télécharger directement à partir de S3.

Answer 3

J'ai conçu des solutions sur AWS pour la photographie de Stock des sites qui stocke des millions d'images couvrant TB de données, j'aimerais partager quelques-unes des meilleures pratiques dans AWS pour votre besoin:

P1) Stocker le fichier Image d'Origine dans S3 Standard option

P2) Magasin de la reproductibilité des images comme les pouces etc ... dans la S3 de Redondance Réduite option (RRS) pour réduire les coûts

P3) Méta-données sur les images, y compris les URL S3 peuvent être stockés dans Amazon RDS ou Amazon DynamoDB, selon la complexité de la requête. Interroger les entrées à partir d'Amazon RDS. Si votre requête est complexe, il est également de pratique courante pour Stocker les méta-données dans Amazon CloudSearch ou Apache Solr.

P4) Livrer vos pouces pour les utilisateurs avec une faible latence à l'aide d'Amazon CloudFront.

P5) de la File d'attente de votre image conversion thru SQS ou RabbitMQ sur Amazon EC2

P6) Si vous prévoyez d'utiliser l'EBS, alors ils ne sont pas évolutives avec votre EC2. Donc, idéalement, vous pouvez utiliser GlusterFS que votre commune pool de stockage pour toutes vos images. Plusieurs Amazon EC2 dans le dimensionnement Automatique mode peut toujours se connecter à elle et l'accès en écriture/images.

Answer 4

Vous avez déjà exposé les avantages et les inconvénients des deux.

Si vous prévoyez de stocker des téraoctets d'images, avec les exigences de stockage augmente jour après jour, S3 sera probablement votre meilleur pari qu'il est construit spécialement pour ces types de situations. Vous obtenez illimité de l'espace de stockage, sans avoir à vous soucier de la fragmentation de vos données sur de nombreuses EBS volumes.

Les coûts récurrents de la S3 est qu'il s'agit de 50% plus cher que l'EBS. Vous devrez également apprendre l'API et de l'implanter dans votre application, mais c'est une dépense qui, je pense, vous devriez être en mesure d'absorber très rapidement.

Answer 5

Pensez-vous que les images pour durer indéfiniment?

Amazon EBS FAQ est assez clair; le taux d'échec annuel n'est pas "zéro"; ils citent de 0,1% à 0,5%. C'est mieux que le disque sous votre bureau, mais il aurait besoin d'un certain type de sauvegarde.