28

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

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

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

  1. ユーザーファイルを保存するためにマウントされた多数の EBS ボリュームを持つ EC2 インスタンスを用意します。

    • 長所: S3 よりもはるかに高速で、EBS ボリュームからのファイルの圧縮は簡単です。
    • 短所: Amazon は、使用できる EBS ストレージの量に上限を設けており、S3 ほどの冗長性はないと考えています。

  2. ファイルがアップロードされて処理された後、システムはそれらのファイルを S3 バケットにプッシュして長期保存します。ファイルが要求されると、S3 からファイルを取得し、クライアントに出力します。

    • 長所: 冗長性、ファイル ストレージの制限なし
    • 短所: 非常に遅いようです。S3 バケットをファイルシステムのボリュームとしてマウントする方法はありません。圧縮されたファイルを提供するには、各ファイルを EC2 インスタンスに転送し、圧縮し、最終的に出力を送信する必要があります (これもまた遅い!)

私の仮定には欠陥がありますか？大量のファイル ストレージを管理するためのより良い方法を考えられる人はいますか?

4

5 に答える 5

22

不特定多数のユーザーがサービスを使用する場合は、採用するオプションに関係なく、スケーラビリティが常に問題になることを念頭に置くことが重要です。需要に合わせてサービスをスケーリングする必要があります。単一のインスタンスではなく、EC2 インスタンスのプールを持つ Auto Scaling グループでサービスが実行されると仮定すると便利です。

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

  1. ファイル名の予測可能性: URL の予測可能性を回避するには、アップロードされたファイルにハッシュとして名前を付け、SimpleDB などのデータベースに元のファイル名と所有権を保存します。オプションで、「Content-Disposition: filename=original_file_name.ext」などの http ヘッダーを設定できます。 "ダウンロードしたファイルに適切な名前を付けるようブラウザに通知します。

  2. 承認: ユーザーがサービスの特定のファイルをダウンロードするように要求すると、クエリ文字列認証または一時的なセキュリティ資格情報を使用して、その特定のユーザーに一時的な承認を発行し、ファイルへの読み取りアクセスを一定期間付与します。その後、サービスは S3 バケット URL にリダイレクトします。直接ダウンロード用。これにより、EC2 プール インスタンスの負荷が大幅に軽減され、他のリクエストをより迅速に処理できるようになります。

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

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

  1. ユーザーがフォルダーの圧縮を要求する
  2. フロントエンド EC2 インスタンスは、SQS キューに圧縮リクエストを作成します
  3. バックエンド EC2 インスタンスは、SQS キューの圧縮リクエストを消費します
  4. バックエンド インスタンスはファイルを S3 から EBS ドライブにダウンロードします。生成されたファイルは一時的なものになるため、I /O レイテンシーと処理時間。
  5. 圧縮ファイルが生成された後、サービスはファイルを S3 バケットにアップロードし、オプションでオブジェクトの有効期限プロパティを設定します。これにより、S3 バケットは一定期間後にファイルを自動的に削除するように指示されます (これもストレージ コストを削減するためです)。 SNS トピックでファイルをダウンロードする準備ができたという通知を発行します。
  6. ユーザーがまだオンラインの場合は、トピックからの通知を読み、zip ファイルをダウンロードする準備ができていることをユーザーに通知します。しばらくしてもこの通知が届かない場合は、圧縮に予想よりも時間がかかっていることをユーザーに伝えることができます。ファイルをダウンロードする準備が整い次第、サービスから電子メールで通知されます。

このシナリオでは、それぞれフロントエンドとバックエンドの 2 つの Auto Scaling グループを持つことができ、それぞれ異なるスケーラビリティ制限を持つ可能性があります。

于 2012-08-11T13:39:18.197 に答える
5

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

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

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

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

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

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

于 2012-12-20T14:25:18.497 に答える
2

このユースケースでは、S3 を使用する方が適しています。スケーリングが向上し、よりシンプルになります。なぜあなたはそれが遅いと心配していますか？EC2 と S3 間の転送は非常に高速です。

于 2012-08-11T00:53:06.243 に答える