パブリックロードバランサー

パブリックロードバランサー を使うと、公開アプリケーション を動かしているサーバー間にトラフィックを分散できます。

Cloudflare Tunnel に 公開アプリケーションルート を追加すると、Cloudflare は作成したトンネルの UUID を使って cfargotunnel.com のサブドメインを生成します。アプリケーションをロードバランサープールに追加するには、<UUID>.cfargotunnel.com を エンドポイントアドレス に使い、エンドポイントのホストヘッダー にアプリケーションのホスト名（app.example.com）を指定します。サービスが Cloudflare Tunnel の背後にある場合、Load Balancer は app.example.com をエンドポイントとして直接追加することをサポートしません。

• 公開アプリケーションルート を持つ Cloudflare Tunnel

Cloudflare Tunnel の公開アプリケーション用にロードバランサーを作成するには:

1. Cloudflare ダッシュボードで Load Balancing ページを開きます。

   Load Balancing を開く ↗

2. Create load balancer を選び、Public load balancer を選びます。

3. Select website で、公開アプリケーションルートのドメインを選びます。

4. Hostname ページで、ロードバランサーのホスト名を入力します（例: lb.example.com）。

5. Pools ページで Create a pool を選び、わかりやすい名前を入力します。

6. 次の値でトンネルエンドポイントを追加します。

   • Endpoint Name: アプリケーションを実行しているサーバーの名前
   • Endpoint Address: <UUID>.cfargotunnel.com（Tunnel ID は the [Cloudflare dashboard](https://dash.cloudflare.com/) under **Networking** > **Tunnels** で確認します）
   • Header value: 公開アプリケーションルートのホスト名（例: app.example.com）
   • Weight: 1（エンドポイントが 1 つの場合）

7. Fallback pool を選びます。ルーティングの選択肢は トラフィックステアリングポリシー を参照してください。

8. （推奨）Monitors ページで、エンドポイントにモニターを関連付けます。HTTP または HTTPS アプリケーションの場合は、次の HTTPS モニターを作成します。

   • Type: HTTPS
   • Path: /
   • Port: 443
   • Expected Code(s): 200
   • Header Name: Host
   • Value: app.example.com

9. ロードバランサーを保存してデプロイします。

テストするには、ロードバランサーのホスト名（lb.example.com）でアプリケーションにアクセスします。

ロードバランサーの設定の詳細は Load Balancing のドキュメント を参照してください。

アプリケーションは、ロードバランサーのホスト名に対する Cloudflare の設定を既定で使います。Rules、Cache Rules、WAF ルール が含まれます。ホスト名の設定は Cloudflare ダッシュボード ↗ で変更できます。

Cloudflare Tunnel の背後にある公開アプリケーション向けの、よくあるロードバランシング構成を確認します。

この例では、2 つの異なるデータセンターのサーバーで動く Web アプリケーションがあるとします。ユーザーが世界中からアクセスできるよう、アプリケーションを Cloudflare に接続します。さらに、プライマリサーバーが故障したときにセカンダリサーバーがすべてのトラフィックを受け取るよう、Cloudflare にサーバー間のロードバランシングを任せます。

graph LR
		subgraph LB["パブリックロードバランサー <br> app.example.com "]
			subgraph P1[Pool 2]
				E1(["**エンドポイント:** &lt;UUID_1&gt;.cfargotunnel.com<br> **ホストヘッダー**: server2.example.com"])
			end
			subgraph P2[Pool 1]
				E2(["**エンドポイント:** &lt;UUID_2&gt;.cfargotunnel.com<br> **ホストヘッダー**: server1.example.com"])
			end
		end
		R@{ shape: text, label: "app.example.com" }
		R--> LB
    P1 -- Tunnel 1 --> cf1
    P2 -- Tunnel 2 --> cf2
		subgraph D2[プライベートネットワーク]
			subgraph r1[リージョン eu-west-1]
			cf1@{ shape: processes, label: "cloudflared <br> **ルート:** server2.example.com" }
			S1(["サーバー 2<br> 10.0.0.1:80"])
			cf1-->S1
			end
			subgraph r2[リージョン us-east-1]
			cf2@{ shape: processes, label: "cloudflared <br> **ルート:** server1.example.com" }
			S3(["サーバー 1 <br> 10.0.0.2:80"])
			cf2-->S3
			end
		end

		style r1 stroke-dasharray: 5 5
		style r2 stroke-dasharray: 5 5

図のとおり、一般的な構成は次のとおりです。

• データセンターごとに専用の Cloudflare Tunnel
• トンネルごとに 1 つのロードバランサープール。ロードバランサーのホスト名は、ユーザー向けアプリケーションのホスト名（app.example.com）にします。
• プールごとに 1 つのロードバランサーエンドポイント。エンドポイントのホストヘッダーは、cloudflared の公開アプリケーションホスト名（server1.example.com）にします。
• 各データセンターで、トンネルごとに少なくとも 2 つの cloudflared レプリカ。cloudflared のホストマシンが停止した場合に備えます。

ユーザーはロードバランサーのホスト名（app.example.com）でアプリケーションに接続できます。各プールはトンネルあたり 1 エンドポイントしかサポートしないため、この構成は Active-Passive フェイルオーバー にのみ有効です。

次の図は、1 つのロードバランサーでプライベートネットワーク上の 2 つの異なるアプリケーションへトラフィックを振り分ける方法です。

graph LR
		subgraph LB["パブリックロードバランサー <br> lb.example.com"]
			subgraph P1[App 1 用のプール]
				E1(["**エンドポイント:** &lt;UUID_1&gt;.cfargotunnel.com<br> **ホストヘッダー**: app1.example.com"])
				E2(["**エンドポイント:** &lt;UUID_2&gt;.cfargotunnel.com<br> **ホストヘッダー**: app1.example.com"])
			end
			subgraph P2[App 2 用のプール]
				E3(["**エンドポイント:** &lt;UUID_1&gt;.cfargotunnel.com<br> **ホストヘッダー**: app2.example.com"])
				E4(["**エンドポイント:** &lt;UUID_2&gt;.cfargotunnel.com<br> **ホストヘッダー**: app2.example.com"])
			end
		end
		R@{ shape: text, label: "app1.example.com <br> app2.example.com" }
		R--> LB
    E1 -- Tunnel 1 -->cf1
		E3 -- Tunnel 1 --> cf1
		E2 -- Tunnel 2 --> cf2
		E4 -- Tunnel 2 --> cf2

		subgraph N[プライベートネットワーク]
			cf2[cloudflared <br> **ルート:** app1.example.com <br> **ルート:** app2.example.com]
			S3(["App 1 <br> 10.0.0.1:80"])
			cf2-->S3
			cf2-->S1
			cf1[cloudflared <br> **ルート:** app1.example.com <br> **ルート:** app2.example.com]
			S1(["App 2 <br> 10.0.0.2:80"])
			cf1-->S1
			cf1-->S3
		end

このロードバランシング構成には次が含まれます。

• 両方のアプリケーションへ同一のルートを持つ 2 つの Cloudflare Tunnel
• アプリケーションごとに 1 つのロードバランサープール
• 各ロードバランサープールに、トンネルごとのエンドポイント
• 各アプリケーションの DNS レコード。ロードバランサーのホスト名を指します。

ユーザーはロードバランサー経由ですべてのアプリケーションにアクセスできます。プールあたり複数のトンネルエンドポイントがあるため、この構成は Active-Active フェイルオーバー をサポートします。Active-Active は、プール内の利用可能なすべてのエンドポイントでリクエストを同時に処理します。トラフィックを分散することで、性能とスケーラビリティが向上します。

ダッシュボードで公開アプリケーションルートを設定すると、Cloudflare はアプリケーションのホスト名（app1.example.com）をトンネルのサブドメイン（<UUID>.cfargotunnel.com）へ向ける CNAME DNS レコードを自動生成します。これらの DNS レコードを 編集 し、代わりにロードバランサーのホスト名を指すようにできます。

ロードバランサーあたり複数アプリ を設定する前後の DNS レコードの例は次のとおりです。

変更前:

変更後:

トンネルエンドポイントでは TCP モニターは使えません。代わりに、cloudflared ホスト上にヘルスチェック用エンドポイントを作り、HTTPS モニターを使います。たとえば、cloudflared で固定の HTTP ステータス応答を返すことができます。

1. ヘルスチェック用に 公開アプリケーションルートを追加 します。
   • Hostname: health-check.example.com
   • Service Type: HTTP_STATUS
   • HTTP Status Code: 200
2. 次の設定で モニターを作成 します。
   • Type: HTTPS
   • Path: /
   • Port: 443
   • Expected Code(s): 200
   • Header Name: Host
   • Value: health-check.example.com

このモニターは cloudflared に到達できることを確認します。上流サービスがリクエストを受け付けているかどうかは確認しません。

ロードバランサーは、同じトンネルの レプリカ を区別しません。同じトンネル UUID を 2 つの別ホストで動かすと、ロードバランサーは両方のホストを 1 つのエンドポイントとして扱います。クライアントと特定のホストの間で セッションアフィニティ を維持するには、ホストごとに異なるトンネル UUID で Cloudflare に接続する必要があります。

異なる拠点のエンドポイント間でトラフィックの偏りがある場合は、ロードバランサーの設定を調整する必要があります。

Cloudflare は Anycast ルーティング ↗ で、エンドユーザーのリクエストを最も近いデータセンターへ送ります。cloudflared は同じデータセンター内の接続でリクエストを処理することを優先するため、エンドポイント間のトラフィック分散に影響します。

同じトンネル UUID で cloudflared のレプリカ を動かしている場合は、トラフィックステアリング をより細かく制御するために、別々のトンネルへ切り替えることを検討してください。