WordPressを高可用構成するための記事やプレゼン資料をいくつか集めてみましたよ。
運用コストの参考資料
 |
| リンクしてます |
SlideShareに興味深いプレゼンテーションがありました。
・AWS+WordPress - AWSでスケーラブルなWordPressサイトを構築しよう
1.5万〜2万PV／日のWordPressサイトを運用しているで月額費用は1.5万円程度ということで目安としていいのではないでしょうか。
こちらの例では、EC2をオートスケールさせてピーク時は６台ほど稼働しているように思われます。 データベースはRDSは１台で運用のようです。
RDSはマルチAZにしておかないと、ちょいちょい止まる気がするのですが・・・
というところで、マルチAZな構成例を探すと、
AWS上にマルチAZで構成
 |
| Tutorial: Highly Available WordPress (Part II) |
英語サイトでなんですけど。
AWS（アマゾン・ウェブ・サービス）上にロードバランサー（ELB）を使って負荷分散を行いつつElastiCacheクラスタを用いる方法は先の例と同じです。
apache benchコマンドを使いインスタンスタイプ毎とNginxとApacheとのベンチマーク結果も紹介されていますので、m1インスタンスですが参考になるのではないでしょうか。
Nginxだけピックアップすると：
- m1.small+ElastiCache+WordPress3.5（Nginx）：80 request/sec
- c1.medium+ElastiCache+WordPress3.5（Nginx）：280 request/sec
- m1.large+ElastiCache+WordPress3.5（Nginx）：200 request/sec
インスタンスタイプがm1/c1混在ですので結果としては微妙だけど。
m1.medium（今なら、m2.medium）を用いるとして140 request/sec強のパフォーマンス程度は見込めると考えて良さそうですね。
マルチAZに配備したEC2インスタンスにELBをアタッチしてGlusterFSで同期させていますが、AZ間アクセスでのコストが気になります。
ここはもう少しシンプルに、カスタマイズしたAMIを作成して使う方法でもいいんじゃないかな。
RDSをマルチAZ＋AutoScaleでEC2インスタンスを増減させるのが良いのかね
なににせよデータベースが一番のネックになりやすいため、そこだけ手厚くしておきたいです。
そうすると、データベースはRDSをマルチAZ構成となりますが個人的にはmariadbをEC2で使ってもよいのではと思ったりもします。
もしくは、amazon aurora、ただ運用コストが合えばですが。
auroraの良いところはdbデータをs3に保持してサーバインスタンスの稼働はアマゾンが動作（SLA）を保証してくれるところ。 ユーザからみると止まらないDBという理解でいいのでしょう。
次は、Webサーバのパフォーマンスですが
単純計算で、毎秒100リクエスト／インスタンスをさばければ、ロードバランサーで分散させるとして200リクエスト／秒、１時間なら720,000リクエスト、１日なら1700万リクエストは応答できそうだからオートスケール立てなくても良さそう。
インスタンスがフリーズした時のことを考えて、autoscaleは設定するとしてもインスタンス数は２本常時でピーク対応として最大４インスタンスを設定しておけばいいでしょう。
それから気になるところは、
ElastiCacheをmemcachedにするとマルチAZクラスターにはできなようですので、そこのところは単純にAZ毎に配置させればなんとかなりませんかね。
ということで・・・
AWS上にWordPressを立ててみて様子をみたいと思います。
RDS(auroradb）＋ElastiCache＋ELB＋autoscale＋CloudWatch＋EC2 ２台＋２台（Nginx）で。
先にRDS（aurora）のコストをチェックしてからだね。
費用の目安は15000円〜20000円／月額になりそうな感じ
う〜ん、ちょっとお高い。。。