AWS 複数のEC2 ＋ goofysでS3バケットをマウントしたときの問題点。

Question

複数のEC2 ＋ goofysでS3バケットをマウントしたときの問題点を見つけたので、
ここに書き残します。

EC2で2台のWEBサーバーを構築、ALBにて負荷分散。
2台のEC2は同じS3上の領域をマウント（goofysでS3バケットをマウント）

WEBサーバーのDocumentRootをgoofys上に設置

問題発覚

2台のWEBサーバーをWEB_A WEB_Bとする。

1.ある利用者がパソコンのWEBブラウザでWEB_A経由でサイト閲覧して、ファイル更新（画像ファイルの更新ファイル名は元のまま）を行う。

2.別の利用者がパソコンのWEBブラウザでWEB_B経由でサイト閲覧して、１で更新されたファイル閲覧を行う。

1. 1で更新したはずのファイルが元のまま。

2. 数日経過後調査すると、WEB_A経由でサイト閲覧すると更新後のファイルが表示される。
   WEB_B経由でサイト閲覧すると更新前のファイルが表示される。

という状況。

いろいろ調べて、どうやらページキャッシュというものらしいと判明

echo 3 > /proc/sys/vm/drop_caches

のコマンドをたたくと解消されると判明。

独自にシェルプログラムを書いて自動実行する等、何らかの対策が必要となる。

Answer 1

Amazon EFSというサービスが、7月からTokyoリージョンで利用できるようになります。

これにより、現時点でのS3を使ったファイルストレージやストレージマウントの方法は、
ベストプラクティスでは無くなってしまいます。

以下をご一読ください。

Amazon EFS 公式イントロダクション
Amazon EFS 公式ドキュメント

S3は、バケット以下を（フォルダもファイルも）すべてオブジェクトとして扱っています。
デリミタでファイルとフォルダを区別しているだけですので、
S3をストレージとしてマウントさせる方法はあまり良い使い方ではありません。

S3は、Simple Storage Serviceの頭文字をとってS3と呼んでいますが、
アーキテクチャとして３拠点のストレージをミラーリングしている意味もあります。

S3にファイルを置くと、必ずファイルsyncが走って他の２箇所のストレージに対してクローンするので
同期完了まで時間が多少かかるので、連続処理などには向いていないというデメリットがあります。
削除アクションを行った場合は、３拠点のストレージが全て削除されるまで待って完了となります。

ちなみにecho 3 > /proc/sys/vm/drop_cachesは、
意図的にOSが持っているLinuxのメモリキャッシュも削除するので
Linuxの処理速度が落ちると思いますよ。

Comments

[oyaji_sj_hi]

ありがとうございます。
そもそも「全部日本国内でやれ」と上に言われたのが、s3を無理くりマウントして使用し始めたきっかけでした。
今後はEFSを推奨していきます。

Answer 2

複数のユーザーから同じデータを更新する時はファイルではなくデータベースを使います。
データベースさわったこと無い新人向けトランザクション入門

Comments

[oyaji_sj_hi]

コメントありがとうございます。
ちょっとした画像掲示板的なサイトでDBは使わない方針なのです。

Answer 3

一応解決済みですが、もっと良いやり方があればご指摘下さい。