オリジン不要、静的Webサイトをエッジから配信

世界のWebサイトの多くは静的サイトで、Fastly のコンテンツ配信ネットワークはこれらのページを素早くオリジンからビジターに届けます。ここで、このプロセスからオリジンを取り除くことができるとしたら、皆さんどう思いますか。

Webサイトの構築に静的サイトジェネレーターをお使いでしょうか。create-react-app や Gatsby、Docusaurus、Vite など、静的ファイルを出力する人気のフレームワークを使用している方もいるかもしれません。シンプルに、静的ファイルを配信する必要があるだけという場合もあるでしょう。compute-js-static-publish を使用すると、圧倒的なスピードを誇る Fastly の Compute@Edge プラットフォームにすべてをデプロイして配信できるようになります。

静的 Web はまだまだ広く使用されています。もちろん多くのWebサイトはインタラクティブですが、ブログ、リファレンスページ、商品情報のページなど、Web の多くは、もともと静的な性質を持っています。ページのコンテンツは、何らかのファイルやコンテンツ管理システムで変更・更新され、Webサイトは最も新しいバージョンのデータを配信します。 

一部のWebサイトでは Gatsby のような静的サイトジェネレーターが使われています。このようなツールは、Markdown や HTML のソースデータとテンプレートを組み合わせてWebサイト全体をビルドします。例えば Fastly のすべてのチュートリアルと参考資料が掲載されている Developer Hub では、Gatsby が使われています。また、Fastly の 「expressly」に関するサイトでは Docusaurus が使われています。どのツールを使うにしても、こうしたジェネレーターは一般的に、ファイルのバンドルを出力として作成します。

これらのファイルは通常 Web サーバーにアップロードされ、静的に配信されます。最近では、Fastly などのコンテンツ配信ネットワークをサーバーの前に配置して、世界中でWebサイトをキャッシュできるようにすることが一般的にベストプラクティスとされています。

ここで一歩下がって考えてみましょう。この時点で Web サーバーが行っているのは、CDN 向けにWebサイトの完全なコピーを保存して、キャッシュできるようにすることのみです。各 POP にはWebサイトのサブセットの一部が保存されている可能性があります。

Webサイト全体を Fastly にアップロードできる仕組みがあったら、どうなるでしょうか。すべての POP にWebサイトの配信に必要な全ファイルが保存されるため、オリジンが不要になります。

エッジへの静的パブリッシング

最近リリースされた Fastly の開発ツールを使用すれば、これが可能になります。@fastly/compute-js-static-publish はコマンドラインツールかつランタイムライブラリです。オリジンサーバーを必要とせず、静的Webサイトを完全にエッジで配信できるようにすることを目的としています。

「public」というディレクトリに、Webサイトに必要なファイルがあるとして、以下のコマンドを入力します (NodeJS 16 以降がインストールされているものとします)。

npx @fastly/compute-js-static-publish --public-dir=./public

これにより、compute-js というディレクトリに Compute@Edge アプリケーションが生成されます。この生成されたプロジェクトの src/index.js ファイルには、静的ファイルを配信するためのコードが含まれています。

これで Fastly のローカル開発サーバーでサイトをテストできるようになりました。Fastly CLI がインストールされているものとして、以下を入力します。

cd ./compute-js
fastly compute serve

これで http://localhost:7676/ を訪問するとWebサイトが閲覧できるようになりました。

サイトを公開する用意ができたら、最後に以下のコマンドを使用します。

cd ./compute-js
fastly compute publish

fastly compute serve または fastly compute publish を実行して Compute@Edge プロジェクトをビルドするたびに、compute-js-static-publish は public ディレクトリをスキャンして Compute@Edge プログラムを再生成します。

静的ファイルはどこへ？

ソースファイルのコンテンツはすべて、Fastly にデプロイできる単一の Wasm バイナリにコンパイルされます。

生成された src/statics.js ファイルに秘密の鍵があります。中をのぞいてみると、このような行が見えるはずです (正確なコンテンツは、プロジェクトに含まれるファイルによって異なります)。

import file0 from "../../public/index.html?staticText";
import file1 from "../../public/main.css?staticText";

export const assets = {
  "/index.html": { contentType: "text/html", content: file0, module: null, isStatic: false },
  "/main.css": { contentType: "text/css", content: file1, module: null, isStatic: false },
};

これらの行は、Asset Modules と呼ばれる Webpack の機能を活用してビルドされたモジュールに静的ファイルを含めます。この機能によって、指定された各ファイルに、各参照ファイルのコンテンツを値とするモジュールが作成されます。このツールは、アプリケーションがビルドされるたびに public ディレクトリをスキャンし、この src/statics.js ファイルを再生成するため、ディレクトリにすべてのファイルが揃います。各ファイルのコンテンツがこのファイルによってエクスポートされた assets オブジェクトに保管されます。オブジェクトではプロジェクトディレクトリと関連する、各ファイルのファイル名がキーとなります。

例えば、index.html file のコンテンツを確認するには、assets['/index.html'].content の値を取得するだけです。

バイナリ (非テキスト) ファイルの場合、プロセスはもう少し複雑ですが、基本的な概念は同じです。詳しく知りたい場合は、Webpack の asset/inline に関するページを読むことをお勧めします。また、このツールが作成した生成コードについて読むことで、Fastly でのバイナリファイルの処理について理解が深まります。

結果的に、@fastly/compute-js-static-publish を使用すると、ファイルはオリジンなしですべて Fastly POP に格納されます。つまり、以下の図のようになります。

もう1つ注意が必要な点は、Compute@Edge の Wasm バイナリに対する制限と制約です。特に、コンパイルされたパッケージサイドが 50 MB を超えないようにする必要があります。これは圧縮されたパッケージサイズであるため、50 MB を超えるソースファイルを含めることができる可能性はありますが、この制限に留意してください。

すべてを統合

compute-js-static-publish によって現在のサイトの構築方法やデプロイ方法がどのように変わるのでしょうか。すでに継続的インテグレーション (CI) を使用してサイトをデプロイしている場合、CI から Fastly に直接パブリッシュできます。そうでない場合は、GitHub Actions および Compute@Edge で GitHub Actions を使用する方法をご確認ください。

compute-js-static-publish コマンドでは引数を提供してサービス ID を指定することが可能なため、デプロイのパイプラインに統合できます。現在のセットアップが以下のようになっている場合 :

最後の2ステップを以下のように置き換えます。

最後のステップは以下のようになります。

npx @fastly/compute-js-static-publish --public-dir=/path/to/built/site --service-id=<YOUR_SERVICE_ID>
cd compute-js
fastly compute publish

これで Web サーバーにファイルをアップロードする必要がなくなりました。エッジプログラムにすべての静的アセットが含まれているため、パージのステップも必要ありません。パッケージが Fastly のエッジノードに伝播されると、すべてに更新済みのコンテンツが行き渡ります。

各種の静的サイトジェネレーター向けプリセット

このツールを設計していた時、さまざまなサイトジェネレーターを使用している同僚から社内フィードバックを受けました。多くの場合、使用しているサイトジェネレーターの種類に基づいた手順を説明する必要がありました。通常、サイトジェネレーターは種類によってそれぞれ異なる方法で出力を生成します (出力ディレクトリ名が異なるなど)。しかし、同じジェネレーターを使用しているユーザーは全員、同じ設定を使用しています。そこで私たちはプリセット、つまり特定のジェネレーター向けのデフォルト設定を取り入れることにしました。もちろん、必要に応じて個々の設定をオーバーライドすることも可能です。

<u>create-react-app</u> を使用してアプリケーションのブートストラップを行うとします。ユーザーは npm run start コマンドを使用して開発サーバーを起動し、公開する準備が整ったら npm build を実行します。これによりすべての出力ファイルが build というディレクトリに配置されます。また、静的ファイル (永久にキャッシュ可能なハッシュ化されたファイル名を持つファイル) は build/static というディレクトリに配置されます。つまり、これらのディレクトリ名を compute-js-static-publish コマンドに提供するのではなく、以下をただ実行するだけで済みます。

npx @fastly/compute-js-static-publish --preset=create-react-app

現時点では、Vite、SvelteKit、Gatsby、Docusaurus、Next.js 向けのプリセットが利用可能です (バンドルは next export コマンドを使用して作成されます)。

あらゆることを実行できるプラットフォームとしての Compute@Edge

Compute@Edge はあらゆることをエッジで実行できる可能性を秘めた汎用コンピューティングプラットフォームです。Fastly では、今回ご紹介したようなツールを使用してこのプラットフォームで実現できることについて、さらに多くのアイデアをお客様に提供していきたいと考えています。

私たちは、お客様がエッジでさらに多くのコードを実行し、より迅速に開発できる環境を提供できるよう努めています。その一環として、新しいものから使い慣れたものまで、お客様がさまざまなツールを活用できるよう取り組んでいます。お客様はこのようなツールをお使いでしょうか。また、どのような用途にお使いでしょうか。ぜひ Twitter で Fastly までお知らせください。