ALBを使って「Hello,EC2!」「Goodbye,EC2!」と表示させてみた。

kudou.m written 2年 ago

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。

はじめに

今回ALBの冗長構成を用いてEC2にアクセスし、作成したHTMLファイルをブラウザで表示するハンズオンを行いました。自身が結構躓いていたこともあり、アウトプットも兼ねてまとめてみました。

ALBとは

ALB（Application Load Balancer）はELB（Elastic Load Balancer）の一つで、EC2やコンテナなどWebサービスにおける負荷(Load)を分散(Balancing)させるロードバランシングです。サーバーに対しての負荷を軽減し、効率化するために自動的に複数のEC2などに負荷を分散します。

Application Load Balancer は、開放型システム間相互接続 (OSI) モデルの第 7 層であるアプリケーションレイヤーで機能します。ロードバランサーはリクエストを受信すると、優先度順にリスナールールを評価して適用するルールを決定し、ルールアクションのターゲットグループからターゲットを選択します。リスナールールを構成し、アプリケーショントラフィックのコンテンツに基づいて異なるターゲットグループにリクエストをルーティングできます。それぞれのターゲットグループでルーティングは個別に実行され、複数のターゲットグループに登録されているターゲットの場合も同じです。ターゲットグループレベルで使用するルーティングアルゴリズムを設定できます。デフォルトのルーティングアルゴリズムはラウンドロビンです。代わりに最小の未処理のリクエストを指定することもできます。-AWS公式ドキュメントより引用-

ALBを使用するメリットは以下のようになります。

①複数のアベイラビリティーゾーンで実行されるため、一つのゾーンで障害が発生しても他のゾーンでサービスを継続できます。
②レイヤー7のルーティングをサポートしており、ホスト名、パス、ヘッダー、HTTPメソッドなどに基づいてトラフィックをルーティングすることができます。
③Autoscallingを用いることで必要に応じて自動的にEC2インスタンスを追加または削除することができます。これにより、トラフィックの増加に柔軟に対応することができます。

今回の目的

ALBを用いた冗長構成でブラウザ上に「Hello,EC2!」「Goodbye,EC2!」と表示させること。
また片方のEC2を停止してブラウザが表示し、高可用性が保たれているかを確認する。

構成

今回構築する中でやりたいことは
①それぞれのAZでパブリックサブネットを作成し、その中に各ECを配置し、マルチAZ構成をとり高可用性を実現。
②ALBからEC2へ疎通を行う。
③ブラウザ上に「Hello,EC2!」「Goodbye,EC2!」と表示させる。
④意図的に片方のEC2を停止し、冗長構成が取れているのかを確認する。

構築手順

①事前準備

今回の検証にて用意するもの
・VPC
・パブリックサブネットを２つ
・インターネットゲートウェイ
・ルートテーブル
これらの用意をします。
「VPC」→「VPCを作成」より

設定項目
作成するリソース	VPCなど（一括で設定します）
AZの数	２個
パブリックサブネットの数	２個
プライベートサブネットの数	０個（今回は使用しないため）
NATゲートウェイ	なし（今回は使用しないため）
VPCエンドポイント	なし（S3ゲートウェイは使用しないため）
DNSオプションにチェック	・DNSホスト名を有効化・DNS解決を有効化

このような構成になれば事前準備は完了です。

②セキュリティグループを作成

SG（セキュリティグループ）の作成を行っていきます。
EC2用とALB用にそれぞれSGを作成していきます。

インスタンス	セキュリティグループ	インバウンドルール	理由
kuma-test-EC2	kuma-test-EC2-SG	HTTP(0.0.0.0/0) SSH(MYIP)	・HTTPを許可する設定はEC2をWebサーバーとして利用するため・SSHを許可する設定はindex.htmlをEC2内に格納するため
kuma-test-ALB	kuma-test-ALB-SG	HTTP(0.0.0.0/0) SSH(MYIP)	・HTTPを許可する設定はWebブラウザ上にて表示するため →ブラウザからの要求であるHTTPを許可する・SSHはローカルよりEC2に接続するため

各SGを作成したら次はEC2を２つ作成します。
→今回は「kuma-EC2-test-a」「kuma-EC2-test-b」を用意しました。
　各EC2に先ほど作成した「kuma-test-EC2-SG」を設定してください。
※今回は作成手順は省略します。

③EC2にHTMLファイルを格納する

TeratermにてEC2にテスト用のindex.htmlファイルを格納していきます。
まずは「kuma-test-EC2-a」に格納していきます。
Amazon Linux 2のCUI画面でコマンドを入力します。

パッケージの更新

sudo yum update -y

Apacheをインストール

 sudo yum install -y httpd

htmlファイルの追加

 sudo vi /var/www/html/index.html

Hello,EC2!
(「Hello,EC2!」と入力し:wqで保存して終了)

Apacheの起動

 sudo service httpd start

Apacheの起動状態を確認します。（Active: active(running)と表示されれば起動しています。）

sudo systemctl status httpd

これで「kuma-test-EC2-a」にてindex.htmlファイルが格納されました。

同様にもう一つのEC２である「kuma-test-EC2-b」にもindex.htmlファイルを作成します。

htmlファイルの追加

 sudo vi /var/www/html/index.html

Goodbye,EC2!
(「Goodbye,EC2!」と入力し:wqで保存して終了)

「kuma-test-EC2-a」との違いを出すために「kuma-test-EC2-b」には
「Goodbye,EC2!」というindex.htmlファイルを格納します。

④ターゲットグループを作成

次は負荷の分散先であるターゲットグループを作成していきます。
サービスメニューの「EC2」の画面上から「ターゲットグループ」を選択。

設定項目	選択
ターゲットタイプ	インスタンス
ターゲットグループ名	任意の名前
VPC	自身のVPCを選択
可能なインスタンス	作成した２つのEC2を選択 →必ず「includs as pending below」を押してください

※他の項目はデフォルトで設定しています。
作成後、下記の画像のように「Targets」にて作成したEC2にどちらも紐づき「Health status」が「healthy」となれば完了です。ターゲットグループにしっかりとEC2が設定されています。

⑤ロードバランサーを作成

続いてロードバランサーを作成していきます。
ターゲットグループ作成の時同様、「EC2」の画面上から今度は「ロードバランサー」→「ロードバランサーの作成」より
作成を行っていきます。

設定項目	内容
ロードバランサーの選択	ALB
ロードバランサーの名前	kuma-test-ALB
スキーム	Internet-facing(インターネット向け)
IPアドレスタイプ	IPv4
VPC	自身のVPCを選択
マッピングズ	・自身で作成した任意のAZにチェックを付ける・選択欄より任意のサブネットを選択（今回は事前に作った二つのAZにそれぞれ異なるサブネットを選択）
セキュリティグループ	kuma-test-ALB-SG
リスナー・ルーティング	【Default action】より【kuma-test-target】を選択

※他の項目はデフォルトで設定しています。
こちらも下記の画像のように表示されれば作成完了です。
ALBが作成したそれぞれのAZに接続されていることを確認できます。

以上で基本的な設定は完了しましたが、最後の設定としてSGの設定を変更します。

⑥EC2への接続をロードバランサーからのみにする

事前にEC2にApacheのインストールをしていたためEC2のSG上にてインバウンドルールが
「HTTP: 0.0.0.0/0(すべてのトラフィックを許可)」で設定されています。

そのため現在のEC2の状態として
・直接EC2から接続
・ALBからの接続
が可能となっているため、ALBの冗長性を確認するため今回はEC２に直接接続できないように設定を変更します。

	セキュリティグループ	インバウンドルール
変更前	kuma-test-EC2-SG	HTTP(0.0.0.0/0)
変更後	kuma-test-EC2-SG	HTTP (kuma-test-ALB-SG)

インバウンドルールの変更を終えた後は実際に直接EC2に接続できないことを確認してみます。
「EC2」よりパブリックIPv４アドレスをコピーして実際にブラウザに表示できないことを確認します。

↑「パブリックIPv4」をコピーしてそのままブラウザ表示してみます。

HTTP接続ができなくなっていることを確認できました。

⑦ロードバランサーに接続する

EC2に直接接続できなくなったのを確認できたので最後にロードバランサー経由のアクセスをしてみましょう。
先ほどEC2用のSGにて「kuma-test-ALB-SG」からのHTTP接続のみに変更したためEC2のパブリックIPでは表示されなくなっております。
そのため今回はALBのDNS名を用いて表示させます。
「EC2」→「ロードバランサー」→「Details」より「DNS name」をコピー。

それではブラウザ上にて表示してみましょう。

【kuma-test-EC2-a】の場合

【kuma-test-EC2-b】の場合

このように表示されれば成功です。
けれどこれだけでは実際に冗長構成がとれているのか判断できません。
ですので次は意図的に片方のEC2を停止してもう片方だけでしっかり表示されているか確認してみます。

検証

検証方法としては片方のEC2を意図的に停止し、HTTP接続が行えるかどうかの冗長構成を確認していきます。
以下のように検証していきます。
【１】「kuma-test-EC2-b」にてApacheを停止してHTTP接続をしてみます
【２】【１】と同様に「kuma-test-EC2-a」のほうでApacheを停止してHTTP接続をしてみます。

まずは「kuma-test-EC2-b」のApacheを停止してみて正常に冗長構成が保たれているかを確認していきます。

①「kuma-EC2_test_b」にてSSH接続を行います。
②一度現在のApacheの状態を確認します。

sudo systemctl status httpd

Active: active(running)と正常に作動している状態です。

③Apacheを停止させるコマンドを入力します。

sudo systemctl stop httpd.service

④Apacheが停止しているかコマンドで確認してみましょう

sudo systemctl status httpd.service

上記のようにActive:　inactive（dead）となっていれば停止しています。
↓またEC2が作動しているのかどうかをターゲットグループでも見ていきましょう。

「EC2」→「ターゲットグループ」にて「kuma-test-EC2-b」のヘルスチェックが「unhealthy」となっているのを確認します。

⑤Apacheが停止したことを確認できたので、このままブラウザ上にて先ほどのページが表示されるかみてみましょう。先ほどの結果と変わらず「Hello,EC2!」と表示されていればしっかり冗長構成が取れています。

⑥停止したApacheを起動させましょう

sudo systemctl start httpd.service

※起動後。先ほどのコマンドで正常に作動しているのか確認しましょう。

同様に「kuma-test-EC2-b」のほうも確認していきます。

こちらでは「kuma-test-EC2-a」のほうでApacheを停止します。

先ほどのコマンドの手順で停止をします。
↓ターゲットグループにて「kuma-test-EC2-a」のヘルスチェックが「unhealthy」となっているのを確認します。

それではブラウザでどのように表示されるのか確認しましょう。

先ほどと同様にDNS名をコピーしてブラウザ表示します。

「Goodbye,EC2!」としっかり表示されております。
こちらで「kuma-test-EC2-b」も動作していることが確認できました。
無事冗長構成も取れているようなので検証は終了です。

まとめ

調べていくうちにクラウドを最大限有効活用するにはALBはかなり大事な存在だということを改めて認識しました。何かの障害で単一のEC2インスタンスのみ接続ですと、耐障害性が危ぶまれます。そのための高可用性・耐障害性をもつALBについて、より今回のハンズオンで理解を深めることができました。

種類	プロトコル	概要
Classic Load Balance	TCP,SSL,HTTP,HTTPS	古いバージョンのELBで、レイヤー4およびレイヤー7の負荷分散をサポートしています。古いアプリケーションに対しては、Classic Load Balancerが最適な場合があります。
Application Load Balancer	HTTP,HTTPS,HTTP/2	レイヤー7の負荷分散をサポートしており、HTTP/HTTPSトラフィックに最適です。ALBは、リスナールールによって、リクエストを転送するターゲットグループを決定します。
Network Load Balancer	TCP,UDP,TLS	レイヤー4の負荷分散をサポートしており、TCP/UDPトラフィックに最適です。また、高速なネットワーク接続をサポートしており、低レイテンシでの通信を実現します。
Gateway Load Balancer	TCP,UDP	ファイアウォール、侵入検知、防止システム、ディープパケットインスペクションシステムなどのサードパーティの仮想アプライアンスをクラウドに展開、拡張、管理するように調整されています。異なるVPC間のトラフィックをルーティングすることができます。