ALBのヘルスチェックの豆知識

AWS運用自動化サービス「Cloud Automator」
この記事は1年以上前に書かれたものです。
内容が古い可能性がありますのでご注意ください。

こんにちは、技術4課の多田です。

私事ですが、サーバーワークスに入社して1年が経ちました。本当にあっという間でしたが、入社前後での自分のスキルアップを実感した1年でした。

2年目も引き続き頑張っていこうと思います。

さて、今回は、Application Load Balancer(以下、ALB)に関する豆知識情報になります。

ターゲットヘルスステータス

ALBでは、トラフィックを振り分ける対象をターゲットグループという形でグルーピングし、コンテンツパスベースでのルーティングを行います。

ターゲットグループでは、配下のEC2のステータスをチェックして管理しているのですが、各ステータスについては以下の通りです。

ステータス名 説明
initial ターゲットを登録中か、ターゲットで最初のヘルスチェックを実行中という状態
healthy ターゲットは正常という状態
unhealthy ターゲットはヘルスチェックに応答しなかったか、ヘルスチェックに合格しなかった状態
unused ターゲットがターゲットグループに登録されていないか、ロードバランサーのリスナールールで使用されない。または、ロードバランサーに対して有効ではないアベイラビリティーゾーンにターゲットがある状態
draining ターゲットは登録解除中で、接続のストリーミング

今回、注目するのは、「unhealthy」と「unused」になります。

「unhealthy」と「unused」について

両者の挙動の違いについて理解するために以下のような環境を準備して確認を行います。

シンプルなALBとEC2のみの構造で、EC2にApacheがインストールされています。ALBの構成方法については、寺田のこちらのブログを参照ください。

image

初期の状態は、ターゲットグループのEC2が正常な判定の「healthy」です。インスタンスにもヘルスチェックも来ている状態です。

tagetgroupstatus-1

それではこの状態から「unhealthy」ステータスに遷移させるために、意図的にApacheを停止させます。

停止後は、ヘルスチェックも受け付けられない状態になり、「unhealthy」ステータスに遷移しています。

次に、ヘルスチェックのパスに指定しているヘルスチェックコンテンツのファイル名をリネームしてみましょう。尚、今回指定しているのは、ドキュメントルート直下の「index.html」です。

ファイル名を変更後、ヘルスチェックのHTTPステータスが403となり、ステータスは「unhealthy」扱いになりました。

tagetgroupstatus-4

最後に、EC2を停止しても同じように「unhealthy」となるかを確認してみましょう。

ターゲットグループのステータスを確認してみますと、ステータスは「unused」という扱いになりました。

tagetgroupstatus-3
EC2インスタンスが停止した時には、ALBのヘルスチェックステータスが「unused」となり、
Apahceのデーモンが停止したり、ヘルスチェックパスに設定しているページのリネームを行った場合は「unhealthy」の状態へと遷移する点に違いがあります。

「unhealthy」扱いになるのは、ALBの振り分け先となるEC2上のデーモンが停止してたり、ヘルスチェックコンテンツのファイル名が変わってしまったりといった事態が当てはまることになります。

Route53のDNSフェイルオーバー対処

EC2インスタンスが停止した時、ALBのヘルスチェックステータスが「unused」となり、Apahceのデーモンが停止したり、ヘルスチェックパスに設定しているページのリネームを行うことで「unhealthy」の状態へと遷移する点に違いがあります。

このようなステータスが関係してくる場面の1つとして、Route53のDNSフェイルオーバーがあると思います。私も実際に試してみたところ、ALB配下のEC2が停止してもDNSフェイルオーバーは発生せず、EC2内のApacheを停止させた場合、DNSフェイルオーバーが発生しました。

従来のClassic Load Balancer(CLB)のようにEC2を停止した場合、DNSフェイルオーバーが発生しない点にALBとCLBの間に動作仕様の差異があるため、注意が必要です。

ただ、ALB配下のEC2が停止してもRoute53のDNSフェイルオーバーを実施する場合、別の仕組みを作りこむ必要があります。

その手段の1つとして私が動作確認を行った、弊社のCloud Automatorを使った対処について紹介します。

以下の図では、東京リージョンのEC2が停止した後、CloudWatch Alarmが発動してSNSによる通知が飛びます。
次に、Cloud AutomatorのジョブによりRoute53のレコードをソウルリージョンのALBのDNS名にレコードに書き換え、トラフィックを別リージョンに制御しています(赤の矢印が該当の処理です)。

Cloud AutomatorでのRoute53レコード書き換え設定方法については、こちらを合わせてご覧ください。尚、私の設定は以下のようにしました。

 

AWS側で肝となるのは、CloudWatchのAlarm設定です。

通知の条件として、状態が「警告」と「不足」を指定しているのですが、前者がターゲットヘルスステータスの「unhealthy」時、後者が「unused」時の状態となります。

どちらもCloudWatch Alarmとして定義しておけば、どちらの状態でもDNSフェイルオーバーを実施できます。

それでは、東京リージョンのEC2を停止して、動作確認を行います。尚、フェイルオーバー前のdigの結果については以下の通りです。

AWSマネージメントコンソールより対象のEC2を停止します。

 

CloudWatch Alarmの画面でもステータスが「OK」から「不足」に遷移してSNS通知の条件となりました。

 

Cloud Automatorの後処理設定で処理結果をメール通知する機能があり、それを有効化していたため、メールでも処理が成功したというメッセージが確認できました。

DNSフェイルオーバー後のdigの結果を見ると、ソウルのALBのDNS名が返されています。

 

まとめ

ALBのターゲットグループにおけるヘルスチェックステータスについて動作確認した内容をレポートしました。

※尚、本レポートは2017年2月7日時点のものになります。

この記事が何かの参考になれば、幸いです。それでは!

AWS運用自動化サービス「Cloud Automator」