はじめに
AWS を始めとするパブリッククラウドにおいて Web サーバーを構成する際、
「ステートレス」というキーワードが重要視される。
サーバーに可能な限り固有の状態を持たせないことによって、サーバーの生成・廃棄が容易になる。
それによって、パブリッククラウドが備える膨大なリソースを活かした柔軟な水平スケーリング、高可用性が実現できるからだ。
余談: ペットと家畜のアナロジー
どうでもいいが、クラウドサーバーにおける生成・廃棄の容易さに対する考え方は、ペットと家畜のアナロジーを用いて議論されることがある。
つまり、個々のサーバーをかけがえのない大事なペットと捉えるか、死んだら替えを用意するだけの社畜家畜と捉えるか。
冗長構成のために WordPress サーバーを (ほぼ) ステートレスにするには
WordPress サーバーの状態とはなんだろうか。
- DB に記録されるデータ
- セッションストア
- メディアファイル
- その他ファイル
- WordPress コアのファイル
- プラグインのファイル
- プラグインが作成するファイル
- テーマが含む JS、CSS、画像など
1.は Amazon RDS 等のマネージドな RDB サービスを使用すれば済む。
2.も WordPress コアについては、 DB と Cookie を使用しているので基本的には問題にならない。プラグインなどで PHP のセッションを使っている場合でも、ElastiCache を導入すれば対処できる。
3.はデフォルトだと各サーバー内にファイルとして保存されることになるので、まさしく唾棄すべき状態だ。
4.も状態が生じうるが、運用方法次第 (WordPress の自動アップデートを無効化してブルー・グリーンデプロイできちんと管理して行う、プラグインやテーマを勝手にインストールしないなど) で状態を極力発生しないようにできるし、それにより公開サイトへ不都合が生じることを防ぐことができる。
(ただし、自動アップデート無効化によるセキュリティの低下は妥協せざるを得ない。)
よって、冗長構成のWordPressサーバーを構築する際の最初の仕事は、 3.メディアファイルへの対応であろう。
メディアファイルどうする問題
1. rsync や lsyncd でファイル同期
冗長化構成の AWS EC2 における、lsync + rsync によるファイル同期
- お手軽 (コスト的な意味で)
- 数秒〜の遅延が発生する
- 同期対象を明示的に指定する必要がある
- オートスケーリングするような環境には向かない
- オートスケーリングしない環境ならば、楽で良いのでは
2. 自前で共有ディスクを構築 (NFS)
男は度胸！何でもためしてみるのさ。
3. マネージドな NAS サービスを使用
【東京リージョン対応】Amazon EFS の速度計測してみた結果【祝】
例えば EFS (AWS) や Cloud Filestore (GCP) など。
- 一見すると最も正攻法に思われるが NFS なので基本的にとても遅い
- データ量が少ない場合、IOPS がかなり低いので、小規模な Web サイトの配信用途には不向きかと
- プロビジョンドスループットモードで設定する、ダミーデータを数百 GB 程度置いて水増しするなど、金に糸目を付けないなら話は別
4. 自前で共有ディスクを構築 (分散ファイルシステム)
GlusterFS や CephFS など。
どちらも RedHat が開発していたり、それなりに実績もあるらしい。
男は度胸！何でもためしてみるのさ。
5. WordPress のプラグインで S3 へファイル同期
【WordPress】プラグインを使用して静的ファイルやメディアファイルを S3 へオフロード
オートスケーリングする環境向けには、この方法が現実的かと。
おわりに
- NFSが速かったなら、世界はどんなに美しかったのだろうか
- WordPress と直接的に関係はないが、できればアクセスログ、エラーログもサーバー内のファイルではなく、外部に集積したほうがいろいろと都合が良い
