ネットワークパフォーマンスの最新情報：開発者ウィーク2022

Cloudflareは、世界最速のネットワークを構築しています。ですが、この言葉をそのまま鵜呑みにしてもらいたいわけではありません。それを実証するために、私たちは絶えず自社と他社を比較して当社が最速であることを確認しています。開発者ウィークということで、競合製品に対する当社のWorkers製品のパフォーマンス、および全体的なネットワークパフォーマンスの最新情報をお伝えしたいと思います。

今年の初め、Fastly社のCompute@Edgeと比較したところ、全体的に当社の速度が勝っていました。今回は同様のテストを繰り返しただけでなく、さらに多くの競合他社との比較を示すために、AWS Lambda@Edgeも対象に追加しました。要約すると、当社は市場最速の開発者向けプラットフォームを提供しています。お客様の環境をより高速にするために私たちがどのようにネットワークを構築しているのか、また、それをどのように開発者向けプラットフォームに反映させているのかについて説明します。

ネットワークパフォーマンスの最新情報

一般的なネットワークパフォーマンスに関するデータと、WorkersをCompute@EdgeおよびLambda@Edgeと比較したデータの2つを用意しました。

グローバルなネットワークパフォーマンスを定量化するには、他のプロバイダーを使用した世界中の様々なネットワークで自分たちを比較した十分なデータを取得する必要があります。当社はReal User Measurements (RUM) を使用して、様々なプロバイダーから100kBのファイルを取得し、世界中のユーザーからさまざまなプロバイダーのパフォーマンスがレポートされています。データをレポートするユーザーが多いほど、信号の信用度は高くなります。目標は、さまざまなプロバイダーの中で速いのはどこか、さらに重要なことは、Cloudflareのどこを改善できるのかを正確に把握することです。その方法の詳細については、こちらのオリジナルのSpeed Weekブログ記事をご覧ください。

Cloudflare One ウィーク（2022年6月）では、最も多くの報告書に記載されているネットワークの多くで、当社が競合他社よりも高速であることをお伝えしました。世界のネットワーク上位3,000（アドバタイズされたIPv4アドレス数）のうち、各プロバイダーがp95 TCP接続時間で1位となったネットワーク数の内訳は次のとおりです。これは、あるネットワーク上のユーザーがプロバイダーに接続するのにかかった時間を表しています。以下のデータはCloudflare One ウィーク（2022年6月）のものです：

開発者ウィーク（2022年11月）のネットワーク上位3,000の分布は以下のとおりです：

Cloudflareは、一般利用されるネットワークで最速であるだけでなく、すべての国において最速のプロバイダーになることにも力を注いでいます。

Cloudflare One ウィーク（2022年6月）のネットワーク上位3,000のデータを世界地図で表すと、以下のようになります（Cloudflareはオレンジ色）。

また、開発者ウィーク（2022年11月）のネットワーク上位3,000を見てみると、世界では以下のようになります：

Cloudflareは、ロシア、ウクライナ、カザフスタン、インド、中国などのヨーロッパとアジアのより多くの国でNo .1になり、世界最速のネットワークという当社の使命をさらに果たす結果となりました。では、Supercloudを最速の開発者プラットフォームにするために、このネットワークがどのように支えているかについてお伝えしたいと思います。

開発者プラットフォームの比較方法

最初のテストを公開してから6ヶ月が経ちましたが、ここで簡単におさらいしましょう。ネットワークへの接続時間、リクエスト完了に要した時間、全体の応答時間の計測結果を比較します。私たちはこれらの数字を「接続」、「待機」、「応答」と呼んでいます。これらの数字を選択した理由は、ユーザーの優れた体験のためにできるだけ高速であることが要求される重要な構成要素であるためです。当社は、可能な限りユーザーに近い場所でピアリングすることで、接続時間を短縮することができます。当社では、コードの実行速度が可能な限り高速になるよう最適化することで、待機時間を短縮することができます。この2つのプロセスを最適化すると、要求のエンドツーエンドのレイテンシーを表す応答時間が最適化されます。

テスト方法論

「接続」、「待機」、「応答」を測定するために、各プロバイダーに対して、単純なノーオペレーション命令のJavaScript関数、複雑なJavaScript関数、複雑なRust関数の3つのテストを実施しました。単純なRust関数でのテストを実施しない理由は、多くのプロバイダーが両方をWebAssemblyにコンパイルすることで、ほとんど時間がかからないことを想定していること、エンドツーエンド機能のベースラインはノーオペレーション命令のJavaScript関数ですでに用意されていることです。

ここでは、それぞれの関数を紹介します：

JavaScriptノーオペレーション命令：

async function getErrorResponse(event, message, status) {
  return new Response(message, {status: status, headers: {'Content-Type': 'text/plain'}});
}

JavaScriptハード関数：

function testHardBusyLoop() {
  let value = 0;
  let offset = Date.now();

  for (let n = 0; n < 15000; n++) {
    value += Math.floor(Math.abs(Math.sin(offset + n)) * 10);
  }

  return value;
}

Rustハード関数：

fn test_hard_busy_loop() -> i32 {
  let mut value = 0;
  let offset = Date::now().as_millis();

  for n in 0..15000 {
    value += (((offset + n) as f64).sin().abs() * 10.0) as i32;
  }

  value
}

各プラットフォームがエンドユーザーにどれだけ近いかを評価することに加えて、各プラットフォームがコンピューティングの最適化にどれだけ優れているかのテストを試行します。ただし、今回のテストでは、Lambda@Edgeについては当社のRust関数にネイティブに対応するにはお客様自身でコンパイルしたWASMバイナリをアップロードする必要があるため、Rustテストは実施しませんでした。Lambda@EdgeにはRustを実行するための最適な開発者プラットフォームとツールがないため、Lambda@EdgeのRustのシナリオは除外することにしました。そのため、Lambda@Edgeの数値の比較は、JavaScriptの単純テストとJavaScriptのハードテストのみが対象となります。

実際のユーザーからのWorkersパフォーマンスの測定

データの収集は、Catchpointと呼ばれるサードパーティサービスと、当社独自のネットワークパフォーマンスベンチマークテストの2つの異なる方法を用いて行います。まず、Catchpointを使用して、一連のプローブ合成データを収集しました。Catchpointは、業界標準の「合成」テストツールであり、世界中に分散している実際のユーザーからの収集値を測定します。Catchpointは、世界中に分散した合計約2,000ものエンドポイントを有するモニタリングプラットフォームであり、テストごとに特定のリソースと時間を取得するように設定することができます。Catchpointは、負荷に対するエンドツーエンドのパフォーマンスを測定するための一貫性のある反復可能な方法を提供し、ユーザーにとってのベストエフォートの近似値を提供するため、当社のようなネットワークプロバイダーにとって有用です。

Catchpointには、世界中のISPに組み込まれたバックボーンノードがあります。つまり、これらのノードは利用者と同じようにISPルーターに接続され、トラフィックはISPネットワークを経由して監視対象の各エンドポイントに到達します。これらは、実際のユーザーに近い形で再現することはできますが、本当の意味で実際のユーザーを再現することはできません。たとえば、これらのノードの帯域幅は100%がプラットフォームの監視に占有されるのに対し、自宅のインターネット接続では、インターネット体験はさまざまなユースケースが混在することになり、中にはWorkersアプリケーションとまったく通信しないものもあります。

今回新しく行ったテストでは、世界中のラストワンマイルとなるISPに組み込まれている300のバックボーンノードを選択しました。クラウドプロバイダーのノードや、複数のトランジットオプションがある都市圏のノードを除外し、重複する経路を可能な限り排除するようにしました。

これらのテストは、私たちがグローバルネットワークのパフォーマンスに関するデータを収集するのと同じように、無料のWebサイトに接続したユーザーが1XXXエラーページを受信した際に収集される独自のデータセットとのクロスチェックを行っています。このエラーページが表示されると、レンダリングの一部としてこれらのテストが実行され、これらの呼び出しに関するパフォーマンスメトリックがCloudflareにアップロードされます。

また、テスト方法を、Fastly、Cloudflare、AWSの有料アカウントを使用するように変更しました。

Workers、Compute@Edge、Lambda@Edgeの比較

今回は、エンドツーエンドでどのようなことを行っているかを示すために応答時間から見ていきましょう：

すべてのケースで当社が最速です。次に、実際の演算処理が実行される前の、ユーザーがコンピュートプラットフォームに接続する速度を示す接続時間を見てみましょう。

なお、これらの時間は、実行されているコードによって異なることは想定されていませんが、同じテストのセットから抽出しているため、ここで分割しています。

それでは、待機時間についてはどうでしょうか？待機時間はリクエストの演算にかかった時間を表しています。では、一番プラットフォームを最適化しているのはどこでしょうか？ハード関数によるRustテストではFastlyがまだわずかに優勢（さらなる最適化で打ち負かす予定です）ではあるものの、ここでもCloudflareです。

これらの結果を検証するため、Catchpointの結果を当社独自のデータセットと比較しました。以下は、当社のデータから、Fastly、AWS、CloudflareのJavaScriptとRustのハード関数ループのp95 TTFBを示したものです：

CloudflareはJavaScriptとRustの呼び出しが高速です。これらの数字は、Rustの呼び出しにおけるFastlyのわずかな演算処理の優位性も裏付けています。

ここから得られる重要なポイントは、ほぼすべてのテストでリクエスト処理にかかる時間でCloudflareが高速であることに加えて、Cloudflareのネットワークとパフォーマンスの最適化全体で他と一線を画し、Workersプラットフォームをすべてにおいてさらに高速にできるという点です。もちろん、今後もこの状態を継続していく予定です。

あなたのアプリケーションを、より高速に

レイテンシーはユーザーエクスペリエンスにとって重要な要素であるとともに、ユーザーが可能な限り高速に処理できることを保証できることは、アプリケーションを成功させるために開発者にとっても欠かせない要素です。Workers、D1、R2でアプリケーションを構築したり、Pagesでドキュメントをホストしたり、SaaSプラットフォームの一部としてWorkersを活用する場合でも、当社のグローバルネットワークであるSuperCloudでコードを実行することで、ユーザーに可能な限り最高の体験を提供できます。

当社のネットワークは、お客様のコードを可能な限り高速化するために超最適化されています。アプリケーションの実行にCloudflareのネットワークを使用すれば、Cloudflareが最高のユーザー体験を提供していることを容易に知ることになり、お客様は可能な限り最高のアプリケーションを作ることに集中できます。これは、Cloudflareの開発者プラットフォームが、世界最速のネットワークの上に構築されているからです。さあ、一歩踏み出して、私たちと共にいち早くあなたの夢を実現しましょう。