AWSクラウドを活用したWordPress環境構築・運用のやり方講座

AWSクラウドを活用した
WordPress環境構築・運用のやり方講座
横井公紀
https://www.facebook.com/kiminori.yokoi

なぜ、クラウドにWordPress？

規模の大きな
Webサイトの運営
してみませんか？

波は読めない。突然やってくる。

or
どちらを使っていますか？

200 User
×200
×200 サーバダウン

サーバが落ちた
なんとかしてくれ
増やしましょう

今でしょ！いつ増やしたいの？

物理サーバは
簡単には増やせない

要件の確定→発注→設定
→キッティング
1〜2ヶ月は
かかります

繰り返しますが、
波は突然やってきます

なぜ、波はやってくるのか？
今、見たいから！

どうしたらいいんだ…

あらかじめ
買っておくしかない

波は突然来ますが、
やがて引いていきます

200 User
→ 50 User
×200
→×50
×200
→×50
こんなにいらない

せっかく買ったのに…

200 User
→ 50 User
×200
→×50
×200
→×50
無駄なし！

突然の負荷に強く
お金にも優しい！

AWSにWordPressを構築してみよう！

・Amazon社が提供するクラウドサービス
・使いたいときに、使いたいだけのリソース
・使いたいときに、すぐ使える
・急にアクセスが増えても大丈夫

どうやって使うの？
クレジットカードを準備し、アカウントを作ります。

ログインしてみる
ユーザとパスワードを入れるだけです。

ここにある全てのサービスを使えます。
(使った分だけお金が発生します！)
メニュー画面！

コストを抑えた
負荷に強いサイト

落ちないサイトを
つくるために
・サーバを複数台にして、負荷分散します。
・WordPressとDBとの相乗りをやめます。
・Apacheをチューニングします。
・そしてAWSでAuto Scaling！

基本構成
EC2
Availability Zone #1

負荷分散構成 ※不完全
EC2
EC2
ELB
(AWSのロードバランサ)

EC2
EC2
WordPressの記事データは
MySQL (データベース)に保存されます

EC2
EC2
2台にしたら、どっちに保存される？

EC2
EC2
RDS
DBを共通の参照先にする必要が
あります。

EC2
EC2
RDS
DBも冗長化できます。
(Multi-AZ機能)
RDS
データを自動で
レプリケーションします。

EC2
EC2
RDS
片方のDBが落ちると
自動で切り替わります
RDS

EC2
EC2
RDS

あなたのWordPress
同時に何人
接続できますか？

httpd.conf
MaxClientsが256だから、
256までいける！

httpd.conf
MaxClients (が256だから、
256までいける！
↑
おそらく
かなりの確率で
違います

httpd = Apache
Apacheのプロセス
(リクエスト処理中と
待機中を含みます)

消費メモリ
メモリ消費を
見てみましょう。
1プロセスあたり
60MBほど
消費していますね。

メモリの総容量
そもそも、どれだけのメモリが使えるのかを
知っておく必要があります。

自分のサーバ(WordPress)の
限界を知ろう！
メモリ全体:
3,858,708 (KB) ※m3.medium / 3.75GB
Apache 1プロセスあたりのメモリ消費:
約60,000 (KB)
起動できるApacheのプロセスは・・・
3,858,708 ÷ 60,000 = 約64

設定では256プロセスまで
起動するようになっているけど
実際は64プロセスまでしか
起動できないようです。

※今の説明には注意が必要です
・物理メモリを全てApacheに割り当てた前提の
試算になります。
・実際は他のプロセスでもメモリを消費しています。
よって、もっと厳しく、余裕を見て、
メモリ消費量の見積をしなければなりません。
だから、メモリをApacheに最大限使わせるためにも、
WordPressとMySQLは別サーバにしたほうが良いのです。

256個まで起動
と書いてある
EC2
実際は
64個までしか
起動できない

そしてサーバダウンへ
・Apacheの設定ファイルには
「最大256プロセスまで起動する」と書いてあります。
Apacheは設定ファイルを読み込んで、
256プロセスまでは、起動しようと頑張ってしまいます。
・ところが、実際は64プロセスまでしか起動できないため、
メモリに空きがなくなり、プロセスを起動できなくなります。

Apacheを起動すると、
・まず8プロセスが起動し待機
・アクセスがない場合、
待機プロセスを5まで減らす。
・アクセスが増えてくると
処理プロセスが増えて、
待機プロセスが減るため
待機プロセスを20まで増やす。
・処理/待機合わせて256プロセスまで。
(ただし、待機<=20)

プロセスを増やす
= メモリ消費が増える
だけではない！

プロセスを増やすために
CPUを使います
・Linuxではプロセスを起動するとき、CPU利用率が
跳ね上がります。
・つまり、先ほどのような設定にしていると、
待機プロセスが足りなくなる → プロセスを起動
→ CPU利用率が上がるの繰り返しとなります。

そしてサーバダウンへ (2回目)
・「アクセスが集中したとき、動的にプロセス数を増やす」
このApacheの仕組みは便利なものですが、
先ほどの理屈から、CPU消費が跳ね上がっていきます。
・プロセスの起動を繰り返すうち、
応答を返さなくなることがあるのです。
これでは本末転倒になってしまいます。

Apacheの設定を
変えてみよう！

・アクセスがなくても
待機プロセスは50のまま。
待機プロセスが処理プロセスに変わる。
(処理プロセスが50のとき、
待機プロセスは0)

・アクセスがなくても
待機プロセスは50のまま。
待機プロセスが処理プロセスに変わる。
(処理プロセスが50のとき、
待機プロセスは0)
無駄にプロセスの
起動が発生せず
CPU利用率の増加を
防ぐことができます

1プロセスあたりの
メモリ消費が膨れ上がらないように
様子を見つつ設定しておきましょう。

MaxRequestsPerChildは
CPUとメモリのトレードオフ
・「1プロセスあたり処理できるリクエスト数」
を設定します。リクエスト数が設定値に達すると、
プロセスを落とし、新しいプロセスを起動します。
・多ければ多いほど、メモリ消費が上がりますが、
プロセスが長生きしますので、CPU消費は上がりません。
・小さいとメモリ消費は小さくなりますが、
プロセスの起動が頻発し、CPU消費が上がります。

自分のサーバ(WordPress)の
限界を知ろう！
メモリ全体:
3,858,708 (KB) ※m3.medium / 3.75GB
Apache 1プロセスあたりのメモリ消費:
約60,000 (KB)
起動できるApacheのプロセスは・・・
3,858,708 ÷ 60,000 = 約64
この見積は、MaxRequestsPerChildの
設定次第と言えるでしょう。

落ちないサイトを
つくるために
・サーバを複数台にして、負荷分散すると
落ちにくくなることが分かりました。
・自分のサーバの限界に合わせてApacheを
設定できるようになりました。

ここまでの前置きがあって、
AWSを活用しよう！
という話ができます。

Auto Scaling機能で
「限界」を超えよう！

Auto Scalingとは？
・AWSの標準機能で、サーバの負荷状態に応じて、
自動でサーバを増減します。
・たとえば、
「CPU利用率が5分平均80%を超えたら、1台起動」
「CPU利用率が10分平均10%を割ったら、1台停止」
といったことが可能です。

http://www.slideshare.net/horiyasu/20131206-‐reduce-‐costbyawsver2引用:
AWS堀内康弘様「AWSでコストを削減できる理由」

http://www.slideshare.net/horiyasu/20131206-‐reduce-‐costbyawsver2引用:
AWS堀内康弘様「AWSでコストを削減できる理由」
アクセスが少ない時は、1台分の費用
アクセスが増えた時だけ、N台分の費用

設定例
CPUの利用状況に応じて
サーバを増やす！

CPU利用率でサーバの増減
・先ほどのチューニングができている前提だと、
アクセス数が爆発的に増加している
= プロセスの起動が頻発している
= CPU利用率が増加する
・CPU利用率が上がると、レスポンスが悪くなります。
サーバを増やして、負荷を分散してあげましょう。

ネットワーク(In)の状況に
応じて、サーバを増やす！
設定例

ネットワーク(In)でサーバの増減
・先ほどのチューニングができている前提だと、
アクセス数が爆発的に増加している
= ネットワーク(In)が増加している
= 1プロセスあたりのメモリ利用率が増加する
・やはりサーバを増やして、負荷を分散してあげましょう。

Auto Scalingで運用してみよう
・先ほどまで説明してきたように、
1台のサーバで処理できるリクエストには限界がありますが
サーバの台数を2台にすれば、2倍処理できます！
・2台に増やすとその分費用が発生しますが、
高スペック1台を常時起動するよりも安価で済みます。
CPUやネットワークの状況を見つつ、財布と相談して
増やし方を検討します。

AWSで費用が
発生するポイント
・サーバの起動時間とスペックに応じて
費用が発生します。
・対インターネットに通信する
データのサイズ(Out)に応じて
費用が発生します。

Spot Instanceを活用しましょう
・AWSの余剰リソースを使ってサーバを起動する
「Spot Instance」を使うと、費用を格段に落とすことが
出来ます。
・Spot Instanceでは、インスタンスの時間価格が入札価格
(= 1時間あたりいくらまでなら払う？)を
を上回るとサーバが落ちてしまいます(常時起動の保証なし)
が、入札価格>>>>>>>>時間価格にしておくと落ちません。

1時間あたり、$0.0117
= 1時間1.4円！

入札価格をこのへんにしておけば落ちない
値動きは、直近3ヶ月
ほぼ全ての日で
$0.01〜$0.02/時間
※「落ちない」とはSpot
Instanceの仕組み上落ちないという意味です。

AWS EC2インスタンス
月額費用比較
m3. mediumの場合
オンデマンド(通常契約): $70.28
リザーブド(1年分前払い): $39.25
スポット: $8.7 ！！！
※リザーブドとは指定期間分の料金を前払いすると、期間中の総額がオンデマンドより安くなる特典です。

上記に記載の費用は、前払費用を12で割り、月額費用に換算したものとなります。

サーバ10台同時に起動しても
月額1万円くらい！！

通信量(Out)を
抑えるには？
・Apacheで、コンテンツを圧縮して
返すように設定しましょう。
(物によりますが、
大きいと1/8くらいまで抑えられます。)
・mod_deflate を有効化しましょう。

まとめ
・AWSで負荷に強く、安価にサイトを
運用できます。
・自分のサーバの限界を知った上で、
Apacheを設定しましょう。
・「限界×サーバ台数」を意識した
Auto Scalingと、Spot Instanceの
活用で、徹底的低コストに運営しましょう。

まとめ
・何もかもデフォルト任せではなく、
「どうやって動いているか？」
「どうやったら早くなるのか？」
を突き詰めていくのが、構築の
面白いところです。
・自分で仕組みをきちんと理解すれば、
トラブル対応も楽になるはずです。

AWSとWordPressの組み合わせで
負荷に強いサーバを
安価に運営しよう！

AWSクラウドを活用したWordPress環境構築・運用のやり方講座

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Último

Último (9)

AWSクラウドを活用したWordPress環境構築・運用のやり方講座