Le montage de godets S3 directement dans des instances EC2 est-il sûr?

comme le dit le titre de ma question, je voudrais savoir si c'est une bonne pratique ou non,

Je sais que je peux le monter dans une instance EC2 mais je me demandais si, comme j'ajouterais plus d'instances pour faire évoluer mon application, cela pourrait causer des problèmes; avez-vous de l'expérience avec cela?

J'utilise S3 pour permettre le téléchargement de fichiers via un script PHP, donc fondamentalement la question est:

Est-ce une bonne pratique d'utiliser le montage ou existe-t-il de meilleures façons de gérer les téléchargements de fichiers utilisateur?

Merci d'avance

Si vous utilisez S3 comme pour stocker des données de téléchargements d'utilisateurs, en particulier dans un environnement distribué, une grande considération est le fait que S3 est `` finalement cohérent '' (bien que, certaines régions soient cohérentes en lecture après écriture). La conséquence de cela est que vous pouvez télécharger un fichier avec succès, mais si vous vérifiez son existence immédiatement après, il se peut qu'il n'existe pas. Ce problème est plus prononcé pour les scénarios tels que les mises à jour ou les suppressions, où même la cohérence de lecture après écriture n'aidera pas.

Ce qui précède s'appliquera à vos téléchargements vers S3 quelle que soit l'approche que vous adoptez. En fait, cela est vrai de la plupart des problèmes que l'on pourrait attendre de S3 - ce n'est pas tant l'approche utilisée pour stocker les données que ce sont les limitations de S3 qui seront probablement les plus problématiques.

S3fs utilise l'API S3 - tout comme le fait le SDK PHP (ou autre). De plus, S3 est conçu pour gérer des niveaux de concurrence assez élevés - donc (à part les problèmes de cohérence) il ne devrait pas y avoir de problème de montage sur plusieurs instances (en gardant à l'esprit qu'il ne s'agit pas d'un système de fichiers traditionnel - des problèmes comme le verrouillage, etc sont traités du côté S3).

Cela dit, chaque implémentation présente des avantages et des inconvénients potentiels:

S3fs:

• Pas de prise en charge des téléchargements partiels / fragmentés (pour autant que je sache) - vous devez donc télécharger le fichier complet pour en lire n'importe quelle partie - probablement pas un problème si vous l'utilisez simplement pour stocker (et servir) les téléchargements.
• Écrit en C ++ gains de performances possibles
• Votre application bénéficie de toute mise à jour de s3fs
• Implémente la mise en cache (à la fois des fichiers complets et des informations sur les fichiers) - a le potentiel d'améliorer un peu la vitesse et de réduire les coûts
• Limité aux fonctions que le fusible expose

SDK:

• Expose l'ensemble complet des fonctionnalités que S3 a à offrir - selon votre cas d'utilisation, cela peut être suffisant pour mériter l'utilisation du SDK
• Intégration potentiellement plus étroite avec votre application - les erreurs renvoyées, etc. peuvent permettre à votre application de faire des choix mieux informés (et donc plus précis)
• Tous les avantages possibles doivent être codés - votre application doit en profiter et être tenue à jour avec les futures modifications de S3
• Plus de complexité et de surcharge pour votre code

En termes de «sécurité», vous pourriez signifier «prévenir la corruption des données» ou «empêcher tout accès non autorisé». En ce qui concerne le premier, le SDK pourrait aider un peu à gérer la cohérence éventuelle (sous la forme d'erreurs plus verbeuses), mais le stockage sous-jacent est le même, et je m'attends à ce que les différences soient mineures. En ce qui concerne le contrôle d'accès - vous pouvez utiliser IAM pour créer un compte limité, mais ce compte aura toujours besoin d'un accès en lecture / écriture à vos fichiers S3. Les deux doivent être suffisamment sécurisés, dans les deux cas, votre système doit être compromis pour accéder à votre compartiment S3 - je suggérerais cependant qu'avec S3fs (car les informations d'identification sont généralement stockées en dehors de la racine Web et ne sont pas accessibles du tout via PHP) la sécurité est légèrement meilleure.

Opinion personnelle: je préférerais s3fs pour un cas où il y a un seul répertoire de téléchargement (par exemple un site qui l'utilise) et où l'accès sera assez simple (il suffit de télécharger des fichiers et parfois de mettre à jour / supprimer). Si vous avez besoin d'un accès plus complexe (par exemple, téléchargements partiels, plusieurs compartiments, etc.) ou que vous allez utiliser le SDK S3 à d'autres fins, je m'en tiendrai également au SDK pour les téléchargements.

Je préférerais télécharger vers S3 via PHP lib. Il est plus facile que de monter S3 sur chaque serveur.

Découvrez cet exemple: http://aws.amazon.com/code/126

Pour l'un de mes projets, j'ai utilisé cette lib: http://undesigned.org.za/2007/10/22/amazon-s3-php-class . Ça a vraiment bien marché pour moi.

Vous pouvez autoriser les utilisateurs à télécharger directement sur s3 à partir du navigateur sans télécharger sur votre serveur (puis télécharger sur s3.)

Voici quelques bons conseils pour cela: https://leonid.shevtsov.me/post/demystifying-s3-browser-upload/

après le téléchargement du fichier, si vous devez traiter le fichier (zip, transcodage, etc.), vous pouvez utiliser S3fs