アマゾンウェブサービスでEBSとS3のどちらを選択するかを決めるのに助けが必要

Question

私はファイルストレージと共有機能を組み込んだプロジェクトに取り組んでおり、AWSを活用するための最良の方法を何ヶ月も研究した後も、まだ少し心配です。

基本的に、私の決定は、EBSストレージを使用してユーザーファイルを格納するか、S3を使用するかです。システムは、ユーザーがほんの一握りのファイルをダウンロードしたいときにオンザフライZipアーカイブを組み込みます。また、ユーザーがファイルをダウンロードするときに、ファイルのURLを公開したくありません。

私が思いついた2つの最良のオプションは次のとおりです。

ユーザーファイルを保存するために多数のEBSボリュームがマウントされているEC2インスタンスがあります。
- 長所：S3よりもはるかに高速で、EBSボリュームからファイルを圧縮するのは簡単です。
- 短所：Amazonは使用できるEBSストレージの量に上限があり、S3ほど冗長ではないと思います。
ファイルがアップロードされて処理された後、システムはそれらのファイルをS3バケットにプッシュして長期保存します。ファイルが要求されると、S3からファイルを取得してクライアントに出力します。
- 長所：冗長性、ファイルストレージの制限なし
- 短所：非常に遅いようです。S3バケットをファイルシステムのボリュームとしてマウントする方法はありません。zipファイルを提供するということは、各ファイルをEC2インスタンスに転送し、圧縮して、最後に出力を送信することを意味します（これも遅いです！）

私の仮定のいずれかに欠陥がありますか？大量のファイルストレージを管理するためのより良い方法を誰かが考えることができますか？

Alessandro Oliveira · Accepted Answer

サービスが不確定な数のユーザーによって使用される場合、採用されたオプションに関係なく、スケーラブル性が常に懸念されることを覚えておくことが重要です。需要を満たすためにサービスをスケーリングする必要があります。サービスが、単一のインスタンスではなくEC2インスタンスのプールを持つAuto ScalingGroupで実行されると想定すると便利です。

許可されたユーザーのみがファイルをダウンロードできるようにするURLの保護に関しては、サービスを中間として機能させることなくこれを行う方法はたくさんあります。その場合、少なくとも2つの問題に対処する必要があります。

ファイル名の予測可能性：URLの予測可能性を回避するために、アップロードされたファイルにハッシュとして名前を付け、元のファイル名と所有権をSimpleDBなどのデータベースに保存できます。オプションでhttpヘッダーを設定できます。「Content-Disposition：filename = original_file_name.ext」など、ダウンロードしたファイルに適切な名前を付けるようにユーザーにアドバイスします。
authorization：ユーザーがサービスの特定のファイルをダウンロードするように要求した場合、 Query String Authentication または Temporary Security Credentials ファイルへの読み取りアクセスを一定期間許可している特定のユーザーの場合、サービスはS3バケットURLにリダイレクトして直接ダウンロードします。これにより、EC2プールインスタンスの負荷が大幅に軽減され、他のリクエストをより迅速に処理できるようになります。

S3バケットへのスペースとトラフィックを減らすために（保存および転送されたGBごとに支払うことを忘れないでください）、S3にアップロードする前にgzipなどの標準アルゴリズムを使用して個々のファイルを圧縮し、ヘッダー「Content-Encoding：gzip」を設定することもお勧めします。自動解凍をユーザーのブラウザで機能させるため。選択したプログラミング言語がJavaの場合は、Webプロジェクトから静的リソースをアップロードするために作成したプラグインコード webcache-s3-maven-plugin を確認することをお勧めします。

フォルダーを圧縮する際の処理時間については、ユーザーがすぐにダウンロードできるようにするために、フォルダーが短時間で圧縮されることを保証できないことがよくあります。これは、最終的には数分かかる巨大なフォルダーが存在する可能性があるためです。または圧縮する時間ですらありません。このため、非同期圧縮処理を許可するためにSQSおよびSNSサービスを使用することをお勧めします。これは次のように機能します。

ユーザーがフォルダーの圧縮を要求する
フロントエンドEC2インスタンスがSQSキューに圧縮リクエストを作成します
バックエンドEC2インスタンスは、SQSキューの圧縮リクエストを消費します
バックエンドインスタンスはファイルをS3からEBSドライブにダウンロードします。生成されたファイルは一時的なものになるため、ephemeralタイプのディスクで少なくともm1.smallインスタンスを使用することをお勧めします。 I/Oレイテンシと処理時間を削減するために、仮想マシンに対してローカルです。
圧縮ファイルが生成された後、サービスはファイルをS3バケットにアップロードし、オプションで Object Expiration プロパティを設定します。これにより、S3バケットは特定の期間（再びストレージコストを削減します）、ファイルをSNSトピックでダウンロードする準備ができたことを通知します。
ユーザーがまだオンラインの場合は、トピックからの通知を読み、Zipファイルをダウンロードする準備ができていることをユーザーに通知します。しばらくしてこの通知が届かない場合は、圧縮に予想よりも時間がかかっていることをユーザーに伝えることができます。ファイルをダウンロードする準備ができ次第、サービスは彼に電子メールで通知します。

このシナリオでは、フロントエンドとバックエンドの2つのAuto Scalingグループを使用できます。これらのグループには、異なるスケーラビリティ制限がある場合があります。

Charles Engelke · Answer

S3を使用してEC2インスタンスから直接Zipファイルを提供することに固執する場合は、ローカルに保存するよりも複雑になります。ただし、S3はどのEC2ストレージボリュームよりもはるかに耐久性があるため、ファイルを長期間保持する必要がある場合は、とにかくS3を使用することをお勧めします。

ファイルのURLを直接公開したくないと言います。将来、他の人にブックマークを付けてサービス認証をバイパスさせたくないという理由だけで、S3には優れたソリューションがあります。

1-提供するファイル（必要に応じて圧縮）をプライベートS3バケットに保存します。

2-ユーザーがファイルをリクエストしたら、リクエストを認証してから、有効なリクエストをファイルの署名付きの一時的なS3 URLにリダイレクトします。これらのURLを作成できるさまざまな言語のライブラリがたくさんあります。

3-ユーザーはEC2インスタンスを経由せずに、S3から直接ファイルをダウンロードします。これにより、帯域幅と時間が節約され、おそらくユーザーに可能な限り最速のダウンロードが提供されます。

これはURLを公開しますが、おそらくそれで問題ありません。ユーザーがURLを保存しても、設定した有効期限が過ぎると機能しなくなるため、問題はありません。私のサービスでは、その時間を5分に設定しました。デジタル署名されているため、ユーザーは署名を無効にしないとURLの有効期限を変更できません。

jamieb · Answer

このユースケースでは、S3を使用することをお勧めします。スケーリングが向上し、シンプルになります。なぜ遅いのか心配ですか？ EC2とS3の間の転送はかなり迅速です。

John Hanley · Answer

いくつかの考慮事項：

EBSボリュームのコストはS3の数倍です。
EBSのボリュームサイズの制限は16TBであるため、これは問題にはなりません。ただし、そのサイズのボリュームはvery高価です。
バケットがEC2インスタンスと同じリージョンにあることを確認してください。
VPCエンドポイントを使用してS3と通信します。これははるかに高速です。
EC2インスタンスタイプに必要なネットワーク帯域幅があることを確認してください。 CPUとネットワークの速度は、インスタンスのサイズに応じて向上します。

私はすべてをS3に保持し、必要に応じてファイルをダウンロードしてパッケージに圧縮します。次に、ZipをS3にアップロードし、S3からダウンロードするためのS3署名付きURLをユーザーに配信します。

ユーザーにEC2インスタンスからのダウンロードを許可することはできますが、多くのユーザーがエラーの問題、再試行の問題、帯域幅の低下などを抱えています。Zipファイルが小さい（100 MB未満）場合はローカルに配信し、そうでない場合はS3にアップロードしてS3を許可します。ユーザーのダウンロードの問題に対処します。

別のオプションは、Zipファイルを作成してS3に保存するLambda関数を作成することです。これで、ネットワーク帯域幅やスケーリングについて心配する必要はありません。 Lambda関数は、ブラウザーに配信するS3 URLを返すか、Lambdaが顧客にリンクを電子メールで送信する可能性があります。これについてはSESを調べてください。注：Lambdaファイルシステムには512 MBのスペースしかなく、メモリは最大1.5GBまで割り当てることができます。これより大きいZipファイルを生成している場合、Lambdaは機能しません（現時点では）。ただし、複数のZipファイル（part1、part2、...）を作成できます。