ec2をファイルサーバーとして使用する必要がありますか？
ユーザーがアップロードしたコンテンツを複数のEC2アプリケーションサーバー間で共有できるようにする必要があります。私は、rsync、マウントされたNFS、およびS3を、このデータをほぼリアルタイムで共有できる可能性のあるオプションとして検討しました。アップロードおよびダウンロードされるユーザーファイルは、ほとんどの場合1〜10MBです。頻繁にアクセスされるものもあれば、一度だけアクセスされてから削除されるものもあります。
私の最新のアプローチでは、EC2インスタンスをアプリケーションサーバーとは別に、厳密にファイルサーバーとして起動します。このオプションを使用すると、ユーザーがファイルをダウンロードするために、ダウンロードしたいファイルに関するデータをデータベースに照会するアプリケーションサーバーの1つに接続されます。次に、ユーザーはダウンロードするように求められ、ダウンロードのためにファイルサーバーに接続します。
このオプションは他のオプションよりも高速になると思います。私が見る唯一の欠点は、ファイルサーバーを自動スケールアップ/ダウンできないことです。ただし、スケールアップして、ファイルが配置されているファイルサーバーを示す列をデータベースに作成することはできます。
これは良いアプローチですか、それとも何かが足りませんか？また、サーバーの仕様に基づいて、ファイルが1〜10 MBの場合に、ファイルサーバーで同時に発生する可能性のあるアップロード/ダウンロードの数を判断する良い方法は何ですか？それとも負荷テストから判断するのが最適ですか？
スケーリングの観点からも、1つのファイルサーバーにある1つの特定のファイルが非常に人気になった場合に問題が発生しますか？ CDNを使用すると、この問題は解決しますか？
S3とCloudFrontが最初のオプションですが、レイテンシーが許容できない場合は、他にもあります。
単一のファイルサーバーが適切に機能している場合は、 GlusterFS のようなスケーラブルな分散ファイルサーバープラットフォームに移行できます。これにより、複数のEC2インスタンスにまたがってファイルを保存し、それらを単一のマウントとして表示することができます。 「レプリカ2」オプションを使用して、冗長性のために各ファイルの2つのコピーを作成できます。次に、異なるアベイラビリティーゾーンで2つのインスタンスを使用して、可用性を高めます。ファイル自体は、プロビジョニングされたIOPSまたはSSDエフェメラルを備えたEBSを含むEC2サポートディスクに保存されます（これは以前に行ったことがあります-Glusterの冗長性により、エフェメラルの揮発性がそれほど懸念されないため、SSDのメリットを享受できますfast IO）。
EC2に固有のデータがないように設計する必要があります。これは、単に計算機と考えてください。
いくつかのオプションがあります。
S3
ファイルを保存および取得するためのスケーラブルで信頼性の高いサービス。ファイルシステムとしてはうまく機能しないため、大量の読み取りと書き込みを行う場合は、優れたソリューションではありません。
CloudFront（CDN）
静的ファイル（css、js、画像）はCloudFrontから提供できます（S3またはEC2からデータを取得できます）。これによりパフォーマンスが大幅に向上するため、S3を使用してファイルを取得し、CloudFrontから提供できます。
GlusterFS
EC2のクラスターをネットワーク接続ストレージとして使用できます。もちろん、これによりセットアップが少し複雑になり、最速のソリューションではありません。
Elasticache/Memecached
独自のmemecachedをホストするか、Elasticacheサービスを使用できます。このソリューションはファイルストレージではありませんが、高性能の分散メモリオブジェクトキャッシングシステムとして役立ちます。
CloudFrontでS3を使用する場合は、CDNの方が適しています。私の推奨事項は、ユーザーが生成したコンテンツをアプリケーションサーバーから分散化することです。アーキテクチャ内でスケールアップまたはスケールダウンするときにサーバーを揮発性に保つことは、優れた設計手法です。