ちょうど4年前、私たちはエッジ上で直接動作するサーバーレスプラットフォーム「Cloudflare Workers」を発表しました。
今週は、既存のWebアプリケーションをより高速化するためにCloudflareが行っているさまざまな方法についてお話します。もし今日、あなたがアイデアを形にしたいと思ったなら、Cloudflareのエッジ上でプロジェクトを構築し、それをインターネット上に直接デプロイすることで、アプリケーションが場所に関係なくすべてのユーザーにとって常に高速であることを最高の形でご理解いただけるはずです。
Cloudflare Workersが性能面で他のサーバーレスプラットフォームとどのように差別化されるかについてお話ししてから数年が経ちましたので、今こそ最新情報をお伝えする時だと考えました。ここ数年のWorkersプラットフォームでの取り組みのほとんどは、新機能、API、ストレージ、デバッグ、可観測性ツールの導入など、プラットフォームをより強力にするものでしたが、パフォーマンスも疎かにはしていません。
現在、Workersは3年前に比べてP90で30%速くなっています。また、Lambda@Edgeに比べて210%、Lambdaに比べて298%速くなっています。
さらに、コールドスタートも排除しました。
サーバーレスプラットフォームのパフォーマンスの測定方法
これまでに何百ものCDNのパフォーマンスベンチマークを実行してきましたが、方法はシンプルです。世界中のノードから同じアセットにリクエストを行い、それぞれのノードにその返答が返るまでにかかった時間について報告するツール「Catchpoint」を使用します。
しかし、サーバーレスパフォーマンスの測定は少し異なります。比較する対象は静的アセットではなく、コンピューティングパフォーマンス（計算能力）であるため、すべての関数が同じ処理を行うことを確認する必要があります。
2018年の速度テストに関するブログで行ったテストは、単に各関数が現在の時間を返すだけのものでした。今回のテストでは、このタスクを実行できない「サーバーレス」製品は、最低条件を満たしていないため除外されました。この一連のテストで使用されたサーバーレス製品は、正確で公正な結果を得るため、同じ計算の複雑さを持つ同じ関数を実行しました。
何を測定しているのかも重要です。パフォーマンスが重要な理由は、それが実際のエンドユーザーの体験に影響を与えるためです。利用者にとって遅延の原因が何であるか（DNS、ネットワーク輻輳、コールドスタート）は重要ではありません。利用者が気にすることはアプリケーションの読み込みにかかる時間を待つことです。
そのため、ユーザーエクスペリエンスを基準にしたエンドツーエンドのパフォーマンスを測定することが重要です。そのため、私たちはパフォーマンスの測定にグローバルなベンチマークを使用しています。
以下の結果は、北米、南米、ヨーロッパ、アジア、オセアニアにわたる50のノードからのテスト結果を示しています。
青：Cloudflare Workers 赤：Lambda@Edge 緑：Lambda
（結果へのリンク）。
この結果からわかるように、Workersはユーザーが世界のどこにいても、速度において利用者に最高の体験を保証しています。
Workersでは、開発者はグローバルに最高のパフォーマンスを得るため追加の作業をする必要ありません。開発者が負荷分散やリージョンを追加で設定する必要はありません。すべてのデプロイは、Cloudflareの広範なエッジネットワーク上で瞬時に稼働します。
たとえ世界中で対応する必要がない場合でも、顧客基盤が米国の東海岸に位置している場合でも、Workersはすべてのリクエストに対して最速のレスポンスを保証することができます。
上のグラフは、us-east-1に可能な限り近いワシントンDCからの結果です。最適化を行っていないにもかかわらず、Workersは34%も高速です。
その理由は？
サーバーレスプラットフォームのパフォーマンスを決定づける要素は何か
コード自体のパフォーマンスは別として、エンドユーザーの観点からすると、サーバーレスアプリケーションのパフォーマンスは基本的に「実行されるアプリケーションとユーザーとの距離」と「ランタイム自体を起動するのに要する時間」の2つの不定要素に依存しています。ユーザーからの距離がアプリケーションのパフォーマンスにますます大きなボトルネックとなっていることに気づいた多くのサーバーレスベンダーは、エッジに近づくことに力を入れ始めています。エッジ（エンドユーザーに近い場所）でアプリケーションを実行することで、パフォーマンスを向上させることができます。5Gが普及するにつれて、この傾向はますます加速し続けていくでしょう。
しかし、サーバーレス分野の多くのクラウドベンダーは、より高速なパフォーマンスを追求する際に重要な問題に直面しています。そして、それは、サービスを構築するために使用しているレガシーアーキテクチャが、エッジ固有の制限ではうまく機能しないということです。
サーバーレスモデルの目標は、基盤となるアーキテクチャを意図的に抽象化することであるため、AWSのようなレガシークラウドプロバイダーがLambdaのようなサーバーレスサービスをどのように作成したのかを明確に知る人は居ません。従来のクラウドプロバイダーは、コードを実行するためにコンテナ化されたプロセスを立ち上げることでサーバーレスサービスを提供します。プロバイダーは、バックグラウンドでこれらのプロセスを自動的にスケールさせます。コンテナが立ち上がるたびに、コードだけでなく、使用している言語のランタイム全体も同時に起動されます。
最初のグラフで示されたグローバルパフォーマンスを改善するために、ベンダーは大規模で集中化されたアーキテクチャ（少数の大規模データセンター）から、エッジベースの分散型の世界（世界中に点在するより小さなデータセンター）へ移行し、アプリケーションとエンドユーザーの距離を縮めようとしています。しかし、このアプローチには問題があります。小規模なデータセンターは、マシンも少なく、メモリも少ないことを意味します。ベンダーがよりエッジに近いところで運用するために、小規模ではあるが多数のデータセンター戦略を追求するたびに、個々のプロセスでコールドスタートが発生する可能性が高まります。
これにより、コンテナベースのアーキテクチャ上のサーバーレスアプリケーションにパフォーマンスの上限が生じます。小規模データセンターを有するレガシーベンダーがアプリケーションをエッジ（ユーザーの近く）に移動させると、サーバーが減り、メモリ量も低下し、アプリケーションがコールドスタートを必要とする可能性が高まります。その可能性を減らすために、より集中型のモデルへと回帰しています。しかしそれは、数少ない大規模な集中型データセンターの1つからアプリケーションを実行することを意味します。このような大規模な集中型データセンターは、定義上、ほとんどの場合、ユーザーから遠く離れた場所に位置します。
これは、上記のグラフのLambda@Edgeで実行したときのテスト結果を見ることで確認できます。エンドユーザーに近づいているにもかかわらず、コンテナがより頻繁に立ち上がらなければならないため、p90のパフォーマンスはLambdaのそれよりも遅くなっています。
コンテナ上に構築されたサーバーレスアーキテクチャは、その境界線を上下させることはできますが、最終的に、その境界線の曲線を移動させるためにできることはあまりありません。
Workersが非常に高速である理由
Workersは、エッジファーストのサーバーレスモデルを念頭に置いてゼロから設計されました。Cloudflareは、巨大な集中データセンターからエッジにコンピュートを押し出すのではなく、分散型のエッジネットワークからスタートしました。この制約の中で作業を進める中で、私たちは革新を余儀なくされました。
以前のブログ記事の1つで、Workersのアーキテクチャに、この革新の結果である「リクエストごとにコールドスタートを発生させることなく、迅速に立ち上がる軽量なV8 Isolateに基づいて構築する」という新しいパラダイムシフトをどのようにもたらしたかについて説明しています。
Isolatesを運用することにより、私たちはすぐにメリットを享受できるだけでなく、V8が進化するにつれて、私たちのプラットフォームも向上します。たとえば、V8がWASMのコンパイラーであるLiftoffを発表した際、すべてのWASM Workersが瞬時に高速化しました。
同様に、Cloudflareのネットワークに改善が加えられた場合（例えば、新しいデータセンターを追加する場合）やスタック（HTTP/3のような新しい高速プロトコルのサポート）などに改善が加えられれば、Workersは即座にその恩恵を受けます。
さらに、私たちは常にWorkers自体の改善を行い、プラットフォームをさらに高速化する努力を常に続けています。たとえば、昨年、当社はお客様のためにコールドスタートをなくすのに役立つ改善をリリースしました。
Workersがパフォーマンスの問題を特定し、解決する上での大きな強みは、その運用規模です。現在、Workersは何十万もの開発者にサービスを提供しており、趣味で利用する個人から世界中の企業まで、多岐にわたるユーザーが毎秒数百万のリクエストを処理しています。私たちが1人のお客様のために改善を行うたびに、プラットフォーム全体が高速化されます。
パフォーマンスは重要事項
サーバーレスモデルの最終目標は、開発者が本来得意とすること、つまりユーザーのためのエクスペリエンスの構築に集中できるようにすることです。すぐに最高のパフォーマンスを提供できるサーバーレスプラットフォームを選択することで、開発者の心配が1つ減ります。もしあなたがコールドスタートの最適化に時間を費やしているのであれば、それは顧客に最高の機能を構築する時間が奪われていることになります。
開発者がユーザーに最高の体験を提供するためにアプリケーションのパフォーマンスの向上に努めるように、私たちはWorkers上に構築する開発者の体験を向上させるために常に努力しています。
利用者が反応の遅さを我慢したくないように、開発者もデプロイサイクルの遅さを我慢したくありません。
ここでもWorkersプラットフォームが優位性を発揮します。
Cloudflare Workersへのすべてのデプロイは1秒未満でグローバルに反映されます。そのため、コードのデプロイを待つ必要がなく、利用者は可能な限りすばやく変更を確認できます。
もちろん、重要なのはデプロイ時間だけではなく、開発サイクル全体の効率も重要です。そのため、サインアップからデバッグまで、すべてのステップで当社は常に改善を目指しています。
私たちの言葉をそのまま信じるだけでなく、ぜひご自身でお確かめください！
言うまでもなく、私たちは当社に対する贔屓目を排除して中立な目線でお伝えしていますが、少しだけ自信を持っているのも事実です。とはいえ、私たちの言葉をそのまま信用する必要はありません。
是非サインアップして最初のWorkerを今すぐデプロイしてみてください。わずか数分で完了します！