ロードバランサーは、プールの健全性 と トラフィックステアリングポリシー に従って、プール間にトラフィックを分散します。各ロードバランサーは、DNS ホスト名(lb.example.com、dev.example.com など)または IP アドレスで識別します。
構成例は 一般的なロードバランサー構成 を参照してください。
パブリックロードバランサーは、パブリックインターネットからのトラフィックを処理します。デプロイするとホスト名が自動で割り当てられ、すぐに利用できます。これらのロードバランサーは、公開ホスト名、パブリック IP アドレス、プライベート IP アドレスなど、さまざまな宛先へトラフィックを送れます。
一方、プライベートロードバランサーは、プライベートネットワーク内での内部利用を想定しています。ホスト名は自動では割り当てられませんが、Gateway のファイアウォールポリシーや内部 DNS で割り当てできます。プライベートロードバランサーは、Cloudflare One Client や Cloudflare WAN などのプライベートネットワークオンランプ経由のトラフィックだけを受け付けます。転送先はプライベート IP アドレスに限られます。
DNS レコードの詳細は、負荷分散用の DNS レコード を参照してください。
Cloudflare は keep-alive 接続を維持し、エッジネットワークからサイトのオリジンへトラフィックをプロキシする際の、繰り返しの TCP 接続の性能向上とコスト削減を図ります。
オリジンで HTTP Keep-Alive 接続を有効にします。Cloudflare は、最後の HTTP リクエストから最大 15 分(900 秒)まで、開いている TCP 接続を再利用します。開いている TCP 接続が多すぎると、オリジンの Web サーバーは接続を閉じます。HTTP Keep-Alive により、Cloudflare がプロキシするリクエストで接続が早期にリセットされるのを避けられます。
HTTP Cookie でユーザーセッションを特定のサーバーに結び付ける場合 は、セッションアフィニティ を設定し、Cookie ヘッダーで HTTP リクエストを解析します。keep-alive により複数の HTTP リクエストが同じ TCP 接続を共有しても、各リクエストを正しいアプリケーションサーバーへ送れます。
たとえば、F5 BIG-IP のロードバランサーは、TCP 接続の開始時にセッション Cookie を設定し(存在しない場合)、同じ TCP 接続上の以降の HTTP リクエストの Cookie を無視します。Cloudflare は同じ TCP 接続で複数の HTTP セッションを送るため、セッションアフィニティが崩れやすくなります。ロードバランサーを Cookie ヘッダーで HTTP リクエストを解析する設定にすると、この問題を避けられます。
手順は ロードバランサーを作成する を参照してください。
ロードバランサーのプロパティの最新一覧は、Cloudflare API ドキュメントの ロードバランサーのプロパティ を参照してください。
Cloudflare API は、ロードバランサー向けに次のコマンドをサポートしています。
| コマンド | メソッド | エンドポイント |
|---|---|---|
| ロードバランサーを作成する | POST |
/zones/:zone_id/load_balancers |
| ロードバランサーを削除する | DELETE |
/zones/:zone_id/load_balancers/:id |
| ロードバランサーを一覧表示する | GET |
/zones/:zone_id/load_balancers |
| ロードバランサーの詳細 | GET |
/zones/:zone_id/load_balancers/:id |
| 特定のプロパティを上書きする | PATCH |
/zones/:zone_id/load_balancers/:id |
| ロードバランサー全体を上書きする | PUT |
/zones/:zone_id/load_balancers/:id |