Skip to content

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

FAQ

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

概要

Load Balancing の詳細(ハウツー、チュートリアル、その他のリファレンス)は、製品ドキュメント を参照してください。


オリジンがこれほど多くのヘルスモニターリクエストを受け取るのはなぜですか?

この問題は、次の 2 つの要因が重なって起きることがあります。

複数の Health Monitor Regions

モニターをプールに紐づける とき、エンドポイントの健全性監視に Cloudflare が使う Health Monitor Regions を指定できます。

複数のリージョンを選ぶか、All Data Centers (Enterprise Only) を選ぶと、そのプールと関連エンドポイントへの トラフィックが大幅に増える ことがあります。各リージョンは 3 つのデータセンターから個別のヘルスモニターリクエストを送ります。All Data Centers を使うと、既存のすべての Cloudflare データセンターから個別のヘルスモニターリクエストが送られます(データセンター数は増え続けています)。

トラフィックを減らすには、選ぶリージョン数を減らすか、All Data Centers 以外のオプションを選んでください。

ヘルスモニターリクエストの間隔が短い

ヘルスモニターリクエストの間隔が短いと、エンドポイントへ送るトラフィックが増えることがあります。


エンドポイントまたはプールが不健全と見なされるのはなぜですか?

エンドポイントとプールが不健全になる仕組みは エンドポイントとプールの健全性 を参照してください。

エンドポイントが健全だと分かっているのに、ロードバランシングが不健全と報告する場合は、モニター で次の設定を確認してください。

  • 設定したエンドポイントに対して curl リクエストを実行します。表示されるレスポンスが、モニターの設定と一致することを確認します。
  • ファイアウォールまたは Web サーバーが ヘルスモニター をブロックまたはレート制限しておらず、Cloudflare の IP アドレス からのリクエストを受け入れていることを確認します。
  • Response Body で特定の値を探している場合は、その値が比較的静的で、HTML ページの先頭 10 KB 以内にあることを確認します。
  • エンドポイントが 301 または 302 ステータスコードを返す場合は、Follow Redirects がオンであることを確認します。
  • Timeout の値を長くしてみます。
  • ヘルスモニターの Host Header を確認します。
  • Authenticated Origin Pulls (mTLS)Argo Smart RoutingBring your own CA (mTLS)Dedicated CDN Egress IPs、または HTTP/2 to Origin を使っている場合は、これらの機能を設定しているゾーンに対応する Simulate Zone のゾーン値を入力していることを確認します。

プライマリプールがまだ健全なのに、ロードバランサーがセカンダリプールへトラフィックを送るのはなぜですか?

特定のデータセンターからのヘルスモニターリクエストが失敗すると(エンドポイント自体は健全でも)、トラフィックがそのプールから外れることがあります。そのデータセンターは、当該データセンターから見て健全と見なされる別のプールへ、少数のリクエストを送ることがあります。

エンドポイントとプールが不健全になる仕組みは エンドポイントとプールの健全性 を参照してください。


プールまたはエンドポイントが不健全になると何が起きますか?

プールまたはエンドポイントが不健全になると、設定に基づいて、ほかの健全なプールまたはエンドポイントへトラフィックが再ルーティングされることがあります。次の場合に、この動作が起きることがあります。

  1. All-Datacenters 監視のプールで、特定のデータセンターでモニターが失敗した場合。この場合、モニターが再び成功するまで、そのデータセンター内の影響を受けたエンドポイントからすべてのトラフィックが外されます。これらの事例は、LB リクエスト分析で、不健全なエンドポイントまたはプールからのステアリングとして記録されます。

  2. FQDN エンドポイントアドレスのプールで、特定のデータセンターで再帰 DNS ルックアップが失敗した場合。この場合、DNS リクエストが失敗したリクエストだけが、影響を受けたエンドポイントから外されます。上流の権威リゾルバーがときどきタイムアウトまたは失敗し、ローカル DNS キャッシュの TTL が切れてホットパスでリモートルックアップが必要になる場合は、散発的に起きることがあります。これも LB リクエスト分析では不健全なエンドポイントからのステアリングとして表示され、リクエストログから解決済みエンドポイント IP が欠けます。

これらの状況を避けるには:

  1. All-Datacenters 監視を使わないでください。

  2. エンドポイント設定には IP アドレスを使います。それが難しい場合は、Cloudflare が権威(プライマリまたはセカンダリ)であるドメインを使います。

エンドポイントとプールが不健全になる仕組みは エンドポイントとプールの健全性 を参照してください。


Load Balancing と Health Checks の違いは何ですか?

Cloudflare Load Balancing はエンドポイントの健全性を監視し、その情報などをもとに着信リクエストをルーティングします。個々のエンドポイントにはモニターが紐づき、一定間隔でモニターリクエストを発行します。

Cloudflare Health Checks はロードバランサー内のモニターと同じですが、サーバーの健全性のプローブだけが目的で、トラフィックの分散は行いません。


Load Balancing Analytics でリクエスト数が違って見えるのはなぜですか?

Load Balancing Analytics を確認すると、ほかの Cloudflare ダッシュボード(Caching など)と比べて、リクエスト数が違って見えることがあります。

ロードバランシングの requests は、ロードバランサーが行った未キャッシュのリクエスト数です。デフォルトでは、Cloudflare は解決した IP アドレスを最大 5 秒間キャッシュします。この組み込みキャッシュが、数値の食い違いの原因になることがよくあります。


ロードバランサーまたはモニターで特定のエラーコードが出ます

特定のエラーコードと次の手順の一覧は Load Balancing のトラブルシューティング を参照してください。


関連リソース

役に立ちましたか?