Fastly Fiddle で Compute@Edge のコードのテストが可能に

すでに一般公開されている Compute@Edge は、色々な意味で VCL からの大きな変化を意味しますが、私たちの Fiddle へのアプローチは全く異なります。お客様は Fastly が提供するローカルサーバーをご自身のマシンで実行して Compute@Edge で作成されたプログラムをテストすることができます。そのため、Fiddle のアプローチが異なる一番の理由を理解するには、なぜ Fiddle が便利なのかをまず把握する必要があります。

Compute@Edge での構築に Fiddle ツールが役立つ理由

コードをローカル環境でテストする機能があっても、Compute@Edge で構築するために Fiddle ツールを利用するメリットはたくさんあります。その中でも特に大きなメリットの一つは、developer.fastly.com で提供されているサンプルコードをドキュメント内ですぐに実行できることです。また、今読んでいるこのブログ記事内でも可能です。以下の RUN をクリックすると、その場ですぐに確認できます。

Fiddle では、サンプルコードを瞬時に試すことができるだけでなく、コードの共有にも最適です。お客様が Fiddle を利用して問題や質問を提起すると、Fastly の有能で粘り強いサポートチームが Fiddle を利用してソリューションやアイディアを提供することがよくあります。lint 機能が搭載され、瞬時にフィードバックを返す Fiddle を使用することで、共有したコードが想定通りに動作することを確認し、コピー & ペーストのミスやセミコロンの位置の間違いなどによって生じる時間の無駄を防ぐことができます。

Compute@Edge のコードにも対応

ユースケースはほぼ同じかもしれませんが、Compute@Edge のコード構造は VCL と大きく異なります。VCL サービスでは、ウィンドウやフックなど、事前に定義された複数の「サブルーチン」でカスタムコードの実行が可能なステートマシーンが使用され、さまざまな段階でリクエストとレスポンスのサイクルにアクセスできます。VCL コードを全く記述しなくても、標準のキャッシュリバースプロキシとしてサービスは稼働します。それとは対照的に、単一のエントリーポイントを擁する Compute@Edge のプログラムの場合、ユーザーがリクエストとレスポンスの全サイクルの責任を負います。Compute@Edge でコードを全く記述しない場合、サービスは起動しません。

これに対応するため、Fiddle で VCL 以外の言語を選択した場合、見慣れた VCL のサブルーチンボックスが消えて、「MAIN」と書かれた単一フィールドが表示されます。このフィールドにコードを記述します。Compute@Edge では、プログラムが起動するのに最低限の量のコードが必要なため、シンプルなボイラープレートがあらかじめ Fiddle に入力されています。これだけでも機能するので、興味があれば、好きな言語を選択して RUN をクリックしてみてください。Fiddle を設計した際に最も重視したことの一つは、実際に機能する設定をワンクリックで開始できることです。面倒なセットアップが不要なので、すぐにイテレーションを始めることができます。

Fastly Fiddle で VCL を使用する場合、リクエストを実行すると、実行された VCL サブルーチンを含む、一連のインストルメンテーションが表示され、リクエストがキャッシュサーバーでどのように処理されたのかを把握できます。一方、Compute@Edge の場合、若干異なります。

Compute@Edge のインストルメンテーション

Fastly がリクエストを処理する際、Compute@Edge と VCL で共通の部分があります。Compute@Edge の場合でも、以下が表示されます。

• クライアントのリクエストのレスポンス

• オリジンへのあらゆるリクエストとレスポンス

• ログエンドポイント (Compute@Edge の場合、stdout と stderr を含む) に送信されるあらゆるコンテンツ

しかし「サブルーチン」は存在しないため、表示されません。その代わりにインスタンスイベントが表示され、通常インスタンスの開始と終了が示されます。これらのインスタンスは、以下のように緑で表示されます。

最もエキサイティングなのは、ホストコール、すなわち、リクエストをオリジンサーバーに転送するなど、Wasm ランタイム外の動作をトリガーするためにコードが行う呼び出しを表示できることです。VCL サービスの場合、ネイティブコードとして実行されるためホストコールを行うことはなく、VCL コンパイラによって安全性が保証されています。一方 Compute@Edge の場合、Wasm によって提供される安全性の保証には、サービスがプログラムの外にあるリソースを呼び出すと、それを表示し、インストルメントできるという副次的メリットがあります。

Fiddle では、ホストコールと地理的位置の検索をサポートする機能の統合を開始しました。

今後数か月の間にこれをさらに拡大し、ディクショナリや ACL の検索、キャッシュとのやり取りなど、VCL プログラムでは効果的にインストルメントできなかったことをレポートできるよう取り組みます。

依存関係の特定

VCL と Compute@Edge の主な違いの一つは、Compute@Edge のプログラムにはインポートされたパッケージに依存関係が存在する可能性があることです。一方、VCL ではユーザーがインポートを定義することはできません。Compute@Edge の場合、パッケージマニフェストで宣言されたインポートはコンパイル時にプログラムに組み込まれますが、セキュリティ上の理由から、Fiddle では crates.io や npm からインポートすることはできません。今のところ、最も広く使用されている依存関係 (Fastly の Developer Hub に JavaScript と Rust 向けのリストがあります) を定義したので、皆さんのコードでこれらを使用できます。これは Rust Playground などのツールで使用されているアプローチと似ています。

npm モジュールを要求する、またはインポートするだけで、あたかもプロジェクトにすでに存在していたかのようにスケッチに追加できるという、Runkit が採用しているアプローチは非常に優れています。しかし、このようなことを実行するには言語特有の解析が必要になり、これは、可能な限り多くの言語で機能を利用できるようにしたい私たちとしては避けたいことです。Fastly は今後もこの課題への取り組みを続け、より多くの依存関係に対してより効果的なサポートを提供できるよう努めます。

その間も、Fiddle を使用して何百ものユースケースが Compute@Edge で構築されることでしょう。

実際に試してみましょう

興味がおありでしたら、ぜひお試しください。まだ Compute@Edge をご利用でない場合は、今すぐ登録して、サーバーレスのパワーを実感してください。現在 Fastly では、コミットメントなしで Compute@Edge を試すことができる、無料トライアルキャンペーンを実施しているので、ぜひご利用ください。