AWS ELB
4ヶ月ぶりにダーツ部が活動しました。
ぜんっぜんダメでした。
3時間投げても、4ヶ月前の投げ方がわかりませんでした。
1年ぐらい前に三ヶ月間ほど週二で通って身につけてフォームもブランク空くと分からなくなるもんです。
ブログはそうならないように頑張ります。
さて、本題。
前回はAMIを利用してEC2インスタンスを複製し、
同一構成のEC2インスタンスを2つのAZに分けて配置しました。
ただし、これだけでは2つのWebサーバがあるだけで、
負荷分散も冗長化も構成されていません。
入口となるグローバルIPアドレス、DNSがバラバラだからです。
一般的な負荷分散方式としてDNSラウンドロビンを使ったDNSによる負荷分散、
ロードバランサーを入口に置くことで振り分けてもらうことによる負荷分散があります。
前者は負荷分散としては意味がありますが、冗長化の観点では役に立たないため、あまり採用されません。
ロードバランサーの過負荷となる場合にロードバランサーを複数並べてDNSラウンドロビンして負荷分散することは可能です。
ただし、この場合も各ロードバランサーを冗長化しないと、意味を成し得ません。
またGSLBのようにDNSによって死活監視を行うことでDNSレコードをダイナミックに切り替えるシステムを使うことでロードバランサーの負荷も、そもそもロードバランサーを置く必要がなくなる仕組みもあります。
AWSのRoute53を使えば簡単に組むことができます。
、、、今調べたらELBは負荷に応じてスケーリングするようです。
AWSさん、さすがです。
今回はELBを起動して、
2つのWebサーバを負荷分散、冗長化できる構成を組みます。
EC2でWebAP構築
↓
RDSでWebAP-DB構築
↓
AMIでEC2のイメージ化、複製
↓
ELB (Elastic Load Balancing)
ELBはロードバランサーです。
通信を振り分けてくれることにより負荷分散してくれたり、
負荷分散対象を監視し、ダウンした対象を切り離すことで冗長化構成としてくれます。
ELB作成
- EC2画面へ遷移
AWSのメニューからEC2を選択します。
ELBはEC2画面より作成します。AWSのポータルが日本語対応しました。
アマゾンジャパンの方、本当にありがとうございます。
- ELB作成
左のメニューからロードバランサーを選択します。
「ロードバランサーの作成」ボタンを押下します。
- ロードバランサーの定義
基本情報を入力します。
ロードバランサー名
: 名前です。DNS名にも利用されます。
今回はlbとします。
内部向け LB の作成
: 作成する対象のVPCを指定します。
内部向けロードバランサーの作成
: インターネットに開放せず、内部からのアクセスのみの場合、
こちらをチェックしてください。
ロードバランサーのプロトコル/ロードバランサーのポート
: アクセス元が指定するプロトコル/ポート番号です。
今回は80番ポート(http)を利用します。
インスタンスのプロトコル/インスタンスのポート
: ロードバランサーがインスタンスにアクセスするプロトコル/ポート番号です。
今回は80番ポート(http)を利用します。
サブネットの選択
: バランシン対象が存在するサブネットを選択します。
今回は2つのazにあるpublic networkを選択します。
EC2インスタンスに設定したサブネットです。
- セキュリティグループの割り当て
80番ポートが空いていればいいのでEC2インスタンスに割り当てたセキュリティグループを選択します。
- セキュリティ設定の構成
httpだと注意されます。。
- ヘルスチェックの設定
ELBがEC2インスタンスを監視する方式を指定します。pingプロトコル
: HTTP、HTTPS、SSL、TCPから選択します。
今回はHTTPを利用します。
pingポート
: そのポート番号です。
今回は80番ポートを利用します。
pingパス
: ヘルスチェック先パスを指定します。デフォルト値は「/index.html」です。
SSL、TCPの場合、指定不要です。
応答タイムアウト(秒)
: ヘルスチェックの応答待ち時間を指定します。デフォルト値は「5」です。
ここで指定した時間以内に応答がない場合、NGと判断します。
ヘルスチェック間隔(秒)
: ヘルスチェックを行う間隔を指定します。デフォルト値は「30」です。
非正常のしきい値
: EC2インスタンスがダウンしたと判断するヘルスチェックNG連続回数を指定します。
デフォルト値は「2」です。
正常のしきい値
: EC2インスタンスがアップしたと判断するヘルスチェックOK連続回数を指定します。
デフォルト値は「10」です。デフォルト設定の場合、30秒ごとに監視対象サーバに向けて、
http://<対象サーバ>/index.html
のリクエストを発行し、5秒間応答がない、を2連続検知すると、
監視対象サーバがダウンしたと判断します。
- EC2 インスタンスの追加
振り分け対象のサーバを指定します。
今回は作成したWebサーバ2台を選択します。クロスゾーン負荷分散の有効化
: LBが存在するEC2インスタンスにしか振り分けない場合、こちらのチェックを外してください。
Connection Drainingの有効化
: LBがEC2インスタンスを強制的に切り離す時間を設定します。
ファイルダウンロード等長時間のリクエスト処理があった場合、
切り離してもここで指定した秒数は待つ、という設定です。
メンテナンス等で片系切り離して設定変更などする時に大変有用な機能です。
- タグの追加
- 確認
LBが作成されます。
- 作成状況確認
一覧画面へ遷移します。作成されたELBを選択して、概要タブを選択します。
ステータスが「2 個のうち 2 個のインスタンスが実行中です」となっていれば準備完了です。
DNS名はメモってください。インスタンスタブを選択します。
インスタンスの各ステータスが「InService」となっていることも確認します。
- 動作確認
それでは接続しましょう。
その前に、、、
接続先がわかるように各Webサーバのindex.htmlをホスト名等分かり易いように編集してください。$ curl http://lb-*********.ap-northeast-1.elb.amazonaws.com/index.html ip-192-168-100-35
Web#2(複製先)へアクセスされました。
それではもう一回。$ curl http://lb-*********.ap-northeast-1.elb.amazonaws.com/index.html ip-192-168-0-54
Web#1(複製元)へアクセスされました。
はい、ちゃんとバランシングされていますね。次に片系を落としてみて切り離されることを確認しましょう。
今回はWeb#2を落とします。
[root@ip-192-168-100-35 ~]# /etc/init.d/httpd stop Stopping httpd: [ OK ]
15秒ぐらいでWeb#2のステータスがOutOfServiceとなりました。
それでは接続$ curl http://lb-*********.ap-northeast-1.elb.amazonaws.com/index.html ip-192-168-0-54
Web#1にアクセスされました。
10回ほどアクセスしても全てWeb#1へアクセスされました。Web#2を起動します。
[root@ip-192-168-100-35 ~]# /etc/init.d/httpd start Starting httpd: httpd: apr_sockaddr_info_get() failed for ip-192-168-100-35 httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName [ OK ] >|| 10分ほどでWeb#2のステータスはInServiceとなりました。 >|| $ curl http://lb-*********.ap-northeast-1.elb.amazonaws.com/index.html ip-192-168-0-54 $ curl http://lb-*********.ap-northeast-1.elb.amazonaws.com/index.html ip-192-168-100-35
またWeb#2へ振り分けられるようになりました。
以前、ELBは切り離されたインスタンスはアップしても自動復旧しない(ELBに組み込まれない)という情報を得たのですが、改善したようです。
いかがでしたでしょうか?
AWSを使えば負荷分散、冗長構成のWebAPシステムを簡単に構成することが出来ます。
メンテナンスも考慮されたシステムとなっており、インフラ担当の悩みをどんどんAWSが吸収してくれます。
インフラ担当の運用・保守をAWSに任せることができるので、
その分、楽しい楽しい開発業務に専念することができます。
次回はElastic Cacheを利用してステートレスのWebAP構成を作りましょう。