② Part 3:クラウドフレア / NET:サーバーレス・エッジ・コンピュート分野の競合アマゾンAWSとの比較分析

- クラウドフレア(NET)は、サーバーレス・エッジ・コンピュートで優位性を持つが、AWS Lambda@EdgeやFastlyなどの強力な競争相手も存在する。
- 同社の優位性は、ネットワークカバレッジと低レイテンシー、またV8アイソレートによる高速なアプリケーション起動にあるが、言語サポートの限界やエコシステムの成熟度で劣る面もある。
- 同社は、生成AI関連のサービスやVectorizeの導入により競争力を強化しているが、GPU性能やAIサーバーの能力に限界があり、今後の成長にはさらなる投資と開発が必要と見ている。
※「① Part 3:クラウドフレア / NET:エッジ・コンピュート分野における同社のテクノロジー面での強み&競争優位性」の続き
クラウドフレア(NET)とAWSの比較
クラウドフレア(NET)には、サーバーレス・エッジ・コンピュート分野で数社の競合がいる。
ファストリー(FSLY)は、エッジ・コンピートのパイオニアの1つとして強力な競争相手である。
アマゾンのAWS(AMZN)のLambda@Edgeも強力な競争相手で、クラウドベースのサーバーレス・コンピュートAWS Lambdaをエッジに拡張したものであり、クラウドフレアの市場における今後の可能性を制限する可能性がある。
エッジ・コンピュートにおけるAWSに対するクラウドフレアとファストリーの優位性は、明らかにネットワーク・カバレッジにある。
AWS Lambdaはアプリケーションに対して1つのAWSリージョンに配置され、Lambda@EdgeはAWSデータセンターにまたがってグローバルに配置される。
Lambda@Edgeに対するWorkersとFastly Computeの利点は、より多くの小規模な分散型エッジPoP(Point of Presence:ポイント・オブ・プレゼンス)に配置されていることである。
つまり、Lambda@Edge上で実行されるアプリケーションよりも、クラウドフレアやファストリーのネットワーク上で実行されるアプリケーションの方が、ほとんどの場合ユーザーに近いため、低レイテンシーを実現できる。
そして、AWSに対するクラウドフレアとファストリーのもう1つの利点は、それぞれクラウドフレアのV8アイソレート(V8 Isolates)とファストリーのWasm(WebAssembly Modules)モジュール上でアプリケーションを実行することである。
これらは、クラウド環境で使用されるコンテナよりも、それぞれ1000倍、10万倍小さい。
また、この超軽量性により、クラウドフレアとファストリーは、コンテナ化されたアプリケーションで経験するコールド・スタート時間をなくすことが出来ている。
コールド・スタートは、リクエストに応答するために必要なコードがしばらく使用されていない場合に発生する。
このような非アクティブな状況の後、言語ランタイム(Python、Node.jsなど)は、コンテナ環境で再初期化し、コンピュート(CPU、メモリなど)をプロビジョニングし、コードを実行する必要があることから時間がかかる。
対照的に、クラウドフレアのV8アイソレートとファストリーのWasmは、クラウドで必要とされるような完全なコンテナの重い初期化を必要としないため、ほぼ瞬時に開始するように設計されている。
これは、ランタイムとコードが即座に実行可能であることを意味し、起動レイテンシを実質的にゼロにし、入ってくるリクエストに対してより速いレスポンスを提供する。
クラウドフレアとAWS LambdaおよびLambda@Edgeの、より分散されたグローバルなPoPカバレッジと、より高速なランタイムの初期化によるレイテンシの削減の合計は、以下のチャートの通りである。
クラウドフレアとファストリーのAWSに対する優位性にもかかわらず、我々が2021年初頭に取材を開始して以来、開発者の間で彼らがより大きな勢いを得ていないことに驚いている。
今にして思えば、Cloudflare WorkersとFastly Computeを利用する上でのある欠点が、予想以上に普及が遅れている原因だと考えられる。
例えば、Workersプラットフォームはこれまで、JavaScript、TypeScript、WebAssemblyのみをネイティブでサポートしていた。
これは、PythonやJavaのような他の言語を使いたい開発者にとってはハードルとなっていた。
実際、PythonやJavaは、RustやC++など他の多くの言語と同様にWebAssemblyにコンパイルすることができるが、変換を行うプロジェクト(PyodideやMicroPythonなど)は成熟していないため、PythonやJavaの開発者にとっては摩擦が生じている。
クラウドフレアはごく最近、Pythonをネイティブに導入している(2024年4月にGA化)。
これは大きなマイルストーンであり、開発者の採用率を上げるはずだが、ネイティブ言語のサポートが限られていることがこれまでのところ逆風となっている。
対照的に、Lambda@EdgeはPythonやJavaを含む幅広い言語を、変換することなくネイティブサポートしてきた。
つまり、開発者はWebAssemblyのコンパイルに煩わされることなく、これらの言語を直接使用し、そのエコシステムやライブラリをフルに活用することができるのである。
そして、このAWS LambdaとCloudflare Workersの言語サポートの違いは、戦略的ゴールの違いを照らしている。
AWSはユーザーエクスペリエンスと開発者にとって最も親しみやすいプラットフォームであることに重点を置いており、一方、クラウドフレアはコールド・スタートの廃止など、限界を押し広げることに執拗に集中しているため、ネイティブでサポートされる言語の数を管理可能な数に保つ必要があった。
とはいえ、Lambda@Edgeが何倍ものワークロードを実行しているように、前者の戦略が今日まで多くの成功をもたらしているのは確かだ。
興味深いことに、AWSのこのアプローチは彼らの全体的な成功の核となっている。
なぜなら、彼らは限界を押し広げることを望まず、より確立された技術を、完璧に提供することに焦点を当てているからである。
典型的な例は、2010年代のAWSとグーグル(GOOG/GOOGL)のクラウドアプローチを比較したものである。
AWSは開発者が最も慣れ親しんでいるVM(仮想マシン)に重点を置いていたのに対し、グーグルは、開発者にとってはより習得しにくい、より革新的なコンテナとKubernetesを推進していた。
そして、AWSは、より確立された技術に集中しながらも完璧なサービスを提供することで、クラウド戦争でグーグルを打ち負かしたのである。
クラウドフレアにとってのもう1つの欠点は、Cloudflare Workersが完全なコンテナランタイムをサポートしておらず、特定のタイプのレガシーアプリケーションや特殊なアプリケーションを実行する能力が制限されていることである。
また、Cloudflare Workersの成熟度とエコシステムは、急速に成長しているとはいえ、AWSやマイクロソフト(MSFT)のAzureに比べるとまだ比較的新しく、サードパーティの統合やツールの成熟度は低い。
また、確立されたリファレンスアーキテクチャや、Workersに特化したベストプラクティスガイドも少ないため、新規ユーザーが効果的に使い始めることが難しくなっている。
さらに、一部のワークロード、特に重い計算能力や特定のランタイム環境を必要とするワークロードは、Workersに適していない。
既存のアプリケーション、特にWorkersがネイティブにサポートしていない言語で書かれたアプリケーションを移行するには、大幅なリファクタリングが必要となる。
Workers採用への逆風は、サーバーレス・エッジやWorkersに限ったことではなく、より広くサーバーレスに当てはまる。
数年前からサーバーレスは、クラウドでのサーバーレスであれエッジでのサーバーレスであれ、次の大きなコンピューティングパラダイムとして注目されてきたが、まだ本格的に普及し、主流になるには至っていない。
その理由は、開発者が特定のベンダーに縛られたくないからだ。
例えば、Workers上でWasmランタイム、D1やR2といったクラウドフレアのデータベース・オプション等を使用してサーバーレス・アプリケーション・スタックを作成した場合、ホスティング・プロバイダーを変更したい場合に、コードベースを単純にAWSにコピー&ペーストすることは不可能であり、スタックを再構築する必要がある。
一方、VMやコンテナに基づいてアプリケーションを作成した場合、VMやコンテナは高度に標準化されているため、他の環境にスタックをかなり簡単に移植することができる。
つまり、現時点では、サーバーレスアーキテクチャの標準化の欠如が、サーバーレス・エッジ領域のWorkersだけでなく、サーバーレスクラウド領域のワーカーにとっても、採用を妨げている。
標準化の欠如は、開発者が避けたいベンダー・ロックインにつながる。
なぜなら、特に年配の開発者は、閉鎖的で独自性の強い規格を持つことで成功を収めたが、ユーザーとしてはこの規格から脱却するのは非常に難しいIBM(IBM)やオラクル(ORCL)のようなレガシーな名前にロックインされた痛みをまだ感じているからである。
また、Workers上でアプリケーションを構築・実行する際の以前の欠点の1つは、ストレージの不足だった。
多くの開発者は、データベースやオブジェクト・ストレージをハイパースケーラのクラウドに置く必要がある場合、WorkersやFastly Computeのレイテンシの利点に価値があるのか疑問に思うだろう。
しかしここ数年、クラウドフレアはオブジェクトストレージ用のR2(様々な種類のデータを低コストで保存するために必要)、SQLデータベース用のD1(アプリケーションに関連する構造化されたトランザクションデータの保存と読み出しに必要)、NoSQLデータベース用のWorkers KV(アプリケーションに関連する半構造化・非構造化データ用のキー・バリュー・ストア)などのストレージのイノベーションを導入することで、迅速に対応してきた。
これによって、クラウドフレア(NET)がAWSやAzureと基本的な部分で肩を並べるべく前進していることは明らかだが、その道のりは極めて長い。
開発者が安心してAWS、或いは、Azureからクラウドフレアに乗り換えられるようにするには、ネイティブ言語のサポート、ストレージのオプション、CI/CDのサポート、その他さまざまなサービスを追加し続ける必要がある。
例えば、クラウドフレアはデータベース面で素晴らしい進歩を遂げたが、D1ではCockroachDB、MySQL、PostgreSQL、MariaDBなどのSQLデータベースには遠く及ばない。
というのも、D1はSQLの軽量版であるSQLiteをベースにしているため、エンタープライズ規模のアプリケーションに必要な並行性(複数の同時操作やトランザクションを競合することなく処理し、データの一貫性と整合性を確保する能力)を実現できないからである。
そのため、D1は、例えば中小企業向けのeコマース・サイトの商品リストや注文など、書き込み操作(データベース内のデータや状態を変更する操作)の数が多くない場合に適している。
例えば、商品を閲覧するには、データを変更しない読み取り操作が必要であり、書き込み操作を必要とする注文は、読み取り操作を必要とする商品ビューよりも常に大幅に少なくなる。
したがって、(アマゾンのようなものではなく、中小企業の)eコマースサイトのこの部分はD1に適している。
このような点から、クラウドフレアがハイパースケーラの能力を模倣し、あらゆるアプリケーションのニーズに対応する代替スタック開発になるには程遠いことがわかる。
同社のマシュー・プリンス最高経営責任者(CEO)は、この課題を痛感しており、同社がハイパースケーラーと直接競合するのではなく、マルチクラウド、ハイブリッド環境における「接続クラウド」になると考えていることを、彼のレトリックは示している。
同社がコネクティビティクラウドとして台頭するための1つの方法は、データのエグレスを無料で提供することであり、これはインターネットへのデータ送信に課金するハイパースケーラーとは対照的なアプローチである。
AWSのエグレス料金は、データをAWSの外部に取得・送信する必要がある場合に発生する(AWSリージョン間で送信されるデータも同様)。
例えば、アプリケーションがAWSサーバーからデータを取得する必要があるWebアプリケーションのリクエストに応答する場合や、機械学習のトレーニングのためにAWSの外部にデータを送信する場合などが挙げられる。
コストはリージョンと転送されるデータ量によって異なり、一般的にデータ量が多いほどGBあたりのコストは低くなる。
つまり、ユーザーがAWSからより多くのデータを転送すればするほど、コストは増大し、大規模なデータ転送を必要とする企業にとっては大きな負担となる。
対照的に、クラウドフレアのR2オブジェクトストレージサービス、またはD1とWorkers KVは、データのエグレス料金/手数料を請求しない。
この価格設定モデルにより、ユーザーは追加コストを発生させることなく、クラウドフレアのストレージからインターネットにデータを転送できるため、予測可能性が高くなり、データ転送の必要性が高い企業にとって、より手頃な価格になる可能性がある。
データのエグレス料金をなくすことで、クラウドフレアは、同社のユーザが、AWSのような従来のクラウドプロバイダーに関連する高騰するコストを心配することなく、大量のデータ転送を処理できるようにしている。
これは、特にストレージからデータを頻繁に取得し、ユーザーに提供するWebアプリケーションにとっては、大幅なコスト削減につながります。
つまり、開発者は、ハイパースケーラでアプリケーションのコンピューティングを実行しながら、アプリケーションのストレージ/データベースとしてクラウドフレアのR2、D1、またはWorkers KVを使用するという魅力的なオプションを持つことになる。
このセットアップにより、AWSやAzureにストレージ/データベース・サービスを持つことで通常発生するデータのエグレス料金が不要になり、まさに同社CEOのプリンス氏がコネクティビティ・クラウドとして想定しているエッセンスとなる。
理論的には、これは非常に魅力的なセットアップになるはずだ。
なぜなら、極端な例では、インフラ料金の80%がコンピュートではなくネットワーキングによるものだからだ。
そして、コネクティビティ・クラウドとして、クラウドフレアはインフラ・コストを劇的に削減することができる。
しかし、大きな注意点としては、D1の限界について、先に述べたコメントを繰り返してしまうことである。
なぜなら、D1がエンタープライズ・スケールのアプリケーションをサポートするように拡張できない限り、開発者はクラウドフレアを接続クラウドとして選択することはなく、同社のSQLデータベースを高トラフィックのアプリケーションに使用することになるだろう。
もちろん、アプリケーション用のコンピュートもクラウドフレアにあれば、低コストで低レイテンシーのアプリケーション環境を実現できる。
また、プリンスCEOの長期的な第一の目的は、ハイパースケーラーに代わる包括的な選択肢を提供することにあるようである。
しかしながら、この野望が達成できない場合でも、パブリッククラウドのワークロードのパフォーマンスを向上させ、コストを削減するための接続性クラウドとしてクラウドフレアを推進することは、素晴らしい代替案となるだろう。
つまり、AWSに対するクラウドフレアの展望には、長所、短所、進歩の各ポイントが混在している状況となっている。
しかし、他のCDN+エッジ・コンピュート・プレーヤーとの競争はどうだろうか?
ピュアプレイのエッジコンピュート企業に対するクラウドフレアの最大の強みは、開発者エクスペリエンス、セキュリティ機能、ストレージオプションのように見える。
また、クラウドフレア(NET)は、エッジ・コンピュートのライバルが遅れをとっているのに対し、生成AI関連のさまざまなサービスをいち早く提供している。
Workers AIは、開発者がクラウドフレアのPoPでモデルを訓練することを可能にし、テキスト生成、テキストから画像への変換、翻訳などのための多くのオープンソースモデルへのアクセスを提供している。
さらに、開発者は独自のモデルも簡単にインポートできる。
クラウドフレアは、ファストリー(FSLY)などがまだPoPに追加していないGPUの導入により、モデルへのアクセスを提供できるようになった。
特筆すべきイノベーションは、クラウドフレアのベクトル・データベース・ソリューション「Vectorize」で、検索機能やレコメンデーション、自然言語処理(NLP)を必要とするアプリケーションには不可欠となっている。
ベクトル・データベースでは、単語や画像のような多様なデータは、高次元のベクトル空間内でベクトルに変換される。
これらの次元は、使用されるAIモデルに基づいて100から約3000に及ぶことがあり、データのセマンティックな意味を符号化し、類似点の効率的な検索を可能にする。
例えば、「I sat on the river bank(私は川岸に座った)」と「私は川岸で給仕を待つために座った(I sat waiting to be served at the bank)」の「bank」という単語は、異なる数字のベクトルで表現される。
どちらの文にも "bank "という単語は含まれているが、ベクトルによって捉えられる周囲の文脈によって、両者の意味は区別され、n次元空間内の異なる位置に位置づけられる。
このため、テキストから画像への変換のようなアプリケーションでは、解釈や出力が大きく異なることになる。
類似検索では、"we had a picnic on the bank(川岸でピクニックをした)"というテキストに関連する画像を検索する場合、ベクトルデータベースは金融の銀行(bank)ではなく川岸(bank)を含む画像を検索する。
クラウドフレアのVectorizeは現在パブリック・ベータ版となっており、同社がソリューションを改善する間、サービスにバグや問題が含まれる可能性があることを開発者に警告している。
それにもかかわらず、同社は、開発者がモデルを微調整し、推論を組み込み、アプリケーションに生成AI機能を作成するためのツールを同社のエッジで提供しており、これはエッジのライバルが提供しているものよりもはるかに優れている。
とはいえ、クラウドフレアのWorkers AIとGenAIプロモーション全体には、大きなアスタリスクがある。
これは、推論のためにGPUアクセスを提供しているにもかかわらず、同社が非常に強力なGPUを提供できないため、結果として、非常に強力なモデルを提供できなくなっているためである。
彼らが設計し、OEMのQuantaに製造させたGen12サーバーをベースにしても、エヌビディア(NVDA)のH100を搭載できるわけがない。
クラウドフレアのGen12サーバーの消費電力が700ワットであるのに対し、H100の消費電力は350ワットだったと記憶しており、つまり、サーバーを完全に再設計しない限り、H100を組み込む方法はないということである。
加えて、1チップあたり3万ドルもするH100を購入するという障害もある。
実際、同社のネットワーク関連の設備投資予算は売上高の約8%、GPUの設備投資予算はさらに2~4%で、2024年会計年度の売上高ガイダンスは1億6,500万ドルとなっている。
仮に3%の中間点を使用すると、GPUに割り当てられるのは~5,000万ドルに相当し、1チップあたり3万ドルのH100を1,667枚しか購入できないことになる。
そして、同社の300以上のPoP規模を考慮すると、この影響はごくわずかだろう。
しかし、クラウドフレアがすべてのPoPにエヌビディアのGPUを導入していることは分かっているとすると、彼らはいったい何を購入しているのだろうか?
同社はこの情報を開示していないが、同社がアクセスを提供しているモデルのサイズを踏まえると、データセンターにおいて、AIではなく、グラフィックス用に設計されたエヌビディアのRTX 4000 Ada GPUカードである可能性が高いと見ている。
これらのGPUカードは20GBのGDDR6メモリーを搭載しているが、これは主要で最もパワフルな生成AIモデルの要件をはるかに下回っている。
現実的には、20GBのRAMがあれば、クラウドフレアのRTX 4000 Ada GPUはトップモデルの量子化(パラメータ削減)バージョンを実行し、パラメータ数を〜130億まで減らすことができる。
しかし、これはAIのトレーニングを行うには十分ではなく、AIの推論を行うには十分だが、強力なモデルを作るには不十分である。
クラウドフレアの投資家にとって、これは潜在的な懸念事項である。
というのも、同社はAIの開発を進めているが、ハイパースケーラのようにH100やその他の強力なGPUを手に入れる余裕はないからである。
そのため、オープンソースのモデルにはパラメータ数の少ないものが多く、ドキュメントを見ても80億以上のパラメータを持つモデルは見当たらない。
現状では、生成AI革命の初期段階であるため、同社には問題はないだろう。
特に、AI以外の開発者の仕事量がAI開発者の仕事量をはるかに上回っており、RTX GPUの購入による同社のこれまでの動きで十分だからである。
しかし、同社はネイティブのAIサーバーを持っていないため、GenAIの勢いが増すにつれて不利になる。
典型的なAIサーバーの構成は、H100が8つでCPUが2つだが、今のところ同社のGen12サーバーはGPUが~1/4(H100=1ならもっと少ない)に対してCPUが2つの割合となっている。
つまり、同社がデータセンターの再設計を行わなければ、将来的に不利になるのは明らかである。
エッジ・コンピュートのライバルに対するクラウドフレアのもうひとつの強みは、フロントエンド開発サービスである。
同社は、JAMstack(JavaScript、API、Markupを使用して、高速で安全かつスケーラブルなウェブサイトやアプリケーションを構築することに重点を置いた最新のウェブ開発アーキテクチャ)をネイティブに統合したPagesと呼ばれる専用のフロントエンドサービスを持っており、バックエンドに重点を置いたWorkersを補完し、開発者はスクラッチから細かいUI/UXの検討まで、フルスタックのアプリケーションを構築することができる。
Pagesは、ウェブアプリケーションの安全なフロントエンドを素早く構築するためにJamstackフレームワークを使用している。
アカマイ・テクノロジーズ(AKAM)や他のいくつかのアプリケーションは、同じレベルのネイティブ・フロントエンド機能を備えておらず、サードパーティの統合に頼る必要がある。
しかし、ファストリーは2022年にGlitchを買収して以来、そのようなネイティブなフロントエンド開発能力を持つようになった。
ただし、Pagesは、CDN+エッジ・コンピュートというライバルに対してフロントエンドで優位性があるにもかかわらず、GitHub、ギットラブ(GTLB)、Vercel(これについては後述する)などの他のJAMstackフロントエンド開発製品と比較すると、かなり基本的なものとなっている。
クラウドフレアは、シンプルな要件と、エンドツーエンドのアプリケーション開発を完成させるために、Pagesを開発したが、より複雑な多くの一般的なウェブサイトでPagesが使われているのを見ることはない。
そして、これは、やや不公平な面もあるが、同社にとって不利なことだと解釈することもできる。
なぜなら、同社は多くの自社製品を生み出しているが、そのほとんどは高度に洗練されたものではなく、広範な需要に応えることはできないからである。
次のレポートでは、クラウドフレア(NET)とファストリー(FSLY)との比較について深堀していきたい。
※続きは「③ Part 3:クラウドフレア / NET:エッジ・コンピート分野のファストリーとの競合分析&同社の強み・競争優位性」をご覧ください。