はじめに

Fastly といえば CDN のイメージをもっている人が多いと思いますが、CDN と共通のプラットフォーム上でアップロードしたプログラムのコードを動作させる、いわゆる Edge Computing (プロダクト名は Fastly Compute）も提供しています。

おかげさまで Fastly Compute も少しずつ利用事例などが増えてきていますが、CDN と Computing の使い分けについて質問を受けることが多くなってきました。

この記事ではどのようなケースで CDN を利用し、どのようなケースで Computing を利用するのがよいかについて解説してみたいと思います。

それぞれのサービスの概要

まず最初にそれぞれのサービスの概要について確認してみたいと思います。

Fastly CDN

CDN は Content Delivery Network の略で、CDN 事業者は一般的にグローバルに大きなネットワークと多数のサーバーを保持しています。

エンドユーザーからのリクエストは最適な（通常は距離的に近い）CDN サーバーに誘導され、CDN サーバーがお客様のコンテンツを保持するサーバー（オリジンサーバーと呼びます）に代わって配信することで安定して高速に Web コンテンツを配信することが可能になります。

CDN サーバーがリクエストを受けたタイミングでコンテンツを持っていない場合、オリジンサーバーからコンテンツを取得してクライアントに配信を行い、同時に以降のリクエストに備えてサーバー上にキャッシュ（コピーを保持）します。

また、Fastly CDN では画像の最適化やリクエストとの条件に基づくロードバランシングなど、単にキャッシュして配信する意外にもさまざまな処理を CDN 上に実装することができます。

Fastly Compute

Fastly Compute プラットフォームは Fastly が保持する CDN と同一のグローバルネットワーク上で、お好みの言語でコードを実行する高度なエッジコンピューティングシステムです。コードを WebAssembly にコンパイルすることで、セキュリティと移植性が確保されます。コードは Wasmtime を使用して実行されます。

現在 Fastly Compute の SDK でサポートされている言語は Rust, JavaScript, Go の３種類です。

Compute プラットフォームを使用すると、データストア、動的構成、リアルタイムメッセージングなどの Fastly エッジプリミティブにアクセスできます。このプラットフォームはスタックのすべてのレイヤーで完全に言語に依存しないため、好みのパッケージレジストリから依存関係を含めることができます。

認証、パーソナライゼーション、ジオフェンシング、SEO、可観測性、テンプレート、API、さらにはアプリケーション全体など、思いつくものはすべて Compute プラットフォームで実行できます。

Fastly CDN と Compute の使い分け

それではここからが本題です。Fastly CDN と Compute の使い分けについて複数の観点から考えてみます。

Fastly では特定のドメインに対して Fastly CDN か Fastly Compute のどちらかを選択して利用することになります。
CDN を利用しながら特定のパスだけ Compute を使用する、といった使い方は出来ません。今後こういった使い方もサポートしていく予定となっていますが、2024年11月時点ではこのような使い方は未サポートとなっています。

機能

Fastly CDN

名前の通り CDN 機能が簡単に利用出来ます。キャッシュをして配信するというCDN の基本機能以外にも画像の最適化機能や VCL をつかって条件に応じたロードバランシングや認証処理など、ちょっとした処理を CDN 上に実装することも可能です。

Fastly Compute

Fastly Compute プラットフォームは高度なエッジコンピューティングシステムであり、開発者が選んだ言語で記述されたコードをグローバルエッジネットワーク上で実行することが出来ます。

CDN と同じような挙動をするプログラムを実装することも可能ですし、オリジンサーバーレスで動作するアプリケーションを構築することもできます。

設定作成の難易度

一般的には CDN の設定の方が難易度が低いです。シンプルな CDN の設定であれば対象のドメインとオリジンサーバーを指定するだけで設定は完了します。

ただし、複雑な処理を行いたい場合は VCL を書く必要が出てきます。VCL でも if 文による条件分岐や正規表現の利用、サブルーチン内での変数、クエリパラメタの制御、関数の作成などプログラム的な処理を実装することが可能です。
ただし for loop はサポートしていないなど、設定言語としては柔軟ですがプログラム言語と比較できるレベルではないです。

また、既に Rust, JavaScript, Go でのコーディングに馴染みがあるのであれば、新たに VCL を理解するよりも Compute で使いなれた言語で処理を実装する方が楽に感じる方もいるかもしれません。

Fastly CDN、Compute　のそれぞれの設定は以下のような手順で作成します。

Fastly
最小限の設定としては UI もしくは API で対象のドメインとオリジンサーバーを指定するだけで設定を作成することが出来ます。
TTLの細かい制御や条件に応じた挙動が必要な場合は UI で設定、もしくは VCL のコードを直接記載して追加していきます。

Fastly Compute
Fastly SDK を利用して Rust, JavaScript, Go から選択した言語でプログラムを作成する必要があります。SDK には Starter Kit が含まれており、これをベースに必要な動作を行う設定をコーディングしていきます。

コンテンツの作成

Fastly CDN

インターネット上に存在するオリジンサーバーから取得してきたコンテンツをキャッシュして配信します。
Fastly CDN にも Synthetic Response という簡易的な静的なレスポンスを作成する機能はありますが、取得してきたコンテンツの中身そのものに変更を加えることが出来ません。

Fastly Compute

取得してきたコンテンツの内容を変更したり、複数のロケーションから取得したコンテンツを組み合わせてひとつのレスポンスを生成することが得意です。

オリジンサーバーレスでリクエスト内容に応じたレスポンスを生成して返却したりすることも可能です。
完全なデータベースのような機能はまだ実装されていませんが、KV ストアなどの機能はあるので、グローバルでのリアルタイム性が求められないのであれば保存された KV ストアの値に応じて処理を制御してコンテンツを生成することも可能です。

パフォーマンス

Fastly CDN(VCL) と Fastly Compute で実現可能なことが異なるため単純な比較は難しいのですが、例えば Compute で CDN 相当の機能を実装した場合について考えてみます。

単純な CDN の実装（Readthrough Cache を一回くぐらすだけ、のようなもの）は Compute 的には send() や fetch() の処理待ちというイメージになるので、VCL での処理時間とも大差ない可能性が高いです。

restart を使う処理は Compute の方が早くなるケースもあるかと思います。

複数のオリジンにアクセスして処理を決定する（いわゆるプリフライトリクエスト）の場合、VCL では一度特定のオリジンにアクセスしてレスポンスを受け取ってから restart する必要がありますが、Compute の場合は並行して複数のオリジンにアクセスして処理を実行することが出来ます。

その他複雑な文字列処理や、リクエスト処理を行う場合、Compute 側での言語選択やコード実装にも依存しますが Compute の方が早いケースも出てくると考えられます。

ただ、いずれにせよクライアントから見た CDN のパフォーマンスは CDN サーバーとの接続性などが占める割合も大きいため、CDN 相当の機能を Compute で実装しても VCL で利用しても全体のパフォーマンスとしては実効的な差異が出るケースはそれほど多くないと思われます。

なお、統計的なデータがあるわけではないのであくまで個人的な見解である点ご了承ください。今後追加で何かデータ等が入手できた場合は記事内容を更新したいと思います。

コスト

契約形態にもよりますが、Fastly のオーソドックスな課金形態としてはざっくり以下のようになっています。

Fastly CDN
リクエスト数 + 配信容量(GB)

Fastly Compute
リクエスト数 + 配信容量(GB) + Compute で処理したリクエスト数

リクエストや配信は CDN でも Compute でも発生するので CDN、Compute 双方で発生します。

Compute の場合はそれに加えて(配信容量と比較すると少なめではありますが) Compute の利用料金が発生します。

まとめ

キャッシュ配信やロードバンランサー、画像変換など CDN（VCL)で出来ることであれば特にこだわりがない限り CDN で実装することをお勧めします。理由としては以下のような点があげられます。

工数をかけずに設定（と VCLコード）だけで利用可能
VCL の豊富で成熟した機能を利用することが出来る
コスト的にも Compute よりも抑えることが出来る

ただし、キャッシュの処理などを VCL で制御するのではなくコードで制御・管理したい、VCL ではコードが肥大化してしまう、ということであれば CDN 的なサービスを Compute で実装することも問題ありません。

Compute からキャッシュを制御するための機能(API)もどんどん充実してきていますので、機能的には問題となるケースは少ないと考えられます。

逆に CDN で出来ないことを実現したい場合は必然的に Fastly Compute を選択することになります。