概要
こちらで計測したとおり、Amazon EFS (バーストモード) のランダムリード性能は (少なくとも、よくあるブログやコーポレートサイトレベルなどの大規模でないサイト用途では、) かなり低いらしい。
「ほんまかいな……」
と思って、[efs slow] や [efs tuning] のキーワードでググってみても、 やはり同様に EFS の遅さに苦しんでいる人がちらほら。
したがって、EFS を使用してサーバーを冗長化する場合は、極力ディスクIOを減らすための工夫が必須となる。
(ドでかいダミーファイルを設置して使用容量をかさ増しすることによって、ベースライン性能そのものを上げようという向きもあるらしいが果たして……)
構成案
1. 静的コンテンツのキャッシュを CloudFront で受け持つ場合
参考: こちらの『2つ目の解決策』
ごもっともな構成。
ここまでする必要があるのかと少しひるんでしまうが、可用性向上のためということで……
WordPress だと、下記のような雰囲気だろうか。
CSS, JS, メディアファイルなどの静的リソース
CloudFront でキャッシュさせてしまう。
/wp-includes/*/wp-content/*
PHPなどの動的リソース
CloudFront でキャッシュできるかは要件次第か。 なので、例えば PHP ならば OPCache や FastCGIキャッシュなど、最低でもオリジンサーバー側でできるだけキャッシュしよう。
2. 静的コンテンツのキャッシュをプロキシキャッシュで受け持つ場合
前述の案1とほぼ同様だが、もっとシンプルにしてくれっていう場合。
静的リソースのキャッシュを NGINX のプロキシキャッシュなどで受け持ってもらえば、CloudFront 無くせるかもね、という発想 (cf. Cache Proxyパターン)。
参考: 【nginx】WordPress でキャッシュしてはいけないページ（ファイル、ディレクトリ）設定！！！ – oki2a24
留意すべき点
EFSボリューム の自動マウント設定
言うまでもないが、例によって /etc/fstab 追記を忘れずに行おう。
参考: 自動的にマウントする – Amazon Elastic File System
セッションストア
「EFS にセッションファイルも置いてしまえば良いのでは？」
とちょっと思うが、これもぐぐるとクソ遅くなるらしいのでやめたほうが良さそう。
MySQLのDBに置くようにするか、ElastiCache の memcached や Redis を使おう。
そんな金ないという場合は、ALB でセッション維持設定を有効化しよう。
キャッシュ無効化について
- CloudFront のキャッシュ無効化は C3 Cloudfront Cache Controller のようなプラグインで可能
- NGINX のプロキシキャッシュ等はどうすればいいんだろう……
バックアップについて
参考: DataPipelineを利用してEFSのバックアップ環境を作ってみた ｜ Developers.IO
AWS Data Pipeline を使用してバックアップ処理を自分で設定する必要がある。 ただし、要はファイルを普通にコピーしているだけなので、バーストクレジットは普通に消耗するらしい。
ただでさえ遅いのに、バーストクレジットを使い果たしたら目も当てられないの状況になってしまうのでは……
WordPress の更新について
私が試したところ、EFS 上に WordPress を設置した場合だけ、なぜか管理画面上での WordPress コア更新が失敗するようになった (同環境で EBS 上にファイルだけ移動したところ成功した)。
サクッとググった範囲でも同様の事例があるらしいが、原因・解決策を見つけられず……
所感
lsync + rsync のような小細工感満載な手法によりファイル同期するよりも、 EFSというAWSのマネージドサービスを使用して (ある意味) 正攻法的な手法でサーバーを冗長化できるようになったのはうれしいが、小規模Webサイトの冗長化用途での実運用は厳しそうな雰囲気……
