SEワンタンの独学備忘録

IT関連の独学した内容や資格試験に対する取り組みの備忘録

【AWS】入門その⑤ ELBでEC2の負荷分散をしてみよう

【WEBサーバの構築】③

基本的にはECを使った「その④」の続きとなります。

www.wantanblog.com

負荷分散とELB

負荷分散の仕組み

一般的なサービスでもサーバに障害が発生したときでもサービスを継続するために可用性を高めるための冗長化の仕組みがとられています。冗長化とは予備系のサーバなどを用意することですが、単に複数台を用意するだけでは無駄が生じます。
そこで一般的には冗長性と同時に通常時の処理性能も上げる負荷分散の仕組みとしてロードバランサが用いられるます。
サーバへの処理を複数の機器に割り振ることによって、特定の危機に負荷が集中するのを防ぐこともできます。

AWSでは負荷分散の仕組みとしてELB(Elastic Load Balancing)が用意されています。

ELBとは

Elastic Load Balancing は受信したアプリケーションまたはネットワークトラフィックを、Amazon EC2 インスタンス、コンテナ、IP アドレス、複数のアベイラビリティーゾーンなど、複数のターゲットに分散させます。Elastic Load Balancing はアプリケーションへのトラフィックが時間の経過とともに変化するのに応じてロードバランサーをスケーリングし、大半のワークロードに合わせて自動的にスケーリングできます。

引用元:Elastic Load Balancing とは - 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時間は使用可能になっているのでしょう。

AWS クラウド無料利用枠 | AWS

ELBの活用

今回はELBを導入し以下の構成を構築することを目指します。

f:id:wantanBlog:20190721022518p:plain

カスタムAMIによるEC2インスタンスの作成

まずは冗長構成をつくるためにEC2インスタンスを複数作成する必要があります。
手動で作成同じものを作成することも可能でしょうが、一般的に同じものを複数作成する場合は手動よりもコンピュータに任せた方がミスが最小限になるため実践的でしょう。

ここではカスタムAMIという機能を使用します。

①インスタンスの停止

以前作成したインスタンスが停止していない場合は、以下のメニューから停止を行います。

アクション>インスタンスの状態>停止

②イメージの作成

アクション>イメージ>イメージ作成 を押下。
f:id:wantanBlog:20190721023553p:plain

イメージ名とイメージ説明を入力しイメージ作成を押下。
他の項目はそのままでいいらしい。
f:id:wantanBlog:20190721024059p:plain

これでOK。
f:id:wantanBlog:20190721024232p:plain

③AMIの確認

AMIからを押下すると今作成したものが確認できる。
f:id:wantanBlog:20190721024710p:plain

④カスタムAMIからEC2インスタンスを生成

対象のAMIを右クリックするとメニューが表示されるので起動を押下。
f:id:wantanBlog:20190721025110p:plain

ここから先は最初に作成したときと同様の操作を行う。覚えていない場合はその④の以下を参照。

【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号機)
f:id:wantanBlog:20190722001253p:plain

・image2server(以下、2号機)
f:id:wantanBlog:20190722001310p:plain


大丈夫みたいですね。

ELBによる負荷分散構成の構築

いよいよロードバランサ(ELB)を導入します!

①ELB作成画面を開く

左側のメニューからロードバランサを選択。私の場合はスクロールして下の方にありました。

f:id:wantanBlog:20190722001823p:plain

②ELBの基本設定

ロードバランサーの作成を押下。
f:id:wantanBlog:20190722002057p:plain

上の説明でも少しふれましたが「Classic Load Balancer」を選択します。
f:id:wantanBlog:20190722002303p:plain

ロードバランサ名に任意の名前を入力。
場所はデフォルトで大丈夫そうです。
f:id:wantanBlog:20190722002547p:plain

③ELBのセキュリティグループ設定

以下の感じで設定すればOK。
f:id:wantanBlog:20190722003012p:plain

セキュリティ構成については一旦そのままでいきます。
SSL証明書をインストールしてHTTPS通信を有効化する場合がここの設定みたいです。
f:id:wantanBlog:20190722003314p:plain


④ヘルスチェックの設定

機器の障害チェックのアレですね。私はオンプレの設定したことがないので理論上しかしりませんでしたが、あぁなんだか楽しい。
とりあえず設定上の要件はありませんのでそのままでいきます。
f:id:wantanBlog:20190722004051p:plain


⑤EC2インスタンスの選択

ここでここまでで作成した二つのEC2インスタンスを選択します。私の場合は以下の2つです。
・image1server
・image2server
f:id:wantanBlog:20190722004507p:plain

⑥タグの作成

任意のNameタグを作成します。
f:id:wantanBlog:20190722004822p:plain

その後作成を押下し以下の完了画面が表示されればOK。
f:id:wantanBlog:20190722005119p:plain

⑦ELBの動作確認

インスタンスタブからインスタンスの状態を確認する。
ステータスの状態
OutOfService:インスタンスが利用できない
InService:インスタンスが利用できる

f:id:wantanBlog:20190722010505p:plain

なぜか「OutOfService」から状態が変わらない。。
さぁ調査だ!

原因調査

①ヘルスチェック設定の見直し

ネット上で検索してまず表示されるのがここでした。
index.htmlではなくhealth.htmlのヘルスチェック用のファイルを作成しておいているものが多かったので
EC2インスタンスの「/var/www/html/」にhealth.htmlを配置し、ヘルスチェックのping ターゲットもhealth.htmlに変更。

しばらく待ちましたがダメでした。

調査が難航しましたが、セキュリティグループに関する記述を発見。

②セキュリティグループの設定見直し

見つけたのは「セキュリティグループに自分のグループIDが追加されてないとダメ」というものだったので設定変更。
これも通用しない。

ここでさすがに気付きました。

問題はEC2に設定しているセキュリティグループでした。

以前私がEC2インスタンスを生成したときに、セキュリティを強固にするために一応接続元が私のIPのみから受け付けるようにしていました。
これがいけなかったのです。

EC2側の設定したセキュリティグループのインバウンドが私のIPのみから接続を許可していたので、ELBからの接続も許可するようにしなければなりません。

以下汚い図
f:id:wantanBlog:20190722023146p:plain

設定内容としては
サイドメニューの「ネットワーク&セキュリティ>セキュリティグループ」からEC2に設定したセキュリティグループを開きインバウンド側に以下を追加しました。
IPではなくてセキュリティグループでソースを設定できるようなので、ELBに設定したセキュリティグループのグループIDからの接続を許可します。

タイプ プロトコル ポート範囲 ソース
HTTP TCP 80 ELBに設定したセキュリティグループのグループID

ここまでしなくてもソースを全て許可してもいいかもしれない。
とりあえず構築経験がある人なら割とすぐに気付きそう。

「InService」になりました!
f:id:wantanBlog:20190722024014p:plain

私と全く同じ設定にした場合、同様のことがおきると思います。
結果的に「①ヘルスチェック設定の見直し」の対応はしなくてもたぶん大丈夫で、②のインバウンドの設定のみすればOKと思います。

サーバは起動していてもヘルスチェックが正常にできてないとLBからは接続できなくなことが体感できて、インフラ素人には悪くない経験でした。


⑧ELBの動作確認

作成したELBの「DNS 名 」をコピーしてブラウザからアクセスします。

1号機と2号機それぞれが使用されていることを確認できました。
f:id:wantanBlog:20190722025049p:plain

f:id:wantanBlog:20190722025102p:plain

なぜか2号機がなかなか使用されませんでした。
振り分けのルールは単にラウンドロビンではないような気がしますが現時点ではどうなっているか不明。さすがにどっかに記述があるのかな?



エラー対応で疲れたので今回はここまで。独自ドメインとかDNSの設定とかもあるみたいですが、次回からは一旦WEBプリケーションサーバの構築に入りたいと思います。
RDSとかも使う予定。