まーぽんって誰がつけたの?

iOS→Scala→インフラなおじさん技術メモ

WordpressをAmazon ECSで冗長化する

wordpressを動かすには何が必要か

f:id:masato47744:20180125005154p:plain

まずwordpressを動かすために何が必要かを整理すると、wordpressはMySQLとphpが動く環境が必要です。 なので本当に必要なものはDBサーバーとWebサーバーだけなんだけど、実際の本番運用してくとしたら画像のキャッシュとかDBの冗長化とかWebサーバーの冗長化を考えないといけない。

コンポーネント 必須
PHPが動くWebサーバー
RDB(MySQL)
キャッシュサーバー
画像ストレージ

オールインワンパッケージのamimoto amiという選択肢

f:id:masato47744:20180125005147p:plain

で、それらをいい感じに一つの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にできたところで、これを以下のような構成で冗長化

f:id:masato47744:20180125005306p:plain

コンポーネント 中身
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でマウントできたりしたら、上記であげたデメリットも解消するので時が来たらきっとやるでしょう