営業→エンジニアへリスキリング転職した中途が、入社3ヶ月目でＡＬＢヘルスチェック設定変更時の挙動を検証してみた

こんにちは、2024年4月より中途入社しました今野です！

前職までは営業畑で働いておりましたが、転職をきっかけにエンジニアへのリスキリングをチャレンジしており日々研修を受けている日々です。

AWSが提供するApplication Load Balancer (以下、ALB)について触る機会がありヘルスチェック機能の挙動について検証してみましたのでその内容を記事にまとめました！

こんな方向け

中途研修の中で、ヘルスチェックの設定を変更した場合の通信影響について問われたため、実際に検証してみようと思い書くことにしました。

HTTPなど、アプリケーション層（レイヤー7）で機能するロードバランサーです。主に、WEBサーバーとアプリケーションサーバーの負荷分散に使用されます。

ロードバランサーが負荷分散をするターゲットに対して定期的にチェックを行い、ターゲットが正常に稼働しているかどうかを確認する機能です。 AWSマネージメントコンソール上ではターゲットグループという項目にて設定します。詳細は以下のAWSドキュメントをご確認ください。

ALBの挙動として、ターゲットグループにて異常（=Unhealty）な登録済みターゲットのみが含まれている場合そのヘルスチェックステータスに関わらず、それら全てのターゲットにリクエストをルーティングするというものがあります。

ヘルスチェックの設定値を変更した直後は正常（=Healty）な判定がヘルスチェックによって行われるまで登録済のターゲットが全て異常（=Unhealty）を示すはずです。

今回はヘルスチェックが正常に行われている2つのEC2を負荷分散しているALBに対し、ヘルスチェックのパスを存在しないパスに変更してみます。登録済みのEC2が全てヘルスチェックに失敗したら、全てのターゲットにリクエストをルーティングされるはずです。

上記の構成図の通り、ALBを配置し、異なるAZのPublic SubnetへEC2をそれぞれ配置してターゲットグループへ設定します。各EC2には下記の通り設定をします。

Apache(2.4)のインストール
ドキュメントルート配下にindex.htmlを格納
- Webサーバ1へのアクセス→「hello world!!」を表示
- Webサーバ2へのアクセス→「hello SWX!!」を表示

ロードバランサーはラウンドロビンの挙動をするので、アクセスごとにターゲットグループ配下のEC2インスタンスに交互に通信を振り分けるよう設定してあります。

果たして、ALBの挙動はどうなるでしょうか。。。

ブラウザでアクセスしてみると、特にダウンタイムもなく交互に通信できていることが確認出来ました！ AWSのドキュメント通り、ロードバランサーのアルゴリズムに基づいて有効な全てのAZ内のターゲットへトラフィックが許可されていることがわかります。

ALBの挙動は実際に触れてみると気づくことがたくさんあると感じました！今後も検証したことがあれば発信していきたいと思います！！