トップ > AWS > Nginx + WordPress ELB篇

Nginx + WordPress ELB篇

AWS WordPress
記事タイトルとURLをコピーする

こんにちは。CSチームの坂本です。

今回も、前回の「Nginx + WordPress RDS篇」に引き続き、「Nginx + WordPress ロードバランサー篇」の構成での運用上の問題点を、AWSのサービスを使って解消していきたいと思います。

画像のアップロード先とデータベースサーバーの問題は解決しましたが、NginxのロードバランサーがまだSPOF（単一障害点）となっています。今回はAWSのサービス「Amazon ELB」を使ってこの問題を簡単に解決したいと思います。

目次

  1. 1. はじめに
  2. 2. 今回の構成
  3. 3. Amazon ELBとは？
  4. 4. ELBの作成
  5. 5. Webサーバーのセキュリティグループの設定変更
  6. 6. 動作確認
  7. 7. ELBの仕組みの確認
  8. 8. まとめ

 

1. はじめに

今回利用するAWSのサービスは「Amazon ELB」というAWSのロードバランサーサービスです。このサービスを使うことでSPOFにならないロードバランサーの環境が簡単に構築できます。

どれだけ簡単に構築できるのかは、後述の4. ELBの作成で確認してみてください。

 

2. 今回の構成

前回までの構成で利用していたNginxのロードバランサーをELBに置き換えてみます。

  3. Amazon ELBとは？ ELBとは「Elastic Load Balancing」の略で、複数のEC2の「トラフィックの負荷を分散」してくれるAWSのロードバランサーサービスです。 異なるゾーン（物理的なサーバーの置き場所がわかれている）にあるEC2インスタンスに振り分けができますので、前回のRDSのMulti-AZと似たようなイメージで1ゾーンで障害が発生した場合にも備えられます。 更に、「ELBのロードバランサーの数自体」も、トラフィックの負荷に応じて「自動的に増減」する仕組みとなっていますので、負荷が増加した場合も手動でロードバランサーの数を増やす必要がありません。 「Elastic」という文字通り、まさに「柔軟」に対応してくれるサービスなのです。 上の図で確認すると、Nginxのロードバランサー1台がELBというロードバランサー1台に変更されたかのように感じてしまうかもしれませんが、ELBはサービス名であり、1台のロードバランサーを表すものではありません。   4. ELBの作成 それでは、どのくらい簡単に構築できるのか確認するために、実際にELBを作成してみましょう。 まず、AWS Management ConsoleのEC2の画面の左側のメニューから「Load Balancers」を選択し、「Create Load Balancer」ボタンを押します。

「Create New Load Balancer」ウィザードが表示されますので、「Load Balancer Name」に適当な名前（今回はwordpress）を入力して進みましょう。

次の画面では、EC2のインスタンスのヘルスチェックの設定をおこないます。動的なサイトですので、「Ping Path」の値を「/index.html」から「/index.php」に変更して進みます。 ※ヘルスチェックに使う「index.php」は、事前にWebサーバーのドキュメントルートに置いてください。

次に負荷分散先のWebサーバーを選択します。 同じゾーンにWebサーバーを配備して分散することも可能ですが、「耐障害性を高める」ためにも今回は別々のゾーンにWebサーバーを配備します。事前に別々のゾーンにEC2インスタンスを準備しておきましょう。 その際に注意点があります。ELBは以下の仕様となっているので気をつけてください。

  1. ゾーン間で均等に配分
  2. EC2のインスタンスタイプを考慮しない

上記を念頭に入れて、各ゾーンに配備するEC2インスタンスの数とインスタンスタイプは事前に同じにしておきましょう。

今回はTokyoリージョンの各ゾーンに1台ずつ、計3台のt1.microインスタンスを準備しました。3台ともチェックを入れて次に進みます。


▲Tokyoリージョンの3つのゾーン（ap-northeast-1a、 ap-northeast-1b、 ap-northeast-1c）に各1台ずつ準備
  「Create」ボタンを押してしばらく待つとELBの作成が完了します。

「Description」タグを選択すると、この後の手順で利用する「DNS Name（wordpress-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com）」と「Source Security Group（amazon-elb/amazon-elb-sg）」が確認できます。

  5. Webサーバーのセキュリティグループの設定変更 ELBが作成できたら「ELBからのアクセスのみ許可」するように、Webサーバーのセキュリティグループの設定を変更します。 左のメニューで 「Security Group」を選択し、Webサーバーで使用しているセキュリティグループにチェックを入れます。 そして、現状はどこからでもアクセスを受け付けるように画面の右下の辺りで設定されていますので、「Delete」をクリックしてその設定を削除しておきましょう。 次に、「Inbound」タグの「Create a new rule」で「HTTP」を選択し、「Source」に「amazon-elb/amazon-elb-sg」と入力して「Add Rule」ボタンを押します。 最後に「Apply Rule Changes」ボタンを押して設定を確定させましょう。

画面右下で設定が変更されたことを確認して完了です。

  6. 動作確認 では、実際に振り分けされているか、簡単に動作確認してみましょう。 各Webサーバーの「/usr/share/nginx/html/wordpress/index.php」に「echo "ap-northeast-1a";」と各ゾーン名が表示されるようにコードを追加します。

define('WP_USE_THEMES', true);

echo "ap-northeast-1a";

/** Loads the WordPress Environment and Template */
require('./wp-blog-header.php');

 

「ap-northeast-1b」、「ap-northeast-1c」のEC2インスタンスにも追加し、ブラウザからアクセスして確認してみましょう。

まずは「ap-northeast-1a」に振り分けられたことが確認できました。

次に、「index.php」でヘルスチェックをおこなっていますので、「PHP-FPM」を落として他のサーバーに振り分けられるか確認してみましょう。 今回は、「ap-northeast-1b」に振り分けられることを確認するために、「ap-northeast-1a」と「ap-northeast-1c」の「PHP-FPM」を終了させました。

sudo /etc/init.d/php-fpm stop
Stopping php-fpm:                                          [  OK  ]

 

問題なく「ap-northeast-1b」に振り分けられたことが確認できました。

  7. ELBの仕組みの確認 最後に、ELB作成後のロードバランサーの数を確認してみます。 「ELBはサービス名であり、1台のロードバランサーを表すものではない」ということは最初に触れました。実際、ELB作成後はどのような状態になっているのでしょうか。 ELBは以下の仕組みとなっているそうですので、それを念頭に入れてdigコマンドで確認してみます。

  1. ELBのそれぞれのロードバランサーはグローバルなIPアドレスを持っている
  2. ELBへのアクセスはドメイン名でおこなわれる
  3. ドメイン名の名前解決の際、配下のロードバランサーのIPアドレスがランダムに並べて返される
dig wordpress-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com A

;; QUESTION SECTION:
;wordpress-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com. IN A

;; ANSWER SECTION:
wordpress-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.xxx.xxx.69
wordpress-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.xxx.xxx.210
wordpress-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com. 60 IN A 54.xxx.xxx.241

 

3つのIPアドレスが返されました。現状はアクセス数が少ないので、各ゾーンに1台ずつロードバランサーが配備されている状態のようです。

今回、負荷試験はおこなっていませんが、アクセス数が増えるとロードバランサーが自動で増加し、返されるIPアドレスが増えるはずです。

 

8. まとめ

Webサーバーを負荷分散した場合のロードバランサーのSPOFの問題を、ELBを使って簡単に解消することができました。

これで現状の構成でSPOFとなっている箇所はありません。

ですが、AWSには他にもさまざまなサービスがありますので、それらを利用して日々の運用が楽になるように、もう少しカイゼンしてみましょう。

次回は、3台のEC2インスタンスの内、1台がダウンしてしまった場合に自動で新しいWebサーバーを立ち上げて「常に同じ構成で運用」できるようにしたいと思います。