WordpressをAutoScalingするためのシステム構築と参考するといいリンク集 #AWS

Wordpressを冗長構成にする前に基本となる構成

EC2+EBS - Wordpess本体が入る。更新データとしてはプラグイン、テーマ、アップロードされた画像ファイルなどがEBSへローカルデータとして保存されている。
RDS - MySQLが走っている。RDSにかんしては今回はMultiAZ使えば大丈夫でしょうという前提ですすめます。

Wordpressをスケーラブルにする時(EC2をいっぱいたてた時)に注意する点

WEBサーバのデータの共有 - Wordpressの場合Wordpress本体のphpリソース、更新にてアップロードされた画像ファイルの同期を考慮する。
セッション情報の保持 - 今回に関してはとりあえず管理画面内のページを考慮すれば大丈夫かと。。
ログ等のデータの保存 - AutoScalingで立ち上がったインスタンスのアクセスログなどはEBS上に保存されているが、出来ればEBSも一緒に破棄してしまいたいのでログはS3にどのインスタンスか分かる形で残しておきたい

スケーラブルにするアーキテクチャ候補

rcyncを使ったインスタンス間でのストレージ領域の同期
- メリット基本的には通常のWordpress環境なので、Wordpressまわりの不具合の心配がない。
- デメリットマスターとスレーブのサーバ構成になるため。ストレージ領域に影響する管理画面での操作はマスターにアクセスされるようコントロールの必要あり。 rcyncはcronでの定期実行になるため、多少のタイムラグが起こる。 AutoScalingでのインスタンスを追加・削除のタイミングでの処理を面倒見なければならない。
特に一つ目がややこしい。ELBはアクセスパスによるインスタンスの振り分けには対応していないため、AWSによらない方法で実現する必要がある。ちなみにCloudFront をいれることで可能になる。
s3cmd,apacheのmod_ext_filterを使った静的コンテンツのみS3から配信する
- メリット S3のマネージドなメリットを享受できる。EC2に関してはマスターのAMIから増やすだけ。AutoScalingにかんする手間が少ない。
- デメリット S3から配信するものを切り分けするルールが重要。ファイルを更新した場合毎回s3cmdを実行する必要がある。自動化するのであれば cronの設定をするなど別の仕組みが必要。
固定化されたソースが多いサイトであれば効果は期待できそうだが、そうでなければ結局一つ目と変わらないこといなりそう。。
CloudFrontのBhaviorで振り分けルールを設定しキャッシュサーバ配信を行う。
- メリット他の選択肢のようなファイルの同期問題がそもそもない。スケーリングもマネージドサービスにおまかせできる。基本EC2一台で大量のアクセスに耐えることが出来る。やすい。
- デメリットセッションを利用するページが多い場合、コントロールが煩雑になる。アクセスに対し、コンテンツをサーバーサイドで動的に変更するようなページには使えない。つまり会員制サイトなどの場合(ECサイトとか)は部分的にしか活用はできない。
今のところこの構成が一番本命。なんといってもキャッシュコントロールの設定さえ決まれば運用での負担はほぼない。
（番外編）EFSを使った共有ストレージ構成 ※今はまだプレビュー
- メリット同期の問題にあったストレージ領域がマネージドサービス型の共有ストレージ領域に展開されるため、同期の問題が解決する。
- デメリットまだあんまり把握できていないのですが、、わりと料金がかかる？感じ。

参考にした本とリンク

実際にrcyncとCloudFrontを使った環境を構築したのでまたアップします。