【ALB】EC2停止時の動作はどうなるの?設定箇所や仕様を検証しました!

  • 2019年7月15日
  • AWS
AWS

こんにちは。ますのです。
ELBを利用するにあたり、ターゲットグループのOS停止時やunhealthy時、Apache・Nginxなどのサービス停止時の動作はどうなるの??と仕様確認が必要になりましたので結果をまとめました!

検証環境の準備

ざっくりとこんな構成図です。以前作成した記事から流用。めんどくさいわけじゃないよ^q^

OSCentOS 7
ミドルウェアApache
ロードバランサーALB(Application Load Balancer)

ALBのセッション時間の設定箇所

今回は主にターゲットグループ側の設定をいじって検証を行います。
ロードバランサーの「アイドルタイムアウト」に関しては、ALB⇔EC2間の処理の応答時間になるので今回は無関係として想定しております。

設定箇所:AWS管理コンソール>EC2>ロードバランシング>ターゲットグループ より

  1. 説明タブ:属性
    ・維持設定の期間(スティッキーセッション)
  2. ヘルスチェックタブ:ヘルスチェックの編集
    ・しきい値
    ・タイムアウト
    ・間隔 

OS/サービス停止時、ALBの設定を変更した時の動作を検証

【Case1】ターゲットグループ設定値

維持設定非正常のしきい値タイムアウト間隔
5時間25秒30秒

【Case1:検証結果】

スト内容ターゲット
インスタンス
OSの状態Apacheの状態接続先の変化切替
時間
備考
①正常動作時EC2:A起動起動A→AAを維持したままBには遷移しない。
EC2:B起動起動
②AのApacehが停止した場合EC2:A起動停止A→B60秒前後AのApache停止後アクセスすると「502 Bad Gateway」 と表示される。
EC2:B起動起動
③AのApacheが復活した場合EC2:A起動起動B→BALBヘルスチェック:healthyに切り替わった後もBを表示し続ける。
EC2:B起動起動
④AのOSが停止した場合EC2:A停止A→B10秒前後AのOS停止後、読み込み中となり画面遷移しなくなる。
EC2:B起動起動
⑤AのOSが復活した場合EC2:A起動起動B→BALBヘルスチェック:healthyに切り替わった後もBを表示し続ける。
EC2:B起動起動

どうやらOS停止時と、サービスの停止時ではALBのセッション時間が異なるようですね。
次の検証ではこのあたりがどういう仕組みになっているかみたいので、ターゲットグループの設定時間を少しいじってみることにしました。

【Case2】ターゲットグループ設定値

維持設定非正常のしきい値タイムアウト間隔
5時間22秒5秒

【Case2:検証結果】

テスト内容ターゲット
インスタンス
OSの状態Apacheの状態接続先の変化切替
時間
備考
①正常動作時EC2:AA→AAを維持したままBには遷移しない。
EC2:B
②AのApacehが停止した場合EC2:A○→×A→B10秒前後AのApache停止後アクセスすると「502 Bad Gateway」 と表示される。
EC2:B
③AのApacheが復活した場合EC2:A×→○B→BALBヘルスチェック:healthyに切り替わった後もBを表示し続ける。
EC2:B
④AのOSが停止した場合EC2:A○→×A→B5秒前AのOS停止後、読み込み中となり画面遷移しなくなる。
EC2:B○動
⑤AのOSが復活した場合EC2:A×→○-→○B→BALBヘルスチェック:healthyに切り替わった後もBを表示し続ける。
EC2:B

【検証結果】ALBのセッション時間はOS停止時、サービス停止時で異なる

ターゲットグループの「タイムアウト」「間隔」を変更したところ、OS停止時とApache停止時でセッションの遷移時間が異なる結果になりました!
何度か異なる設定で試してみましたが、どうやらALBの設定ではこんな感じで振り分けの判断をしていそうです。

・OS停止時:タイムアウト(5)*非正常のしきい値(2)=10秒
・サービス停止時:間隔(30)*非正常のしきい値(2)=60秒
維持設定(スティッキーセッション)が障害時に辛いことにならないかとびびってましたが、あくまでも維持設定は正常時のみのクライアント側のcookieの保持のようですね。
アプリ側の皆様もこれできっと安心してくれる。そう信じてるであります!
最新情報をチェックしよう!