数年前、より高速で効率の良いインターネットの実現に向けて、Argoをリリースしました。Argoはネットワーク状態を監視し、オリジンサーバーリクエストのためのインターネット上の最適なルートを検出し、途中で輻輳を回避します。
Tiered Cacheは、オリジンからアセットを要求するデータセンターの数を減らすArgoの一機能です。Tiered Cacheを有効にすると、南アフリカのリクエストは北米のオリジンに直接送信する代わりに、近くにある大規模なデータセンターを調べて、リクエストされたデータが最初にそこでキャッシュされているかどうかを確認します。Tiered Cacheで使用されるデータセンターの数と場所は、トポロジーと呼ばれる構成によって制御されます。デフォルトでは、キャッシュヒット率と遅延のバランスを取る汎用トポロジーをすべての顧客に使用していますが、これはほとんどのユーザーに適するものです。
今回は、Smart Topologyをご紹介します。これは、Argoの内部インフラストラクチャ上に構築することによってオリジンにリクエストを行うための最適なデータセンターを特定することで、キャッシュヒット率を最大化するものです。
標準的なCache
アセットをキャッシュする標準的な方法は、各データセンターをオリジンサーバーのリバースプロキシにすることです。このスキームでは、データセンターでミスが起きると、アセットのオリジンへリクエストが送られます。1つのアセットに対するオリジンへのリクエストは、データセンターの数だけ何回でも行うことができます。
データセンターでキャッシュミスが発生すると、アセットが他のデータセンターにキャッシュされている場合でも、リクエストがオリジンサーバーに送信されます。これは、データセンター同士が互いの存在にまったく気付かないためです。
理論的には、キャッシュミスを最小限に抑えるために、アセットに対するリクエストをすべてのデータセンターに送信する必要があります。しかし、すべてのリクエストを全データセンターに送信することは現実的ではありません。
リクエストが行われる前にアセットを最も近いキャッシュに移動させると、キャッシュヒットの遅延が最小値になりますが、この種の予測は一般的には不可能です。代わりに、優れたヒューリスティックでは、最初のキャッシュミス後にアセットを最も近いキャッシュに移動させます。
ただし、アセットをどこかでコピーされているはずなのですが、各データセンターにクエリーを実行しなければ、ネットワーク内のどこにそれがあるかを知ることはできません。
各データセンターへのクエリーを回避するには、最初のキャッシュミス後にアセットのコピーを既知の場所に保存し、他のデータセンターで使用できるようにする必要があります。これこそがまさにTiered Cacheが行うことです。
Tiered Cache
Tiered Cacheは、あるデータセンターがオリジンにリクエストを行う前に、他のデータセンターがキャッシュとして機能できるようにしておくことで、キャッシュヒット率を向上させます。Tiered Cacheでは、あるデータセンターは他のデータセンターのオリジンへのリバースプロキシになります。
プロキシされたデータセンターが同じアセットをリクエストした場合、そのアセットはプロキシするデータセンターにすでにキャッシュされ、オリジンからではなく、そこから取得できます。オリジンへのリクエストは全体的に少なくなるのです。
カスタムトポロジー
トポロジーは、どのデータセンターが他のデータセンターのためのプロキシとして機能する必要があるかをTiered Cacheで示します。
お客様にとって、最適なトポロジーを考案することは、最適化と継続的なメンテナンスを必要とする課題です。最適なトポロジーは、お客様側が個人的に保持する情報と、Cloudflareのみが保持するその他の情報に基づき構成されるものです。
たとえば、遅延とキャッシュヒット率の望ましいバランスを把握することは、お客様だけが持つ情報ですが、インターネットを最大限に活用する方法は当社が把握していることです。Enterpriseのお客様は通常、専用のインフラストラクチャチームが、ソリューションエンジニアと協力して、Tired Cacheトポロジーを手動で最適化および保守します。
すべてのお客様がトポロジーをパーソナライズしたいとは限りません。このため、汎用トポロジーがあるのです。
汎用トポロジー
汎用トポロジーは、ロケーションに関係なく、任意のオリジンに対して遅延を少なくしキャッシュ効率をよくするために設計されています。キャッシュ効率と遅延という2つの制約の間でバランスを取ります。
汎用トポロジーには、キャッシュミスにつながるリクエストがオリジンに移動する前に非常に長い回り道をしなくて済むように、世界中に分散される複数のプロキシデータセンターがあります。プロキシデータセンターの数とキャッシュヒット率のバランスがとれています。これは、プロキシするデータセンターが互いに気付くためです。
プロキシデータセンターがオフラインになると、プロキシされたデータセンターはフォールバックを使用するか（フォールバックがオンラインの場合）、Tiered Cacheが無効になった状態に戻ります。
一般的な使用に最適なバランスを実現するために、汎用トポロジーでは、小さなデータセンターが同じ地域領域内の大きなデータセンターによってプロキシされるように指示します。
Smart Topology
Smart Topologyでは、オリジンが1つの場所にあると仮定し、顧客がダッシュボードでスイッチをオンにするだけで、自動的に最適な状態になるように設定されます。実際にこれを行うためには、Cloudflareは、お客様がCloudflareにオリジンの場所を伝えることなく、オリジンへの遅延が最も少ないデータセンターを特定できる必要があります。
遅延の判定方法
オリジンの遅延が最も少ないデータセンターを特定するにはいくつかの方法があります。
IP ジオロケーション
遅延の近似値として物理距離を使用できますが、Smart Topologyはいくつかの理由でこの方法で構築されませんでした。まず、最高の商用IP地理データベースでさえ、必要なカバー率と精度が備わっていません。第二に、完璧な精度であっても、物理的な距離がインターネット遅延の近似値として使えるかどうかは疑わしいところです。
プローブ
IP アドレスへの遅延は、そのアドレスをプローブすることによって正確に判断できます。プローブは、TCPハンドシェイクを実行するのに必要な時間になります。各データセンターはオリジンをプローブし、遅延を直接測定し、最小値を検出することができます。エニーキャストと TCPターミネーション（終端）を含むエッジケースを除き、IP アドレスへの遅延は、その IP アドレスの背後にあるオリジンサーバーへの遅延と同じであると仮定できます。
トポロジー選択アルゴリズム
トポロジー選択アルゴリズムの目的は、キャッシュミスと遅延を最小限に抑えることです。トポロジーは、キャッシュヒット率を最大化するために、単一のプロキシデータセンターを選択します。プロキシデータセンターはオリジンに近いものが選択されるため、プロキシされたデータセンターでのキャッシュミスによる遅延は、Tiered Cacheがオフの場合に比べると大幅に悪くなることはありません。
選択は最終的には安定するはずです。安定性は重要です。選択肢が変わるたびに、プロキシされたデータセンターでのキャッシュミスが新しいプロキシデータセンターでのキャッシュミスを引き起こす可能性が高くなるためです。容量は重要です。データセンターがオフラインになると、大量のキャッシュミスが発生する可能性があるためです。オリジンへの遅延を最小化することは、ネットワークを効率的に使用するために重要です。
データセンター選択アルゴリズムは、各オリジンで最速のデータセンターのリーダーボード（順位表）のようなものです。データが収集されると、より高速なデータセンターは特定のオリジンのリーダーボードから他を排除することができます。この比較は、24 時間の遅延の中央値に基づいて行われ、1 時間ごとに行われます。十分な規模と見なされるデータセンターのサブセットのみが対象になります。
最終的には、データセンターをプロキシする選択肢が安定します。時間が経つにつれて、データセンターは各オリジンごとに競合するレコードを生成し、リーダーボードの競争力の低い記録が必要に応じて置き換えられていきます。したがって、リーダーボード上のオリジンの遅延は単調に減少するだけです。現実世界には常に物理的な限界があるため、最終的に理想的なデータセンターは高すぎる記録を打ち立てることになります。
またリーダーボードには、最も遅延が少ないデータセンターと2 番目に遅延が少ないデータセンターの両方が含まれています。遅延が2 番目に少ないデータセンターは、優先データセンターがメンテナンスのためにオフラインになった場合のフォールバックとして機能します。
エニーキャスト ネットワーク
オリジンIP アドレスへの遅延を測定し、それがオリジンサーバーへの遅延を表していることが前提ですが、これが成立しないケースも存在します。サービスの提供にエニーキャストテクノロジーを使用しているクラウドプロバイダーは、Cloudflareの他には2、3社しかいません。エニーキャストでは、インターネットに接続されている場所に関係なく、複数の機器がIP アドレスを共有でき、インターネットは通常、そのアドレス宛てのパケットを最も近い機器にルーティングします。エニーキャストネットワークを使用してオリジンサーバーをプロキシする場合、オリジンサーバーの IP アドレスへの遅延は、実際にはオリジンサーバーへの遅延ではなく、エニーキャストネットワークのエッジへの遅延になります。オリジンサーバーへの実際の遅延は、プローブによって判断できません。
遅延がデータセンターとオリジン間の実際の遅延を表さない場合、アルゴリズムは 1 つの最適なプロキシデータセンターを選択できません。間違ったデータセンターを選択すると、オリジンへのリクエストの遅延に悪影響を及ぼし、コストが高くなる可能性があります。
たとえば、クラウドプロバイダーが、実際に世界中の複数のデータセンターにルーティングする IP アドレスを提供しているとします。パケットはネットワークに入ると、プライベートインフラストラクチャを介して正しい宛先にルーティングされます。このエニーキャストIPアドレスに対する遅延が最も小さいデータセンターは、実際のオリジンサーバーとは異なる大陸にある可能性もあります。したがって、見かけ上の遅延は、オリジンへの実際の遅延の真の測定値として信頼することはできないのです。
データセンター選択アルゴリズムでは、オリジンが 1 つの地理的位置にあることを前提とし、各データセンターからの遅延を決定するためにプローブできます。これらのネットワークは、これらの前提の一つまたは両方を壊すため、それらを検出するための手順を開発する必要がありました。まず、IPは1つの地理的位置に表示され、そのようなネットワークによってプロキシされていないと仮定します。オリジンまでの遅延は、ファイバーを通過する光の速さで制限されます。データセンターとオリジンサーバー間の距離は不明ですが、データセンター間の距離はCloudflareが把握しています。
オリジンサーバーをピットストップとしてその行程に置くことを想像してみてください。そうすると、オリジンサーバーと任意の2つのデータセンター間で理論上最小になり得る観測可能な遅延のペアを算出することができます。これらのデータセンターとオリジンの両方からの遅延プローブデータを用いて、観測された遅延が予測されたよりも小さいかどうかを確認できます。
もともとの前提では、オリジンIP アドレスが1か所にあるオリジンサーバーを識別し、そのIPアドレスへの遅延はオリジンサーバーへの遅延であると仮定していました。観測された遅延が光よりも速い場合は、明らかに仮定は誤りになります。スマートトポロジーは、元々の前提が成り立たない場合に、汎用トポロジーに戻します。さらに確実にするために、世界中の複数のデータセンターでこの制約をチェックし、物理的に不可能な観測が1つでもある場合は前に戻します。
全体像
Smart Topologyを有効にすると、多くのCloudflareシステムが連携して、最終的にオリジンからアセットをリクエストするために正しいデータセンターが使用されます。
お客様がTiered Cache Smart Topologyを有効にすると、オリジンから見て、次のようなことが起こる可能性があります。プロキシデータセンターが、オリジンIPを包含するCIDRブロックにすでに割り当てられている場合、優先データセンターまたはフォールバックデータセンターを使用して、オリジンからアセットをリクエストします。それ以外の場合は、汎用トポロジーを使用して、オリジンからアセットを引き出すために使用するプロキシデータセンターが決定されます。プロキシデータセンターへの遅延は、プロキシデータセンターの選択肢が時間の経過とともに更新されるときにのみ減少します。
まとめ
この技術を開発することで、優れたエンジニアリングを行い、インパクトのある製品を構築する多くの機会を生み出すことができました。これは他から独立して行われたものではありません。Cloudflareがすでに構築したインフラストラクチャを使用し、そこまでの進展を利用してさらなる進展を実現するという飛躍的な成長を遂げたのです。このフレームワークを構築すると、将来的な可能性にも多くの扉が開かれます。たとえば、将来的には、理想的なプロキシデータセンターを選択する方法を探ることができます。これは、オリジンへの実際の遅延を隠すエニーキャストネットワークの背後にあるオリジンにも適用できるものです。