コンテンツにスキップ

Cloudflaredのトンネル容量

Cloudflareトンネルが稼働しているので、cloudflaredがエンドユーザーからの予想されるリクエスト量を処理するのに十分なシステムリソースを持っているか評価してください。

Unlike legacy VPNs where throughput is determined by the server’s memory, CPU and other hardware specifications, Cloudflare Tunnel throughput is primarily limited by the number of ports configured in system software. Therefore, when sizing your cloudflared server, the most important element is sizing the available ports on the machine to reflect the expected throughput of TCP and UDP traffic.

単一のマシンでポートを使い果たした場合は、cloudflaredを実行する追加のサーバーを追加する必要があります。

トンネルのサイズを決定する

必要なcloudflaredホストサーバーの数を決定するには:

  1. 基本的な推奨事項から始めます:

    • Run a cloudflared replica on two dedicated host machines per network location. Using two hosts enables server-side redundancy and traffic balancing.
    • Size each host with minimum 4GB of RAM and 4 CPU cores.
    • Allocate 50,000 ports to the cloudflared process on each host.

    This setup is usually sufficient to handle traffic from 8,000 users (4,000 per host).

  2. この学習パスを完了し、ユーザーがネットワークに積極的に参加している場合、実際のトンネル使用量を計算します。

  3. どれだけの余裕を持たせたいかを決定し、必要に応じてトンネルのサイズを変更します。

トンネルのスケール

Cloudflareトンネルをスケールする方法は2つあります:既存のトンネルの追加レプリカを追加するか(図1)、ネットワークのIPスペースを複数のトンネルに分割するか(図2)です。

flowchart TB
accTitle: 図1: すべてのプライベートネットワークをプロキシするトンネルの複数レプリカ。
subgraph replica1[my-tunnel]
  ip1[10.0.0.0/8 </br> 172.0.0.0/8 </br> 192.0.0.0/8]
end
subgraph replica2[my-tunnel]
  ip2[10.0.0.0/8 </br> 172.0.0.0/8 </br> 192.0.0.0/8]
end
subgraph replica3[my-tunnel]
  ip3[10.0.0.0/8 </br> 172.0.0.0/8 </br> 192.0.0.0/8]
end
replica1 <--> C((Cloudflare))
replica2 <--> C
replica3 <--> C
flowchart TB
accTitle: 図2: 異なるプライベートネットワークをプロキシする複数のトンネル。
subgraph tunnel-1
  ip1[10.0.0.0/8]
end
subgraph tunnel-2
  ip2[172.0.0.0/8]
end
subgraph tunnel-3
  ip3[192.0.0.0/8]
end
tunnel-1 <--> C((Cloudflare))
tunnel-2 <--> C
tunnel-3 <--> C

レプリカを追加するタイミング

既存のCloudflareトンネルの追加レプリカを追加する(2つが基本的な推奨事項)ことは、トンネル内のIPルートへの追加トラフィックをサポートするためだけに行うべきです。レプリカは常に同じ物理的場所に追加する必要があり、プールモードで動作できるようにします。異なる地理的場所にレプリカを追加することを検討している場合は、Cloudflareトンネルのネットワークプロキシ設計を再評価し、トンネルを追加するタイミングを参照してください。

トンネルを追加するタイミング

異なる場所のサーバー

ネットワークが異なる地理的場所に分散している場合は、新しいトンネルを作成することを検討してください。たとえば、10.0.0.0/8で表されるネットワークがほぼ完全に東部アメリカに連続していると仮定し、10.0.50.0/24の重複しない例外が太平洋北西部から提供されているとします。太平洋北西部から追加のレプリカを提供するのではなく、10.0.50.0/24を別のCloudflareトンネルに分割することをお勧めします。この新しいトンネルを太平洋北西部近くのホストマシンから提供し、独自のバランスの取れたレプリカ実装を持たせます。

同じ場所のサーバー

ネットワーク内のすべてのルートが同じ物理的場所から提供されている場合でも、制御プレーンの冗長性の観点から、レプリカを追加するのではなく、ネットワークを別々のトンネルに分割することが最終的に理にかなう場合があります。

たとえば、10.0.0.0/8172.0.0.0/8、および192.0.0.0/8の範囲を複数のレプリカを持つ単一のトンネルからプロキシしている場合、ネットワークの多様なトラフィックに関してポート枯渇の状態に達する可能性があります。10.0.0.0/8172.0.0.0/8、および192.0.0.0/8をそれぞれ独立したトンネルに分割し、それぞれに独自のレプリカを持たせることが理にかなうかもしれません。あるいは、特定のアプリケーションや機能(DNSサーバーや高ボリュームの独立したトラフィックを生成する他の機能など)を見つけ、それらを適切なスループットとレプリカボリュームを持つスタンドアロンのトンネルに分割することもできます。