AWS ELBでヘルスチェックを設定する方法とポイントを初心者向けに解説！

1. ヘルスチェックとは？

1. ヘルスチェックとは？

ヘルスチェックは、AWS Elastic Load Balancer（エラスティックロードバランサー、略してELB）がターゲットグループ内のEC2（イーシーツー）インスタンスやコンテナの正常性を確認する機能です。設定されたエンドポイントに対して定期的にリクエストを送り、応答が正常かどうかを判断します。

これにより、異常が発生したサーバーを自動的に除外し、正常なサーバーだけにトラフィックを振り分けることができます。

2. ヘルスチェックの基本パラメータ

2. ヘルスチェックの基本パラメータ

ELBで設定するヘルスチェックにはいくつかの重要なパラメータがあります。初心者でも理解しやすいように代表的なものを紹介します。

• プロトコル：HTTP（エイチティーティーピー）、HTTPS（エイチティーティーピーエス）、TCP（ティーシーピー）など。
• パス：例えば「/health」や「/index.html」など。サーバーが応答できるエンドポイントを指定します。
• ヘルシーしきい値：サーバーが「正常」と判断されるまでに必要な連続成功回数。
• アンヘルシーしきい値：サーバーが「異常」と判断されるまでに必要な連続失敗回数。
• タイムアウト：応答を待つ時間。
• 間隔：ヘルスチェックを実行する間隔。

3. ヘルスチェックを設定する手順

3. ヘルスチェックを設定する手順

実際にAWSコンソールからヘルスチェックを設定する手順は以下の通りです。

1. AWSマネジメントコンソールにログインし、「EC2」から「ロードバランサー」を選択。
2. 対象のELBを選び、「ターゲットグループ」を確認。
3. ターゲットグループの「ヘルスチェック」タブをクリック。
4. プロトコル（HTTPやHTTPS）を選択し、パスを指定。
5. タイムアウト、間隔、しきい値を適切に設定。
6. 保存して設定を有効化。

4. ヘルスチェックのポイントと注意点

4. ヘルスチェックのポイントと注意点

ヘルスチェックを正しく機能させるためには、いくつかのポイントを押さえておく必要があります。

• 実際に稼働しているアプリケーションが応答できるパスを指定する。
• ヘルスチェック専用のエンドポイントを用意すると管理しやすい。
• しきい値は厳しすぎると正常なサーバーを外してしまうので注意。
• タイムアウトや間隔はアプリケーションの応答時間に合わせて調整する。

5. 初心者でも分かる例え話

5. 初心者でも分かる例え話

ヘルスチェックを人間の健康診断に例えるとわかりやすいです。会社が社員に定期的な健康診断を受けさせて、体調が悪い人には無理に仕事をさせないのと同じです。ロードバランサーも定期的に「サーバーは元気ですか？」と確認し、問題があるサーバーにはリクエストを振らないようにします。これにより、全体のシステムが安定して動作します。

6. ヘルスチェックでよくあるトラブル

6. ヘルスチェックでよくあるトラブル

初心者が設定でつまずきやすいポイントをまとめます。

• セキュリティグループの設定が不十分で、ヘルスチェックの通信が通らない。
• 指定したパスが存在しない、または正しいステータスコードを返さない。
• アプリケーションの応答時間が長く、タイムアウトに引っかかる。

こうした問題は、セキュリティグループのルールを確認したり、アプリケーション側でヘルスチェック専用エンドポイントを準備することで解決できます。

まとめ

まとめ

ここまでAWSのELB（Elastic Load Balancer）におけるヘルスチェックの基本から設定方法、注意点までを詳しく解説してきました。クラウドインフラを運用する上で、システムの「止まらない仕組み」を作ることは最も重要なミッションの一つです。その中核を担うのが、今回学んだヘルスチェック機能です。

ヘルスチェックの重要性を再確認

ウェブサイトやアプリケーションを公開していると、予期せぬエラーやサーバーの過負荷によって、一部のインスタンスが正常に動作しなくなることがあります。もしロードバランサーが異常なサーバーにユーザーを送り続けてしまったら、そのユーザーはエラー画面を目にすることになり、サービスの信頼性は大きく損なわれます。

ヘルスチェックを正しく設定しておくことで、ELBは「どのサーバーが元気で、どのサーバーが休憩が必要か」を24時間365日、休まずに監視し続けてくれます。この自動化された仕組みこそが、AWSを利用する大きなメリットの一つと言えるでしょう。

実践的な設定例：Python (Flask) でのヘルスチェック用エンドポイント

記事の中でも触れましたが、ヘルスチェックには「専用のエンドポイント」を用意するのがベストプラクティスです。例えば、Pythonの軽量フレームワークであるFlask（フラスク）を使用して、ヘルスチェック専用のパスを作成する場合のコード例を見てみましょう。

from flask import Flask, jsonify

app = Flask(__name__)

# メインのコンテンツ
@app.route('/')
def index():
    return "こんにちは！これはメインページです。"

# ヘルスチェック用のエンドポイント
# ELBはこのURL（/health）に定期的にアクセスします
@app.route('/health')
def health_check():
    # データベースの接続確認など、内部のステータスチェックをここで行うのが理想
    # 正常な場合は HTTP 200 OK を返却する
    return jsonify({"status": "healthy"}), 200

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=80)

サーバー側での確認方法（Linuxコマンド）

実際にELBからのヘルスチェックが届いているかどうかは、Webサーバー（ApacheやNginx）のアクセスログを確認することで把握できます。Linuxサーバーにログインして、リアルタイムでログを追跡するコマンドを実行してみましょう。

tail -f /var/log/nginx/access.log
10.0.1.50 - - [29/Jan/2026:12:00:01 +0900] "GET /health HTTP/1.1" 200 20 "-" "ELB-HealthChecker/2.0"
10.0.1.50 - - [29/Jan/2026:12:00:31 +0900] "GET /health HTTP/1.1" 200 20 "-" "ELB-HealthChecker/2.0"

このように、「ELB-HealthChecker」というユーザーエージェントからのアクセスが、設定した間隔（この例では30秒おき）で届いていれば、ヘルスチェックは正常に機能しています。もしログが全く流れてこない場合は、セキュリティグループ（ファイアウォール）の設定で、ELBからの通信を許可しているか（ポート80番など）を再確認してください。

運用のコツ：しきい値のチューニング

最後に、運用におけるアドバイスです。ヘルスチェックの設定値は、厳しすぎても緩すぎてもいけません。

• 判定が厳しすぎる場合： ネットワークの一時的なゆらぎで、正常なサーバーが切り離されてしまい、残ったサーバーに負荷が集中する恐れがあります。
• 判定が緩すぎる場合： 実際に故障しているのに「正常」と判断され続け、ユーザーにエラーを返し続けてしまいます。

まずはデフォルト値で運用を開始し、アプリケーションの特性に合わせて、タイムアウト時間やしきい値を微調整していくのが、安定稼働への近道です。AWSのCloudWatch（クラウドウォッチ）などの監視ツールも併用しながら、最適な設定を見つけていきましょう。