ただし、ロードバランサーの役割はトラフィックの分散だけではありません。
ロードバランサーとプールが、オフラインのサーバーや、すでに過負荷のサーバーへリクエストを送っても意味がありません。理想的には、サーバーが処理できるリクエストだけを転送します。
そこで登場するのが、ロードバランシングのもう一つの要素であるモニターとヘルスチェックです。
flowchart RL
accTitle: ロードバランシングのモニターの流れ
accDescr: モニターはヘルスモニターリクエストを送り、各プール内のサーバーの現在の状態を確認します。
Monitor[モニター] -- ヘルスモニター ----> Endpoint2
Endpoint2 -- 応答 ----> Monitor
subgraph Pool[プール]
Endpoint1((エンドポイント 1))
Endpoint2((エンドポイント 2))
end
モニターは定期的にヘルスチェックを発行し、プール内の各サーバーの健全性を評価します。
モニターが定期的に発行するリクエストです。モニター設定に応じて pass または fail を返し、エンドポイントが引き続きトラフィックを受けられるかを確認します。
各ヘルスモニターリクエストは、次の 2 つの問いに答えようとします。
- エンドポイントはオフラインか？: エンドポイントはヘルスモニターリクエストに応答するか。応答する場合、十分に速く応答するか（モニターの Timeout フィールドで指定）。
- エンドポイントは想定どおり動作しているか？: エンドポイントは想定した HTTP レスポンスコードを返すか。レスポンス本文に特定の情報が含まれるか。
いずれかの答えが「いいえ」の場合、そのエンドポイントはヘルスモニターリクエストに失敗します。
このリクエストとレスポンスの仕組みにより、ロードバランサーは受信リクエストを処理できるサーバーを把握できます。