WordpressをAmazon ECSで冗長化する
wordpressを動かすには何が必要か
まずwordpressを動かすために何が必要かを整理すると、wordpressはMySQLとphpが動く環境が必要です。 なので本当に必要なものはDBサーバーとWebサーバーだけなんだけど、実際の本番運用してくとしたら画像のキャッシュとかDBの冗長化とかWebサーバーの冗長化を考えないといけない。
コンポーネント | 必須 |
---|---|
PHPが動くWebサーバー | ○ |
RDB(MySQL) | ○ |
キャッシュサーバー | |
画像ストレージ |
オールインワンパッケージのamimoto amiという選択肢
で、それらをいい感じに一つのAMIにしてくれてるところがある。amimotoという会社が作ってて、amiがマケプレで売ってる。インスタンス料金以外にとられる値段もたいしたことなくて、そのamiの中に、MySQL、キャッシュ設定がチューニングされたNginx、php-fpmなどが全部込みで入ってる。
コンポーネント | 中身 |
---|---|
PHPが動くWebサーバー | nginx + php-fpm |
RDB(MySQL) | MySQL |
キャッシュサーバー | nginxがいい感じに設定されてる |
画像ストレージ | ディスク |
管理画面の制限 | sshログインしてnginxの設定を書き換える |
DBの冗長化 | なし |
メディアのバックアップ | EBS丸ごとバックアップ |
DBのバックアップ | EBS丸ごとバックアップ |
なので、もし吹っ飛んだ時の復旧までのダウンタイムがある程度許容できる、アクセスがたいしてこないことが分かってるなどの場合は、このamiを一個立ててパフォーマンスが悪くなってきたらお金を積んでインスタンスのスケールアップをしてくという方法も全然ありだと思う。
真面目に本番運用を考えると・・
でも実際、本番運用を考えていくと色々懸念点が出てきた。
- DBのバックアップどうする?
- DBの冗長化どうする?
- メディアデータ(画像とか)のバックアップどうする?
- 管理画面だけ社内IP制限してbasic authしたい
- wordpressだけをスケールさせたい場合は?
これらを解決するにはami一本の場合だと、インスタンス内のcronにmysqldumpを書くとか、amiを定期的にバックアップするとか、webサーバー部分だけのスケールはできないからインスタンスタイプを上げるしかないとかちょっと困ることが出てくる。
wordpressだけ冗長化させたい
AWSを使うのでDBのバックアップを考え出すと、やっぱりお世話はRDSにお任せするのが一番。 メディアデータはS3などのストレージに入れておけばバックアップも考えずに済む。 キャッシュはS3とcloudfrontを使ってできるし、そういうプラグインがwordpressに用意されてる!! ただ、一つ問題なのが、wordperssだけスケールさせたい場合。
設定ファイルを持ってしまってるwordpressさん
そんなの増やせばいいだけじゃんと思うんだけど、wordpress本体の設定はDBだけではなく、wp-config.phpという部分に設定を書き込んでいたり、プラグイン本体などを保持している。 なので、増やしたらサーバー同士でファイルの同期をとらないといけない。これが面倒。。 :disappointed: ディスク領域を共有フォルダのように使えるAmazon EFSというのがあるが、これはまだTokyoにきていないのと、S3をマウントするgoofysというのもあるがDockerとの設定がうまくいかないみたいだった。
ちなみに、k8sなら、PersistentVolumeという共有ディスクが簡単に設定できる仕組みもある
docker imageに含めてしまうという発想の転換
実はwp-config.phpは最初のwordpress初期化時にしか書き込みが行われないようだった。また、プラグインもあらかじめwp-content配下においておけばいいみたいだった。
デメリットとしては、 * 管理画面からupdateできない * 管理画面からプラグインやテーマをインストールできない updateしたければ、docker imageを再ビルドしてねということになる。
ECSで動かす
docker imageにできたところで、これを以下のような構成で冗長化
コンポーネント | 中身 |
---|---|
PHPが動くWebサーバー | nginx + php-fpm |
RDB(MySQL) | RDS |
キャッシュサーバー | Cloudfront |
画像ストレージ | S3 |
管理画面の制限 | 前段のnginxで制限 |
DBの冗長化 | RDSのMulti-AZ |
メディアのバックアップ | S3のSLAを信頼する |
DBのバックアップ | RDSのデフォルトsnapshotとLambdaで定期実行 |
これで、アクセスが増えた場合もwebサーバー部分だけ冗長化ということもやりやすくなった。
今後
Amazon EFSがきて、ECSのtaskでマウントできたりしたら、上記であげたデメリットも解消するので時が来たらきっとやるでしょう