Skip to content

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

システム要件

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

コネクターである cloudflared は軽量で柔軟なため、Raspberry Pi、ノート PC、データセンターのサーバーなど、さまざまな環境に導入できます。

従来の VPN ではスループットがサーバーのメモリ、CPU、その他のハードウェア仕様で決まります。一方、Cloudflare Tunnel のスループットは、主にシステムソフトウェアで設定したポート数によって制限されます。そのため、cloudflared サーバーのサイジングでは、想定する TCP および UDP トラフィックのスループットに合わせて、マシン上で利用できるポート数を確保することが最も重要です。

推奨構成

多くの用途では、次の構成を基準にします。

  • ネットワーク拠点ごとに、専用ホスト 2 台で cloudflared レプリカ を実行します。ホストを 2 台使うと、サーバー側の冗長性を確保できます。
  • 各ホストには、メモリ 4 GB 以上、CPU 4 コア以上を割り当てます。
  • 各ホストの cloudflared プロセスに、ポート を 50,000 割り当てます。

この構成で、通常は Cloudflare One Client ユーザー 8,000 人分（ホストあたり 4,000 人）のトラフィックを処理できます。cloudflared が実際に使うリソースは、1 秒あたりのリクエスト数、帯域、ネットワーク経路、ハードウェアなど、多くの変数に依存します。ユーザーが増えた場合や、既存の トンネル容量 を超えるトラフィックになった場合は、その拠点に cloudflared ホストを追加してトンネルをスケールできます。

ポート数

cloudflared はデバイスからのリクエストを受け取ると、ホスト上のポートを使って評価し、オリジンサービスへ転送します。マシンはハードウェア上、最大 65,535 ポートまでです。さらに、マシン上の各サービスが使えるポート数にも上限があります。そのため、次の導入モデルを推奨します。

  • cloudflared は専用ホストに導入します。多くの場合はこのモデルが適切ですが、サーバーレスやクラスターのワークフローでは、専用ホストが難しいことがあります。
  • ホストは、cloudflared サービスが使えるポートを 50,000 割り当てます。残りのポートは、システムの管理プロセス用に予約します。

Linux で cloudflared が使えるポート数を増やすには、次の手順を行います。

マシンに /etc/sysctl.d/ ディレクトリがある場合:

echo 'net.ipv4.ip_local_port_range = 11000 60999' | sudo tee -a /etc/sysctl.d/99-cloudflared.conf
sudo sysctl -p /etc/sysctl.d/99-cloudflared.conf

ない場合:

echo 'net.ipv4.ip_local_port_range = 11000 60999' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p /etc/sysctl.conf

Windows で cloudflared が使えるポート数を増やすには、TCP と UDP の 動的ポート範囲 ↗ を設定します。

netsh int ipv4 set dynamicport tcp start=11000 num=50000
netsh int ipv4 set dynamicport udp start=11000 num=50000
netsh int ipv6 set dynamicport tcp start=11000 num=50000
netsh int ipv6 set dynamicport udp start=11000 num=50000

プライベート DNS

DNS クエリは、TCP や DNS 以外の UDP リクエストより多くのシステムリソース を使います。サービスの可用性を高めるため、プライベート DNS トラフィック は、専用の Cloudflare Tunnel に分けることを推奨します。トンネルは専用ホストで動かし、内部 DNS リゾルバーの IP 向けルートだけを含めます。

ulimits

Linux と macOS では、ulimit の設定でログインユーザーが使えるシステムリソースが決まります。cloudflared サーバーでは、次の ulimit を設定することを推奨します。

ulimit 説明 値
-n オープンファイルまたはファイルディスクリプタの最大数 ≥ 70,000

現在の ulimit を確認するには、ターミナルを開いて次を実行します。

ulimit -a

オープンファイルの ulimit を設定するには:

ulimit -n 70000

上記のコマンドは、現在のターミナルセッションに対してだけオープンファイルの上限を設定します。再起動や再ログイン後には残りません。この上限を永続的に適用するには、ご利用の OS に合った永続設定の方法で構成してください。

想定スループット

cloudflared がプロキシするプライベートネットワークトラフィックの多くは、次のいずれかです。

  • TCP リクエスト（より一般的で、リソース消費は少なめ）
  • UDP リクエスト（あまり一般的ではなく、リソース消費は多め）

TCP トラフィックは、ポートをほぼ瞬時に使って解放します。つまり、ポート 50,000 の cloudflared インスタンスを過負荷にするには、組織が 1 秒あたり 50,001 件の TCP リクエストを継続的に発生させる必要があります。

UDP トラフィックは性質が異なります。通常 UDP の大半を占める DNS クエリは、cloudflared のポートで 5 秒間保持されます。DNS 以外の UDP トラフィックは、接続の間ポートを保持し、その時間は任意です。つまり、ポート 50,000 の cloudflared インスタンスを過負荷にするには、プライベートリゾルバーへ 1 秒あたり 10,000 件の DNS クエリを継続的に送るか、接続のリセット間隔より短い時間に累計 50,000 件の DNS 以外の UDP リクエストを送る必要があります。

トンネル容量を算出する

基準の推奨構成 は、Cloudflare Tunnel 導入の出発点です。代表的なユーザー数が少なくとも 1 週間ネットワークを使ったあと、実際のトラフィックパターンに合わせてトンネルサイズを調整できます。

トンネル容量を算出する手順は次のとおりです。

  1. トンネル実行時に メトリクスサービス を設定します。
  2. 1 週間ほど経過したら、次の トンネルメトリクス を照会します。
    • cloudflared_tcp_total_sessions
    • cloudflared_udp_total_sessions
  3. 総セッション数を総時間で割り、平均の 1 秒あたりの TCP リクエスト数 と 1 秒あたりの DNS 以外の UDP リクエスト数 を求めます。
  4. プライベート DNS リゾルバーで、平均の 1 秒あたりのプライベート DNS リクエスト数 を取得します。
  5. 算出した値を、次のサイジング計算機に入力します。

システム設定





メトリクス




結果

>
>
>
この計算機は参考用であり、結果はすべて見積もりです。

これらの結果で、トンネルのサイズが適切かを判断できます。トンネル容量を増やすには、cloudflared レプリカ を動かす同一構成のホストを追加します。

役に立ちましたか？