問い合わFastly 無料トライアル

嘘、大嘘、そして (Cloudflare の) 統計 : Cloudflare のパフォーマンステストの欠陥を証明

数週間前Fastly競合企業の一つである Cloudflare が、自社のエッジコンピューティングプラットフォームは Compute@Edge比べて3倍も高速であると 自社のブログ記事断言しました。しかし Cloudflareよるこの見当違いな主張は、事実とは異な印象を与えるために統計が利用されるリスクについて学ぶ良い機会でもありました。この記事では、Cloudflareテスト手法を分析するとともに、より有用で科学的な比較による結果を紹介します。


世の中には大嘘、そして統計3種類の嘘が存在すると言われています。これは統計の説得力を皮肉った言葉であり、統計の中には信用できるものもありますが、今回 Cloudflare公開した統計は明らかに信頼性に欠けます。

Cloudflare's claim to be 196% faster than Compute@Edge

Cloudflare主張には多くの問題があります。まず Catchpoint名前を持ち出すことで、この調査がまるで第三者機関による独立したものであるかのような印象を与えますが、実際はそうではありません。Catchpointツールはニーズに合わせて設定可能なため、公平で厳格な基準に基づいたテストを行うことも、自分の主張を裏付けるためにツールを恣意的に利用して、都合のよい結果を得ることも可能です。

Cloudflareテストにおける問題点

Cloudflareテストの設計と実施方法には、いくつかの欠陥があります。

  1. Cloudflareテストでは、厳選された Catchpoint ノードが使用されています。この特定のノードセットが選ばれた理由は示されていませんが、Cloudflareインフラストラクチャのロケーションは Fastly のものとは異なるため、不公平なテストロケーションの選択は、大幅に偏った結果を招きます。

  2. Cloudflareテストでは、一般公開されている成熟したプロダクトである Cloudflare Workers実行された JavaScript動作と、Compute@Edge実行された JavaScript動作が比較されています。Compute@Edge プラットフォームは現在一般公開されており、本番環境での使用が可能ですが、Compute@Edge JavaScriptサポートはベータ版のプロダクトとして公開されています。Fastlyドキュメントにも明記されているようにベータ版のプロダクトは本番環境での利用には適していません。より公平なテストを行うのであれば、プロダクトライフサイクルにおいて同等の段階にある Compute@Edge での Rust動作と Cloudflare Workers での JavaScript動作を比較するべきでした。

  3. Cloudflareテストでは、Fastly無料トライアルアカウントが使用されています。有料アカウントとは異なり、無料トライアルアカウントの使用には制限があるため、負荷の下でのパフォーマンスを比べることはできません。

  4. Cloudflareテストはたった1日、しかも1時間の行われました。そのため、日々のトラフィックパターンや異常なイベントを正規化できず、結果にランダムな歪みが生じる可能性があります。1日の間に複数のテストを異な時間帯で行うことで、都合の良い結果が得られる可能性が高くなります。

  5. Cloudflareブログ記事には、テストコードは「単に現在の時刻を返すだけの関数を実行した」とあるにもかかわらず、その直後に受信リクエストのヘッダーのコピーを返すコードサンプルが表示されています。これらの記述のいずれかに間違いがあるはずです。テスト手法がはっきり説明されていな場合、テスト結果の客観的な評価や再現は不可能です。

  6. コンピューティング負荷がほとんど無く、ペイロードサイズもそれほど大きくなく、プラットフォーム API使用しないテストで TTFB (最初の1バイトが到着するまでの時間)評価するだけでは、Compute@Edgeパフォーマンスの測定において意味のある結果は得られません。

とてもまともな科学とは言えません。では、なぜ Fastly はわざわざこのような記事に注目しているのでしょうか。そして、Compute@Edgeパフォーマンスは実際にどれほどのものなのでしょうか。

実は Compute@Edge Cloudflare Workers より速かった

実のところ、TTFB だけではどちらのプラットフォームの方が速いと断言することはできません (その点については後ほど)。しかし、今回のテストをより公平な方法で再現した結果では、TTFBおいても Fastlyネットワークと Compute@Edgeパフォーマンスのスコアが、Cloudflareネットワークと Cloudflare Workersスコアを上回りました。

エッジネットワークの相対的なパフォーマンスの測定は容易ではありません。CDN時代を超えた今、たった一つの変数のみでエッジネットワークの価値を判断することはできません。今回のテストには使用されませんでしたが、いくつもの素晴らしいエッジ機能を提供する Cloudflare は、このことを誰よりもよく理解しているはずです。

誤解を与えるようなこのベンチマークと同様の条件で比較調査を行う気はありませんが、Cloudflare利用規約では同社のサービスを使ったベンチマーク調査を実施することは禁じられているため、Fastly条件での再調査を行うことはできません。

Cloudflare's terms of use

そこで今回は、Fastlyプラットフォームに対して同じテスト (同じヘッダーを使用して Catchpoint使って TTFB測定)実施しました。ただし、今回のテストには、以下の決定的な違いがあります。

  • より長期のテスト期間 (1時間ではな1週間)設定し、より多くの Catchpoint ノード (50ではな673)使用

  • JavaScript代わりに、Rust からコンパイルされた Wasm バイナリを使用

  • Fastly無料トライアルアカウントではなく、有料アカウントを使用  

データはこちらでご覧いただけますが、結論から言うと、より公平な手法で行われたテストの結果から、以下のような欠陥のある測定基準を利用した場合でも、6つのリージョンのうち4つのリージョンにおいて、Fastlyネットワークと Compute@Edge は、Cloudflareネットワークと Workers よりもスピードが速かったことがわかりました。

Median TTFB for Cloudflare vs. Fastly

Fastly データ : TTFB中央値、Catchpoint ノード 673、リクエスト 378,000、実施期間 2021-11-24 00:00 から 2021-11-30 00:00 (6日間) 結果Cloudflare データ: TTFB中央値、Catchpoint ノード 50、リクエスト数不明、実施期間 2021-11-08 20:30 から 2021-11-08 22:00 (1.5時間) 結果]

Cloudflare推奨する TTFB基準にした場合、Compute@Edge実行する Fastlyネットワークは、Cloudflare Workers よりもアメリカとヨーロッパでは2倍、オセアニア地域では10倍速いことがわかりました。も一度言いますが、Cloudflare利用規約ではベンチマーク調査は禁じられているため、Cloudflareサービスを直接利用してオセアニア地域の他からかけ離れた値を再現することはできませんでした。

エッジサーバーで直接 WebAssembly バイナリを実行するため、Compute@Edge にはネイティブ言語がありません。しかし、Rust開発者のエクスペリエンスとコンパイルされたコードのパフォーマンスの両方の観点から見ても、大変優れた言語です。つまり、WebAssemblyコンパイル可能であれば、何でも Compute@Edge実行することができます実際、多くのお客様が Compute@Edge幅広く活用しています。

でも JavaScript は?

多くのお客様にとって JavaScriptサポートが重要なポイントであることは Fastly重々承知しています。しかし 私たちは、JavaScript からコンパイルされた Compute@Edge パッケージのパフォーマンスにまだ完全に満足していません。JavaScriptサポートがまだベータ版であるのは、そのためです。Fastly では、本番環境にふさわしパフォーマンスが得られるようになり次第、プロダクトを正式版としてリリースするようにしています。

エッジコンピューティングプラットフォームを構築するにあたって、Fastly同業他社とはだいぶ異なアプローチを取ってきました。したがって、Fastly では始めから問題への取り組み方自体が他と異なり、それに伴いパフォーマンスの進化の仕方も変わってきます。

正しデータの測定

では、このテストにおいて TTFB有用な測定基準ではな理由について、より詳し見てみましょう。

今回 Cloudflare行ったテストでは、コンピューティングパフォーマンスの測定において意味のある結果を得ることができません。たった一つの変数を測定するのではなく、客様にとって意味のある主なユースケースにおけるエッジコンピューティングのパフォーマンスを測定するベンチマークを使用することが重要です。ネットワークの RTT加えて、以下のような変数の測定が重要です。

  • リクエストを客様のコードに渡す際のスタートアップ時間

  • 様々なサイズのワークロードに対するコンピューティングパフォーマンス (思考時間)

  • リクエスト頻度の高いオブジェクトとロングテールコンテンツの両方に対するキャッシュパフォーマンス

  • オリジンリクエストを含むユースケースにおけるオリジンサーバーへの RTT

Cloudflareテストでは、ネットワークの RTT さえも適切に測定されていませんでした (TTFB にはネットワーク RTTサーバーの思考時間が含まれるため)。また、それぞれの要素が全体的な値に占める割合を判別できません。パフォーマンスをよく理解するためには、各要素を単独で測定する必要があります。

例えば以下のグラフでは、Fastly サービスのアジアでのネットワーク RTT TTFB中央値が示されています。VCL プラットフォーム (左のグラフ) では、ネットワーク RTT (青い線) TTFB (緑の線)ほぼ同じになるほど、キャッシュヒットの配信が高速であることが分かります。Compute@Edge場合 (右のグラフ)、TTFB線は RTT とは明らかに異なり、任意のコードを実行するのにかかる負荷の増加の影響が反映されています。それでも、一般的に接続のレイテンシが大きいリージョン (以下のグラフのアジアも含めて) では、RTT大部分を占めています。

Medians for network RTT and TTFB in Asia for a Fastly service

先ほどのテスト結果にも見られるように、RTT地域によって大きな差があります。つまり Cloudflareテストでは、Fastlyエッジコンピューティングプラットフォームの相対的なパフォーマンスを示す「サーバーの思考時間」明確にされていません。

客様のために、より優れたインターネットを

現在 Fastly では、より現実的な環境にてパフォーマンスを計測するベンチマークスイートの作成に取り組んでおり、そのコードは追って公開する予定です。より優れたインターネットの構築を目指す Fastly は、企業同士の無意味な競争に膨大な労力を費やすことを避けるため、ベンチマークの結果は独立した第三者機関によって計測発表されます。

とにかく、Cloudflare Workers Compute@Edge より196%高速であるという発言は、確実に間違っています実際、Workers Compute@Edge よりもまったく速くありません。いずれにせよ、お客様にとって最も意味があるのは、ビジネスにとって重要な指標です。お客様のビジネスのニーズに、Fastlyスピードが十分であるかご興味がある方は、ぜひ Compute@Edge試し上、自身でテストを行ってみてください。


この記事には、Fastly想定や仮定、およびこの記事の公開時において Fastly入手できた情報に基づいた「将来の見通し」に関する記述が含まれています。将来の見通しに関する記述には、既知および未知のリスク、不確実性、ならびにその他の要因が影響する場合があり、これらによって実際の結果、パフォーマンス、または成果が同記述において明示的または暗示的に示されたものと実質的に異な可能性があります。これらの記述には今後のプロダクトやサービスに関するものが含まれますが、これらに限定されません。法律の規定による場合を除き、Fastlyこれらの将来の見通しに関する記述を公に更新する義務、および実際の結果が同記述において予想されたものと実質的に異な可能性がある理由について更新する義務を負いません。これは、将来的に新し情報が入手可能になった場合でも同様です。実際の結果が実質的に異な原因となり得る重要な要因は、Fastly米国証券取引委員会 (SEC)提出するレポート (20201231日に終了した事業年度の Form 10-Kよる年次報告書および Form 10-Qよる四半期報告書を含む)随時詳述されます。SEC提出したレポートのコピーは Fastly Web サイトに掲載されており、Fastly から無料で入手できます。

Andrew Betts
Head of Developer Relations
Laura Thomson
VP of Engineering
Hooman Beheshti
VP of Technology
投稿日
興味がおありですか?
エキスパートへのお問い合わせ
この投稿を共有する
Andrew Betts
Head of Developer Relations

Andrew Betts Fastly Head of Developer Relations として世界各地の開発者と協力し、Web 高速化、セキュリティ、信頼性、使いやすさの向上に努めています。Fastly 入社前は、Web コンサルティング会社 (後に Financial Times により買収) 設立し、Financial Times 先駆的な HTML5 ベースの Web アプリケーションの開発を統括したほか、同紙のラボ部門の設立にも携わりました。また、W3C Technical Architecture Group (World Wide Web 開発を導く9名で構成される委員会) 選出メンバーでもあります。

Laura Thomson
VP of Engineering

Fastly Vice President of Engineering 務める Laura Thomson Internet Society 理事会のメンバーでもあります。Fastly 入社前は Mozilla 10年以上勤務し、エンジニアリングチームとオペレーションチームを統括したほか、Let's Encrypt 役員を務めていたこともあります。ソフトウェア開発に関するベストセラー書籍の著者でもある Laura 過去20年間にわたり、世界各地の数多くのカンファレンスで講演しています。

Hooman Beheshti
VP of Technology

Hooman Beheshti Fastly VP of Technology 務め、Web パフォーマンスサービスを開発しています。アプリケーションアクセラレーション開発のパイオニアである Hooman Radware 在籍中に初期のロードバランサの設計に携わったほか、Strangeloop Networks Crescendo Networks シニアレベルの技術職を歴任しました。20年近くにわたりインターネットを高速化するコアテクノロジーの開発に従事し、ロードバランシング、アプリケーションパフォーマンス、コンテンツ配信ネットワークの専門家として頻繁に講演を行っています。