はじめに
アプリケーションロードバランサー（ALB）は、AWS環境でスケーラブルなアプリケーションを構築する際に欠かせないサービスの一つです。
今回は、ALBの「ヘルスチェックのパス」に焦点を当て、簡単な技術検証を行いながら解説していきます。
この記事では、自分自身の備忘録も兼ねて、ヘルスチェックに関する知識を体系的に整理していきます。
書こうと思ったきっかけ
今回、ALBのヘルスチェックについて記事をまとめようと思った理由は、AWSを学び始めた当初、この「ヘルスチェック」が具体的に何をしているのかイメージが湧かなかった経験があるからです。
当時は、ターゲットが "Healthy" になったり "Unhealthy" になったりする状態をうまく理解できず、困ったことがありました。
結論として、ヘルスチェックは設定したパスが正常に応答しているかを確認する仕組みです。
同じようにヘルスチェックの仕組みで悩んでいる方もいるのではないかと思い、この記事をまとめることにしました。
ALB関連の技術検証の記事
ALBはAWSの中でも非常に重要なサービスの一つです。そのため、これまでにもさまざまな技術検証を行ってきました。過去の記事も参考にしていただけると嬉しいです。
これ以外にも技術検証を行っていますので、興味のある方はぜひマイページから探してみてください！
ヘルスチェックとは？
アプリケーションロードバランサー（ALB）のヘルスチェックは、ターゲット（EC2インスタンスやコンテナ）が正常に動作しているかを定期的に確認する機能です。
ヘルスチェックの結果をもとに、ALBはリクエストを送信するターゲットを選別します。
ヘルスチェックの主な特徴
- HTTP/HTTPSプロトコルを使用してターゲットのステータスを確認
- ヘルスチェックに合格したターゲットにのみリクエストをルーティング
- ターゲットが非正常と判断された場合、自動的にリクエスト対象から除外
ヘルスチェックの設定項目
ALBのヘルスチェックでは、以下のパラメータなどを細かく設定できます。
| 項目 | 説明 |
|---|---|
| プロトコル | HTTPまたはHTTPSを選択 |
| パス | ヘルスチェック用のエンドポイント（例: /health） |
| ポート | チェックを行うターゲットのポート番号（通常は80または443） |
| 間隔（Interval） | ヘルスチェックのリクエストを送る間隔（秒） |
| タイムアウト | ヘルスチェック応答のタイムアウト（秒） |
| 正常チェック数 | ターゲットを正常と判断するために必要な連続成功回数 |
| 異常チェック数 | ターゲットを異常と判断するために必要な連続失敗回数 |
これらは基本的な設定ですが、ALBでは「スティッキーセッション」と呼ばれる、アクセスしてきたセッション情報を保持する機能も利用可能です。
ALBのスティッキーセッションについては、過去の記事で詳しくご紹介しています。興味のある方はそちらも参考にしてみてください。
ヘルスチェック用のエンドポイント（パス）について
ヘルスチェックでは、ターゲットのエンドポイントが正しいか、または /healthのような指定されたエンドポイントが正常に応答しているかを確認します。
AWSマネジメントコンソールでは、以下のようにヘルスチェック用のパスを設定する項目があります。
補足：ヘルスチェックのパスが「/」に設定されている場合
ヘルスチェックのパスが「/」と設定されている場合、これはターゲット（EC2インスタンスやコンテナ）に対して送信されるリクエストのURLパス部分がルート（/）であることを意味します。
ALBは、指定されたターゲット（例: EC2インスタンス）に対し、HTTPまたはHTTPSリクエストを送信します。
このリクエストは、設定されたポート（通常は80または443）に対して行われ、パスが「/」に設定されている場合、送信されるリクエストは以下のようになります。
例:
ターゲットのIPアドレスが http://192.168.1.100 で、パスが「/」に設定されている場合、リクエストは次のようになります。
http://192.168.1.100/
「/」はアプリケーションのルートパスを指し、システム全体が正常に稼働しているかを確認するための最も基本的な方法です。
このパスに応答がない場合、アプリケーション全体がダウンしている可能性が高いと判断されます。
実際にヘルスチェックを確認してみた
ここでは、過去の技術検証記事で取り扱ったTerraformによるコード化された構成を使用して、ヘルスチェックの動作を検証します。
現在、2台のウェブサーバーに対して、ALBからヘルスチェックが実行されている状況です。
ヘルスチェック用のエンドポイント（パス）を変更してみる
通常、EC2上のウェブサーバーにはindex.htmlを配置し、それをヘルスチェックで確認するように設定しています。
今回は、一時的にヘルスチェックのパスを存在しないHTMLファイル /test.html に設定して挙動を確認してみます。
想定通り、存在しないパスに対してヘルスチェックが実行され、正常に応答しないために「Unhealthy」と判定されたことが確認できました。
Health checks failed with these codes: [404]
また、詳細画面からもロードバランサーがターゲットに対して送信したヘルスチェックリクエストに対し、HTTPステータスコード404（Not Found）が返されたことが記録されています。
まとめ
ここまで読んでいただき、ありがとうございました！
今回は、基本的なALBのヘルスチェックのパスについて深掘りし、検証を行いましたが、記事をまとめる中で、自分の理解が曖昧だった部分もクリアになりました。
AWSの勉強を始めた方や、これから勉強を始めようと思っている方の学びのきっかけや、技術的な支えになれば幸いです！
余談
少し余談になりますが、仕事が休みの日や休日などは、朝から晩までパソコンを触っていることが多く、睡眠時間がつい短くなってしまうことがあります。
今回の年末年始も平均して睡眠時間が5時間を切っていたため、昨日は疲れが溜まり、8時間ほどしっかり眠ることができました。
やはり、たくさん寝た翌日は、頭がすっきり整理され、やりたいことも明確になります。改めて、睡眠の大切さを実感した次第です。
ただ、知的好奇心が人一倍強く、「知らないことを知りたい」「技術をもっと学びたい」という想いが、最近では睡眠欲を上回ってしまうのが贅沢な悩みです（笑）。
今年は、この贅沢な悩みと向き合いながら、うまくバランスを取りつつ改善していきたいと思っています。
関連記事