AWSにおいてWebサーバーから参照するファイルサーバーを冗長構成したい

具体的な方法ではなく案だけですが、下記とかでしょうか。

 s3fs で S3 をマウント

AWS なら S3 をファイルサーバとしてとして使えばなにも考えなくても高度に冗長化されています。

ただ s3fs はあんまり奨励されないという話をどこか？で聞いた気もします。

あと、goofys という golang 実装の似たようなものもあり、こちらのほうが動作が高速なそうです。

 Amazon EFS を NFS でマウント

AWS に EFS という NFS としてマウントできるフルマネージドサービスがあります。これを使っておけばなにも考えなくても冗長化されています。

ただ、また正式にリリースされていないこと、日本のリージョンではまだ使えません。

実際に使ったことはないので、詳細はわかりません。。。

 GlusterFS

複数台の EC2 インスタンスに GlusterFS を入れてレプリケーションを設定すれば、フォールトトレラントな分散ファイルシステムにできます。

 CephFS

Ceph をファイルシステムとして使う CephFS を複数台の EC2 インスタンスで構成すれば、GlusterFS と同じようにフォールトトレラントな分散ファイルシステムにできます。

実際に使ったことはないので、詳細はわかりません。。。

 Pacemaker/Corosync/DRBD/NFS

複数台の EC2 インスタンスに Pacemaker/Corosync/DRBD/NFS をセットアップし、DRBD でディスクをミラーリング、Pacemaker/Corosync で Active/Standby な HA クラスタで NFS をホストする、とかでフォールトトレラントな分散ファイルシステムにできます。

Pacemaker のリソースとして、Active 側に下記のものをもたせる感じです。

• DRBD の Primary
• DRBD デバイスのマウント
• NFS サービスの開始
• VIP の付与（Floating VIP）

ただし、AWS だとサーバに Floating VIP を付与するだけだとダメだったかもしれません（Source/Dest Check を無効にすれば大丈夫？）。

少なくとも Multi-AZ でやる場合は Floating VIP だとダメで、Routing Based HA と呼ばれるパターンを使用する必要があります。

が、そもそも、Multi-AZ で DRBD やら Pacemaker/Corosync やらがまともに動作するのか・・疑問もあります。

 設計をみなおす

そもそも Web サーバがファイルサーバを POSIX ファイルシステムとしてマウントできる必要があるでしょうか？

Web サーバで Web アプリが動いているなら、AWS のストレージ系のフルマネージドサービス（S3 とか）にファイルを格納して、クライアントからのリクエストに応じて Web アプリがそのデータを取り出して返せば良いと思います。

もし、一旦 Web アプリが受けて S3 からファイルを取り出すオーバーヘッドが無視できない、もしくは、そもそも Web サーバにアプリが動いていない、とかなのであれば S3 の Static Web Hosting で、S3 自体を Web サーバとして使えば良いのではないかと思います。

コメントを元に追記

Webアプリによって生成された画像

S3 に配置するのがデファクトな感じしますけど・・Web アプリが S3 からファイルを取り出すオーバーヘッドが気になるのであれば、Web アプリとその画像とで URL のドメインを別にして、クライアントからは S3 の Static Web Hosting に直接アクセスさせれば良いと思います。

Webアプリへログインするためのセッションファイル

アプリケーションの言語によるかもしれませんが、大抵の場合 memcached にセッションを置くことができるだろうので、AWS ElastiCache にセッションを置くのが良いだろうと思います。

もしくは ELB で Sticky Session を設定してセッションを Web サーバ間で共有しないよう事にするとかでも（片方の Web サーバが止まるとそのサーバに Sticky されていたクライアントはセッションが切れますけど）。