Cloudflare Load Balancing は SaaS です。世界中のユーザー向けにアプリケーションをホストしつつ、保守、フェイルオーバー、耐障害性、スケーラビリティの負担を大きく減らせます。Cloudflare Load Balancing を使うと、次の課題に対応できます。
- 想定外の急増を含む、大量の着信トラフィックを効率よく処理する
- アプリケーションとサービスをユーザーから到達可能な状態に保つ
- 特に高トラフィック時に、すべてのユーザーへ速い応答と十分な性能を保つ
- トラフィック需要の変化に合わせ、インフラを成長に対応させる
- アプリケーションとサービスを分散型サービス拒否（DDoS）攻撃から守る
Cloudflare Load Balancing は、Cloudflare のコネクティビティクラウド上にあります。これはプログラム可能なクラウドネイティブサービスの統合基盤で、すべてのネットワーク（企業とインターネット）、クラウド環境、アプリケーション、ユーザーのあいだで、任意対任意の安全な接続を実現します。データセンターは over 330 cities に広がり、over 13,000 network peers と相互接続する、世界最大級のネットワークです。主要なインターネットエクスチェンジでの存在感も、ほかの大手テクノロジー企業より大きいです。
その結果、Cloudflare は世界のインターネット接続人口の約 95% から約 50 ms 以内で動作します。すべての Cloudflare サービスは各拠点で動く設計なので、リクエストは発生源の近くでルーティング、検査、フィルタリングされます。性能が良く、ユーザー体験も揃います。
この文書は、グローバルとローカルの両方のトラフィック管理に Load Balancing を導入したい組織向けのリファレンスアーキテクチャです。
このリファレンスアーキテクチャは、既存インフラの担当がある、またはその知識がある IT、Web ホスティング、ネットワークの専門家向けです。ルーティング、DNS、IP アドレスなどのネットワークの基礎と、ロードバランサーの基本的な動きを知っていると読みやすいです。
Cloudflare と Load Balancing の基礎を固めるには、次の資料を推奨します。
- ソリューションブリーフ: Cloudflare Private Network Load Balancing ↗（5 分）
- ソリューションブリーフ: Cloudflare GTM Load Balancing ↗（5 分）
- ブログ: Elevate load balancing with Private IPs and Cloudflare Tunnels: a secure path to efficient traffic distribution ↗（13 分）
このリファレンスアーキテクチャを読むと、次が分かります。
- Cloudflare Load Balancing が、Private Network Load Balancing とグローバルトラフィック管理の両方にどう使えるか
- Cloudflare のグローバルネットワークが、Cloudflare Load Balancing の機能をどう高めるか
- Cloudflare ロードバランサーの機能と、各種ユースケースへの当てはめ方
- Cloudflare ロードバランサーの構成と、設定の種類
この文書では、「エンドポイント」は、公開または非公開の着信トラフィックを受け取り、処理する任意のサービスまたはハードウェアです。負荷分散は Web サーバー以外にも使えるため、オリジン、ホスト名、プライベートまたはパブリック IP、仮想 IP（VIP）、サーバー、専用ハードウェアなど、あらゆる送信先を表す語としてエンドポイントを使います。オンプレミスでも、パブリックまたはプライベートクラウド上でも構いません。サードパーティのロードバランサーでもかまいません。
ステアリングはロードバランサーの中心機能です。ポリシーに基づいてリクエストを扱い、送り、転送します。ポリシーは通常、リクエスト URL、URL パス、HTTP ヘッダー、設定したウェイト、優先度、エンドポイントのレイテンシ、応答性、容量、負荷などを考慮します。
OSI モデル ↗ の レイヤー 7 ↗ はアプリケーション層です。SSH、FTP、NTP、SMTP、HTTP(S) などのプロトコルがここにあります。この文書でレイヤー 7 またはレイヤー 7 ロードバランサーと言うときは、HTTP(S) ベースのサービスを指します。Cloudflare のレイヤー 7 スタックでは、DDoS 防御、Bot Management、WAF、CDN、Load Balancing などを顧客のサイトに適用し、性能、可用性、セキュリティを高められます。
OSI モデル ↗ のレイヤー 4（トランスポート層）は、2 台のデバイス間のエンドツーエンド通信を担います。レイヤー 4 で動くネットワークサービスは、より幅広いサービスとプロトコルに対応できます。Cloudflare の公開レイヤー 4 ロードバランサーは、Spectrum という製品で有効になります。Spectrum はレイヤー 4 のリバースプロキシです。負荷分散に加え、DDoS 攻撃 ↗ からの保護と、エンドポイント IP の隠蔽も提供します。
SSL（Secure Sockets Layer）とその後継の TLS（Transport Layer Security）は、インターネット上の接続を保護する暗号プロトコルです。SSL/TLS オフロードは、SSL/TLS 終端または SSL/TLS アクセラレーションとも呼ばれます。ロードバランサーや Web サーバーで、SSL/TLS の暗号化と復号をエンドポイントの性能に影響させずに処理する手法です。証明書管理が簡単になり、リソース負荷の高い処理を専用装置へ移せます。エンドポイントはコンテンツとアプリケーションロジックに集中できます。
現代の Web サイトやアプリケーションには、主に 3 つの課題があります。
- 性能: ユーザーのリクエストと操作に、アプリケーションがすぐ応答すること
- 可用性: アプリケーションが稼働し続け、ユーザーのリクエストに応答できること
- スケーラビリティ: ユーザーの行動や需要に応じて、アプリケーション資源を増やし、減らし、配置し直すこと
アプリケーション性能に影響する要因はいくつかあります。もっとも多いのは、エンドポイントにかかる使用量や負荷です。エンドポイントが提供できる計算資源は有限です。リクエストが一度に多すぎる、または CPU/メモリ使用が増える種類のリクエストだと、応答が遅くなるか、応答しなくなります。
対策として、エンドポイントの計算資源を増やす方法があります。ただし、アイドル時や低負荷時は、使いきれない資源に対して費用を払うことになります。複数エンドポイントを置く方法もあります。ただし、エンドユーザーに意識させずに振り分けるには、ロードバランサーが必要です。
図 1 は、ロードバランサーがない場合の負荷の偏りです。
ロードバランサーを使うと、複数エンドポイントを置き、トラフィックを分けて、1 台だけが過負荷にならないようにできます。ロードバランサーがすべての着信リクエストを受け、適切なエンドポイントへ転送します。クライアントはエンドポイントの可用性や負荷を知る必要はありません。リクエストをロードバランサーへ送れば、残りはロードバランサーが処理します。図 2 は、ロードバランサーがユーザーからのトラフィックを複数エンドポイントへ均等に振る例です。
性能のもう一つの問題は、クライアントとエンドポイントの距離です。距離が長い、またはホップ数が多いと、往復時間（RTT）は一般に長くなります。
RTT は規模が大きくなると重要です。たとえば、クライアントとエンドポイントがともに米国にある場合、RTT は 25ms 程度が妥当です。クライアントが順次 20 件の応答を必要とすると、計算時間を除いた所要時間は 500ms（20 × 25ms）です。同じクライアントが APAC から接続すると、RTT は 150ms を超えることがあり、合計読み込み時間は 3000ms（20 × 150ms）と望ましくありません。HTTP/2 や HTTP/3 のリクエストストリーミングで計算は変わり得ます。ただし、動的または対話的なコンテンツでは、応答の情報から次のリクエストが生まれるため、この例はおおむね当てはまります。図 3 がその仕組みです。
ロードバランサーは、空いているエンドポイントへ振るのと同じように、地理的に近いエンドポイントへ振ることもできます。クライアントにとって応答が速くなります。具体的には、リクエスト送信元の IP を調べ、場所を判定し、最も近い、またはその地域に適したエンドポイントを選びます（GeoDNS などの DNS ソリューションに近い動きです）。
サービスの可用性は、ロードバランサー背後のエンドポイントの、意図しない停止と意図した停止の両方を含みます。意図しない停止の要因には、ハードウェア障害、ソフトウェアの不具合、ネットワーク問題、ISP やその他ベンダーの問題があります。どれだけ進んだ組織でも、これらは避けられません。
ロードバランサーは、エンドポイントの健全性を常に監視して解決します。ヘルスチェックへの応答が遅い、またはまったく応答しない場合、エンドポイントは不健全とマークされます。監視方法はいくつかあります。ICMP（ping）や TCP 接続テストなどの基本的な検査、HTTP GET を送り特定の応答コードと本文を確認する高度な検査などです。劣化状態になると、ロードバランサーはそのエンドポイントへのリクエストを減らすか止め、健全なエンドポイントへ振ります。運用が戻り、ヘルスチェックに応答できるようになると、再び健全とマークされ、トラフィックが戻ります。
意図した停止には、容量変更、ハードウェアやインフラのアップグレード、ソフトウェア更新があります。ロードバランサーは、こうした保守のために、1 つ以上のエンドポイントからトラフィックを穏やかに外します。
効果的なスケールは、顧客やユーザーの需要に応え、不要な課金を避けるために必要です。トラフィック増加時は、性能と可用性を保つためにエンドポイントを一時的に増やすことがあります。ただし、想定最大トラフィックに常に足りる台数をオンラインにしておくと、オンプレミスでも AWS、GCP、Azure などのクラウドでも費用が大きくなり得ます。ロードバランサーは、リクエスト、接続、レイテンシを監視し、容量の動的な増減を可能にします。
もう一つのスケールは地理です。サービスが広がると、エンドポイントの場所が重要になります。エンドポイントと異なる地域のユーザーは、同じ地域のユーザーより応答が遅く、品質が下がることがあります。新しい地域にエンドポイントを置くとき、トラフィックの分け方を決める必要があります。この課題には、global traffic management（GTM）と Private Network Load Balancing という、層の異なる負荷分散で応えてきました。次の節で詳しく説明します。要約すると、GTM ロードバランサーが最初のリクエスト（多くの場合 DNS）を扱い、適切な地域のエンドポイント近くに置いた Private Network Load Balancer へトラフィックを振ります。
前述のとおり、グローバルなアプリケーションとサービスの負荷分散は 2 層です。第 1 層は Global Traffic Management または Manager（GTM）で、Global Server Load Balancing（GSLB）とも呼ばれます。第 2 層は Private Network Load Balancing で、Server Load Balancing（SLB）とも呼ばれます。この節では、各種類の目的と連携を定義します。
Global Traffic Manager は、多くの場合インターネットからのリクエストを、適切な地域またはデータセンターへルーティングします。多くの GTM ロードバランサーは DNS 層で動き、次ができます。
- 地理的な地域または物理的な場所に基づき、DNS リクエストを IP アドレスへ解決する
- クライアントに最も近いエンドポイントまたはサービスの IP を返し、接続できるようにする
図 4 は、クライアントの場所または地域に基づき、GTM ロードバランサーがデータセンターを選ぶ例です。
Global Traffic Manager はトラフィックをプロキシし、さまざまな検査もできます。HTTP リクエストのヘッダーの読み取り、変更、削除や、地域や地理に基づく URL の変更などです。GTM は、世界中からのトラフィックを振るのが目的なので、クラウドベースのロードバランサー（Cloudflare など）での実装が向いています。ハードウェアロードバランサーは 1 か所にしかありません。ロードバランサーから遠いほど、エンドユーザー体験は遅くなります。クラウドベースなら多くの地域で動かせるので、DNS のみ、レイヤー 4、レイヤー 7 のいずれでも性能を出しやすいです。
Private Network Load Balancing は、データセンター内または地理的な拠点内でトラフィックを振ります。Private Network Load Balancer は、負荷分散、SSL/TLS オフロード、コンテンツスイッチング、その他のアプリケーション配信を担えます。クライアントリクエストを複数エンドポイントへ効率よく分け、性能を上げ、高可用性を保ちます。Private Network Load Balancer は通常プライベートネットワーク内に置き、公開または非公開のリソースを負荷分散します。図 5 では、GTM ロードバランサーがヨーロッパのデータセンターを選び、そのデータセンターの Private Network Load Balancer へリクエストを送り、最終的なエンドポイントへ振ります。
Private Network Load Balancer とそのエンドポイントは、通常ファイアウォールの内側にあります。エンドポイントはプライベートネットワークで保護されていても、デプロイ要件に応じて Private Network Load Balancer への到達は公開にも非公開にもできます。Private Network Load Balancer は、総リクエスト、接続、エンドポイント健全性を監視し、すぐ応答できるエンドポイントへリクエストを振ります。
ロードバランサーのアーキテクチャは主に 2 つです。
- オンプレミスのロードバランサー
- 通常はハードウェア。仮想化やソフトウェアベースもあります
- 最大性能を重視します
- クラウドベースのロードバランサー
- パブリッククラウド基盤上のソフトウェアです
- リクエスト発生源の近くで処理します
それぞれに長所と短所があります。オンプレミスのロードバランサーは、組織が完全に管理するプライベートネットワーク内にあることが多く、負荷分散するエンドポイントと同じ場所に置けます。レイテンシと RTT は最小になりやすいです。短所は、物理的に 1 か所に限られることです。ほかの地域からのトラフィックは RTT が長く、応答のレイテンシが高くなります。データセンターを増やすには、機器の購入と導入が必要です。地理的な振り分けには、近くの、または地域に適したデータセンターへリクエストを送るクラウドベースのロードバランサーも、通常は必要です。クラウドベースの長所は、ラック、電源、冷却、保守を気にせず、ほぼどの地域でも動かせることです。シャーシ、モジュール、より太い回線を気にせずスケールできます。一方、エンドポイントと同じ場所にないことが多いため、ロードバランサーとエンドポイント間のレイテンシと RTT は増えます。
Cloudflare は 2016 年からクラウドベースの GTM を提供し、2023 年から Private Network Load Balancing の機能を追加し始めました。この節では、Cloudflare Load Balancing 全体のアーキテクチャを見直し、設定とオプションを詳しく見ます。その前に、Cloudflare のグローバルネットワーク上で動くこと自体の利点を理解することが重要です。
Cloudflare Load Balancing は、Cloudflare のコネクティビティクラウド上にあります。これはプログラム可能なクラウドネイティブサービスの統合基盤で、すべてのネットワーク（企業とインターネット）、クラウド環境、アプリケーション、ユーザーのあいだで任意対任意の接続を実現します。データセンターは over 330 cities に広がり、over 13,000 network peers と相互接続する、世界最大級のネットワークです。主要なインターネットエクスチェンジでの存在感も、ほかの大手テクノロジー企業より大きいです。
その結果、Cloudflare は世界のインターネット接続人口の約 95% から約 50 ms 以内で動作します。すべてのサービスが各拠点で動く設計なので、トラフィックは発生源の近くで接続、検査、フィルタリングされます。性能が良く、ユーザー体験も揃います。
Cloudflare の負荷分散は、Anycast 技術の恩恵を受けます。Anycast により、Cloudflare は世界のすべてのデータセンターからサービスの IP を広報します。トラフィックは常に、発生源に最も近い Cloudflare データセンターへルーティングされます。検査、認証、ポリシー適用がエンドユーザーの近くで行われ、一貫して高い体験になります。
Anycast は、Cloudflare ネットワークの負荷も均等に保ちます。トラフィックが急増しても、複数データセンターへ負荷を分けられます。ユーザーの接続は安定しやすくなります。大きなネットワーク容量と、AI/ML で最適化したスマートルーティングも、性能の継続的な最適化に役立ちます。
一方、ほかの多くの SaaS 負荷分散は Unicast ルーティングです。1 つの IP が 1 つのエンドポイントやデータセンターに結び付きます。多くのこうした構成では、1 つの IP が特定のアプリケーションに結び付くため、距離によってルーティング体験が大きく変わります。オフィス隣のエンドポイントへアクセスする従業員には速く、遠隔や海外の従業員には遅くなる、といった差です。Unicast は負荷のスケールも複雑です。1 か所で資源を増やす必要があります。Anycast なら、多くのデータセンターと地域でトラフィックを分けられます。
図 6 は、地理的に離れたユーザーが、Cloudflare ネットワーク経由で資源へできるだけ速くつながる様子です。
図 6 のとおり、各データセンターではほかの Cloudflare サービスも動いています。Cloudflare はすべてのサービスをすべてのデータセンターで動かし、どこでも同じ体験になるようにしています。たとえばレイヤー 7 ロードバランサーは、DDoS 防御、CDN/Cache、Bot Management、WAF なども使えます。これらは、悪意のあるリクエスト（DDoS Protection、Bot Management、WAF で遮断）や、エンドポイントへ送らずキャッシュで返せるリクエストを減らし、サービスを不要なトラフィックから守れます。必要なサービスを組み合わせ、保護、耐障害性、性能を高められます。
Cloudflare には、すべてのデータセンターで常時動く ネットワーク最適化サービス ↗ もあります。Cloudflare データセンター間の最良パスを確保し、エンドポイントへ届くパスも追跡します。エンドポイントへ常に到達でき、必要なら別の Cloudflare データセンター経由に切り替えられます。ロードバランサーが振り先のエンドポイントを決めたあと、トラフィックはネットワーク最適化サービスへ渡り、送信先への最良パスが決まります。パスは Argo Smart Routing の影響を受けます。有効にすると、時間計測した TCP 接続で、エンドポイントまでの RTT が最も短い Cloudflare データセンターを探します。図 8 は、Argo Smart Routing がエンドポイントへの接続時間を改善する様子です。
トラフィックの流れは、Cloudflare Tunnel の利用でも変わります。Cloudflare Tunnel は次の節で詳しく扱います。Cloudflare Tunnel は特定の Cloudflare データセンターへエンドポイントをつなぐため、そのエンドポイント宛てのトラフィックは、トンネルが終端するデータセンターを通る必要があります。図 9 は、Cloudflare Tunnel でつないだプライベートエンドポイントへの接続が、トンネル終端のデータセンターを通る様子です。
通常、GTM と Private Network Load Balancer は別ハードウェアか、SaaS（GTM）とハードウェアの Private Network Load Balancing の組み合わせです。Cloudflare では GTM と Private Network Load Balancing が 1 つの SaaS にまとまっており、設定と管理が簡単です。GTM ロードバランサーを作り、よりローカルな Private Network Load Balancer へ振る必要はありません。すべてのエンドポイントを Cloudflare へ直接つなぎ、1 つのロードバランサー設定で、正しい地域、データセンター、エンドポイントへ振れます。GTM と Private Network Load Balancing の概念は残りますが、Cloudflare での実装は、設定をできるだけ単純に保つ形です。図 10 は、任意の地域からのグローバルトラフィックを、必要に応じて特定のエンドポイントへ振る様子です。
Cloudflare ロードバランサーは Virtual IP（VIP）と呼ばれることもあり、エントリポイントを設定します。エントリポイントは通常 DNS レコードです。ロードバランサーはまず定義したトラフィックステアリングアルゴリズムでエンドポイントプールを選びます。エンドポイントプールは、機能、地理、地域でまとめたエンドポイントのグループです。1 つの設定に 1 つ以上のエンドポイントプールを置け、各プールには 1 つ以上のエンドポイントを置けます。プールを選んだあと、エンドポイントステアリングアルゴリズムをエンドポイント一覧に適用し、振り先を決めます。図 11 は、クライアントリクエストからエンドポイントまでの基本的な流れです。
Cloudflare ロードバランサーの定義は、主に 3 つの部品に分かれます。
- ヘルスモニター: エンドポイントの健全性を観察し、健全またはクリティカル（不健全）に分類します。
- エンドポイントプール: エンドポイントを定義し、ヘルスモニターとエンドポイントステアリングを適用します。
- ロードバランサー: エンドポイントプールの一覧とトラフィックステアリングポリシーを適用します。
以降の節では、エンドポイントプールとロードバランサーの両方で使うステアリングから始め、Cloudflare ロードバランサーの設定オプションと検討事項を説明します。
ステアリングはロードバランサーの中核です。方式によって、最終的に選ばれるエンドポイントが決まります。ロードバランサーから見ると、ステアリングは 2 か所で適用されます。
1 つ目は「トラフィックステアリング」です。着信リクエストを扱うエンドポイントプールを、多くの場合、近さやリクエスターの地理に基づいて決めます。トラフィックステアリングは、グローバルトラフィック管理の考え方に近いです。
2 つ目は、地域、データセンター、またはエンドポイントプールを選んだあとのステアリングです。ここでロードバランサーは、リクエストまたは接続を扱う 1 つのエンドポイントを選びます。これを「エンドポイントステアリング」と呼びます。どちらの層でも、ロードバランサーを導入する顧客のニーズに合わせた方式を使います。アルゴリズムはいくつかあり、両方のステアリング種別に使えるものばかりではありません。
以下で、Cloudflare が提供するすべてのステアリング方式を詳しく見ます。節の末尾に早見表があります。どのアルゴリズムがどの用途に向くかの確認に使えます。
トラフィックステアリングは、エンドポイントのグループ（エンドポイントプール）を選びます。もっとも多い用途は、応答が最も速い、地理的な地域、または物理的な場所に基づいてプールを選ぶことです。トラフィックステアリングはグローバルトラフィック管理に近く、エンドポイントへ送る最初のステップです。
エンドポイントステアリングは、リクエストまたは接続を受けるエンドポイントを選びます。ランダム、以前選んだエンドポイント（session affinity が有効な場合）、または使用が少なく応答が速いエンドポイントを選べます。エンドポイントステアリングは Private Network Load Balancing に近く、リクエストまたは接続の最終送信先を決めます。
ウェイト付きステアリングは、ロードバランサーからのリクエストを扱うエンドポイントプールとエンドポイントの差を考慮します。エンドポイントのウェイトは必須ですが、特定のステアリング方式を選んだときだけ使われます。エンドポイントプールのウェイトも、特定の方式を選んだときだけ必要です。ウェイトをいつ使うかは、ステアリングオプションの概要 を参照してください。
ウェイトは、ロードバランサー内の 1 件のリクエストまたは接続について、エンドポイントプールまたはエンドポイント選択のランダムさに影響します。過去のデータや現在の接続情報は見ないため、短い時間では分布にばらつきが出ることがあります。ただし、長い期間と十分なトラフィックでは、設定したウェイトに近づきます。session affinity は初回接続のあとにウェイトを上書きします。session affinity は、以降のリクエストを同じエンドポイントプールまたはエンドポイントへ送るための機能です。図 12 は、容量と選択確率が等しい 2 つのエンドポイントプールのウェイト例です。
Least Outstanding Request Steering などの特定のアルゴリズムは、未完了のリクエストと接続の数を考慮します。ウェイトは、より多くの未完了リクエストまたは接続を扱えるエンドポイントまたはプールを決めるために使います。要するに、選んだステアリング方式に関係なく、ウェイトはエンドポイントまたはプールの容量を定義します。
ウェイトは 0.00 から 1.00 の任意の数です。エンドポイントプール全体、またはプール内エンドポイントのウェイト合計は 1 である必要はありません。ウェイトを足し、個々の値をその合計で割ると、そのエンドポイントが選ばれる確率になります。
ウェイトから割合への式: （エンドポイントのウェイト）÷（プール内の全ウェイトの合計）=（そのエンドポイントへのトラフィック割合）
ウェイトの使い方を理解するために、図付きの例を示します。この例では、同じ容量または計算資源のエンドポイントへ均等に振ることを目標とします。Random トラフィックステアリングで、3 つのエンドポイントプールへの分布を示します。
例 1:
- エンドポイントプールは 3 つで、いずれもウェイトは 1
- 各プールが選ばれる確率は 33%
ウェイト 1 の計算: (1) ÷ (1 + 1 + 1) = (.3333)（33.33%）
この例では、各プールのウェイトに 1 を付けるのが簡単でした。ただし、3 つのプールで同じ数なら、0.01 から 1.00 のどの数でも同じです。たとえばすべてを .1 または .7 にしても、各プールが選ばれる確率は等しいです。
確率はウェイトの合計から出すため、分かりやすい任意の値を使えます。次の例では、各エンドポイントの容量が同じなので、エンドポイントごとにウェイト .1 を付け、その合計をプールのウェイトにします。
例 2
- エンドポイントプールは 3 つ
- 各プールのエンドポイント数は異なるが、エンドポイントの容量はすべて等しい
- 負荷を均等にするには、各プールの確率を変える必要がある
ウェイト .4 の計算: (.4) ÷ (.4 + .5 + .6) = (.2667)（26.67%）
ウェイト .5 の計算: (.5) ÷ (.4 + .5 + .6) = (.3333)（33.33%）
ウェイト .6 の計算: (.6) ÷ (.4 + .5 + .6) = (.4000)（40.00%）
エンドポイントの容量がすべて同じとは限りません。次の例では、1 つのプールのエンドポイントが、ほかの 2 つのプールのエンドポイントの 2 倍の容量を持ちます。
例 3
- エンドポイントプールは 3 つ
- エンドポイントプール 1 のエンドポイントは、プール 2 とプール 3 の 2 倍の容量
- 目標は、エンドポイントあたりでプール 1 へ 2 倍のトラフィックを送ること
- プール 1 は 4 エンドポイントだが、容量が 2 倍なので、各エンドポイントのウェイトは .2、プール合計は .8
ウェイト .8 の計算: (.4) ÷ (.8 + .5 + .6) = (.4211)（42.11%）
ウェイト .5 の計算: (.5) ÷ (.8 + .5 + .6) = (.2632)（26.32%）
ウェイト .6 の計算: (.6) ÷ (.8 + .5 + .6) = (.3157)（31.57%）
この最後の例では、プール 1 の 4 エンドポイントがほかの 2 倍の容量なので、計算上は 4 ではなく 8 エンドポイントとして扱います。そのため、例 2 の .4 ではなく .8 を使います。
これらは、エンドポイントプールまたはエンドポイントへ負荷を分けるウェイトの、簡単な 3 例です。プール内エンドポイントのウェイトにも、同じ計算を使います。方式ごとの影響は似ていますが、計算は少し変わります。以降の節で扱います。
ウェイトが特に役立つのは、あるプールの資源が別のプールより多い場合や、プール内エンドポイントの容量が揃っていない場合です。能力に応じて、すべての資源を均等に使えます。
Off - failover は、もっとも基本的なトラフィックステアリングポリシーです。エンドポイントプールの並びを優先度リストとして使い、トラフィックを送るプールを選びます。リスト先頭のプールが健全でトラフィックを受けられるなら、そのプールが選ばれます。Off - failover はエンドポイントステアリングにはないため、エンドポイントの選択には別の方式を使います。Off - failover は、アクティブ/パッシブのフェイルオーバーでよく使います。通常はプライマリのデータセンターまたはエンドポイント群がトラフィックを扱い、障害時だけバックアップのエンドポイントプールへ振ります。
Random ステアリングは、トラフィックステアリングとエンドポイントステアリングの両方で使えます。ロードバランサー設定とエンドポイントプールの両方で定義したウェイトに基づき、資源へトラフィックを散らします。ロードバランサー設定の各プールのウェイトは、そのプール内エンドポイントのウェイトと違って構いません。たとえば、2 つのプールのうち 1 つへ 70% を送り、そのプール内では 4 エンドポイントへ均等に分ける、といった使い方です。前の節 ウェイト付きステアリング で、ウェイトの使い方と、プールまたはエンドポイント選択の計算を詳しく説明しています。
Hash ステアリングはエンドポイントステアリングのアルゴリズムです。エンドポイントのウェイトと、リクエストの送信元 IP でエンドポイントを選びます。同じ IP からのリクエストは、常に同じエンドポイントへ振ります。エンドポイントの並びを変える、追加する、削除すると、hash アルゴリズムの結果が変わることがある点に注意してください。
Geo ステアリングは、Enterprise プラン向けのトラフィックステアリングアルゴリズムです。エンドポイントプールを特定の国または地理的な地域へ結びます。ユーザーに近いエンドポイントへ振り、性能を上げる用途に使えます。特定地域のユーザーからのリクエストを、同じ地域の資源や、特定の規制要件を満たす資源へ振り、法令遵守にも役立ちます。
Dynamic ステアリングは、Enterprise プラン向けのトラフィックステアリングアルゴリズムで、往復時間（RTT）プロファイルを作ります。RTT はヘルスプローブのたびに収集し、エンドポイントのモニターリクエストへの応答に基づきます。リクエストがあると、Cloudflare は RTT データを確認し、RTT 値でプールを並べ替えます。ある地域またはコロケーションセンターにそのプールの RTT データがない場合、Cloudflare はフェイルオーバー順でプールへトラフィックを送ります。エンドポイントプールで初めて Dynamic ステアリングを有効にするときは、Cloudflare がそのプールの RTT プロファイルを作るあいだ、反映まで 10 分ほど待ってください。Dynamic ステアリングは地理的な境界を使わず、RTT が最も低いエンドポイントプールだけを選びます。
Proximity ステアリングは、Enterprise プラン向けのトラフィックステアリングアルゴリズムです。リクエストの発生場所から、物理的に最も近いデータセンターへ振ります。
Cloudflare は、次の順でリクエスターの物理的な場所を決めます。
- DNS リクエストに含まれる EDNS Client Subnet ↗ 情報
- Cloudflare へ到達するために使ったリゾルバーの位置情報
- リクエストを扱う Cloudflare データセンターの GPS 位置
Proximity ステアリングでは、すべてのエンドポイントプールに GPS 座標が必要です。Cloudflare は、リクエスト元 IP、DNS リゾルバー、または Cloudflare データセンターから、最も近いプールを計算します。
Least outstanding request ステアリング（LORS）は Enterprise プラン向けで、トラフィックステアリングとエンドポイントステアリングの両方に使えます。
LORS は未応答の HTTP リクエスト数でステアリングに影響し、Cloudflare のレイヤー 7 プロキシ付きロードバランサーでのみ機能します。ほかの種類のロードバランサーに LORS を付けると、Random ステアリングと同じ動きになります。LORS は未完了リクエスト数とウェイトから、ステアリング判断用の変換後ウェイトを作ります。
LORS の変換後ウェイトの式:
weight / (count + 1) = transformedWeight
Random のウェイト計算の再掲:
weight / (total weight) = 選ばれる確率
LORS の例:
- プール A のウェイトは 0.4
- プール B のウェイトは 0.6
- プール A の未完了リクエストは 3
- プール B の未完了リクエストは 0
- 使う式
weight / (count + 1) = transformedWeight
- プール A の変換後ウェイト: 0.4 / (3 + 1) = 0.1
- プール B の変換後ウェイト: 0.6 / (0 + 1) = 0.6
- 使う式
weight / (total weight) = 選ばれる確率
- プール A へ振られる確率: 0.1 / (0.1+0.6) = .1429（14.29%）
- プール B へ振られる確率: 0.6 / (0.1+0.6) = .8571（85.71%）
この例では、次の接続がプール A へ振られる確率は 14.29%、プール B へ振られる確率は 85.71% です。プール B へ振られやすいですが、プール A へ振られる可能性もあります。負荷が軽いときは結果のばらつきが大きく、設定ウェイトと正確に一致しないことがあります。負荷が増えると、実際の振り分けは設定ウェイトに近づきます。
L7 プロキシではないロードバランサーで LORS を使うと、未完了リクエスト数は使えません。分母は常に 1 です。1 で割っても分子は変わらず、分子はウェイトなので、判断はウェイトだけになります。これは前述の Random 方式と同じです。
LORS が向くのは、同時リクエストの急増でエンドポイントプールやエンドポイントがすぐ逼迫する場合です。レイテンシや地理的な近さより、エンドポイントの健全性を重視するアプリケーションに適します。一部またはすべてのリクエストがエンドポイントに重い負荷をかけ、応答生成に時間がかかる場合に特に有用です。
| ステアリング方式 | トラフィックステアリング | エンドポイントステアリング | ウェイトベース | Enterprise 限定 |
|---|---|---|---|---|
| Off - Failover | X | |||
| Random | X | X | X | |
| Hash | X | X | X | |
| Geo | X | X | ||
| Dynamic | X | X | ||
| Proximity | X | X | ||
| Least Outstanding Requests | X | X | X | X |
上表で Enterprise 限定とあるトラフィックステアリング方式は、セルフサービスアドオンでも利用できます。Enterprise 限定とあるエンドポイントステアリング方式は、Cloudflare の Enterprise プランが必要です。
ヘルスモニターは、エンドポイントプール内に設定したエンドポイントの健全性を判定します。ヘルスモニターはプローブ（エンドポイントへの接続試行）を生成し、その応答で健全性を記録します。ヘルスモニターはテンプレートで、サービスタイプ、パス、ポートに加え、間隔、タイムアウト、プロトコル固有の設定など、健全性評価の詳細を含みます。似たサービスをホストするエンドポイントプールにテンプレートを適用します。プールへ付けると、エンドポイントアドレスがヘルスプローブの送信先になります。1 つのヘルスモニターを多くのプールで使え、アカウントレベルのオブジェクトなので、同じ Cloudflare アカウント内の複数ゾーンで再利用できます。
デフォルトでは、ヘルスプローブはエンドポイントアドレスへ直接送られ、レイヤー 7 スタック全体を迂回します。つまり、ロードバランサー経由の実際のトラフィックと、ヘルスプローブの扱いが異なります。設定によっては、実際の接続やリクエストが失敗していても、ヘルスモニターが健全と報告することがあります。
Simulate Zone 機能を使うと、ヘルスプローブは指定ゾーンのレイヤー 7 HTTP/HTTPS リクエストと同じ経路を通り、オリジンへの出口も同じ Cloudflare のソフトウェア定義ルーティングを使います。ヘルスプローブは、実際のリクエストと同じ Cloudflare ネットワーク経路と、ほかのレイヤー 7 処理を経てオリジンエンドポイントへ届きます。
ゾーンで Authenticated Origin Pulls や Bring your own CA などが有効な場合、正しい mTLS 証明書や認証局がないとプローブは失敗します。こうした機能を使うときは、ヘルスモニターに Simulate Zone が必要です。Simulate Zone は、Argo Smart Routing と同じ経路と、Smart Shield Advanced でエッジ IP を制限するときの Dedicated CDN Egress IPs も、ヘルスプローブに使わせます。
ヘルスプローブは次の種類で設定できます。
- HTTP
- HTTPS
- TCP
- UDP ICMP
- ICMP Ping
- SMTP
- LDAP
ヘルスモニターを定義したらエンドポイントへ割り当て、定義した間隔でプローブが送られます。エンドポイントプール内のヘルスモニター設定で、あと 2 つ注目すべき項目があります。1 つ目は Health Threshold です。プールを健全または劣化とみなすために、プール内の何台が健全である必要があるかを決めます。
- 健全状態のエンドポイントプール
- 健全なエンドポイントだけを含む
- 劣化状態のエンドポイントプール
- クリティカルなエンドポイントが 1 つ以上あるが、Health Threshold 以上は保っている
- クリティカル状態のエンドポイントプール
- 健全なエンドポイントが Health Threshold を下回る
- トラフィックを扱えず、すべてのステアリング判断から外される
2 つ目は、Cloudflare グローバルネットワーク内のどの地域からヘルスプローブを出すかを定義することです。選べる項目は次のとおりです。
- All Regions（デフォルト）
- All Data Centers（Enterprise 限定）
- Western North America
- Eastern North America
- Western Europe
- Eastern Europe
- Northern South America
- Southern South America
- Oceania
- Middle East
- Northern Africa
- Southern Africa
- Southern Asia
- Southeast Asia
- Northeast Asia
「All Regions」と「All Data Centers」以外では、ヘルスプローブは選んだ地域内のデータセンターからのみ出ます。地域に閉じたサービスでは、地球の裏側のデータセンターからエンドポイントへ届くかどうかは重要でないことがあります。その場合は、特定の地域または地域の組み合わせに限定するのが妥当です。「All Regions」または「All Data Centers」は、エンドポイント群への到達がアプリケーションの機能に重要な、グローバルなサービス向けです。
エンドポイントは、ロードバランサーがすべてのポリシーを適用したあと、接続とリクエストを扱う実際のサーバーです。物理サーバー、仮想マシン、サーバーレスアプリケーションでも構いません。ユーザーまたはクライアントからのリクエストや接続を扱えれば、エンドポイントです。Cloudflare への定義と接続方法はいくつかあります。次の節で説明します。
Cloudflare のエンドポイントは、IP アドレスまたはホスト名で定義できます。IP アドレスがもっとも単純です。ホスト名にはいくつかの選択肢があります。ホスト名を Cloudflare DNS に置き、プロキシするか、DNS のみ（非プロキシ）にするかを選べます。Cloudflare が権威 DNS ではないドメインのホスト名なら、Cloudflare はそのホスト名を IP へ解決するために外部 DNS サーバーに依存します。Cloudflare Tunnel も使え、こちらも 2 つの選択肢があります。この節で説明します。
前述の「HTTP(S) Load Balancing」の節のとおり、負荷分散はリクエストをエンドポイントへ送る直前の最後の処理です。エンドポイントが Cloudflare エッジでプロキシされていても、ロードバランサーのあと、リクエストはレイヤー 7 スタックを再度通らずエンドポイントへ直接転送されます。保護やキャッシュがないわけではありません。ロードバランサー自体がプロキシされていれば、それらの保護はエンドポイントではなくロードバランサーに付きます。エンドポイントへの直接通信は、引き続きプロキシして Cloudflare のレイヤー 7 スタックで扱えます。ただし、エンドポイントとの通信では、処理はエンドポイントではなくロードバランサーの前に置かれます。図 19 は、Cloudflare のレイヤー 7 スタックがエンドポイントとの関係でどこに置かれるかの違いです。
エンドポイントプールに定義するエンドポイントの種類について、ロードバランサーから見た差はほとんどありません。トラフィックとエンドポイントのステアリングポリシー、およびロードバランサールールを適用したあと、Cloudflare Load Balancing サービスは L7 スタックに、着信リクエストまたは接続の転送先を指示します。リクエストはエンドポイントへ直接送られます。エンドポイントへの接続の種類によって、経路は変わることがあります。Argo Smart Routing や、別の Cloudflare データセンターで終端するトンネル接続のエンドポイントは、Cloudflare エッジからインターネット経由でエンドポイントへ直接出すのではなく、別経路になります。ただし、どの経路でも負荷分散はスタックの最後の処理であり、トラフィックに追加の扱いはありません。エンドポイントへの接続は Cloudflare からエンドポイントへの経路を変えられますが、エンドポイントが選ばれたあとの処理内容は変わりません。
Cloudflare Tunnel はアウトバウンド接続です。ファイアウォール設定を単純にし、複雑さを減らし、セキュリティを高め、資産を Cloudflare ネットワークへつなぎやすくします。トンネルを作る実行ファイルは cloudflared で、この文書と以降の図でも言及します。
Cloudflare Tunnel（cloudflared）は、エンドポイント自身、またはエンドポイントへ IP 接続できる任意のサーバーにインストールできます。Cloudflare への接続はインストール先から始まるため、必要なのは Cloudflare へのアウトバウンドアクセスだけです。1 つの Cloudflare Tunnel は、1 つまたは複数のエンドポイントへ、2 通りの方法でトラフィックを運べます。1 つはエンドポイントを公開到達可能にし、もう 1 つは完全に非公開のままにします。
Cloudflare Tunnel は、エンドポイント自身、またはつなぎたいエンドポイントへレイヤー 3（IP）接続できる任意のサーバーにインストールできます。cloudflared を分ける理由はさまざまです。エンドポイントの隔離と性能確保、ネットワーク接続とエンドポイントを別チームが管理する、サーバーの役割を分けて構成を単純にする、などです。
1 つの cloudflared インスタンスは、2 つの異なる Cloudflare データセンターに 2 本ずつ、合計 4 本のトンネルを作ります。可用性が高く、個別接続の障害リスクを下げます。1 本の接続、サーバー、またはデータセンターがオフラインでも、エンドポイントは利用可能なままです。Cloudflare Tunnel では、可用性とフェイルオーバーのために追加の cloudflared インスタンスも置けます。これらの一意のインスタンスを replica と呼びます。各 replica は 4 本の新しい接続を張り、エンドポイントへの追加の入口になります。各 replica は同じトンネルを指します。cloudflared を動かすホストが 1 台落ちても、ネットワークは維持されます。設計上、replica はトラフィックステアリング（random、hash、round-robin）を提供しません。
公開エンドポイント方式では、エンドポイント上の特定のサービスまたはポートを指すトンネルを定義できます。トンネルはエンドポイント上、またはエンドポイントへ IP 接続できる任意のサーバーで終端できます。この公開ホスト名方式では、トンネル経由でアクセスする各サービスをトンネル設定で定義する必要があります。設定すると、接続先の IP とポートまたはサービスに対して、d74b3a46-f3a3-4596-9049-da7e72c876f5 のような一意のトンネル ID が作られます。このトンネル ID から、Cloudflare 所有ドメイン cfargotunnel.com 上の一意の公開ホスト名が作られ、そのサービスを直接指す DNS A レコード（d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com）になります。このホスト名は公開ですが、アクセスまたは利用できるのは、その Cloudflare Tunnel 設定を所有するアカウント経由のトラフィックだけです。ほかのアカウントは、この DNS アドレスへ直接アクセスまたは送信できません。所有アカウントの外で作った、cfargotunnel.com ホスト名を指す DNS CNAME では、その Cloudflare Tunnel へトラフィックを送れません。
ダッシュボードで設定すると、Cloudflare は DNS ゾーンに、cfargotunnel.com ホスト名を指す CNAME レコードを自動作成します。たとえば、myTunnelService.example.com の CNAME が d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.com の A レコードを指します。主な利点は、CNAME の方が目的が分かりやすく、顧客の DNS ゾーンに属することです。
もう一つの選択肢は、cloudflared を動かすホスト上でトンネルとサービスを作ることです。これを ローカル管理トンネル と呼びます。ローカル管理トンネルでは CNAME は自動作成されないため、トンネルとサービスを定義したあと、組織が手動で設定します。
ロードバランサーの観点では、これらのトンネルをエンドポイントとしてどう使うかを理解することが重要です。エンドポイントは cfargotunnel.com ホスト名でのみ定義できます。cfargotunnel.com アドレスを指す公開 CNAME は正しく動かず、サポート対象外です。ポート 80 または 443 以外で動くエンドポイントサービスでは、特に重要です。Cloudflare ロードバランサーは、エンドポイント上のサービスへアクセスするデフォルトポートが 80 と 443 です。ほかのポートで動くサービスがある場合は、catch-all ルール 付きの Cloudflare Tunnel を設定してそのポートへ到達する必要があります。この設定により、Cloudflare ロードバランサーはポート 443 経由でサービスへ届き、Cloudflare Tunnel がその接続をエンドポイントの目的のポートへプロキシします。
2 つ目の方式はプライベートサブネット向けです。プライベート IP アドレスとサブネットマスクを定義し、Cloudflare グローバルネットワーク内にプライベートな仮想ネットワークを作れます。プライベートサブネット方式ではポートを定義できません。サブネットとマスクを定義すると、そのサブネット全体へそのトンネル経由で到達できます。ただし、Zero Trust ポリシーで許可された組織内ユーザーだけです。
このサブネットは Cloudflare 内の仮想ネットワークに追加され、誰がどうアクセスできるかを顧客が制御します。任意のサブネットやルーティングを定義でき、32 ビットマスク（単一 IP、例: 10.0.0.1/32）も使えます。許可するサブネットは、cloudflared プロセスを動かすホスト上に存在する必要はありません。必要なのは、cloudflared を動かすホストと、Cloudflare Tunnel 経由で到達させるサブネットのあいだのレイヤー 3 または IP 接続だけです。
エンドポイントプールには、いくつかの設定項目があります。この節では、各項目と、Cloudflare ロードバランサーの動作への影響を説明します。
名前と説明のほか、最初の設定はエンドポイントステアリング方式です。エンドポイントステアリングは、最終的にリクエストまたは接続を受けるエンドポイントプールまたはエンドポイントを選びます（各方式の詳細は ステアリング方式 を参照してください）。
個々のエンドポイントはエンドポイントプール内で定義します。1 プールに 1 つ以上のエンドポイントを置けます。
- エンドポイント名 は、主に参照、レポート、分析用です。ロードバランサーやプールの機能には影響しません。
- エンドポイントアドレス は、ロードバランサーがリクエストまたは接続の処理に使える資源を定義します。
- プール内のエンドポイントは、ポート 80 または 443 で到達できる必要があります。エンドポイントが 80 または 443 を待受していない場合は、プロキシサービスまたはネットワークのポート転送装置をエンドポイントの前に置き、ポート 80 または 443 を実際の待受ポートへマップする必要があります。
- 80 または 443 へマップするもう一つの方法は、Cloudflare Tunnel でエンドポイントサービスへつなぎ、その過程で作られたホスト名をエンドポイントアドレスにすることです。意図したエンドポイントポートは自動でポート 443 へマップされます。
エンドポイントアドレス は、次のいずれかで定義できます。
- 公開ルーティング可能な IP アドレス
- Cloudflare でプロキシされた、公開到達可能なホスト名
- 公開到達可能な非 Cloudflare ホスト名
- 仮想ネットワークを選んだ、公開ルーティングされないプライベート IP アドレス
公開 IP と任意の種類のホスト名では、追加設定は不要です。その場合、仮想ネットワークはデフォルト値の「none」にします。「none」は、これらの資源がパブリックインターネット上にあり、Cloudflare のグローバルエッジネットワーク経由でルーティングされることを示します。
仮想ネットワーク オプションは、プライベート IP 資源専用です。この設定は、Cloudflare Tunnel 設定 の背後にある IP サブネットへマップします。エンドポイントの IP へ経路がある仮想ネットワークを選びます。Cloudflare ダッシュボードでは、Zero Trust ページの Networks - Routes からこの設定へ進めます。
エンドポイントウェイト は、random、hash、least outstanding request の各ステアリング方式でのみ使います。エンドポイント定義の一部として常に定義する必要があります。（エンドポイント選択でのウェイトの使い方は ウェイト付きステアリング を参照してください。）
エンドポイントプールでは、リクエストをエンドポイントへ送る前に Host ヘッダーを変更できます。この設定は HTTP(S) レイヤー 7 ロードバランサーにのみ適用されます（プライベート IP や Spectrum を含むレイヤー 4 ロードバランサーでは無視されます）。
リクエストが HTTP(S) のレイヤー 7 ロードバランサーでは、Host ヘッダーが、どの Web サイトを要求しているかをエンドポイントに伝えます。1 つのエンドポイントが複数の Web ドメインをホストすることがあるためです。特定の Web ドメイン向けに設定されたエンドポイントは、Host ヘッダーで要求された資源を自分がホストしていないと判断すると（Host ヘッダーの不一致）、応答しないか失敗応答を返すことがあります。
例:
- ユーザーが
www.example.comへアクセスしようとするとします。ロードバランサーは、すべてのリクエストを受けるホスト名としてwww.example.comを設定します。 - エンドポイントは DNS 上で同じ公開ホスト名を持てないため、ホスト名は
endpoint1.example.comです。 - ユーザーが
www.example.comを要求すると、Host ヘッダーもwww.example.comになります。エンドポイントはwww.example.comの Host ヘッダーに応答するよう設定する必要があります。 - ただし、一部のクラウドや SaaS アプリケーションなどでは、そのように設定できません。未知の Host ヘッダーのリクエストを受け、適切に応答できないことがあります。
- この例では、エンドポイント設定で Host ヘッダーをエンドポイントアドレス
endpoint1.example.comにすると、www.example.comの Host ヘッダーがendpoint1.example.comに置き換わり、エンドポイントが適切に応答できます。
図 21 は、Host ヘッダー不一致の問題です。
また、エンドポイントプールでは、Proximity トラフィックステアリング用の GPS 座標も定義できます。Proximity ステアリングを使わない場合、座標は不要です（Proximity ステアリング を参照してください）。
ロードシェディング は、プール内のエンドポイントが 不健全になりつつある ときに、管理者がリアルタイムで使う応答です。エンドポイントプールでも設定します。
ロードシェディングは、管理者がエンドポイントプールを不健全から守るとき以外は有効にしません。たとえば、まだリクエストには応答しているが、CPU またはメモリ使用が増えている、応答時間が伸びている、ときどき応答しない、といったときに有効にします。
エンドポイントプールの健全性が劣化し始めたとき、ロードシェディングは既存負荷の一部を別のプールへ向けられます。
プールの健全性によっては、新しいリクエストと接続だけをそのプールから外す（シェッドする）だけで足りることがあります。このポリシーは、session affinity の対象外のトラフィックに適用されます。まだプールやエンドポイントが選ばれていない新規接続なので、エンドユーザー体験への影響は出にくいです。
負荷でプールがクリティカル障害に近づく場合、次の選択肢は、追加の session affinity トラフィックもシェッドすることです。session affinity でプールに結びついたリクエストと接続も、振り直しが始まります。ただし、ユーザーのエンドポイントが変わる可能性があるため、体験に影響することがあります。影響の大きさは、負荷分散しているアプリケーションと、エンドポイント間でどれだけ接続コンテキストを共有しているかで決まります。
ヘルスモニターは、Health Threshold とヘルスチェック地域の選択とともに、エンドポイントプールでエンドポイントへ付けます。各オプションの詳細は ヘルスモニター の節を参照してください。
Cloudflare の負荷分散は、GTM と Private Network Load Balancing を 1 つのロードバランサー設定にまとめます。GTM または Private Network Load Balancing に寄る機能や用語はありますが、Cloudflare の顧客向けには、管理しやすい 1 つのインスタンスに統合されています。
用途に応じて、組織は異なる種類の Cloudflare ロードバランサーを使えます。次の節では、デプロイモデルの主な違いと、どの種類をいつ実装すべきかを説明します。
図 22 は、Cloudflare がサポートするロードバランサーとエンドポイントの組み合わせです。
Cloudflare は 3 つの負荷分散デプロイモデルを提供します。それぞれ、ユースケース、機能、プライバシー要件が異なります。
後述の DNS-only 以外は、すべてトラフィックをロードバランサー経由でアンカーします。リクエストまたは接続を作るユーザーやクライアントは、処理に使われるエンドポイントを知りません。ヘッダーでエンドポイント情報を出すことはできますが、これらのアンカー型モデルのデフォルト動作ではありません。
以下で、4 つの主なデプロイモデル（とその違い）を詳しく見ます。
まず、もっとも一般的なモデルが HTTP(S) ベースのレイヤー 7 プロキシ付きロードバランサー です。Cloudflare のエッジ上にあり、公開到達できます。このモデルは、クライアントとエンドポイントのあいだでデータを双方向に渡す開いた接続である WebSockets などもサポートします。
同じレイヤー 7 セキュリティスタックが WAF、DDoS 防御、Bot Management、Zero Trust なども提供するため、これらの公開ロードバランサーへのアクセスは、必要に応じて認証・認可済みユーザーに制限できます。（詳細は ロードバランサーの保護 を参照してください。）
このレイヤー 7 スタックでは、負荷分散が組織の公開 Web 資産の性能、信頼性、到達性をさらに高められます。これらのロードバランサーのエンドポイントは、パブリッククラウド、プライベートクラウド、オンプレミス、または同一ロードバランサー内での組み合わせに置けます。（Cloudflare のエッジネットワークへのつなぎ方は エンドポイントを Cloudflare へつなぐ を参照してください。）
図 23 のとおり、レイヤー 7 スタックの負荷分散部品は、リクエストがエンドポイントへ向かう最後の処理です。性能向上とエンドポイント負荷の削減に大きく効きます。
たとえば、キャッシュはリクエストがエンドポイントへ届く前に返せ、ロードバランサーを動かさずに済みます。WAF、DDoS 防御、Bot Management は攻撃トラフィックを排除し、正規トラフィック用の容量を残せます。
リクエストがロードバランサー処理に達すると、選ばれたエンドポイントへ常に直接送られます。エンドポイントが Cloudflare でプロキシされていても、リクエストはエンドポイントへ直接送られ、それ以上の処理は受けません。
ロードバランサーがエンドポイントを選んだあとに独自の扱いをする場合は、ロードバランサーのカスタムルールを適用します。（詳細は後述の ロードバランサー の節です。）
レイヤー 7 HTTP(S) ロードバランサーに関する重要な注意:
- レイヤー 7 HTTP(S) ロードバランサーは、公開および非公開エンドポイントをサポートします
- レイヤー 7 HTTP(S) ロードバランサーが扱うのは HTTP(S) と WebSocket トラフィックだけです
- レイヤー 7 HTTP(S) ロードバランサーには Zero Trust ポリシーを適用できます
Cloudflare の DNS-only ロードバランサーは、非プロキシのロードバランサーです。Cloudflare エッジを通るのは、実際のトラフィックではなく、資源への最初の DNS リクエストだけです。そのため、図 7 のように DNS が Cloudflare IP に解決してレイヤー 7 スタックを通るのではなく、Cloudflare は DNS-only ロードバランサー向けの DNS リクエストを受け、適切な負荷分散ポリシーを適用し、クライアントが直接接続するための IP を返します。
クライアントとエンドポイントのあいだのトラフィックは 2 者間を直接流れ、Cloudflare のレイヤー 7 スタックを通らないため、DNS-only ロードバランサーは任意の IP トラフィックをサポートできます。
Cloudflare はこれらの接続をプロキシしませんが、ヘルスモニターサービスはプール内のすべてのエンドポイントの健全性を監視し続けます。エンドポイントの健全性または可用性に基づき、Cloudflare の DNS-only ロードバランサーは、健全なエンドポイントへトラフィックが振られるよう、該当エンドポイントを DNS 応答へ追加または削除します。
DNS-only ロードバランサーがトラフィックステアリングでエンドポイントプールを選んだあと、DNS 応答には 1 つまたは複数の IP が返されることがあります。
DNS 応答に 1 つ返すか複数返すかは、選んだプール内エンドポイントに付けたウェイトで決まります。
- すべてのエンドポイントのウェイトが等しければ、すべてのエンドポイントの IP が DNS 応答に含まれます。
- プール内で 1 つでも一意のウェイトを持つエンドポイントがあれば、プールのエンドポイントステアリング方式に関係なく、DNS 応答は 1 つの IP だけです。
アプリケーションに全エンドポイントを知らせてローカルフェイルオーバーさせるか、Cloudflare に 1 つの IP を返させるかを選べます。
図 27 は、エンドポイントプール内のウェイトが、DNS-only ロードバランサーの応答にどう影響するかを示します。
DNS-only ロードバランサーには、プロキシ付きと比べていくつかの制限があります。
- エンドポイントの IP がクライアントへ直接返されるため、ロードバランサーは IP を隠しません。
- 前のモデルで述べた組み込みのレイヤー 7 スタックサービスはありません。つまり、キャッシュ、WAF、DDoS 防御、Zero Trust サポートはありません。
- session affinity は
ip_cookieに限られます。エンドポイントを決定的に選び、以降のすべてのリクエストでそのエンドポイントをクライアント IP へマップします。 - 接続はロードバランサー経由でプロキシされないため、一部のステアリング方式も動きません。たとえば LORS は、Cloudflare がエンドポイントへの接続を把握しないため動きません。これらの方式は、ランダムなウェイト付きステアリングに戻ります。
追加のステアリング方式は ステアリング の節を参照してください。
DNS-only ロードバランサーでは、クライアントとリゾルバーの DNS キャッシュも考慮します。キャッシュ寿命は、リクエストに答える DNS サーバーが決めます。Time-to-Live（TTL） ↗ 値は、送信先が変わっていないかを確認するために新しい DNS リクエストを送るまでの、応答の有効期間を伝えます。TTL は秒です。たとえば TTL 3600 は 1 時間です。ただし、標準的な DNS TTL は通常 12 時間または 24 時間（それぞれ 43200 と 86400）です。
DNS-only ロードバランサーの TTL は 30（秒）です。エンドポイントの健全性が変わる、追加される、削除されるときに、利用可能なエンドポイントの最新一覧を返すよう、より頻繁に問い合わせます。
DNS-only ロードバランサーに関する重要な注意:
- DNS-only ロードバランサーがサポートするのは公開エンドポイントだけです
- DNS-only ロードバランサーはトラフィックをプロキシしないため、エンドポイントへの接続には関与しません
- DNS-only ロードバランサーは、DNS リクエストに対して IP または IP の集合を返すだけです
Cloudflare は、Spectrum 製品による別の入口も提供します。
レイヤー 7 スタックがサポートするのは HTTP(S) と WebSockets だけでした。Spectrum は任意の TCP または UDP ベースのプロトコルをサポートします。Spectrum を入口にする Cloudflare ロードバランサーは、TCP と UDP があるレイヤー 4 で動作します。SSH、FTP、NTP、SMTP など、TCP または UDP を使うサービスは、Spectrum と Cloudflare ロードバランサーを使えます。
対象のサービスとプロトコルが広いため、扱いはレイヤー 7 HTTP(S) スタックより汎用的です。たとえば Cloudflare Spectrum は、レイヤー 4 ロードバランサーで TLS/SSL オフロード、DDoS 防御、IP アクセスリスト、Argo Smart Routing、セッション持続をサポートします。
Cloudflare のレイヤー 4 Spectrum ロードバランサーは公開到達できます。これらの資源へのアクセスは、Spectrum 設定の IP Access Rules で管理できます。WAF 設定の一部として定義でき、「allow」または「block」アクションと、特定の IP、サブネット、国、または Border Gateway Protocol（BGP） ↗ の自律システム番号（ASN）に限られます。
公開であることに加え、Spectrum ロードバランサーは常にプロキシされます。ロードバランサーの入口が Spectrum の場合、前述（図 24 と 25）のプロキシ設定は無視されます。Spectrum ベースのロードバランサー宛てのトラフィックは、常に Cloudflare エッジを通ります。
Spectrum ロードバランサーに関する重要な注意:
- Spectrum ロードバランサーは、公開および非公開エンドポイントをサポートします
- Spectrum ロードバランサーは、最初はレイヤー 7 HTTP(S) ロードバランサーとして作成します。そのあと Load Balancer エンドポイント種別の Spectrum アプリケーションを作り、作成済みのロードバランサーを選びます。
- ロードバランサー設定のプロキシ設定に関係なく、Spectrum ロードバランサーは常にプロキシされます
- Spectrum 経由でインターネットからエンドポイントへ入るポートは変更できません。たとえばポート 22 で Spectrum に入ったトラフィックは、エンドポイントのポート 22 へ振られます
- Spectrum ロードバランサーの session affinity は、hash エンドポイントステアリング方式のみです
- Spectrum ロードバランサーはカスタムルールをサポートしません
| ロードバランサーモデル | 公開 | プロキシ | OSI 層 | トラフィック種別 |
|---|---|---|---|---|
| レイヤー 7 HTTP(S) | X | X | 7 | HTTP(S) |
| DNS-Only | X | 7（DNS） | IP ベース | |
| Spectrum | X | X | 4 | TCP/UDP |
ホスト名設定は、ロードバランサーの公開到達可能なホスト名です。ホスト名は、ロードバランサーを作るゾーン内で作成する必要があります。
プロキシ設定は、Cloudflare がロードバランサーのトラフィックをプロキシするか、クライアントが直接接続するためのエンドポイントを DNS で返すだけかを決めます。詳細は デプロイモデル の節です。
セッションアフィニティは、session persistence または sticky sessions とも呼ばれます。最初のリクエストまたは接続のあと、以降のすべてのリクエストで同じエンドポイントへクライアントをつなぎ続けます。セッションデータをエンドポイント間で共有しないアプリケーションでは、重要な機能です。たとえば、クライアントセッションの途中で新しいエンドポイントが選ばれ、セッション情報（ユーザーの買い物かごの中身など）が失われると、そのアプリケーションの体験は悪くなります。
Cloudflare は、セッションアフィニティを有効にする方法を 3 つ提供します。
- Cloudflare cookie のみ（cookie）: プロキシ付きロードバランサーへの最初のリクエストで cookie が生成され、リクエストの転送先エンドポイントの情報が符号化されます。以降のリクエスト（同じクライアントから同じロードバランサーへ）は、a) cookie の有効期間中、かつ b) エンドポイントが健全なあいだ、その cookie が符号化したエンドポイントへ送られます。cookie が期限切れか、エンドポイントが不健全なら、新しいエンドポイントが計算され、使われます。
- Cloudflare cookie とクライアント IP のフォールバック（ip_cookie）: 上記の cookie 方式に似ていますが、cookie はクライアント IP に基づいて生成されます。同じ IP からのリクエストは、a) cookie の有効期間中、かつ b) エンドポイントが健全なあいだ、常に同じエンドポイントへ振られます。cookie が期限切れか、エンドポイントが不健全なら、新しいエンドポイントが計算され、使われます。
- HTTP ヘッダー（header）: プロキシ付きロードバランサーへの最初のリクエストで、設定した HTTP ヘッダーに基づくセッションキーが生成されます。同じヘッダーの以降のリクエストは、a) セッションの有効期間中、または b) エンドポイントが健全なあいだ、同じエンドポイントへ送られます。セッションアフィニティの TTL 秒のあいだアイドルだった、またはエンドポイントが不健全なら、新しいエンドポイントが計算され、使われます。
これら 3 つのセッションアフィニティオプションは、レイヤー 7 HTTP(S) ロードバランサーにのみ適用されます。セッションアフィニティには TTL が必要で、以降のリクエストを特定のエンドポイントへルーティングする期間を決めます。デフォルト TTL は 82,800 秒（23 時間）で、1,800 秒（30 分）から 604,800 秒（7 日）の範囲で設定できます。
cookie ベースのセッションアフィニティでは、有効期限タイマーはリセットされません。セッションがアイドルでもアクティブでも、開始時点からカウントダウンします。HTTP ヘッダーベースのセッションアフィニティは、セッションに活動があるたびに有効期限タイマーをリセットします。
エンドポイントドレイニングは、セッションアフィニティのサブ機能です。あるエンドポイントでセッションを穏やかに期限切れにしつつ、同じエンドポイントでの新規セッション作成は許しません。管理者がユーザーセッションを突然切らずに、エンドポイントからアクティブセッションを外せるため、保守に役立ちます。
エンドポイントドレイン TTL は、強制終了するまでに、エンドポイントがアクティブセッションを維持できる時間です。ドレイン TTL を設定したあと、エンドポイントプール内の 1 つ以上のエンドポイントを無効にすると、ドレイニングが始まります。次の画像のとおり、管理者はロードバランサー UI で、ドレイニング操作の残り時間を監視できます。
エンドポイントドレイニングが意味を持つのは、セッションアフィニティがある場合だけです。セッションアフィニティがなければ、以降のリクエストや接続が同じエンドポイントへ振られる保証はありません。そのため、エンドポイントを無効にしてもユーザー体験への影響は出にくいです。
ゼロダウンタイムフェイルオーバーは、一時的なネットワーク問題のあいだ、エンドポイントプール内のエンドポイントへトラフィックを自動で送ります。
ゼロダウンタイムフェイルオーバーは、プール内にほかの健全なエンドポイントがあり、521、522、523、525、または 526 のエラーコード が発生している場合にのみ、1 回だけ再試行します。これ以外のエラーコードでは、ゼロダウンタイムフェイルオーバーは発動しません。
これらの応答コードはエンドポイントから返るものではなく、上流の Cloudflare サービスが組織のエンドポイントへ出したリクエストからのものです。ゼロダウンタイムフェイルオーバーには 3 つの動作モードがあります。
- None（オフ）: フェイルオーバーは行われず、ユーザーはエラーメッセージや悪い体験を受けることがあります。
- Temporary: エンドポイントが再び利用可能になるまで、ほかのエンドポイントへトラフィックを送ります。
- Sticky: セッションアフィニティ cookie が更新され、以降のリクエストは必要に応じて新しいエンドポイントへ送られます。セッションアフィニティが HTTP ヘッダーモードのときはサポートされません。
Adaptive routing - failover across pools は、ゼロダウンタイムフェイルオーバーの機能を広げます。同じプール内のエンドポイントだけでなく、別のエンドポイントプールのエンドポイントへもフェイルオーバーできます。
エンドポイントプールは優先度順に設定し、必要に応じて並べ替えられます。この優先度が使われるのは Off - Failover トラフィックステアリング のときだけです。それ以外では、ステアリング方式 の節で述べた基準でプールが選ばれます。
ロードバランサーに割り当てたエンドポイントプールは、そのロードバランサー経由のリクエストまたは接続を扱い得るエンドポイント全体です。エンドポイントプールは通常、同じ能力を持ち、同じデータセンターまたは地理的な地域にあります。プール内のすべてのエンドポイントは、そのプールへ向けられた任意のリクエストを扱える必要があります。エンドポイントプールの詳細は エンドポイントプール の節を参照してください。
フォールバックプールは最後の手段のプールです。すべてのエンドポイントプールが利用できない、または不健全なとき、すべてのリクエストと接続にフォールバックプールが使われます。ロードバランサー内のステアリングではヘルスモニターのデータは常に考慮されますが、フォールバックプールはこのデータに依存せず、対象にもなりません。
ヘルスモニターは、通常はエンドポイントプールの一部として設定します。ロードバランサー設定の一部として、追加、変更、削除できます。詳細は ヘルスモニター の節を参照してください。
トラフィックステアリングは、エンドポイントプール間の振り分け方式です。どの方式を選ぶかは ステアリングの種類と方式 の節を参照してください。
カスタムルール を使うと、ロードバランサーが判断を終える前に、リクエストまたは接続へアクションを実行できます。カスタムルールは、リクエストまたは接続内の特定の フィールド に一致する式で設定します。トラフィックに一致する式を作ったあと、一致したときに実行する アクション を割り当てます。
カスタムルールは、リクエストまたは接続をエンドポイントへ送る前に、ステアリングと出力をカスタマイズする強力な手段です。たとえば HTTP メソッド（GET、PUT、POST など）に一致させ、クライアントからの情報受信専用のエンドポイントプールへ POST を送れます。
あるいは、特定の URL パスへのリクエストでセッションアフィニティ TTL をリセットし、クライアントがトランザクションを完了するのに十分な時間を確保できます。
一致させられるフィールドと実行できるアクションの組み合わせをすべて文書化することはできません。ただし、現在利用できるフィールドとアクションは次の資料にあります。
ロードバランサーのデフォルト動作が上記の文書で足りない場合、カスタムルールで独自の要件を満たせる可能性が高いです。
Cloudflare ロードバランサーのすべてのデプロイモデルには、標準の保護があります。次の節では、デフォルトのセキュリティと、ロードバランサーの前に追加できる任意の保護を簡単に示します。
- プロキシ付き HTTP レイヤー 7 ロードバランサー（公開）
- 攻撃から守る DDoS 防御
- 既知の脆弱性と攻撃を遮断する、Cloudflare managed ruleset と OWASP ruleset 付きの WAF
- DNS-only ロードバランサー（公開）
- DNS-only ロードバランサーを常に利用可能にする DNS DDoS 防御 ↗
- Spectrum レイヤー 4 ロードバランサー（公開）
- レイヤー 4 攻撃から守る DDoS 防御
Cloudflare は、負荷分散と組み合わせて、Web サイト、API、HTTP(S) ベースのサービスなどを守る追加のセキュリティ層を提供します。
- プロキシ付き HTTP レイヤー 7 ロードバランサー（公開）
- どのボットが資源へアクセスできるかを制御する Bot management
- Web アプリケーション向けのカスタムルールを作る WAF
- Web アプリケーション上のスクリプト利用を監視する クライアントサイドセキュリティ
- API を保護する API Shield
- DNS-only ロードバランサー（公開）
- DNS レコードの真正性を確保する DNSSEC
- Spectrum レイヤー 4 ロードバランサー（公開）
- 公開レイヤー 4 ロードバランサーへのアクセスを制御する IP Access Rules
Cloudflare のグローバル Anycast ネットワークは、負荷分散に強力な基盤です。Cloudflare のロードバランサー設定は、世界の over 330 cities から到達でき、容量と帯域は実質的に無制限です。
これらのロードバランサーは、インターネット接続人口の約 95% から約 50ms 以内で動作します。エンドポイントも含め、Cloudflare ロードバランサーは GTM と Private Network Load Balancing の両方を実行できます。Cloudflare は、これら 2 つの異なる負荷分散の概念を 1 つのロードバランサーにまとめます。地理的に関連するデータセンターへトラフィックを振り、リクエストを扱う適切なエンドポイントを選べます。
Cloudflare Tunnel を使うと、エンドポイントをプライベートネットワーク内に置いたまま、Cloudflare ロードバランサーから利用できます。Cloudflare は、HTTP(S) と WebSockets をサポートする公開レイヤー 7 ロードバランサーと、任意の TCP または UDP トラフィックを振れる公開レイヤー 4 ロードバランサーを提供します。場所、用途、既存構成に関係なく、すべての組織とユーザーへ負荷分散を提供できます。