【WEBサーバの構築】③
基本的にはECを使った「その④」の続きとなります。
負荷分散とELB
負荷分散の仕組み
一般的なサービスでもサーバに障害が発生したときでもサービスを継続するために可用性を高めるための冗長化の仕組みがとられています。冗長化とは予備系のサーバなどを用意することですが、単に複数台を用意するだけでは無駄が生じます。
そこで一般的には冗長性と同時に通常時の処理性能も上げる負荷分散の仕組みとしてロードバランサが用いられるます。
サーバへの処理を複数の機器に割り振ることによって、特定の危機に負荷が集中するのを防ぐこともできます。
AWSでは負荷分散の仕組みとしてELB(Elastic Load Balancing)が用意されています。
ELBとは
Elastic Load Balancing は受信したアプリケーションまたはネットワークトラフィックを、Amazon EC2 インスタンス、コンテナ、IP アドレス、複数のアベイラビリティーゾーンなど、複数のターゲットに分散させます。Elastic Load Balancing はアプリケーションへのトラフィックが時間の経過とともに変化するのに応じてロードバランサーをスケーリングし、大半のワークロードに合わせて自動的にスケーリングできます。
ELBの種類としては以下の3種類があるようですが、単にELBといった場合はClassic Load Balancerを指す場合が多いようなのでここでもそれ従い単にELBといった場合はClassic Load Balancerを指すこととします。
・Classic Load Balancer
・Application Load Balancer
・Network Load Balancer
EC2の無料枠
私が確認した現時点のもので、無料枠は以下の通りです。
各自で要確認です。
Elastic Load Balancing
無料利用枠 12 か月間無料
・750 時間/月のロードバランサー時間分を Classic load balancers と Application load balancers の間で共有
・15 GB の Classic load balancer でのデータ処理
・15 LCU の Application Load
基本的にはEC2とセットで使用される前提で750時間は使用可能になっているのでしょう。
ELBの活用
今回はELBを導入し以下の構成を構築することを目指します。
カスタムAMIによるEC2インスタンスの作成
まずは冗長構成をつくるためにEC2インスタンスを複数作成する必要があります。
手動で作成同じものを作成することも可能でしょうが、一般的に同じものを複数作成する場合は手動よりもコンピュータに任せた方がミスが最小限になるため実践的でしょう。
ここではカスタムAMIという機能を使用します。
①インスタンスの停止
以前作成したインスタンスが停止していない場合は、以下のメニューから停止を行います。
アクション>インスタンスの状態>停止
②イメージの作成
アクション>イメージ>イメージ作成 を押下。
イメージ名とイメージ説明を入力しイメージ作成を押下。
他の項目はそのままでいいらしい。
これでOK。
③AMIの確認
AMIからを押下すると今作成したものが確認できる。
④カスタムAMIからEC2インスタンスを生成
対象のAMIを右クリックするとメニューが表示されるので起動を押下。
ここから先は最初に作成したときと同様の操作を行う。覚えていない場合はその④の以下を参照。
【EC2インスタンスの起動】
・EC2インスタンスの生成
「④インスタンスタイプ」以降
注意点としては「⑥インスタンスのタグ付け」の部分でNameタグを別の名前にしておくこと。
私の場合は以下の2つにした。
・image1server
・image2server
後はセキュリティポリシーやキーペアは既存のものを使用すればいい。
一個生成できたらもう一個生成する。
⑤動作確認の準備
通常負荷分散によるサーバは全く同じ構成にするでしょうが今回は動作確認をするために表示内容でどちらのサーバに接続しているかわかるようにしておきます。
確認のための操作なので構築には必須ではないです。
teratermを起動してどちらかのサーバに接続します。
接続方法は同じく過去記事の通りです。
ここでSSH接続すると分かるのがサーバのファイルなどがイメージを作成した元のサーバの通りになっていることですね。
あまり分からずにやっていたのですがこれがイメージから作成した効果ですね。
方法は問いませんが以下を編集します。
・/var/www/html/index.html
当該ディレクトリに移動して
cd /var/www/html/
vimで編集すればいいでしょう。
sudo vim index.html
ホストで編集して置き換えてもOK。
編集が済んだらブラウザにIP直打ちで変更が反映されていることを確認します。
・image1server(以下、1号機)
・image2server(以下、2号機)
大丈夫みたいですね。
ELBによる負荷分散構成の構築
いよいよロードバランサ(ELB)を導入します!
①ELB作成画面を開く
左側のメニューからロードバランサを選択。私の場合はスクロールして下の方にありました。
②ELBの基本設定
ロードバランサーの作成を押下。
上の説明でも少しふれましたが「Classic Load Balancer」を選択します。
ロードバランサ名に任意の名前を入力。
場所はデフォルトで大丈夫そうです。
③ELBのセキュリティグループ設定
以下の感じで設定すればOK。
セキュリティ構成については一旦そのままでいきます。
SSL証明書をインストールしてHTTPS通信を有効化する場合がここの設定みたいです。
④ヘルスチェックの設定
機器の障害チェックのアレですね。私はオンプレの設定したことがないので理論上しかしりませんでしたが、あぁなんだか楽しい。
とりあえず設定上の要件はありませんのでそのままでいきます。
⑤EC2インスタンスの選択
ここでここまでで作成した二つのEC2インスタンスを選択します。私の場合は以下の2つです。
・image1server
・image2server
⑥タグの作成
任意のNameタグを作成します。
その後作成を押下し以下の完了画面が表示されればOK。
⑦ELBの動作確認
インスタンスタブからインスタンスの状態を確認する。
ステータスの状態
OutOfService:インスタンスが利用できない
InService:インスタンスが利用できる
なぜか「OutOfService」から状態が変わらない。。
さぁ調査だ!
原因調査
①ヘルスチェック設定の見直し
ネット上で検索してまず表示されるのがここでした。
index.htmlではなくhealth.htmlのヘルスチェック用のファイルを作成しておいているものが多かったので
EC2インスタンスの「/var/www/html/」にhealth.htmlを配置し、ヘルスチェックのping ターゲットもhealth.htmlに変更。
しばらく待ちましたがダメでした。
調査が難航しましたが、セキュリティグループに関する記述を発見。
②セキュリティグループの設定見直し
見つけたのは「セキュリティグループに自分のグループIDが追加されてないとダメ」というものだったので設定変更。
これも通用しない。
ここでさすがに気付きました。
問題はEC2に設定しているセキュリティグループでした。
以前私がEC2インスタンスを生成したときに、セキュリティを強固にするために一応接続元が私のIPのみから受け付けるようにしていました。
これがいけなかったのです。
EC2側の設定したセキュリティグループのインバウンドが私のIPのみから接続を許可していたので、ELBからの接続も許可するようにしなければなりません。
以下汚い図
設定内容としては
サイドメニューの「ネットワーク&セキュリティ>セキュリティグループ」からEC2に設定したセキュリティグループを開きインバウンド側に以下を追加しました。
IPではなくてセキュリティグループでソースを設定できるようなので、ELBに設定したセキュリティグループのグループIDからの接続を許可します。
タイプ | プロトコル | ポート範囲 | ソース |
---|---|---|---|
HTTP | TCP | 80 | ELBに設定したセキュリティグループのグループID |
ここまでしなくてもソースを全て許可してもいいかもしれない。
とりあえず構築経験がある人なら割とすぐに気付きそう。
「InService」になりました!
私と全く同じ設定にした場合、同様のことがおきると思います。
結果的に「①ヘルスチェック設定の見直し」の対応はしなくてもたぶん大丈夫で、②のインバウンドの設定のみすればOKと思います。
サーバは起動していてもヘルスチェックが正常にできてないとLBからは接続できなくなことが体感できて、インフラ素人には悪くない経験でした。
⑧ELBの動作確認
作成したELBの「DNS 名 」をコピーしてブラウザからアクセスします。
1号機と2号機それぞれが使用されていることを確認できました。
なぜか2号機がなかなか使用されませんでした。
振り分けのルールは単にラウンドロビンではないような気がしますが現時点ではどうなっているか不明。さすがにどっかに記述があるのかな?
エラー対応で疲れたので今回はここまで。独自ドメインとかDNSの設定とかもあるみたいですが、次回からは一旦WEBプリケーションサーバの構築に入りたいと思います。
RDSとかも使う予定。