はじめに
本書の目的
本ドキュメントは、AWSにおけるヘルスチェック機能の基本をやさしく解説します。システムの安定運用や高可用性の維持に役立てることを目的としています。専門用語は最小限にし、具体例を交えて説明します。
ヘルスチェックとは（かんたんな説明）
ヘルスチェックは、サービスやサーバーが正しく動いているかを自動で確認する仕組みです。たとえば、ウェブサイトの応答が止まったサーバーを自動で検出し、トラフィックを止めるといった動作を行います。これにより利用者への影響を小さくできます。
なぜ重要か（期待できる効果）
・障害の早期発見と自動対応でダウンタイムを減らせます。
・不具合のあるサーバーを隔離して、全体の信頼性を高めます。
・監視システムと連携して運用を効率化できます。
本書の構成
以降の章では、定義や仕組み、実際の設定方法、運用面での注意点まで順を追って説明します。初心者の方でも理解しやすいよう、手順や例を示して解説します。
AWSヘルスチェックの定義と基本概念
概要
AWSにおけるヘルスチェックは、ロードバランサーがバックエンドのターゲット（EC2インスタンスやコンテナなど）を定期的に確認する仕組みです。具体的には、Application Load Balancer（ALB）がターゲットに対してリクエストを送り、正常に応答するかを見ます。結果に応じて、ALBは正常なターゲットだけにトラフィックを送ります。
ヘルスチェックの対象（ターゲット）
ターゲットはウェブアプリやAPIを動かすインスタンス、コンテナ、IPアドレスなどです。各ターゲットが期待する応答（例: /health エンドポイントで200 OK）を返せば「正常（Healthy）」と見なされます。
チェックの種類と基本項目
主なチェックはHTTP/HTTPSとTCPです。設定する主な項目は以下です。
– パス（例: /health）
– ポート
– 間隔（インターバル）
– タイムアウト
– 正常/異常判定のしきい値（連続成功/失敗回数）
– 期待するステータスコード（例: 200〜399）
判定の流れ（簡単な例）
ALBが定期的に /health にリクエストを送ります。応答が許容範囲ならカウントが増え、指定回数成功すれば正常扱いに変わります。逆に連続して失敗すれば不健康扱いとなり、トラフィックの振り先から外れます。
注意点と運用のポイント
ヘルスチェックのパスは軽量な処理にし、アプリの起動時間や一時的な負荷を考慮して閾値を設定してください。誤設定だと正常なノードまで切り離されることがありますので、ログやメトリクスと合わせて監視することをおすすめします。
ヘルスチェックが必要とされる理由
なぜヘルスチェックが欠かせないのか
ヘルスチェックの最大の役割は、サービスの安定稼働を守ることです。不安定なバックエンドがユーザーリクエストを受け続けると、応答遅延やエラーが増え、ユーザー体験が損なわれます。ヘルスチェックはその入口で問題を検出し、影響を小さくします。
主な必要理由
- ユーザー体験の維持：正常なサーバーだけにトラフィックを流し、遅延やエラーを減らします。
- ダウンタイムの短縮：異常を自動検出してトラフィックを迂回させることで、サービス停止時間を抑えます。
- 運用負荷の軽減：問題の切り分けと対応を自動化し、手動での確認作業を減らします。
具体的な例
例えば、Webサーバーがメモリ不足で応答しなくなった場合、ヘルスチェックが異常を察知してそのサーバーを負荷分散の対象から外します。これにより、残りの正常なサーバーで処理を続けられます。
自動対応の価値
異常検出後に自動で再起動や通知、フェイルオーバーを行えば、復旧までの時間を短くできます。監視と組み合わせることで、運用チームはより重要な改善作業に集中できます。
ヘルスチェックは単なる監視ではなく、可用性を高めるためのアクティブな仕組みです。
ヘルスチェックの仕組みと技術的特徴
ターゲットごとの設定とリクエスト方式
ヘルスチェックはターゲットグループ単位で設定します。ALBやELBではHTTP/HTTPSで指定したパス（例：/health）へ定期的にリクエストを送ります。期待するのは2xx系の応答です。実例として、/healthに200を返す簡単なJSONを用意すると分かりやすいです。
判定基準（合格・不合格）
各ターゲットは連続する成功回数で「正常」、連続する失敗回数で「異常」と判定されます。間隔（Interval）、タイムアウト、成功/失敗の閾値を組み合わせて誤判定を減らします。短すぎる間隔は負荷を増やします。
Kubernetesのプローブ
KubernetesはLivenessとReadinessという2種類のプローブを持ちます。Livenessはコンテナの生存確認、Readinessはトラフィックを受けられるかの確認です。HTTPリクエスト、TCPソケット接続、コマンド実行のいずれかで判定します。Readinessが不合格だとサービスはそのPodへ転送を停止します。
Amazon ECSのコンテナヘルスチェック
ECSではタスク定義内で指定したコマンドを定期実行します。コマンドが0で終了すれば成功と見なします。異常な終了コードやタイムアウトは失敗扱いです。ECSはデプロイ後の猶予（grace period）を設定可能で、起動直後の一時的な失敗を許容できます。
実装の注意点
- ヘルスエンドポイントは軽量にして副作用を起こさないようにします。
- 内部の依存（DBや外部API）まで厳密に判定すると誤検知が増えます。簡潔に状態を示す設計が有効です。
ヘルスチェックの設定と監視の統合
概要
ヘルスチェックの結果をただ見るだけで終わらせず、監視基盤に取り込むことで運用効果が大きく向上します。ここでは設定手順と運用で役立つ統合の実例を分かりやすく説明します。
設定の基本手順
- メトリクス選定：応答時間、HTTPステータス、エラー率、リソース使用率（CPU、メモリ）などを決めます。例：応答時間が3秒超なら警告。
- データ送信：ヘルスチェックの結果をモニターサービスに送ります。多くはAPIやエージェントで自動送信できます。
ダッシュボード作成と可視化
重要なメトリクスをグラフ化して一目で状態が分かるようにします。例：サービスごとのエラー率と過去24時間の応答時間を並べて表示します。
アラートと通知設定
閾値と通知先を明確にします。たとえば、エラー率が5%を超えたらメールとチャットに通知し、一定回数でオンコールへエスカレーションするルールを作ります。
異常検知システムの連携
単純閾値だけでなく、異常検知を導入すると変化の兆候を早く捕捉できます。自動検出でアラートを絞り、誤検知を減らす工夫をします。
運用上の注意点
- ログとメトリクスを同時に保存し、原因追跡を容易にします。
- 定期的に閾値とダッシュボードを見直し、環境変化に合わせて調整します。
実務運用におけるヘルスチェックの重要性
はじめに
ロードバランサーを運用する現場では、ヘルスチェックが稼働の要になります。適切に設定すると、利用者への影響を最小化しつつ迅速に問題を切り分けられます。
日常運用での利点
- 可用性向上：不調なインスタンスを自動で外し、正常なものにトラフィックを集中できます。具体例：HTTP 500を返すコンテナを自動で除外し、ユーザー影響を抑えます。
- 運用負荷の軽減：手動で切り戻す回数が減り、復旧作業に集中できます。
設定の実務ポイント
- チェック間隔とタイムアウトを調整する：短すぎると誤検知、長すぎると復旧が遅れます。
- 判定基準を明確にする：単純な応答コード（200）だけでなく、簡単な処理結果やヘルス用エンドポイントを用意します。
- コンテナ環境ではライブネス／レディネスを分けて設定します。
障害発生時の運用フロー
- 検知：ヘルスチェックで異常を検知し、アラートを発生させます。
- 切替：ロードバランサーが自動でトラフィックを別の正常インスタンスへ流します。
- 調査と復旧：ログ確認、プロセス再起動、必要ならロールバックを行います。
- 振り返り：原因と設定の見直しを行い、再発防止策を文書化します。
監視と継続的改善
失敗率、MTTR（平均復旧時間）、正常稼働率などを定期的にレビューし、閾値やチェック内容を改善します。小さな障害を意図的に発生させるテストも有効です。
