ロードバランシング
Cloudflare ロードバランシングは、組織がグローバルなユーザーベース向けにアプリケーションをホストし、メンテナンス、フェイルオーバー、レジリエンシー、スケーラビリティの懸念を大幅に軽減できるSaaS提供です。Cloudflare ロードバランシングを使用することで、組織は以下の課題に対処できます。
- 特に予期しない急増やスパイクの際に、大量の受信トラフィックを効率的に処理すること。
- アプリケーションやサービスがユーザーにアクセス可能であることを保証すること。
- 高トラフィック期間中でも、すべてのユーザーに対して迅速な応答時間と最適なパフォーマンスを維持すること。
- 変化するトラフィック需要に適応し、インフラストラクチャが成長に対応できることを確保すること。
- アプリケーションやサービスが分散型サービス拒否（DDoS）攻撃に耐えるのを助けること。
Cloudflare ロードバランシングは、すべてのネットワーク（企業およびインターネット）、クラウド環境、アプリケーション、ユーザー間の安全な任意の接続を可能にするプログラム可能なクラウドネイティブサービスの統一されたインテリジェントプラットフォームであるCloudflareの接続クラウド上に構築されています。これは、120か国以上の310以上の都市にデータセンターを持ち、13,000以上の他のネットワークと相互接続されている、世界最大のネットワークの1つです。また、多くの他の大手テクノロジー企業よりもコアインターネットエクスチェンジでの存在感が大きいです。
その結果、Cloudflareは、世界のインターネット接続人口の約95%に対して約50ms以内で運営されています。そして、すべてのCloudflareサービスはすべてのネットワークロケーションで実行されるように設計されているため、すべてのリクエストはその発信元に近い場所でルーティング、検査、フィルタリングされ、強力なパフォーマンスと一貫したユーザー体験を実現します。
この文書は、グローバルおよびローカルトラフィック管理のロードバランシングソリューションを展開しようとする組織向けのリファレンスアーキテクチャを説明します。
このリファレンスアーキテクチャは、組織の既存のインフラストラクチャに対して何らかの責任を持つIT、ウェブホスティング、ネットワークの専門家を対象としています。ルーティング、DNS、IPアドレッシングなどのネットワーキングの概念に関する経験があると便利であり、ロードバランサーの機能に関する基本的な理解も必要です。
Cloudflareとそのロードバランシングソリューションの基礎的な理解を深めるために、以下のリソースをお勧めします：
- ソリューションブリーフ: Cloudflare LTM ロードバランシング ↗（5分で読めます）
- ソリューションブリーフ: Cloudflare GTM ロードバランシング ↗（5分で読めます）
- ブログ: プライベートIPとCloudflareトンネルを使用したロードバランシングの向上: 効率的なトラフィック分配への安全な道 ↗（13分で読めます）
このリファレンスアーキテクチャを読むことで、以下のことを学べます：
- Cloudflare ロードバランシングがローカルトラフィック管理とグローバルトラフィック管理のユースケースの両方にどのように対処できるか。
- CloudflareのグローバルネットワークがCloudflare ロードバランシングの機能をどのように強化するか。
- Cloudflare ロードバランサーの機能と、それがさまざまなユースケースにどのように適用されるか。
- Cloudflare ロードバランサーの構造とそのさまざまな構成。
この文書において、「エンドポイント」という用語は、受信するパブリックまたはプライベートトラフィックを傍受し、処理する任意のサービスまたはハードウェアを指します。ロードバランシングはウェブサーバーだけでなく、さまざまなタイプのオリジン、ホスト名、プライベートまたはパブリックIPアドレス、仮想IPアドレス（VIP）、サーバー、その他の専用ハードウェアボックスに使用できるため、エンドポイントという用語が選ばれました。これはオンプレミスでも、パブリックまたはプライベートクラウドにホストされている場合もあり、サードパーティのロードバランサーである可能性もあります。
ステアリングは、ロードバランサーの主な機能であり、ポリシーのセットに基づいてリクエストを処理、送信、転送するプロセスです。これらのポリシーは一般的に、リクエストURL、URLパス、HTTPヘッダー、設定された重み、優先度、エンドポイントのレイテンシー、応答性、容量、負荷など、多くの要因を考慮に入れます。
レイヤー7 ↗は、OSIモデル ↗のアプリケーション層として知られ、SSH、FTP、NTP、SMTP、HTTP(S)などのプロトコルが存在します。この文書がレイヤー7またはレイヤー7ロードバランサーに言及する場合、それはHTTP(S)ベースのサービスを意味します。Cloudflareのレイヤー7スタックは、CloudflareがDDoS保護、ボット管理、WAF、CDN、ロードバランシングなどのサービスを顧客のウェブサイトに適用し、パフォーマンス、可用性、セキュリティを向上させることを可能にします。
OSIモデル ↗のレイヤー4は、トランスポート層とも呼ばれ、2つのデバイス間のエンドツーエンドの通信を担当します。レイヤー4で動作するネットワークサービスは、はるかに広範なサービスとプロトコルをサポートできます。Cloudflareのパブリックレイヤー4ロードバランサーは、レイヤー4リバースプロキシとして機能するSpectrumという製品によって有効化されています。ロードバランシングを提供するだけでなく、SpectrumはDDoS攻撃 ↗からの保護を提供し、エンドポイントのIPアドレスを隠すことができます。
SSL（Secure Sockets Layer）およびその後継であるTLS（Transport Layer Security）は、インターネット上の接続を保護するために使用される暗号化プロトコルです。SSLおよびTLSオフロード、またはSSL/TLSターミネーションまたはSSL/TLSアクセラレーションとしても知られる技術は、ロードバランサーやウェブサーバーでSSL/TLSの暗号化および復号化プロセスを処理し、エンドポイントのパフォーマンスに影響を与えないようにするために使用されます。SSL/TLSオフロードは、サーバーのパフォーマンスを向上させ、証明書管理を簡素化し、リソース集約的な暗号化および復号化タスクを専用デバイスにオフロードすることでスケーラビリティを向上させ、エンドポイントがコンテンツとアプリケーションロジックの提供に専念できるようにします。
現代のウェブサイトやアプリケーションは、主に3つの課題に直面しています。
- パフォーマンス: アプリケーションがユーザーのリクエストや入力にタイムリーに応答することを保証すること。
- 可用性: アプリケーションの稼働時間を維持し、常にユーザーのリクエストに応答できるようにすること。
- スケーラビリティ: ユーザーの行動や需要に基づいてアプリケーションリソースを増減または移動させること。
アプリケーションのパフォーマンスは、いくつかの要因によって影響を受ける可能性がありますが、パフォーマンス問題の最も一般的な原因は、エンドポイントにかかる使用量や負荷です。エンドポイントは一般的に提供できる計算リソースの有限な量を持っています。一度に多くのリクエストが到着したり、リクエストの種類がCPU/メモリ使用量を増加させると、エンドポイントは遅く応答するか、全く応答しなくなります。
これらの課題に対処するために、エンドポイントはより多くの計算リソースでアップグレードできます。しかし、アイドルまたは低使用時には、組織は未利用のリソースに対して支払うことになります。組織は複数のエンドポイントを展開することもありますが、それらの間でトラフィックをシームレスにステアリングするためには、エンドユーザーにとってこのプロセスをシームレスにするロードバランシングソリューションが必要です。
図1は、ロードバランサーなしで負荷がどのように分配されるかを示しています：
ロードバランサーは、組織が複数のエンドポイントをホストし、それらの間でトラフィックを分配することを可能にし、単一のエンドポイントが圧倒されないようにします。ロードバランサーはすべての受信リクエストを処理し、適切なエンドポイントに転送します。クライアントはエンドポイントの可用性や負荷について何も知る必要はなく、リクエストをロードバランサーに送信するだけで、ロードバランサーが残りを処理します。図2は、ロードバランサーがユーザーからのトラフィックを複数のエンドポイントに均等に分配する方法を示しています。
パフォーマンスに関連する別の問題は、クライアントとエンドポイントの距離に関係しています。単に遠くに移動することや、より多くのネットワークホップを行う必要があるため、長い距離を移動するリクエストは一般的に高い往復時間（RTT）を持ちます。
RTTはスケールで重要になります。たとえば、クライアントとエンドポイントが両方ともアメリカにある場合、25msのRTTが期待されるのは合理的です。クライアントが20のリクエストに対して応答を必要とする場合、それらを順次処理するのに必要な合計時間（計算時間を除く）は500ms（20 x 25ms）になります。そして、同じクライアントがAPAC地域から接続した場合、RTTは150ms以上になる可能性があり、合計読み込み時間は3000ms（20 x 150ms）という望ましくない結果になります。（確かに、HTTP/2やHTTP/3のリクエストストリーミングの改善により、この計算が変わる可能性がありますが、動的またはインタラクティブなコンテンツを持つウェブサイトでは、応答の情報が追加のリクエストを生成するために使用されるため、一般的にはこの例が当てはまります。）図3は、これがどのように発生するかを示しています。
ロードバランサーは、トラフィックをあまり混雑していないエンドポイントに渡すことができるだけでなく、地理的に近いエンドポイントにトラフィックを渡すこともでき、クライアントにとってより応答性の高い体験を提供します。具体的には、ロードバランサーはリクエストを送信したIPアドレスのルックアップを行い、その位置を特定し、最も近いまたは地域に適したエンドポイントを選択して送信します。（これは、GeoDNSのようなDNSソリューションが提供する機能に似ています。）
サービスの可用性は、ロードバランサーの背後にあるエンドポイントの意図しないダウンタイムと意図的なダウンタイムの両方を含みます。意図しないダウンタイムには、ハードウェアの故障、ソフトウェアのバグ、ネットワークの問題、ISPや他のベンダーの問題など、さまざまな要因が寄与する可能性があります。最も高度な組織でさえ、これらの問題は避けられません。
ロードバランサーは、エンドポイントの健康状態を常に監視することでこれらの問題を解決します。エンドポイントがヘルスチェックに対して遅れて応答するか、全く応答しない場合、そのエンドポイントは不健康としてマークされます。これを行うためのいくつかの方法があり、ICMP（ping）やTCP接続テストのような基本的なヘルステストが含まれます。HTTP GETリクエストを発行し、特定の応答コードと応答ボディがエンドポイントから返されることを確認するような、より高度なヘルステストも使用できます。エンドポイントが劣化状態になると、ロードバランサーは健康なエンドポイントに対してリクエストを減らすか、全く送信しなくなります。エンドポイントが再び稼働し、ロードバランサーがヘルスチェックに対する応答を受け取れるようになると、そのエンドポイントは稼働中としてマークされ、再びトラフィックがその方向にステアリングされます。
意図的なダウンタイムは、容量の変更、ハードウェアやインフラストラクチャのアップグレード、ソフトウェアの更新など、いくつかの異なる形態で発生します。ロードバランサーは、メンテナンスを可能にするために、1つまたは複数のエンドポイントからトラフィックを優雅に削除します。
効果的なアプリケーションのスケーリングは、組織が顧客やユーザーの需要に応え、不要な請求や料金を回避するのに役立ちます。トラフィックが増加する際、組織はサービスがパフォーマンスを維持し、可用性を確保するために、一時的により多くのエンドポイントを展開する必要があるかもしれません。しかし、最大のトラフィックに対応するために常に十分なエンドポイントをオンラインに保つことは、エンドポイントがオンプレミスであろうと、AWS、GCP、Azureなどのクラウドプロバイダーを介してあろうと、コストがかかる可能性があります。ロードバランサーは、リクエスト、接続、エンドポイントへのレイテンシーを監視することで、動的に容量を増減させることを可能にします。
考慮すべき別のタイプのスケールは、地理的スケールです。サービスが人気を博すにつれて、エンドポイントの位置が重要になります。エンドポイントとは異なる地理的地域にいるユーザーは、同じ地域にいるユーザーよりも応答時間が遅く、サービスの質が低下する可能性があります。組織が異なる地域に新しいエンドポイントを展開する際、トラフィックをどのように分配するかを決定する必要があります。この課題は、グローバルトラフィック管理（GTM）とローカルトラフィック管理（LTM）と呼ばれる異なるレイヤーのロードバランシングによって解決されています。この文書では、これらの両方を次のセクションで詳しく説明しますが、要約すると、GTMロードバランサーは最初のリクエスト（通常はDNSを介して）を処理し、その後、適切な地理的地域にあるエンドポイントの近くに展開されたLTMロードバランサーにトラフィックを選択してステアリングします。
前述のように、グローバルアプリケーションとサービスの負荷分散は2つの層で構成されています。最初の層はグローバルトラフィックマネージャー（Global Traffic ManagementまたはGTM）と呼ばれ、グローバルサーバーロードバランシング（Global Server Load BalancingまたはGSLB）とも呼ばれることがあります。2番目の層はローカルトラフィックマネージャー（Local Traffic ManagementまたはLTM）と呼ばれ、サーバーロードバランシング（Server Load BalancingまたはSLB）とも言及されることがあります。このセクションでは、これらの異なるタイプの負荷分散の目的と、それらがどのように連携して機能するかを定義します。
グローバルトラフィックマネージャーは、一般的にインターネットからのリクエストを適切な地域またはデータセンターにルーティングする責任があります。多くのGTMロードバランサーはDNS層で動作し、以下のことを可能にします：
- 地理的地域または物理的場所に基づいてDNSリクエストをIPアドレスに解決する。
- クライアントに最も近いエンドポイントまたはサービスのIPを提供し、接続できるようにする。
図4は、GTMロードバランサーがクライアントの位置または地域に基づいてデータセンターを選択する方法を示しています。
グローバルトラフィックマネージャーは、トラフィックをプロキシし、HTTPリクエストのヘッダーを読み取り/変更/削除したり、地域または地理的場所に基づいてURLを変更したりするなど、さまざまな検査を行うこともできます。GTM機能は、世界中のどこからでもトラフィックを誘導することを目的としているため、クラウドベースのロードバランサー（Cloudflareなど）によって最も効果的に実装されます。ハードウェアロードバランサーは単一の物理的場所に存在するため、ロードバランサーからのトラフィックが遠くなるほど、エンドユーザーの体験は遅くなります。クラウドベースのロードバランサーは、さまざまな地理的場所で実行できるため、DNS専用、レイヤー4、およびレイヤー7のコンテキストに対してパフォーマンスの高いソリューションを提供します。
ローカルトラフィックマネージャーは、データセンターまたは地理的場所内でトラフィックを誘導します。LTMは、負荷分散、SSL/TLSオフロード、コンテンツスイッチング、その他のアプリケーション配信機能を担当することがあります。LTMは、パフォーマンスを向上させ、高可用性を確保するために、複数のエンドポイントにクライアントリクエストを効率的に分配します。LTMロードバランサーは通常、プライベートネットワーク内に配置され、公開またはプライベートにアクセス可能なリソースの負荷分散に使用されます。以下の図5では、GTMロードバランサーがヨーロッパのデータセンターを選択し、そのリクエストをヨーロッパのデータセンターのLTMロードバランサーに誘導し、適切なエンドポイントに導く様子を示しています。
ローカルトラフィックマネージャーとそのエンドポイントは通常、ファイアウォールの背後にあります。しかし、エンドポイントはプライベートネットワークで保護されている場合がありますが、LTMロードバランサーへのアクセスは、展開要件に応じて公開またはプライベートのいずれかになります。LTMロードバランサーは、リクエストがタイムリーに応答できるエンドポイントに誘導されるように、総リクエスト、接続、およびエンドポイントの健康状態を監視します。
主に2つのロードバランサーアーキテクチャがあります：
- オンプレミスロードバランサー
- 通常はハードウェアベースですが、仮想化またはソフトウェアベースにもできます
- 最大のパフォーマンスに焦点を当てています
- クラウドベースのロードバランサー
- ソフトウェアが展開されたパブリッククラウドインフラストラクチャ
- リクエストの発信者に近い場所でリクエストを処理します
それぞれのアプローチには利点と欠点があります。オンプレミスのロードバランサーは通常、組織によって完全に制御されたプライベートネットワーク内に存在します。これらのロードバランサーは、負荷分散しているエンドポイントと同じ場所に配置されているため、レイテンシーとRTT時間は最小限に抑えられるべきです。これらのオンプレミスのロードバランサーの欠点は、単一の物理的場所に制限されていることです。つまり、他の地域からのトラフィックは、長いRTTと高いレイテンシーの応答を持つ可能性があります。また、別のデータセンターを追加するには、新しい機器を購入して展開する必要があります。オンプレミスのロードバランサーは、地理的トラフィックの誘導のために、地理的にローカルまたは地域に適したデータセンターによってリクエストをルーティングするために、通常はクラウドベースのロードバランサーを必要とします。クラウドベースのロードバランサーの利点は、ラックスペース、電力、冷却、メンテナンスを気にせずにほぼすべての地理的地域で運用でき、シャーシ、新しいモジュール、または大きなネットワーク接続に関する懸念なしにスケールできることです。ただし、クラウドベースのロードバランサーは、トラフィックを誘導するエンドポイントと通常は同じ場所に配置されていないため、ロードバランサーとエンドポイント間のレイテンシーとRTTを増加させます。
Cloudflareは2016年からクラウドベースのGTMを提供しており、2023年にはLTM機能を追加し始めました。このセクションでは、Cloudflareの負荷分散アーキテクチャ全体をレビューし、利用可能なさまざまな構成とオプションを深く掘り下げます。しかし、まず、CloudflareのロードバランサーがCloudflareのグローバルネットワーク上で動作することによる利点を理解することが重要です。
Cloudflareの負荷分散は、すべてのネットワーク（企業とインターネット）、クラウド環境、アプリケーション、ユーザー間のあらゆる接続を可能にするプログラム可能なクラウドネイティブサービスの統一されたインテリジェントプラットフォームであるCloudflareの接続クラウドに基づいて構築されています。これは、120か国以上の310以上の都市にデータセンターを持ち、13,000以上の他のネットワークと相互接続されている、世界最大のネットワークの1つです。また、多くの他の大手テクノロジー企業よりもコアインターネットエクスチェンジでの存在感が大きいです。
その結果、Cloudflareは、世界のインターネット接続人口の約95%に対して約50ms以内で運営されています。また、すべてのCloudflareサービスは、すべてのネットワークロケーションで実行されるように設計されているため、すべてのトラフィックは、最良のパフォーマンスと一貫したユーザー体験のために、ソースに近い場所で接続、検査、フィルタリングされます。
Cloudflareの負荷分散ソリューションは、anycast技術の使用から利益を得ています。Anycastにより、Cloudflareは、世界中のすべてのデータセンターからサービスのIPアドレスを発表できるため、トラフィックは常にソースに最も近いCloudflareデータセンターにルーティングされます。これにより、トラフィックの検査、認証、およびポリシーの適用がエンドユーザーの近くで行われ、一貫して高品質な体験が得られます。
Anycastを使用することで、Cloudflareネットワークはバランスが取れています。ネットワーク上でトラフィックが急増した場合、負荷は複数のデータセンターに分散され、ユーザーに対して一貫した信頼性のある接続を維持するのに役立ちます。さらに、Cloudflareの大規模なネットワーク容量とAI/ML最適化されたスマートルーティングは、パフォーマンスが常に最適化されるのを助けます。
対照的に、多くの他のSaaSベースの負荷分散プロバイダーは、ユニキャストルーティングを使用しており、単一のIPアドレスが単一のエンドポイントおよび/またはデータセンターに関連付けられています。このようなアーキテクチャでは、単一のIPアドレスが特定のアプリケーションに関連付けられるため、そのアプリケーションにアクセスするためのリクエストは、トラフィックが移動する距離によって非常に異なるネットワークルーティング体験を持つ可能性があります。たとえば、アプリケーションのエンドポイントの隣で働く従業員にとってはパフォーマンスが優れているかもしれませんが、リモートの従業員や海外で働く従業員にとっては悪いかもしれません。ユニキャストは、トラフィック負荷のスケーリングを複雑にします — 単一のサービスロケーションは、負荷が増加したときにリソースを増やす必要がありますが、anycastネットワークは多くのデータセンターや地理にわたってトラフィックを共有できます。
図6は、Cloudflareネットワークを使用することで、地理的に離れたユーザーができるだけ早くリソースに接続できる様子を示しています。
上記の図6は、Cloudflareがすべてのデータセンターで各サービスを実行しているため、ユーザーがどこでも一貫した体験を得られることを示しています。たとえば、Cloudflareのレイヤー7ロードバランサーは、DDoS保護、CDN/キャッシュ、ボット管理、またはWAFなどの他のサービスを活用することもできます。これらの追加サービスは、悪意のあるリクエスト（DDoS保護、ボット管理、またはWAFによってブロックされる）や、エンドポイントへのリクエストではなくキャッシュを介して提供できるリクエストからサービスを保護するのに役立ちます。これらのサービスは、必要に応じて組み合わせて、サービスや提供物をできるだけ保護され、回復力があり、パフォーマンスが高いものにすることができます。
Cloudflareには、すべてのデータセンターで常に実行されているネットワーク最適化サービス ↗もあり、CloudflareがCloudflareデータセンター間の最良のパスを提供し、エンドポイントへのすべての利用可能なパスを追跡します。これにより、Cloudflareはエンドポイントに常に到達できることを保証し、必要に応じてトラフィックを代替のCloudflareデータセンターに再ルーティングできます。ロードバランサーがトラフィックをどのエンドポイントに誘導するかを決定した後、トラフィックはCloudflareのネットワーク最適化サービスに転送され、宛先に到達するための最良のパスが決定されます。このパスは、Argo Smart Routingという機能によって影響を受ける可能性があり、これを有効にすると、タイミングされたTCP接続を使用して、エンドポイントへの最速のRTTを持つCloudflareデータセンターを見つけます。図8は、Argo Smart Routingがエンドポイントへの接続時間を改善するのにどのように役立つかを示しています。
トラフィックフローに影響を与える別の方法は、Cloudflareトンネルの使用です。この文書では、次のセクションでCloudflareトンネルについて詳しく説明します。Cloudflareトンネルはエンドポイントを特定のCloudflareデータセンターに接続するため、これらのエンドポイントに向けられたトラフィックは、エンドポイントに到達するためにこれらのデータセンターを通過する必要があります。図9は、Cloudflareトンネルを介して接続されたプライベートエンドポイントへの接続が、トンネルが終了するデータセンターを通過しなければならない様子を示しています。
通常、GTMとLTMのロードバランサーは、別々のハードウェアまたは別々のSaaS（GTM）およびハードウェア（LTM）コンポーネントです。CloudflareのGTMとLTMの負荷分散機能は、単一のSaaSオファリングに統合されており、構成と管理が大幅に簡素化されています。GTMロードバランサーを作成し、よりローカルなLTMロードバランサーにトラフィックを誘導する必要はありません。すべてのエンドポイントはCloudflareに直接接続でき、トラフィックは単一のロードバランサー構成から正しい地域、データセンター、エンドポイントに誘導されます。GTMとLTMの機能の概念は残りますが、Cloudflareでの実装は、ロードバランサーの構成をできるだけシンプルで明確に保つ方法で行われます。図10は、グローバルトラフィックが必要に応じて任意の地理的地域から特定のエンドポイントに誘導される様子を示しています。
Cloudflareロードバランサーは、通常、仮想IP（VIP）と呼ばれ、エントリポイントで構成されます。通常、このエントリポイントはDNSレコードです。ロードバランサーは最初に、機能、地理的エリア、または地域に基づいて選択されたエンドポイントのグループであるエンドポイントプールを選択するために定義されたトラフィック誘導アルゴリズムを適用します。ロードバランサーの構成には、1つまたは複数のエンドポイントプールが含まれ、各エンドポイントプールには1つまたは複数のエンドポイントが含まれます。エンドポイントプールを選択した後、ロードバランサーはエンドポイント誘導アルゴリズムをエンドポイントのリストに適用し、トラフィックを誘導するエンドポイントを選択します。図11は、Cloudflareロードバランサー内でのクライアントリクエストからエンドポイントまでの基本的なステップを示しています。
Cloudflareロードバランサーの定義は、3つの主要なコンポーネントに分かれています：
- ヘルスモニター: これらのコンポーネントは、エンドポイントの健康状態を観察し、それらを健康またはクリティカル（不健康）として分類する役割を担っています。
- エンドポイントプール: ここではエンドポイントが定義され、ヘルスモニターとエンドポイントスティアリングが適用されます。
- ロードバランサー: このコンポーネントでは、エンドポイントプールのリストとトラフィックスティアリングポリシーが適用されます。
以下のセクションでは、Cloudflare Load Balancerの設定に利用可能なオプションと考慮事項について詳述します。最初に、エンドポイントプールとロードバランサーの設定の両方で利用されるスティアリングについて説明します。
スティアリングはロードバランサーのコア機能であり、スティアリング方法は最終的にロードバランサーが稼働する際にどのエンドポイントが選択されるかを決定します。ロードバランサーの観点から、スティアリングは2つの主要な領域で適用されます。
最初のものは「トラフィックスティアリング」と呼ばれ、通常はリクエスターの近接性や地理的地域に基づいて、どのエンドポイントプールが受信リクエストを処理するかを決定します。トラフィックスティアリングの概念は、グローバルトラフィック管理のアイデアと密接に関連しています。
スティアリングが適用される2つ目の領域は、地域、データセンター、またはエンドポイントプールが選択された後です。この時点で、ロードバランサーはリクエストまたは接続を処理する単一のエンドポイントを選択する必要があります。これを「エンドポイントスティアリング」と呼びます。これらの2つのレベルでのスティアリングは、ロードバランサーを展開する顧客の特定のニーズに合わせたスティアリング方法を適用することによって行われます。選択できるさまざまなアルゴリズムがありますが、すべてのアルゴリズムが両方のスティアリングタイプに適用されるわけではありません。
以下は、Cloudflareが提供するすべてのスティアリング方法の詳細なレビューです。このセクションの最後には、どのアルゴリズムがどのユースケースに適用されるかを理解するのに役立つクイックリファレンステーブルがあります。
トラフィックスティアリングは、エンドポイントのグループ、すなわちエンドポイントプールを選択します。トラフィックスティアリングの最も一般的な使用法は、最も遅延の少ない応答時間、地理的地域、または物理的な位置に基づいてエンドポイントプールを選択することです。トラフィックスティアリングはグローバルトラフィック管理と密接に関連しており、エンドポイントへのトラフィックを指示する最初のステップとして機能します。
エンドポイントスティアリングは、どのエンドポイントがリクエストまたは接続を受け取るかを選択する役割を担っています。エンドポイントスティアリングは、ランダムにエンドポイントを選択したり、以前に選択されたエンドポイント（セッションアフィニティが有効な場合）を選択したり、リクエストまたは接続に対して最も利用されていない、最も応答が速いエンドポイントを選択するために使用されることがあります。エンドポイントスティアリングは、リクエストまたは接続の最終的な宛先を選択する責任があるため、ローカルトラフィック管理と密接に関連しています。
ウェイテッドスティアリングは、ロードバランサーからのリクエストを処理するエンドポイントプールとエンドポイントの違いを考慮に入れます。エンドポイントの重みは、すべてのエンドポイントに必要なフィールドであり、特定のスティアリング方法が選択された場合にのみ使用されます。同様に、エンドポイントプールの重みも特定のスティアリング方法が選択された場合にのみ必要です。重みが適用されるタイミングについてのクイックリファレンスは、スティアリングオプションの概要セクションを参照してください。
重みは、ロードバランサー内の単一のリクエストまたは接続に対するエンドポイントプールまたはエンドポイントの選択のランダム性に影響を与えます。重みは過去のデータや現在の接続情報を考慮しないため、短期間での分布に変動がある可能性があります。しかし、長期間にわたり、かつ大きなトラフィックがある場合、分布は設定で適用された望ましい重みにより近づくでしょう。重要な点は、セッションアフィニティが初回接続後に重み設定を上書きすることです。セッションアフィニティは、以降のリクエストを同じエンドポイントプールまたはエンドポイントに指示することを目的としています。図12は、選択される確率が等しい2つのエンドポイントプールの重みの例を示しています。
特定のアルゴリズム、例えば最小未処理リクエストスティアリング（Least Outstanding Request Steering）は、オープンリクエストと接続の数を考慮に入れます。重みは、どのエンドポイントまたはエンドポイントプールがより多くのオープンリクエストまたは接続を処理できるかを決定するために使用されます。基本的に、重みは選択されたスティアリング方法に関係なく、エンドポイントまたはエンドポイントプールの容量を定義します。
重みは0.00から1.00の間の任意の数として定義されます。エンドポイントプールの合計重みやエンドポイントプール内のエンドポイントの重みが1に等しくなる必要はないことに注意してください。代わりに、重みは合計され、個々の重み値はその合計で割られて、そのエンドポイントが選択される確率が得られます。
重みからパーセンテージへの方程式: (エンドポイントの重み) ÷ (プール内のすべての重みの合計) = (エンドポイントへのトラフィックの%）
以下は、重みがトラフィックの分配にどのように使用されるかを理解するのに役立つ図を含むいくつかの例です。これらの例では、目標が同じ容量または計算リソースを持つすべてのエンドポイントにトラフィックを均等に分配することだと仮定しています。ランダムトラフィックスティアリングを使用して、3つのエンドポイントプール間のトラフィック分配を示します。
例1:
- 定義されたエンドポイントプールが3つあり、すべての重みは1です。
- 各エンドポイントプールは選択される確率が33%です。
重み1の例の数学: (1) ÷ (1 + 1 + 1) = (.3333)（または33.33%）
この例では、すべてのエンドポイントプールの重み値に1を適用するのは簡単でした。ただし、0.01から1.00の間の任意の数を使用できたことに注意してください。たとえば、すべてのプールを0.1または0.7に設定すると、各プールがトラフィックを受け取る確率は等しくなります。
重みの合計が確率を計算するために使用されるため、組織はこれらの入力を理解しやすくするために任意の数の値を使用できます。次の例では、各エンドポイントが同じ容量を持っているため、各エンドポイントに0.1の重みが割り当てられ、これらの値の合計がエンドポイントプールの重みとして使用されます。
例2
- 定義されたエンドポイントプールが3つあります。
- 各エンドポイントプールには異なる数のエンドポイントがありますが、すべてのエンドポイントは同じ容量を持っています。
- エンドポイント間で負荷を均等に分配するために、各エンドポイントプールには異なる確率が必要です。
重み0.4の例の数学: (.4) ÷ (.4 + .5 + .6) = (.2667)（または26.67%）
重み0.5の例の数学: (.5) ÷ (.4 + .5 + .6) = (.3333)（または33.33%）
重み0.6の例の数学: (.6) ÷ (.4 + .5 + .6) = (.4000)（または40.00%）
エンドポイントがすべて同じ容量を持っていない可能性があります。次の例では、1つのエンドポイントプールのエンドポイントが他の2つのエンドポイントプールのエンドポイントの2倍の容量を持っています。
例3
- 定義されたエンドポイントプールが3つあります。
- エンドポイントプール1には、エンドポイントプール2およびエンドポイントプール3のエンドポイントの2倍の容量を持つエンドポイントがあります。
- 目標は、エンドポイントプール1に対してエンドポイントごとに2倍のトラフィックを配置することです。
- エンドポイントプール1には4つのエンドポイントがありますが、容量が2倍のため、各エンドポイントの重みは0.2とされ、エンドポイントプールの合計は0.8になります。
重み0.8の例の数学: (.4) ÷ (.8 + .5 + .6) = (.4211)（または42.11%）
重み0.5の例の数学: (.5) ÷ (.8 + .5 + .6) = (.2632)（または26.32%）
重み0.6の例の数学: (.6) ÷ (.8 + .5 + .6) = (.3157)（または31.57%）
この最終例では、エンドポイントプール1の4つのエンドポイントが他のエンドポイントの2倍の容量を持っているため、計算はエンドポイントプール1を実質的に8つのエンドポイントを持つものとして扱います。したがって、重みの値は例2で示された0.4ではなく0.8になります。
これらは、重みがエンドポイントプールまたはエンドポイント間で負荷を分配するためにどのように使用されるかを示す3つの簡単な例です。同様の計算は、エンドポイントプール内のエンドポイントに適用される重みにも使用されます。ただし、異なるスティアリング方法内での重みの使用の影響は似ていますが、計算は若干修正されます。以下のセクションで説明します。
重みは、1つのエンドポイントプールが他のエンドポイントプールよりも多くのリソースを持っている場合や、エンドポイントプール内のエンドポイントが等しい容量を持っていない場合に最も有用です。重みは、すべてのリソースがその能力に応じて均等に使用されることを保証するのに役立ちます。
オフ - フェイルオーバーは、最も基本的なトラフィックスティアリングポリシーです。これは、トラフィックをどのプールに向けるかを選択するための優先リストとしてエンドポイントプールの順序を使用します。リストの最初のプールが健康でトラフィックを受け取ることができる場合、それが選択されるプールになります。オフ - フェイルオーバーはエンドポイントスティアリングには利用できないため、別のスティアリング方法がエンドポイントを選択するために使用されます。オフ - フェイルオーバーは、プライマリデータセンターまたはエンドポイントグループがトラフィックを処理するために使用され、障害条件下でのみトラフィックがバックアップエンドポイントプールに向けられるアクティブ/パッシブフェイルオーバーシナリオで一般的に使用されます。
ランダムスティアリングは、トラフィックスティアリングとエンドポイントスティアリングの両方で利用可能です。ランダムは、ロードバランサーの設定とエンドポイントプール内で定義された重みに基づいてリソースにトラフィックを分散させます。ロードバランサーで設定された各エンドポイントプールの重み値は、そのエンドポイントプール内の各エンドポイントに設定された重み値と異なる場合があります。たとえば、ロードバランサーの設定内で、トラフィックの70%が2つのエンドポイントプールの1つに送信され、そのエンドポイントプール内でトラフィックが4つのエンドポイントに均等に分配されることがあります。前のセクションのウェイテッドスティアリングでは、重りがどのように使用され、エンドポイントプールまたはエンドポイントの選択を決定する計算について詳しく説明しています。
ハッシュスティアリングは、エンドポイントの重みとリクエストの送信元IPアドレスを使用してエンドポイントを選択するエンドポイントスティアリングアルゴリズムです。その結果、同じIPアドレスからのすべてのリクエストは常に同じエンドポイントにスティアリングされます。エンドポイントの順序を変更したり、エンドポイントプールからエンドポイントを追加または削除したりすると、ハッシュアルゴリズムを使用した場合に異なる結果が得られる可能性があることに注意してください。
ジオスティアリングは、特定の国や地理的地域にエンドポイントプールを結びつけるために使用されるトラフィックスティアリングアルゴリズムで、エンタープライズプランの顧客に提供されます。このオプションは、ユーザーに近いエンドポイントにトラフィックをスティアリングすることでパフォーマンスを向上させるのに役立ちます。また、特定の地域のユーザーからのリクエストを同じ地域内のリソースや特定の規制要件を満たすために設計されたリソースにスティアリングすることで、法律や規制の遵守にも役立ちます。
ダイナミックスティアリングは、エンタープライズプランの顧客に提供されるトラフィックスティアリングアルゴリズムで、ラウンドトリップ時間（RTT）プロファイルを作成します。RTT値は、ヘルスプローブリクエストが行われるたびに収集され、エンドポイントからモニタリクエストへの応答に基づいています。リクエストが行われると、CloudflareはRTTデータを検査し、RTT値によってプールをソートします。特定の地域やコロケーションセンターにプールの既存のRTTデータがない場合、Cloudflareはフェイルオーバー順序でプールにトラフィックを指示します。エンドポイントプールに対してダイナミックスティアリングを初めて有効にする際は、CloudflareがそのプールのRTTプロファイルを構築するために10分間の時間を許可してください。ダイナミックスティアリングは、意思決定プロセスで地理的境界を使用せず、最も低いRTTのエンドポイントプールを選択することにのみ焦点を当てています。
プロキシミティスティアリングは、リクエストが発生した場所に基づいて最も近い物理データセンターにトラフィックをスティアリングするエンタープライズプランの顧客向けのトラフィックスティアリングアルゴリズムです。
Cloudflareは、次の方法でリクエスターの物理的な位置を特定します。この順序で:
- EDNSクライアントサブネット ↗情報（DNSリクエストで提供されている場合）
- Cloudflareに到達するために使用されたリゾルバのGeoIP情報
- リクエストを処理するCloudflareデータセンターのGPS位置
プロキシミティスティアリングは、すべてのエンドポイントプールにGPS座標を提供する必要があり、CloudflareがリクエストIP、DNSリゾルバ、またはCloudflareデータセンターに基づいて最も近いエンドポイントプールを計算できるようにします。
最小未処理リクエストスティアリング（LORS）は、エンタープライズプランの顧客に提供され、トラフィックスティアリングとエンドポイントスティアリングの両方に使用できます。
LORSは、未回答のHTTPリクエストの数を使用してステアリングに影響を与え、Cloudflare Layer 7プロキシのCloudflare Load Balancersと一緒に使用される場合にのみ機能します。LORSが他のタイプのロードバランサーに割り当てられた場合、その動作はランダムステアリングと同等になります。LORSは、オープンリクエストのカウントと重みを使用して、新しい変換された重みを作成し、それがステアリングの決定に使用されます。
LORS変換重みの方程式：
- weight / (count + 1) = transformedWeight
ランダム重み計算のリマインダー：
- 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に向けられる可能性もあります。負荷条件が軽い状況では、ステアリング結果により多くの変動があり、設定された重みに正確に一致しない場合があります。しかし、負荷が増加するにつれて、実際のステアリング結果は設定された重みに密接に一致します。
LORSを使用して非L7プロキシのロードバランサーを使用する場合、オープンリクエストカウント情報は利用できません。その結果、分母は常に1になります。任意の数を1で割っても分子は変わらないため、この場合、分子は重みであり、ステアリングの決定は重みにのみ基づいて行われます。これにより、上記のランダムメソッドが結果として得られます。
LORSは、エンドポイントプールやエンドポイントが同時リクエストのスパイクによって簡単に圧倒される場合に最適です。レイテンシ、地理的整合性、または他のメトリックなどの要因よりもエンドポイントの健康を重視するアプリケーションに適しています。これは、いくつかまたはすべてのリクエストがエンドポイントに重い負荷をかけ、応答を生成するのにかなりの時間がかかる場合に特に便利です。
| ステアリングメソッド | トラフィックステアリング | エンドポイントステアリング | 重みベース | エンタープライズ専用 |
|---|---|---|---|---|
| オフ - フェイルオーバー | X | |||
| ランダム | X | X | X | |
| ハッシュ | X | X | X | |
| 地理 | X | X | ||
| ダイナミック | X | X | ||
| 近接 | X | X | ||
| 最小未処理リクエスト | X | X | X | X |
上記でエンタープライズ専用としてマークされたすべてのトラフィックステアリングメソッドは、セルフサービスのアドオンとしても取得できます。エンタープライズ専用としてマークされたすべてのエンドポイントステアリングメソッドは、Cloudflareのエンタープライズプランを必要とします。
ヘルスモニターは、エンドポイントプール内に構成された後のエンドポイントの健康を判断します。ヘルスモニターは、エンドポイントへの接続試行であるプローブを生成します。ヘルスモニターは、プローブへの応答を使用してエンドポイントの健康を記録します。ヘルスモニターは、サービスタイプ、パス、ポート、インターバル、タイムアウト、エンドポイントの健康を評価するためのプロトコル固有の設定などの高度な機能を含むテンプレートとして機能します。ヘルスモニターテンプレートは、同様のサービスをホストするエンドポイントを含むエンドポイントプールに適用されます。ヘルスモニターがエンドポイントプールに接続されると、エンドポイントアドレスはヘルスモニタープローブの宛先として使用されます。単一のヘルスモニターは、多くのエンドポイントプールで使用でき、ヘルスモニターはアカウントレベルのオブジェクトであるため、同じCloudflareアカウント内の複数のゾーンで活用できます。
デフォルトでは、ヘルスモニタープローブはエンドポイントアドレスに直接送信され、全体のLayer 7スタックをバイパスします。これは、ロードバランサーを介してエンドポイントへの実際のトラフィックがヘルスモニタープローブとは異なる扱いを受けることを意味します。構成によっては、実際の接続やリクエストが失敗している場合でも、ヘルスモニターがエンドポイントを健康と報告する可能性があります。
Simulate Zone機能は、ヘルスモニタープローブが実際のリクエストと同じパスをたどり、全体のLayer 7スタックを通過することを保証します。これにより、ヘルスモニターはネットワークを通じてエンドポイントに到達するために正確に同じパスをたどります。これは、Authenticated Origin Pulls (AOP)などの特定の機能が有効になっている場合にヘルスモニターに必要です。プローブは、オリジンでの認証のために適切なmTLS証明書が提供されていない場合に失敗します。Simulate Zoneは、ヘルスモニタープローブがArgo Smart Routingによって提供される同じパスと、組織がエンドポイントに到達するためにCloudflareが使用するエッジIPアドレスを制限するためにAegis ↗を活用する際に同じ専用の出口IPを使用することを保証します。
ヘルスモニタープローブは、以下のタイプとして構成できます：
- HTTP
- HTTPS
- TCP
- UDP ICMP
- ICMP Ping
- SMTP
- LDAP
ヘルスモニターが定義されると、それをエンドポイントに割り当て、定義された間隔でプローブがエンドポイントに送信されます。エンドポイントプール内のヘルスモニター構成に関して注意すべき2つの追加設定があります。最初はヘルススレッショルドで、これはプール内のエンドポイントが健康である必要がある数を決定するために使用され、エンドポイントプールが健康または劣化していると見なされるために必要です。
- 健康な状態のエンドポイントプール
- 健康なエンドポイントのみを含む
- 劣化状態のエンドポイントプール
- 1つ以上の重要なエンドポイントを含むが、ヘルススレッショルド設定以上または同等である
- 重要な状態のエンドポイントプール
- ヘルススレッショルド未満の健康なエンドポイントを含む
- トラフィックを処理できない; すべてのステアリング決定から除外される。
エンドポイントプール内でヘルスモニターを定義した後の2つ目の設定は、ヘルスモニタープローブがCloudflareグローバルネットワーク内のどの地域からソースされるべきかを定義することです。利用可能な選択肢は以下の通りです：
- すべての地域（デフォルト）
- すべてのデータセンター（エンタープライズ専用）
- 北米西部
- 北米東部
- 西ヨーロッパ
- 東ヨーロッパ
- 南米北部
- 南米南部
- オセアニア
- 中東
- 北アフリカ
- 南アフリカ
- 南アジア
- 東南アジア
- 北東アジア
「すべての地域」と「すべてのデータセンター」を除いて、ヘルスモニタープローブは選択された地域または地域のデータセンターからのみ送信されます。ローカルに関連するサービスの場合、世界の反対側にあるデータセンターがエンドポイントに到達できるかどうかは重要でない場合があります。したがって、特定の地域または地域のセットにチェックを制限することは理にかなっているかもしれません。「すべての地域」または「すべてのデータセンター」の選択は、エンドポイントのセットに到達することがアプリケーションの機能にとって重要であるグローバルに利用可能なサービスに使用されることを意図しています。
エンドポイントは、ロードバランサーがすべてのポリシーを適用した後に接続とリクエストを処理する実際のサーバーです。エンドポイントは、物理サーバー、仮想マシン、またはサーバーレスアプリケーションである可能性があります。ユーザーまたはクライアントからのリクエストまたは接続を処理できる限り、エンドポイントと見なすことができます。Cloudflareにエンドポイントを定義し接続する方法はいくつかあり、次のセクションではそれらの方法について詳しく説明します。
Cloudflareエンドポイントは、IPアドレスまたはホスト名によって定義できます。IPアドレスは最も簡単で基本的な接続方法であり、ホスト名は考慮すべきいくつかのオプションを提供します。ホスト名はCloudflare DNSで定義でき、プロキシまたはDNSのみ（プロキシなし）にすることができます。もちろん、ホスト名がCloudflareが権威DNSサーバーであるドメインにない場合、Cloudflareは外部DNSサーバーに依存してそのホスト名をIPアドレスに解決します。Cloudflare Tunnelも使用でき、2つの異なるオプションを提供します。これらの方法は、このセクションで以下に説明します。
上記の「HTTP(S) Load Balancing」セクションで述べたように、ロードバランシングはリクエストがエンドポイントに送信される前に実行される最後のプロセスです。しかし、Cloudflareのエッジを介してエンドポイントがプロキシされている場合でも、ロードバランサーの後、リクエストは再度Layer 7スタックを通過することなくエンドポイントに直接転送されます。これは、エンドポイントが保護されていないまたはキャッシュされていないことを意味するわけではありません。ロードバランサー自体がプロキシされている限り、すべての保護はエンドポイントではなくロードバランサーに提供されます。エンドポイントとの直接通信は依然としてプロキシされ、CloudflareのLayer 7スタックで処理されることができますが、エンドポイントとの通信はすべての処理がロードバランサーの前に置かれ、エンドポイントではありません。図19は、CloudflareのLayer 7スタックがエンドポイントに対してどのように配置されているかの違いを示しています。
エンドポイントプールの一部として定義されるエンドポイントのタイプに関しては、ロードバランサーの観点から非常に少ない違いがあります。トラフィックとエンドポイントのステアリングポリシーおよびロードバランサールールが適用されると、Cloudflare Load BalancingサービスはL7スタックに対して、受信リクエストまたは接続をどこに転送するかを指示します。このリクエストはエンドポイントに直接送信されます。エンドポイントへの接続のタイプによっては、異なるパスがある場合があります。Argo Smart Routingや、異なるCloudflareデータセンターで終了するトンネル接続されたエンドポイントのような機能は、リクエストをCloudflareエッジからインターネットを経由してエンドポイントに直接送信するのではなく、トラフィックを異なるルートにルーティングします。しかし、パスに関係なく、ロードバランシングはスタック内の最後のプロセスであり、これはトラフィックが追加の処理を受けないことを意味します。したがって、エンドポイントへの接続はCloudflareからエンドポイントへのパスを変更することができますが、エンドポイントが選択されると、処理や扱いは変わりません。
Cloudflare Tunnelは、組織がファイアウォールの構成を簡素化し、複雑さを軽減し、セキュリティを強化し、資産をCloudflareネットワークにより簡単に接続できるようにするためのアウトバウンド接続です。これらのトンネルを作成する実行可能ファイルはcloudflaredと呼ばれ、この文書および以下の図で参照されることがあります。
Cloudflare Tunnel（cloudflared）は、エンドポイントまたはエンドポイントにIP接続を持つ任意のサーバーに直接インストールできます。そして、Cloudflareへの接続はCloudflare Tunnelがインストールされた場所からCloudflareに向けて開始されるため、必要なアクセスはCloudflareへのアウトバウンドアクセスのみです。単一のCloudflare Tunnelは、1つまたは複数の異なるエンドポイントにトラフィックを輸送することができ、1つはエンドポイントが公開アクセス可能になり、もう1つはエンドポイントが完全にプライベートにのみアクセス可能になります。
Cloudflare Tunnelは、エンドポイント自体またはCloudflareに接続する必要があるエンドポイントまたはエンドポイントに対してレイヤー3（IP）接続を持つ任意のサーバーにインストールできます。cloudflaredを分離する決定は、エンドポイントを隔離し、そのパフォーマンスを確保すること、ネットワークレベルの接続とエンドポイントを管理する別のチームを持つこと、またはサーバーが分離された役割や責任を持つアーキテクチャの単純さのために行われる可能性があります。
単一のcloudflaredインスタンスは、4つの異なるトンネルを作成し、2つの異なるCloudflareデータセンターに2つのトンネルを設置します。このモデルは高可用性を確保し、個々の接続の失敗のリスクを軽減します。つまり、単一の接続、サーバー、またはデータセンターがオフラインになった場合でも、エンドポイントは利用可能なままです。Cloudflare Tunnelは、可用性とフェイルオーバーシナリオのために、組織がcloudflaredの追加インスタンスを展開することも可能にします。これらのユニークなインスタンスはレプリカと呼ばれます。各レプリカは、エンドポイントに対する追加の入口ポイントとして機能する4つの新しい接続を確立します。各レプリカは同じトンネルを指します。これにより、cloudflaredを実行している単一のホストがダウンした場合でも、ネットワークが稼働し続けることが保証されます。設計上、レプリカはトラフィックスティアリング（ランダム、ハッシュ、またはラウンドロビン）のいかなるレベルも提供しません。
公開エンドポイントメソッドは、組織がエンドポイント上で実行されている特定のサービスまたはポートを指すトンネルを定義することを可能にします。トンネルはエンドポイント上またはエンドポイントへのIP接続を持つ任意のサーバー上で終了できます。この公開ホスト名メソッドを使用するには、トンネルを介してアクセスされる各サービスがトンネル構成で定義されている必要があります。構成されると、トンネルが接続トラフィックを行うIPおよびポートまたはサービスに対して、d74b3a46-f3a3-4596-9049-da7e72c876f5のようなユニークなトンネルIDが作成されます。このトンネルIDは、cfargotunnel.comというCloudflare所有のドメイン内のユニークな公開ホスト名に作成され、DNS Aレコードが作成され、そのサービスに直接ポイントします。つまり、d74b3a46-f3a3-4596-9049-da7e72c876f5.cfargotunnel.comです。このホスト名は公開されていますが、Cloudflare Tunnel構成を所有するアカウントを介して送信されたトラフィックによってのみアクセスまたは利用できます。他のアカウントは、このDNSアドレスに直接アクセスしたり、トラフィックを送信したりすることはできません。cfargotunnel.comホスト名を所有するアカウントの外で作成されたDNS CNAMEレコードは、その特定のCloudflare Tunnelを介してトラフィックを送信することはできません。
ダッシュボードを介して構成されると、Cloudflareは自動的にcfargotunnel.comホスト名を参照するDNSゾーンに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 Load Balancersは、エンドポイント上で実行されているサービスにアクセスするためにこれらの2つのポートをデフォルトとしています。組織が他のポートでサービスを実行している場合、Cloudflare Tunnelを構成してキャッチオールルールを使用してそのポートに到達する必要があります。この構成により、Cloudflare Load Balancerはポート443を介してサービスに到達し、Cloudflareトンネルがエンドポイントの希望するポートへの接続をプロキシします。
2番目の方法はプライベートサブネット用です。この方法では、組織がプライベートIPアドレスとサブネットマスクを定義し、Cloudflareのグローバルネットワーク内にプライベート仮想ネットワークを作成するために使用されます。プライベートサブネットメソッドではポートの定義は許可されておらず、サブネットとマスクが定義されると、そのトンネルを介して全体のサブネットにアクセスできますが、アクセスが許可されたユーザーのみが定義されたゼロトラストポリシーを介してアクセスできます。
このサブネットは、Cloudflare内の仮想ネットワークに追加され、顧客はユーザーがどのようにアクセスできるか、どのユーザーがアクセスできるかを制御できます。このサブネットは、32ビットマスク（単一のIPアドレス、IE. 10.0.0.1/32）を使用するなど、任意のサブネット化またはルーティングのために定義できます。許可されたサブネットは、cloudflaredプロセスを実行しているホスト上に存在する必要はありません。必要なのは、cloudflaredを実行しているホストとCloudflare Tunnelを介して到達可能なサブネットとの間のレイヤー3またはIP接続だけです。
エンドポイントプール内には、いくつかの構成オプションがあります。このセクションでは、これらの構成オプションが何であるか、そしてそれらがCloudflare Load Balancerの動作をどのように変更するかについて詳述します。
エンドポイントプールの名前と説明を定義することに加えて、最初の構成はエンドポイントスティアリングメソッドを決定することです。エンドポイントスティアリングは、最終的にリクエストまたは接続試行を受け取るエンドポイントを選択する役割を担っています。（各メソッドの詳細な説明については、スティアリングメソッドセクションを参照してください。）
個々のエンドポイントはエンドポイントプール内で定義され、エンドポイントプールはプールごとに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ダッシュボードで移動するには、ゼロトラストページから_ネットワーク - ルート_を選択します。
_エンドポイントウェイト_は、ランダム、ハッシュ、および最小未処理リクエストスティアリングメソッドにのみ使用されます。これは、エンドポイント定義の一部として常に定義する必要があります。（エンドポイント選択におけるウェイトの使用方法については、ウェイト付きスティアリングセクションを参照してください。）
エンドポイントプールでは、エンドポイントにリクエストを送信する前にホストヘッダーを変更することができます。この構成は、HTTP(S)レイヤー7ロードバランサーにのみ適用されます。（プライベートIPおよびSpectrumを含むレイヤー4ロードバランサーで使用される場合は無視されます。）
HTTP(S)ベースのリクエストがあるレイヤー7ロードバランサー内では、ホストヘッダーはエンドポイントにどのウェブサイトがリクエストされているかを伝えます。単一のエンドポイントが複数の異なるウェブドメインをホストする場合があります。エンドポイントが特定のウェブドメインをホストするように特別に構成されている場合、ホストヘッダーでリクエストされたリソースをホストしていないと判断した場合、応答しないか、リソースに対する失敗応答を送信することがあります（すなわち、ホストヘッダーが不一致の場合）。
たとえば：
- ユーザーが
www.example.comにアクセスしようとすると、ロードバランサーはすべてのリクエストを受け取るためにwww.example.comのホスト名で構成されます。 - エンドポイントはDNS内で同じ公開ホスト名を持つことができないため、そのホスト名は
endpoint1.example.comです。 - ユーザーが
www.example.comにリクエストを送信すると、ホストヘッダーもwww.example.comに設定されます。エンドポイントはwww.example.comのホストヘッダーに応答するように構成される必要があります。 - ただし、特定のクラウドまたはSaaSアプリケーションの場合、エンドポイントはそのように構成できないため、エンドポイントは未知のホストヘッダーを持つリクエストを受け取り、適切に応答できないことがあります。
- この例では、エンドポイント構成で、エンドポイントのホストヘッダーを
endpoint1.example.comのエンドポイントアドレスに設定すると、www.example.comのホストヘッダーがendpoint1.example.comに置き換えられ、このリクエストに適切に応答できるようになります。
図21は、ホストヘッダーの不一致による潜在的な問題を強調しています：
また、エンドポイントプールでは、プールのGPS座標（近接トラフィックスティアリングに使用される）を定義できます。近接スティアリングが使用されていない場合、これらの座標は必要ありません。（近接スティアリングを参照してください）
ロードシェディング—プール内のエンドポイントが不健康になる ↗のを防ぐために管理者が利用できるリアルタイムの応答—もエンドポイントプールで構成されます。
ロードシェディング設定は、管理者がエンドポイントプールが不健康になるのを積極的に防ごうとしている場合を除いて、有効にすることを意図していません。たとえば、リクエストに応答しているエンドポイントがCPUまたはメモリ使用量の増加、応答時間の増加、または時折全く応答しない場合に有効になります。
エンドポイントプールの健康が劣化し始めると、ロードシェディングは既存の負荷の一部を1つのエンドポイントプールから別のエンドポイントプールに向けるのに役立ちます。
エンドポイントプールの健康状態に応じて、新しいリクエストや接続をエンドポイントプールから単にシェッドまたはリダイレクトするだけで十分な場合があります。このポリシーは、セッションアフィニティルールの対象とならないトラフィックに適用されます。なぜなら、これらはまだエンドポイントプールやエンドポイントが選択されていない新しい接続だからです（したがって、最終的にエンドユーザーの体験に影響を与える可能性はありません）。
エンドポイントプールが負荷による重大な障害に近づくと、次のオプションは追加のセッションアフィニティトラフィックをシェッドすることです。これにより、セッションアフィニティを介してエンドポイントプールにバインドされたリクエストや接続がリダイレクトされ始めます。ただし、このプロセスが最終的にユーザーのエンドポイントを変更する可能性があるため、エンドユーザーの体験に影響を与える可能性があることに注意してください。最終的には、影響は負荷分散されるアプリケーションと、エンドポイント間で共有される接続コンテキストの量によって決まります。
ヘルスモニターは、エンドポイントプール内のエンドポイントに接続され、ヘルスしきい値およびヘルスチェック地域の選択が行われます。これらのオプションの詳細は、ヘルスモニターセクションで確認できます。
Cloudflare内の負荷分散は、GTMとLTMの負荷分散を単一の負荷分散構成に統合します。特定の機能や用語がGTMまたはLTMロードバランサーにより適合する場合がありますが、Cloudflareの顧客にとっては、両者が単一の管理しやすいインスタンスに統合されています。
特定のユースケースに応じて、組織はさまざまなタイプのCloudflare Load Balancersを活用できます。次のセクションでは、展開モデルの主な違いを強調し、各タイプのロードバランサーを実装すべきタイミングを説明します。
図22は、Cloudflareがサポートするロードバランサーとエンドポイントのすべての可能な組み合わせを強調しています：
Cloudflareは、異なるユースケース、機能、およびプライバシー要件をサポートする3つの負荷分散展開モデルを提供しています。
以下に、下記で詳しく説明するDNS専用の負荷分散オプションを除いて、すべてのデプロイメントモデルはトラフィックをロードバランサーを通じてアンカーします。これは、リクエストや接続を作成するユーザーまたはクライアントが、リクエストや接続をサービスするために使用されるエンドポイントを認識しないことを意味します。エンドポイント情報は、ヘッダーを使用することで公開することも可能ですが、これらのアンカーされたデプロイメントモデルのデフォルトの動作ではありません。
以下では、4つの主要なデプロイメントモデル（およびその違い）について詳しく探ります。
まず、最も一般的なモデルは HTTP(S)ベースのレイヤー7プロキシ負荷バランサー です。これらのロードバランサーはCloudflareのエッジに存在し、公開にアクセス可能です。他の機能の中でも、このモデルはクライアントとエンドポイントの間でデータを双方向にやり取りできるオープン接続であるWebSocketsをサポートしています。
この同じレイヤー7セキュリティスタックはWAF、DDoS保護、ボット管理、ゼロトラスト、その他のサービスも提供するため、これらの公開ロードバランサーへのアクセスは、必要に応じて認証されたユーザーや権限のあるユーザーに制限できます。（詳細については、ロードバランサーの保護とセキュリティを参照してください。）
このレイヤー7スタックでは、負荷分散は組織の公開ウェブ資産のパフォーマンス、信頼性、到達性をさらに向上させることができます。これらのロードバランサーのエンドポイントは、パブリッククラウド、プライベートクラウド、オンプレミス、または同じロードバランサー内のそれらの組み合わせで展開される可能性があります。（Cloudflareのエッジネットワークにエンドポイントを接続する方法の詳細については、Cloudflareへのエンドポイント接続を参照してください。）
上記の図23に示すように、レイヤー7スタックの負荷分散コンポーネントは、リクエストがエンドポイントに向かう際に実行される最後のプロセスです。これは、パフォーマンスを向上させ、エンドポイントの負荷を軽減する大きなプラスの影響を与える可能性があります。
たとえば、キャッシングはリクエストがエンドポイントに到達するのを防ぎ、ロードバランサーに関与することなく応答することができます。また、WAF、DDoS保護、ボット管理は攻撃トラフィックを完全に排除できるため、正当なトラフィックのためのより多くの容量が残ります。
リクエストがロードバランサープロセスに到達すると、リクエストは常に選択されたエンドポイントに直接送信されます。これは、エンドポイントがCloudflareを通じてプロキシされていても、リクエストはエンドポイントに直接送信され、さらなる処理は受けません。
ロードバランサーがエンドポイントを選択した後のカスタマイズされた処理には、ロードバランサーのカスタムルールが適用されます。（これは、以下のロードバランサーセクションで詳しく説明されています。）
レイヤー7 HTTP(S)ロードバランサーに関する重要な注意事項:
- レイヤー7 HTTP(S)ロードバランサーは、公開およびプライベートエンドポイントの両方をサポートします
- レイヤー7 HTTP(S)ロードバランサーは、HTTP(S)およびWebSocketトラフィックのみをサポートします
- ゼロトラストポリシーはレイヤー7 HTTP(S)ロードバランサーに適用できます
CloudflareのDNS専用負荷バランサーは、プロキシされていない負荷バランサーです。これは、リソースの初期DNSリクエストのみがCloudflareエッジを通過し、実際のトラフィックは通過しないことを意味します。したがって、DNSリクエストがCloudflareのIPに解決され、その後、図7で見たようにレイヤー7スタックを通過するのではなく、CloudflareはDNS専用負荷バランサーのDNSリクエストを受け取り、すべての適切な負荷分散ポリシーを適用し、リクエストクライアントに直接接続するためのIPアドレスを返します。
クライアントとエンドポイント間のすべてのトラフィックがCloudflareのレイヤー7スタックを通過せずに直接移動するため、DNS専用負荷バランサーはあらゆるタイプのIPトラフィックをサポートできます。
Cloudflareはこれらのタイプの負荷バランサー接続をプロキシしないにもかかわらず、ヘルスモニターサービスはプール内のすべてのエンドポイントのヘルスを監視しています。エンドポイントのヘルスまたは可用性に基づいて、CloudflareのDNS専用負荷バランサーは、トラフィックが健康なエンドポイントに誘導されるように、DNS応答に適用可能なエンドポイントを追加または削除します。
DNS専用負荷バランサーがトラフィック誘導を介してエンドポイントプールを選択した後、1つまたは複数のIPアドレスがDNS応答に返される場合があります。
DNS応答内で1つまたは複数のIPアドレスを送信する決定は、選択されたエンドポイントプール内のエンドポイントに割り当てられた重みに基づいています：
- すべてのエンドポイントの重みが等しい場合、すべてのエンドポイントのIPアドレスがDNS応答に返されます。
- エンドポイントプール内で少なくとも1つのエンドポイントがユニークな重みを指定されている場合、DNS応答には単一のIPアドレスのみが返されます — エンドポイントプールで選択されたエンドポイント誘導方法に関係なく。
これにより、組織はアプリケーションがすべてのエンドポイントを認識し、ローカルフェイルオーバーを実行することを許可する柔軟性を持つか、Cloudflareがアプリケーションが利用するための単一のIPを提供することを許可できます。
図27は、エンドポイントプール内で定義された重みがDNS専用負荷バランサーの応答にどのように影響するかを示しています。
DNS専用負荷バランサーには、プロキシ負荷バランサーと比較していくつかの制限があります：
- 負荷バランサーは、クライアントに直接送信されるため、エンドポイントのIPアドレスを隠しません。
- 前のモデルで言及された組み込みのレイヤー7スタックサービスはありません。すなわち、DNS専用負荷バランサーにはキャッシング、WAF、DDoS保護、またはゼロトラストサポートは含まれていません。
- セッションアフィニティは
ip_cookieに制限されており、これはエンドポイントを決定論的に選択し、その後のすべてのリクエストに対してそのエンドポイントをクライアントIPアドレスにマッピングします。 - 最後に、DNS専用のために接続が負荷バランサーを通じてプロキシされないため、特定の誘導方法は機能しません。たとえば、LORSは、Cloudflareがエンドポイントへの接続を認識しないため機能しません。これらの誘導方法はランダム重み付け誘導に戻ります。
追加の誘導方法に関する詳細については、誘導セクションを参照してください。
DNS専用負荷バランサーを使用する際には、クライアントおよびリゾルバのDNSキャッシュに関する考慮事項もあります。キャッシュの寿命は、リクエストに応答するDNSサーバーによって決定されます。生存時間 (TTL) ↗値は、DNSリクエスト者に応答が有効である期間を示し、その後クライアントは新しいDNSリクエストを送信して宛先が変更されたかどうかを確認する必要があります。TTLは秒単位で計算されるため、たとえば、TTL値が3600の場合、TTLは1時間に相当します。ただし、標準のDNS TTL値は通常12時間または24時間、またはそれぞれ43200および86400です。
DNS専用負荷バランサーのTTLは30秒に設定されています。これにより、エンドポイントのヘルスが変化したり、エンドポイントが追加または削除されたりする際に、DNS専用負荷バランサーがより頻繁にクエリされ、可能な限り正確な利用可能なエンドポイントのリストを提供します。
DNS専用負荷バランサーに関する重要な注意事項:
- DNS専用負荷バランサーは公開エンドポイントのみをサポートします
- DNS専用負荷バランサーはトラフィックをプロキシしません — したがって、エンドポイントへの接続には関与しません
- DNS専用負荷バランサーは、IPアドレスまたはIPアドレスのセットでDNSリクエストにのみ応答します
Cloudflareは、Spectrum製品を介して別のインバウンドメソッドも提供しています。
レイヤー7スタックがHTTP(S)およびWebSocketsのみをサポートしているのに対し、SpectrumはTCPまたはUDPベースのプロトコルをサポートします。Spectrumをトラフィックのインバウンドとして使用するCloudflareロードバランサーは、TCPおよびUDPプロトコルが存在するレイヤー4で動作します。TCPまたはUDPをトランスポートに利用する任意のサービスは、SSH、FTP、NTP、SMTPなどを含むCloudflareロードバランサーとともにSpectrumを活用できます。
これが表すサービスとプロトコルの幅を考えると、提供される処理はレイヤー7 HTTP(S)スタックで提供されるものよりも一般的です。たとえば、Cloudflare Spectrumは、TLS/SSLオフロード、DDoS保護、IPアクセスリスト、Argoスマートルーティング、レイヤー4ロードバランサーとのセッション持続性などの機能をサポートしています。
Cloudflareレイヤー4 Spectrumロードバランサーは公開にアクセス可能です。これらの負荷分散リソースへのアクセスは、WAF構成の一部として定義できる_Spectrum構成_を使用して管理できますが、特定のIPアドレス、サブネット、国、またはボーダーゲートウェイプロトコル (BGP) ↗自律システム番号 (ASN)のために「許可」または「ブロック」アクションで作成されたルールに制限されます。
公開であるだけでなく、Spectrumロードバランサーは常にプロキシされます。前述のプロキシ設定（図24および25）は、負荷バランサーのインバウンドパスとしてSpectrumが構成されると無視されます。Spectrumベースのロードバランサーに向かうすべてのトラフィックは、常にCloudflareエッジを通過します。
Spectrumロードバランサーに関する重要な注意事項:
- Spectrumロードバランサーは、公開およびプライベートエンドポイントの両方をサポートします
- Spectrumロードバランサーは、最初にレイヤー7 HTTP(S)ロードバランサーとして作成されます。その後、ロードバランサーエンドポイントタイプでSpectrumアプリケーションが作成され、すでに作成されたロードバランサーが選択されます。
- Spectrumロードバランサーは、負荷バランサー構成のプロキシ設定に関係なく、常にプロキシされます
- インターネットからエンドポイントへのインバウンドポートをSpectrum経由で変更することはできません。すなわち、トラフィックがポート22でSpectrumに入る場合、それはエンドポイントのポート22に誘導されます
- Spectrumロードバランサーは、ハッシュエンドポイント誘導方法を使用してのみセッションアフィニティをサポートします
- Spectrumロードバランサーはカスタムルールをサポートしていません
| 負荷バランサーモデル | 公開 | プロキシ | OSIレイヤー | トラフィックタイプ |
|---|---|---|---|---|
| レイヤー7 HTTP(S) | X | X | 7 | HTTP(S) |
| DNS専用 | X | 7 (DNS) | IPベース | |
| スペクトラム | X | X | 4 | TCP/UDP |
ホスト名設定は、負荷バランサーの公開にアクセス可能なホスト名です。ホスト名は、負荷バランサーが作成されるゾーン内で作成する必要があります。
プロキシ設定は、Cloudflareが負荷バランサーのトラフィックをプロキシするか、単にクライアントが直接接続するためのエンドポイントを持つDNS応答を提供するかを決定します。これは、デプロイメントモデルセクションで詳しく説明されています。
セッションアフィニティ、またはセッション持続性、スティッキーセッションとも呼ばれるこの機能は、最初のリクエストまたは接続の後、クライアントが同じエンドポイントに接続され続けることを保証します。これは、エンドポイント間でセッションデータ — ウェブアプリケーションとのユーザーのインタラクションのコンテキスト — を共有しないアプリケーションにとって重要な機能です。たとえば、クライアントセッションの途中で新しいエンドポイントが選択され、セッションに関する情報（例：ユーザーのショッピングカートの内容）が失われた場合、そのアプリケーションのユーザーエクスペリエンスは悪化します。
Cloudflareは、セッションアフィニティを有効にするための3つの方法を提供しています：
- Cloudflareクッキーのみによるセッションアフィニティ (cookie): プロキシされたロードバランサーへの最初のリクエスト時に、リクエストが転送されるエンドポイントの情報をエンコードしたクッキーが生成されます。その後のリクエスト（同じクライアントから同じロードバランサーへの）は、クッキーがエンコードしているエンドポイントに送信されます。a) クッキーの有効期間中、b) エンドポイントが正常である限り、リクエストはそのエンドポイントに送信されます。クッキーが期限切れになったり、エンドポイントが正常でない場合は、新しいエンドポイントが計算されて使用されます。
- CloudflareクッキーとクライアントIPフォールバック (ip_cookie): これは上記のクッキー方式と似ていますが、クッキーはクライアントのIPアドレスに基づいて生成されます。この場合、同じIPアドレスからのリクエストは常に同じエンドポイントに送信されます。a) クッキーの有効期間中、b) エンドポイントが正常である限り、リクエストはそのエンドポイントに送信されます。クッキーが期限切れになったり、エンドポイントが正常でない場合は、新しいエンドポイントが計算されて使用されます。
- HTTPヘッダーによるセッションアフィニティ (header): プロキシされたロードバランサーへの最初のリクエスト時に、設定されたHTTPヘッダーに基づいてセッションキーが生成されます。同じヘッダーを持つロードバランサーへのその後のリクエストは、a) セッションの有効期間中、b) エンドポイントが正常である限り、同じエンドポイントに送信されます。セッションがセッションアフィニティの有効期限（TTL）秒の間アイドル状態であったり、エンドポイントが正常でない場合は、新しいエンドポイントが計算されて使用されます。
これらの3つのセッションアフィニティオプションは、レイヤー7 HTTP(S)ロードバランサーにのみ適用されます。セッションアフィニティにはTTLが必要で、これはロードバランサーが特定のエンドポイントに対してその後のリクエストをルーティングする期間を決定します。デフォルトのTTLは82,800秒（23時間）ですが、1,800秒（30分）から604,800秒（7日間）まで設定できます。
クッキーに基づくセッションアフィニティでは、期限切れタイマーはリセットされず、セッションの開始からカウントダウンが行われます — セッションがアイドル状態であろうとアクティブであろうと関係ありません。HTTPヘッダーに基づくセッションアフィニティは、セッション内にアクティビティがあるたびに期限切れタイマーをリセットします。
エンドポイントドレインは、セッションアフィニティのサブ機能です。これは、エンドポイントからセッションが優雅に期限切れになることを可能にし、同じエンドポイントで新しいセッションが作成されることを許可しません。エンドポイントドレインはメンテナンスに役立ち、管理者がすべてのアクティブなセッションをエンドポイントから削除するためにユーザーセッションを恣意的または突然に切断する必要がありません。
エンドポイントドレインTTLは、エンドポイントが強制的に終了される前にアクティブなセッションを維持できる時間の量です。エンドポイントドレインTTLが設定されると、エンドポイントプール内のエンドポイント（または複数のエンドポイント）を無効にすることによってエンドポイントドレインが開始されます。以下の画像に示すように、管理者はロードバランサーUIからエンドポイントドレイン操作の残り時間を監視できます。
エンドポイントドレインはセッションアフィニティにのみ適用されます。なぜなら、セッションアフィニティがない場合、後続のリクエストや接続が同じエンドポイントにルーティングされることは保証されないからです。したがって、エンドポイントを無効にしてもユーザーエクスペリエンスには影響しません。
ゼロダウンタイムフェイルオーバーは、一時的なネットワークの問題が発生している間、エンドポイントプール内のエンドポイントにトラフィックを自動的に送信します。
Zero-downtime failover will trigger a single retry only if there is another healthy endpoint in the pool and a 521, 522, 523, 525 or 526 error code is occurring. No other error codes will trigger a zero-downtime failover operation.
これらのレスポンスコードはエンドポイントから返されるのではなく、上流のCloudflareサービスから組織のエンドポイントへのリクエストから返されます。ゼロダウンタイムフェイルオーバーには3つの動作モードがあります：
- なし (オフ): フェイルオーバーは行われず、ユーザーはエラーメッセージや悪いユーザーエクスペリエンスを受け取る可能性があります。
- 一時的: トラフィックは他のエンドポイントに送信され、エンドポイントが再び利用可能になるまで続きます。
- スティッキー: セッションアフィニティクッキーが更新され、その後のリクエストは必要に応じて新しいエンドポイントに送信されます。これは、セッションアフィニティがHTTPヘッダーモードを使用している場合にはサポートされていません。
アダプティブルーティング - プール間のフェイルオーバー は、ゼロダウンタイムフェイルオーバーの機能を拡張し、同じプール内のエンドポイントだけでなく、別のエンドポイントプール内のエンドポイントにもフェイルオーバーを拡張できるようにします。
エンドポイントプールは優先順位の順に構成され、必要に応じて再配置できます。この優先順位は、オフ - フェイルオーバートラフィックスティアリング を使用する場合にのみ考慮されます。それ以外の場合、エンドポイントプールはスティアリングメソッドセクションに記載された基準に基づいて選択されます。
ロードバランサーに割り当てられたエンドポイントプールは、ロードバランサーを介してリクエストや接続を処理できる可能性のあるエンドポイントの全コレクションを表します。エンドポイントプールには、通常、すべて同じ機能を持ち、データセンターまたは地理的地域にあるエンドポイントが含まれます。プール内のすべてのエンドポイントは、エンドポイントプールに向けられたリクエストを処理できる必要があります。エンドポイントプールに関する詳細については、エンドポイントプールセクションを参照してください。
フォールバックプールは、最後の手段のプールです。すべてのエンドポイントプールが利用できないか、正常でない場合、フォールバックプールがすべてのリクエストと接続に使用されます。トラフィックをロードバランサー内でスティアリングする際には、ヘルスモニターデータが常に考慮されますが、フォールバックプールはこのデータに依存せず、影響を受けません。
ヘルスモニターは通常、エンドポイントプールの一部として構成されます。ヘルスモニターは、ロードバランサーの構成の一部として追加、変更、または削除できます。詳細については、ヘルスモニターセクションを参照してください。
トラフィックスティアリングは、エンドポイントプール間のスティアリング方法です。どのトラフィックスティアリングメソッドを選択するかを理解するためのヘルプについては、スティアリングタイプとメソッドセクションを参照してください。
カスタムルールは、ロードバランサーが意思決定プロセスを完了する前に、リクエストや接続に対してアクションを実行することをユーザーに許可します。カスタムルールは、リクエストや接続内の特定のフィールドに一致する式で構成されます。トラフィックに一致するように式が作成されると、式に一致するリクエストや接続に対してアクションが割り当てられます。
カスタムルールは、リクエストや接続がエンドポイントに送信される前に、ロードバランサーからのスティアリングと出力をカスタマイズするための強力なツールです。たとえば、HTTPメソッド（例：GET、PUT、POST）を一致させて、POSTメッセージがクライアントからの情報を受信するために専用のエンドポイントプールに送信されるようにすることができます。
あるいは、特定のURLパスにリクエストが送信されることに基づいてセッションアフィニティTTLをリセットし、クライアントがトランザクションを完了するのに十分な時間を確保することもできます。
一致させることができるフィールドのすべての潜在的な組み合わせや、実行できるアクションを文書化することは不可能です。ただし、以下のリソースは、現在利用可能なすべてのフィールドとアクションを説明しています：
ロードバランサーのデフォルトの動作が上記の文書にカバーされていない場合、カスタムルールがユニークなユースケース要件を満たすのに役立つ可能性があります。
すべてのCloudflareロードバランサー展開モデルには、内在する保護が備わっています。以下のセクションでは、Cloudflareが提供するデフォルトのセキュリティと、Cloudflareロードバランサーの前に追加できるオプションの保護を簡単に説明します：
- プロキシされたHTTPレイヤー7ロードバランサー（パブリック）
- 攻撃から保護するためのDDoS保護
- 既知の脆弱性やエクスプロイトをブロックするためのCloudflare管理ルールセットおよびOWASPルールセットを備えたWAF
- DNS専用ロードバランサー（パブリック）
- DNS専用ロードバランサーが常に利用可能であることを保証するためのDNS DDoS保護 ↗
- Spectrumレイヤー4ロードバランサー（パブリック）
- レイヤー4攻撃から保護するためのDDoS保護
Cloudflareは、ウェブサイト、API、HTTP(S)ベースのサービスなど、あらゆるサービスを保護するためにロードバランシングと組み合わせて使用できる追加のセキュリティレイヤーを提供しています：
- プロキシされたHTTPレイヤー7ロードバランサー（パブリック）
- DNS専用ロードバランサー（パブリック）
- DNSレコードの真正性を保証するためのDNSSEC
- Spectrumレイヤー4ロードバランサー（パブリック）
- 公共のレイヤー4ロードバランサーへのアクセスを制御するためのIPアクセスルール
CloudflareのグローバルAnycastネットワークは、ロードバランシングのための強力なプラットフォームです。Cloudflareのロードバランシング構成は、世界中の310以上の都市でアクセス可能で、事実上無限の容量と帯域幅を持っています。
これらのロードバランサーは、インターネットに接続された人口の約95%に対して約50ms以内で動作し、CloudflareロードバランサーがGTMとLTMの両方のロードバランシングを実行できるエンドポイントを含んでいます。Cloudflareは、これら2つの異なるロードバランシングの概念を単一のロードバランサーに統合しました。これにより、組織は地理的に関連するデータセンターにトラフィックをスティアリングし、リクエストを処理する適切なエンドポイントを選択できるようになります。
Cloudflare Tunnelを使用すると、エンドポイントはプライベートネットワーク内に配置され、Cloudflareロードバランサーによって利用されることができます。Cloudflareは、HTTP(S)およびWebSocketの両方をサポートする公共のレイヤー7ロードバランサーと、任意のTCPまたはUDPトラフィックをスティアリングできる公共のレイヤー4ロードバランサーを提供しています。これにより、Cloudflareは、場所、ユースケース、既存の構成に関係なく、すべての組織やユーザーにロードバランシングサービスを提供できるようになります。