AWSのS3またはEFSに何千もの画像を保存する場所は？

Question

あまりにも遠くない未来のプロジェクト、時間の経過とともに何千もの画像を保存するプロジェクトを作ります。 Amazon S3またはEFSを使用してこれらのイメージを保存するかどうかは難しい判断です。両方とも私は非常に良い選択肢だと思いますが、私の質問は最良のサービスとは何か、あるいはベストプラクティスとは何でしょうか？

私のアプリケーションはLaravelで実行され、私はすでに両方のサービスの統合を行っています。

プロジェクトの特性のほとんどは、以下のとおりです。私は保存するファイルの

• 大半は、95％程度の写真になります。
• 約1.5k枚の写真が毎日保存されます。
• 写真は非常に大きい（プロのカメラ）。
• アプリケーションへのトラフィックはそれほど大きくはありません。一度に100人のユーザー。
• 各ユーザーは1日あたり約100枚の写真を参照します。

おすすめしますか？

Answer 1

S3はまさに正しい答えと実践です。私はあなたのような数多くのアプリケーションを構築していますが、何百万もの画像があり、S3は優れています。また、APIが画像を署名済みのURLとして返すなど、サーバーへの負担を軽減し、静的なWebホスティングを介して直接画像をリンクし、使用頻度の低いデータをアーカイブするためのライフサイクルポリシーを提供するなどの柔軟性も可能です。さらに、イベントトリガーを使用すると、他のAWSサービスとのさらなる統合が容易になります。

保存/アップロードに関して、S3マルチパートアップロードは、パフォーマンスを向上させ、信頼性を向上させるために非常に便利です。

共有ファイルシステムで低レイテンシを必要とするサーバー群（HPCと考える）を集中的に処理している場合は、シナリオの種類に合ったEFSが適しています。 EFSはまた、より高いコストで提供され、S3と同じくらい多くの拡張オプションや組み込み機能を提供しません。あなたのシナリオはEFSを必要とするようには聞こえません。あなたはAWS S3が選択され、提案シナリオで

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosting.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/ShareObjectPreSignedURL.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/NotificationHowTo.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/mpuoverview.html

Answer 2

。どうして？

• イメージは頻繁に追加されるため、EFSの約1/10になります。
• S3でファイルを直接アップロードしてダウンロードできるため、Webサーバーのオーバーヘッドが少なくなります。
• ラムダでイベント駆動型の処理を活用できます（サムネイルの生成、S3ラムダトリガによる画像処理フィルタ）。
• 可用性と耐久性の高レベルのSLA。
• アーカイブライフサイクル管理をサポートし、コストを削減します。頻繁にあなたはまた、画像をキャッシュするためのオプションのいずれかでAWS CloudFrontの使用を検討してくださいすることができます（EBSでもオプションです）画像

  を変更するために発生した場合

AWS EFSもオプションをすることができます。

注：結局のところ、1つのサービスを使用することではありません。あなたの今後のリクエストに基づいて、どちらか一方または両方を選択することができます。