CloudflareのサーバーはもうIPを所有していません。では、どのようにインターネットに接続しているのでしょうか？

Cloudflareの技術の多くはドキュメント化されています。たとえば、アイボール（クライアント）とサーバー間のトラフィックをどのように処理するかは、以下のようにこのブログで何度も取り上げてきました。「エニーキャスト入門書」（2011）、「ロードバランサーを使用しない負荷分散」（2013）、「Path MTUディスカバリーの実践」（2015）、「Cloudflareのエッジロードバランサー」（2020）、「BSDソケットAPIの修正方法について」 (2022)。

しかし、ネットワーク設定の第二部分、つまりサーバーがどのようにインターネットからコンテンツを取得するかについては、あまり触れてきませんでした。本記事ではその点について書いていきたいと思います。インターネットからデータを取得するために使用されるCloudflare IPアドレスをいかに管理するか、当社の送信ネットワーク設計はどのように進化してきたのか、利用可能なIPスペースを最大限に活用するためにどのように最適化したのかについてご説明します。

準備はよろしいですか？お伝えしたいことがたくさんあるんです。

Cloudflareの各サーバーでは、さまざまな種類のネットワークトラフィックを処理していますが、大きく分けて2つのカテゴリがあります。

• _インターネットからのトラフィック_ーアイボールから当社サーバーへのインバウンド接続。本記事ではこれらを「イングレス接続」と呼びます。

• _Cloudflareソーストラフィック_ー当社のサーバーがインターネット上の他のホストに対して開始する発信接続。これを簡潔に「エグレス接続」と呼びます。

これまでエグレスの部分についてはあまり取り上げてきませんでしたが、当社のオペレーションにとってかなり重要な存在です。サーバーはジョブを完了するために発信接続を開始しなければなりません。たとえば次のように。

• 当社の CDN 製品ではコンテンツがキャッシュされる前に、オリジンサーバーからフェッチされます。「Pingora、Cloudflareをインターネットに接続するプロキシ」（2022）、Argoおよび階層型キャッシュを参照してください。

• Spectrum製品の場合、各イングレスTCP接続は、1つのエグレス接続になります。

• Workerは複数のサブリクエストを実行して HTTP レスポンスを構築することがよくあります。それらのいくつかは、インターネットの 1 つの出口接続に対してサーバーにクエリーを送信している可能性があります。

• また、当社ではWARPやCloudflare Gatewayなど、クライアント向けのフォワードプロキシ製品も運用しています。これらのプロキシはインターネット宛てのアイボール接続を処理します。当社のサーバーはユーザーに代わってインターネットへの接続を確立する必要があります。

などです。

当社のイングレスネットワークアーキテクチャは、エグレスネットワークアーキテクチャとはまったく異なるものです。イングレスではインターネットからの接続は、当社のエニーキャストIP範囲によってのみ処理されます。エニーキャストは各データセンターが「アナウンス」し、同じ IP 範囲を処理できるテクノロジーです。多くの宛先が考えられる中、インターネットはどのようにパケットの経路を決めているのでしょうか？アイボールのパケットはインターネットBGPメトリックに基づいて最も近いデータセンターに向かってルーティングされますが、地理的に最も近いデータセンターであることが多いです。通常、BGPルートはあまり変更されず、各アイボールIPは単一のデータセンターにルーティングされると予想されます。

ただし、エニーキャストはイングレス方向ではうまく機能しますが、エグレスでは動作しません。エニーキャストIPからの発信接続の確立は機能しないのです。応答パケットはどうでしょうか。送信元のデータセンターではなく、送信者に地理的に最も近いデータセンターにルーティングされる可能性があります。

このため、最近までは単純かつ従来の方法で発信接続を確立していました。それは各サーバーに独自のユニキャストIPアドレスを割り当てていたのです。「ユニキャストIP」とはそのアドレスを使用するサーバーが世界に1つしかないことを意味します。リターンパケットは正常に動作し、ユニキャストIPで識別される正しいサーバーに正確に返されます。

当初、Cloudflareをソースとする接続は、ほとんどがインターネット上のオリジンサーバーに向かうHTTPフェッチでした。当社の製品ラインが成長するにつれ、トラフィックの種類も増えていきました。最も顕著な例は、当社のWARPアプリです。WARPの場合、当社のサーバーはフォワードプロキシを操作し、エンドユーザーデバイスから送信されたトラフィックを処理します。これはCDN製品と同じ程度の仲介なしで行われ、問題を引き起こします。インターネット上のサードパーティサーバー（オリジンサーバーなど）は、Cloudflareサービスからの接続と当社のWARPユーザーからの接続を区別できなければならないのです。このようなトラフィックのセグメンテーションは、従来、トラフィックタイプごとに異なるIPレンジを使用することで行われてきました（ただし、最近ではAuthenticated Origin Pullsなどのより堅牢な技術を導入しています）。

信頼できるトラフィックプールと信頼できないトラフィックプールの区別の問題を回避するために、各サーバーに信頼できないWARP IPアドレスを追加しました。

必要なタグは信頼できるタグと信頼できないタグだけではないことがすぐに明らかになりました。WARPサービスには国別タグも必要です。たとえば英国を拠点とするWARPユーザーならば、bbc.comのウェブサイトがきちんと表示されていればそれでいいのです。しかし、BBCのサービスはその多くが英国国内だけに限定されています。

これはパブリックIPアドレスを国にマッピングするデータベースを使用し、英国のもののみを許可する_ジオフェンシング_によって行われます。ジオフェンシングは今日のインターネットで広く普及しています。ジオフェンシングの問題を回避するために、WARPユーザーのロケーションに応じて、適切な国のタグが付いた特定のイグジットアドレスを選択する必要があります。インターネット上の他の多くの当事者と同様に、当社も国コードのタグを付けてジオフィードとして公開しています（このように）。公開されたジオフィードは単なるデータでし。IP がsay UKとしてタグ付けされているという事実は、それが英国から提供されていることを意味するのではなく、オペレーターが英国に地理的に配置されることを望んでいることを意味します. インターネット上の多くのものと同様に、それは信頼に基づいています。

この時点で3つの独立した地名タグがあります。

• WARPユーザーの国別タグ - IPを接続するアイボール

• アイボールが接続されているデータセンターの場所

• エグレスIPの国別タグ

最高のサービスのために、国タグがアイボールIPの国と一致するように、エグレスIPを選択します。しかし、特定の国でタグ付けされたIPからの送信は困難です。当社のデータセンターは世界中のユーザーにサービスを提供しています。注意：エニーキャストであるため、イングレスのルーティングを直接制御することはできません。インターネットの地理はからなずしも物理的な地理と一致するとは限りません。たとえば、ロンドンのデータセンターには、英国国内だけでなく、アイルランドやサウジアラビアのユーザーからもトラフィックが届いています。その結果、ロンドンにある当社のサーバーは、多くの国に関連する多くのWARPのエグレスアドレスを必要とします。

これはどのような結果につながるでしょうか。問題空間が爆発的に広がります。各サーバーに1つか2つのエグレスIPアドレスが必要だったのが、今ではそれが数十個になっています。IPv4アドレスは安価ではありません。この設計では1台のサーバーに多くのアドレスが必要となり、数千台のサーバーを運用することになります。実に高価なアーキテクチャです。

要約すると、エニーキャストイングレスでは、ユーザーがどのデータセンターにルーティングされるかを制御できません。したがって、当社の各データセンターは、考えられるあらゆるタグを持つアドレスから外に出ることができなければなりません。また、データセンター内では接続先のサーバーを制御することはできません。タグ、データセンター、データセンター内のサーバーが数多く存在する可能性があります。

イングレスアーキテクチャに問題があるのでしょうか。特定のアイボールがDNSを使用して特定のデータセンターやサーバーにルーティングされる従来のネットワーク設計を使用する方がよいでしょうか。

それも選択肢の一つですが、私たちはそれとは逆の方法を取ることにしました。イングレスでのエニーキャストがお気に入りなのです。それは以下のようにさまざまなメリットがあるからです。

• パフォーマンス：エニーキャストは定義上、アイボールは最も近い（BGPメトリックによる）データセンターにルーティングされます。これは通常、特定のユーザーにとって最速のデータセンターになります。

• 自動フェイルオーバー：仮に当社のデータセンターの1つが利用できなくなった場合、トラフィックは即座に、次に最適な場所へ自動的に再ルーティングされます。

• DDoS耐障害性：DoS攻撃やトラフィックスパイクが発生した場合、負荷は多数のデータセンター間で自動的に分散され、影響が大幅に軽減されます。

• 統一されたソフトウェア：すべてのデータセンターと、データセンター内におけるすべてのサーバーの機能は同じです。世界中のすべてのサーバーで同じソフトウェアスタックを使用しています。各マシンはあらゆる製品に対してあらゆるアクションを実行できます。これにより、簡単に行えるデバッグと優れたスケーラビリティが実現します。

以上のような理由から、イングレスのエニーキャストを維持したいのです。私たちは送信アドレスのカーディナリティの問題を別の方法で解決することにしました。

私たちが運用する何千台ものサーバーのうち、どのサーバーも、可能な限りのタグを持つエグレスIPを使用できなければなりません。この解決策を説明するには、まず2つの極端なデザインを示すのが一番わかりやすいでしょう。

各サーバーは必要なIPをすべて所有：各サーバーは必要なタグを持つすべての専用エグレスIPを所有します。

あるサーバーが必要なIPを所有：特定のタグを持つ専用のエグレスIPが一箇所に存在し、他のサーバーはそのIPにトラフィックを転送します。

いずれの選択肢にも長所と短所がそれぞれあります。

各サーバー上に専用IPを設定

Specialized IP on every server	Specialized IP on one server
Super expensive $$$, every server needs many IP addresses.	Cheap $, only one specialized IP needed for a tag.
Egress always local - fast	Egress almost always forwarded - slow
Excellent reliability - every server is independent	Poor reliability - introduced chokepoints

1つのサーバーに専用IPを設定

とっても高額、サーバーごとに多数のIPアドレスが必要。

安い、タグに必要な専用IPは1つだけ。

エグレスは常にローカル - 高速

Specialized IP on every server	Specialized IP per data center	Specialized IP on one server
Super expensive $$$	Reasonably priced $$	Cheap $
Egress always local - fast	Egress always local - fast	Egress almost always forwarded - slow
Excellent reliability - every server is independent	Excellent reliability - every server is independent	Poor reliability - many choke points

エグレスはほぼ常に転送 - 遅い

信頼性が高い - 各サーバーが独立

信頼性が低い - チョークポイントの導入

当社ではこの問題に懸命に取り組んできました。率直に言って、すべてのCloudflareサーバーで必要なIPをローカルに利用できるようにするという当初の極端な選択肢も、まったく不可能というわけではありません。これがIPv6で実現できたおおよその内容です。IPv6において、必要な大規模なIP空間へのアクセスは問題にはなりません。

しかし、IPv4ではどちらの選択肢も許容されません。1つ目の場合、高速で信頼性の高いエグレスが実現しますが、多大なコストが必要となります。必要なIPv4アドレスが高価なのです。2つ目の選択肢は、できる限り小さなIP空間を使うので、安価ですが、性能と信頼性が低下します。

当社が考案した解決策はその両極端の間にある妥協案です。大まかなイメージとしては、割り当て単位を変更したのです。各サーバーに1つの/32 IPv4アドレスを割り当てるのではなく、データセンターごとに/32 IPを割り当て、それを物理サーバーで共有する方法を考案したのです。

各サーバー上に専用IPを設定

データセンターごとに専用IP

198.51.100.1 - forward to LHR
198.51.100.2 - forward to CDG
198.51.100.3 - forward to MAN
...

1つのサーバーに専用IPを設定

とっても高額

お手頃価格

安い

エグレスは常にローカル - 高速

エグレスは常にローカル - 高速

エグレスはほぼ常に転送 - 遅い

信頼性が高い - 各サーバーが独立

信頼性が高い - 各サーバーが独立

信頼性が低い - チョークポイントが多い

サーバー間でIPを共有するという考え方は新しいものではありません。ルーター上のSource-NATで実現してきた方法です。残念なことに、必要なエグレスIPの数が非常に多く、また運用のサイズも大きいため、ルーターレベルでステートフルファイアウォールまたはNATに依存できません。また、当社は共有状態を好まないので、NATの分散インストールは避けたいところです。

代わりに選択したのは、ポート範囲によるサーバー間におけるエグレスIPの分割です。特定のエグレスIP に対して、各サーバーは使用可能な送信元ポートのごく一部（ポートスライス）を所有します。

インターネットからリターンパケットが届くと、それを正しいマシンに戻すルーティングをしなければなりません。このタスクのために、L4 XDPベースのロードバランサーである "Unimog "をカスタマイズしました。当社のL4 XDPベースのロードバランサー（「 Unimog, Cloudflareのロードバランサー」（2020）は、これにより完璧に動作しています。

たとえば 2,048 ポートのポートスライスを使用すると、31 台のサーバー間で 1 つの IP を共有できます。ただし、ポートが不足する可能性は常にあります。これに対処するために、エグレスポートを効率的に再利用できるよう工夫を重ねてきました。「 ポート不足を解消する方法」（2022）、「IPv4アドレスを共有する方法」（2022）、および当社の Cloudflare.TV セグメントを参考にご覧ください。

これが実にうまくいきました。各サーバーは所有するIPアドレスとポートスライスを認識しています。インバウンドルーティングの場合、Unimogはポートを検査し、パケットを適切なマシンにディスパッチします。

しかし、お話はまだ続きます。単一の/32アドレスをデータセンターにルーティングする方法についての説明がまだ終わっていません。従来、パブリックインターネットにおいて/24または256の IPアドレスの粒度でサブネットをルーティングすることしかできませんでした。当社ではこれがIPスペースの大きな浪費につながっていたのです。

この問題を解決し、IPスペースの利用率を向上させるため、エグレス範囲を…エニーキャスト のようにデプロイしたのです。この状態でUnimogをカスタマイズし、パケットをバックボーンネットワークから正しいデータセンターへ転送するようにしました。Unimogは次のようにデータベースを管理しています。

この設計では、リターンパケットがどのデータセンターに送信されるかは問題ではありません。Unimogがいつでもを修正し、データを適切な場所に転送してくれます。基本的にBGP レイヤーではエニーキャストを使用していますが、設計上、IPはセマンティックとしてデータセンターを識別し、IPとポート範囲は特定のマシンを識別します。その動作はほぼユニキャストと変わりません。

私たちはこのテクノロジースタックを「ソフトユニキャスト」と呼んでいます。なんだか魔法のようですね。BGPレイヤーのエニーキャスト上にソフトウェアでユニキャストを行ったようなものです。

このセットアップにより、大きなメリットを得ることができます。

• 多数のサーバ間で/32のエグレスIPを共有することができる。

• 単一のサブネットを多数のデータセンターに分散でき、その場で簡単に変更できます。これにより、エグレスIPv4範囲を完全に使用できるようになる。

• 同様のIPアドレスをグループ化することができる。たとえば、 UKタグでタグ付けされたすべての IPアドレスは、1 つの連続した範囲を形成する場合がある。これにより、公開されるジオフィードのサイズが縮小される。

• お客様のIPのように、新しいエグレスIP範囲をオンボードするのが簡単。これはCloudflare Zero Trustなど、当社の一部の製品に便利。

しかも、性能と信頼性を損なわず、合理的なコストで実現。

• 通常、ユーザーは最も近いデータセンターから直接のエグレスが可能で、最善のパフォーマンスに。

• 実際のニーズに応じて、IPアドレスの割り当てや解放ができる。このことから、IPコスト管理に柔軟性があり、前もって余分な費用をかける必要がなくなる。

• 異なる場所で複数のエグレスIPアドレスを運用しているので、 信頼性が損なわれることがない。

ソフトユニキャストによって大きな効率を得ることができるようになった一方で、いくつかの問題に直面しました。「このIPは物理的にどこに所在しているのですか?」という質問を受けることがあります。残念ながらその答えはありません。物理的には、当社のエグレスIPはどこにも存在しないのです。BGP の観点からすると、送信範囲はエニーキャストであるため、どこにでも存在すると言えます。論理的には各アドレスは1つのデータセンターで同時に使用されますが、オンデマンドで移動できます。

もう一つの問題例として、サードパーティのCDNで発生したある問題をご紹介します。先ほどもお伝えしたように、当社のパイプラインには3つの国別タグがあります。

• アイボールが接続しているIPの国別タグ。

• 当社のデータセンターの所在地。

• エグレス接続に選んだIPアドレスの国別タグ。

当社のエグレスアドレスが「UK」とタグ付けされていても、実際に英国で使用されているとは限りません。LHRデータセンターのメンテナンスのために、英国のタグ付けをされたWARPユーザーが、パリにルーティングされたケースがありました。ある有名なCDNは、エグレスIPの逆ルックアップを実行し、「UK」としてタグ付けされていることを発見し、ユーザーをロンドンのCDNサーバーに誘導しました。通常であればこれで問題はないのですが…実はその時はパリからのエグレスだったのです。このユーザーは、パケットを英国の自宅からパリにルーティングし、英国に戻すことになりました。これはパフォーマンスを低下させます。

現在はエグレス側のデータセンターでDNS リクエストを実行することで、この問題に対処しています。DNSにはユーザーが意図するジオロケーションではなく、データセンターのロケーションでタグ付けされたIPアドレスを使用しています。この方法で概ね問題は解決しますが、それでも残念ながら例外はいくつかあります。

2021年にAddressing Agilityと共同で行った実験では、イングレスへの対応を刷新する機会は十分にあることが証明されました。ソフトユニキャストは送信側で優れた柔軟性と密度を実現できることを示しています。

新製品が出るたびに、トラフィックの信頼性、製品カテゴリー、ジオロケーションなど、エグレスに必要なタグの数は増えていきます。IPv4アドレスの使用可能なプールが縮小するにつれて、この分野での技術革新が進むことは間違いないでしょう。ソフトユニキャストは当社のソリューションですが、これが最新の開発のままであり続けることはありえません。

それでも今のところ、従来のユニキャストから脱却しつつあるように思います。当社のエグレスIPはもう定まった場所には存在していませんし、最近では実際のユニキャストIPを所有していないサーバーもあります。