Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

エンドポイントとプールが unhealthy になる仕組み

最終更新 Markdown で表示Agent セットアップ

動的ロードバランシングでは、ロードバランサーは処理できるエンドポイントにだけリクエストを送ります。

では、ロードバランサーはどのエンドポイントが処理できるかを、どう知るのでしょうか。モニター、ヘルスモニター、プールの仕組みで判定します。


動的ロードバランシング

動的ロードバランシングは、プールモニターヘルスチェック の組み合わせで動作します。

    flowchart RL
      accTitle: ロードバランシングのモニターの流れ
      accDescr: モニターはヘルスモニターリクエストを送り、各プール内のサーバーの現在の状態を確認します。
      Monitor[モニター] -- ヘルスモニター ----> Endpoint2
      Endpoint2 -- 応答 ----> Monitor
      subgraph Pool[プール]
      Endpoint1((エンドポイント 1))
      Endpoint2((エンドポイント 2))
      end

エンドポイントが unhealthy になる仕組み

ヘルスチェックは モニターが定期的に発行するリクエストです。モニター設定に応じて pass または fail を返し、エンドポイントが引き続きトラフィックを受けられるかを確認します。

各ヘルスモニターリクエストは、次の 2 つの問いに答えようとします。

  1. エンドポイントはオフラインか?: エンドポイントはヘルスモニターリクエストに応答するか。応答する場合、十分に速く応答するか(モニターの Timeout フィールドで指定)。
  2. エンドポイントは想定どおり動作しているか?: エンドポイントは想定した HTTP レスポンスコードを返すか。レスポンス本文に特定の情報が含まれるか。

いずれかの答えが「いいえ」の場合、そのエンドポイントはヘルスモニターリクエストに失敗します。

プールの Health Monitor Regions で選んだ各オプションについて、Cloudflare はそのリージョン内の 3 つのデータセンターからヘルスモニターリクエストを送信します。

ヘルスモニターリクエストは、選択した各リージョン内の 3 つのデータセンターから送信されます。

そのリージョンの過半数のデータセンターでヘルスモニターが成功すると、そのリージョンは健全とみなされます。健全なリージョンが過半数なら、エンドポイント自体も健全とみなされます。

ロードバランシングの分析とログには、グローバルな健全性の変化だけが表示されます。

エンドポイントの健全性ステータスをより正確かつ一貫して変えるには、Create Monitor API エンドポイントconsecutive_upconsecutive_down パラメーターを設定できます。healthy から unhealthy へ変えるには、エンドポイントが連続して unhealthy と判定される必要があります(回数は consecutive_down)。unhealthy から healthy への切り替えも、consecutive_up で同様です。


プールが unhealthy になる仕組み

個々のエンドポイントが unhealthy になると、関連するプールの健全性ステータス(ダッシュボードに表示)に影響する場合があります。

  • Healthy: すべてのエンドポイントが健全です。
  • Degraded: 少なくとも 1 つのエンドポイントが unhealthy ですが、プールはまだ健全と見なされ、トラフィックを受け取っている可能性があります。
  • Critical: プールが Health Threshold で指定した利用可能エンドポイント数を下回り、ロードバランサーからトラフィックを受け取りません(ほかのプールも unhealthy で、このプールが Fallback Pool の場合を除く)。
  • Health unknown: プールのエンドポイントにモニターが付いていないか、モニターがまだエンドポイントの健全性を判定していません。
  • No health: ロードバランサーの Fallback Pool 用です。

トラフィックの分散

プールが Critical ヘルスになると、ロードバランサーは Traffic steering ポリシー に従ってトラフィックを迂回し始めます。

  • Off:

    • アクティブなプールが unhealthy になると、トラフィックは順序どおり次のプールへ送られます。
    • 非アクティブなプールが unhealthy になっても、トラフィックはアクティブなプールへ送られ続けます(フェイルオーバー順では unhealthy なプールをスキップします)。
  • その他の方法: 残りのすべてのプールに、Traffic steering ポリシーに従ってトラフィックが分散されます。

フォールバックプール

このプールは最終手段のプールです。トラフィックを振り分けるとき、このプールのヘルスは考慮されません。

フォールバックプールは重要です。すべてのプールに到達できない(無効または異常)場合でも、ロードバランサーへトラフィックが届くことがあります。ロードバランサーはこのトラフィックの送り先が必要なため、フォールバックプールへ送ります。


ロードバランサーが unhealthy になる仕組み

1 つ以上のプールが unhealthy になると、ダッシュボード上のロードバランサーのステータスも変わることがあります。

  • Healthy: すべてのプールが健全です。
  • Degraded: 少なくとも 1 つのプールが unhealthy ですが、トラフィックはまだ Fallback Pool へ送られていません。
  • Critical: すべてのプールが unhealthy で、トラフィックは Fallback Pool へ送られています。

ロードバランサーが Critical になり、フォールバックプールとして使っているプールも無効な場合:

  • Cloudflare がホスト名をプロキシしている場合は、530 HTTP/1016 Origin DNS failure が表示されます。
  • Cloudflare がホスト名をプロキシしていない場合は、SOA レコードが表示されます。

役に立ちましたか?