AutoScaling 時の WordPress の Web ドキュメントルートの扱いは結構めんどくさいです。
メディアアップロードすると wp-content/uploads/ にファイルがアップロードされたり、WordPress 管理画面からテーマやプラグインのアップロードとか、コア・テーマ・プラグインのアップデートができちゃうんで辛いことになります。
NFS マウントでしのいだりもするんですが、みんなの救世主 Amazon EFS は発表からずいぶん経ってるのに東京リージョンに来るどころか、まだプレビューが外れません....

そんなわけで goofys 使って web ドキュメントルートを S3 バケットにマウントしてみました。

構成

ローンチ時の UserData は、こんな感じ

#!/bin/bash
web_docmentroot='/var/www/html'
s3_region='us-east-1'
s3_bucket='lets.ninja'
if [ ! -e /usr/local/bin ]; then
  mkdir -p /usr/local/bin
fi
yum -y install nginx golang fuse wget
wget https://github.com/kahing/goofys/releases/download/v0.0.6/goofys -P /usr/local/bin
chmod +x /usr/local/bin/goofys
if [ ! -e ${web_docmentroot} ]; then
  mkdir -p ${web_docmentroot}
fi
/usr/local/bin/goofys -o allow_other --uid "$(id -u nginx)" --gid "$(id -g nginx)" --region ${s3_region} ${s3_bucket} ${web_docmentroot}

IAM ロールに S3 へのアクセス権限与えることも忘れずに
ちゃんと、動いたっぽいです。

なお、今回検証に使った環境は以下の通りです。

EC2 : t2.small AMIMOTO HVM
RDS : db.t2.small MariaDB

Loader.io での負荷検証

以下の URL を参考にして wp-login.php からの wp-admin/edit.php へのアクセスを Loader.io で試してみました。
参考URL: Loader.ioを使ってWordPressのバックエンド構成を変えつつ性能を測ってみる、php-fpmとHHVM

0 - 250 同時接続まで実行してみました。

EC2 1台の時の検証結果

同時接続数が 130超えたあたりから 500 Error が頻発してます。

EC2 10台の時の検証結果

最後まで完走してますね。
500エラーも2回しか発生しなかったようです。

雑感

先日書いた OS X に goofys 入れて S3 をマウントするを使えば、Mac から AutoScaling 環境にサクッとデプロイすることもできそうですね。
ちょっと夢が広がってきました。

この構成考えた時にある人から「古いバージョンの goofys は、時々マウント切れるので要監視ですよ」って言われました。
今回使った goofys は ver.0.0.6 ですが、とりあえずテスト中にマウントが切れることはなかったです。

ただ、goofys マウントしたディレクトリ上ではファイルの新規作成が失敗することがあるみたいで vim で直接修正しようとするとバックアップファイルできなかったよってエラー出てました。
他のディレクトリで作成したファイルをコピーすれば問題ないです。
これは EC2 にマウントしたディレクトリでも OS X でマウントしたディレクトリでも同様の状態でした。

今回、検証に使った環境は lets.ninja なんですが、今は CloudFront 外して EC2 1台の状態に戻してますが goofys マウントはそのままにしてあります。
しばらく、このままで動かしてみて goofys マウントの状況とか検証しようと思います。

スポットリクエストで AutoScaling 環境立ち上げれば、かなりのコストダウンになりそうです。
AutoScaling では台数を時間指定で増減させることもできるので、とりあえず自社の開発環境で使ってるインスタンスで試してみようかなぁ。

現場からは以上です。