Compute を活用してエッジでコンテンツを作成する新たな方法
Fastly を経由するコンテンツのほとんどは、通常お客様のサーバーで作成されています。しかし、コンテンツを作成する方法は他にもあります。プログラムでコンテンツを作成することは以前から可能でしたが、サーバーレスコンピューティング環境でのコードの構築、テスト、デプロイを可能にする Compute の登場に伴い、Fastly ではよりパワフル、より効率的なコンテンツの作成・変換方法を開発しました。
Web サーバーとエンドユーザーの間に配置されるコンテンツ配信ネットワーク (CDN) は通常、コンテンツをオリジンから取得するのではなく、キャッシュすることでサーバーから遠く離れているユーザーにより素早くコンテンツを配信することができます。これは、スケーラビリティと高いパフォーマンス性を目指す最先端の Web サイトにとって不可欠な要素です。
せっかくサイトの前に CDN が配置されているのに、すべてのコンテンツを同じ場所で生成するのはもったいないことです。エンドユーザーの近くでリクエストを処理するこのパワフルなツールをインフラストラクチャの一部としてもっと活用してみてはどうでしょうか。
初心レベル : ロボット、リダイレクト、CORS
例えば CORS (オリジン間のリソース共有) は、エッジでの実行に大変適したメカニズムです。オリジン間リソースをリクエストする際、ターゲットホストがリクエストに対応できるかどうか確認するために、ブラウザは OPTIONS リクエスト (プリフライトリクエスト) を発行する必要がある場合があります。これに対するレスポンスは、リクエストの発信元であるオリジン名を通知するため、完全に静的なコンテンツではありません。しかし、Computeまたは VCL を使用してエッジで生成するのに十分シンプルなコンテンツです。以下の「RUN」をクリックして、Fastly VCL サービスで試してみましょう。
このような単純なシンセティックレスポンスは、さまざまなユースケースで活用できます。もう一つの一般的なエッジの活用方法はリダイレクトです。リダイレクトは、HTTP から HTTPS への変更、ホスト名の標準化 (Apex ドメインに www. を追加、または削除するなど)、古いパスを新しいパスにマッピングする場合などに使用されます。
エッジでリダイレクトを処理することで、オリジンの負担を削減できるほか、より優れたパフォーマンスをエンドユーザーに提供できるようになります。
もちろん、シンセティックレスポンスはボディコンテンツを含む場合もあります。マイクロサービスアーキテクチャでは、どこから robots.txt のようなファイルを送信すれば良いか迷う場合がありますが、これはエッジで行うと便利です。
中級レベル : エッジで実行する API 配信とビーコンターミネーション
非常に優れた API ゲートウェイとして活用されることが多い Fastly ですが、オリジンを介さずにエッジで API レスポンスを配信できることをご存知でしょうか。特にジオロケーション情報など、すでに Fastly 内でアクセス可能な情報をクライアントに提供したい場合に便利です。この機能を VCL で試してみてください。
Fastly は、膨大な量の情報をエッジアプリケーションに自動的に提供することが可能です。また、Edge Dictionary を使って独自のキーと値のペアのデータセットを追加することもできます。
API と言えば、以前ブログでエッジでのビーコンターミネーションについて詳しく解説しましたが、パフォーマンス性やユーザーエクスペリエンスを測定するためにクライアントから収集しているメトリクスを、すべて自社のサーバーに送信する必要はありません。Fastly 機能の中でも私が特に気に入っているリアルタイムログストリーミング機能を活用することで、インバウンドデータを整理、検証、エンリッチ化、集約することができます。その後、Fastly から直接 S3や Google Cloud Storage、Big Query、Splunk、または自社のコレクターサーバーへ送信することが可能です。
上級レベル : 複雑なページもエッジで完全にテンプレート化
お客様のサイトを何年もの間支えてきたこれらの機能は、今では VCL と Compute の両方で実行可能になりました。しかし、VCL ではアップストリームから受信した API データを処理し、レスポンスボディを作成することができませんでした。キャッシュなど、さまざまなソースから並行して効率的にデータを読む込んだりクエリを実行し、エッジに保管されたテンプレートを使用して HTML ページを生成するーーこれは、非常にパワフルな機能です。
オリジントラフィックの削減、デバッグの簡素化、問題の分離、より高速なユーザーパフォーマンスなど、アプリケーションのビューレイヤーを完全にエッジに移動するのとほぼ同じメリットが得られます。
先日、同僚の Kailan Blanks が Computeで Rust を使ってこの機能を気象情報アプリで応用する手順を紹介したチュートリアルを Deverloper Hub に追加しました。最終的なアプリは、このようにページのフレーム内で実行することができます。
このアプリは、大規模なアプリケーションをエッジで構築する際に必要な要素がすべて含まれた、非常に優れた例です。
プラットフォーム機能 : Fastly のジオロケーション API を利用したエンドユーザーの位置情報の取得と、Edge Dictionary による動的設定の保存。
オリジンへの API リクエスト : Rust SDK 内の Request 構造体の send() メソッドによる、Fastly のエッジキャッシュを介した Openweathermap へのリクエスト送信。
コミュニティライブラリ : serde_json による Openweathermap からの API レスポンスの解析と、tinytemplate を使った魅力的な HTML ページの作成。WebAssembly にコンパイルするモジュールやライブラリを自由に使用できます。
コンテンツがキャッシュ不可能だと見なされる主な原因は、さまざまなデータが寄せ集められて構成されていることにあります。例えば、完全に形成された HTML ページは、現在のユーザー名、URL に基づいた記事、そしてページへのリクエストの発信元の国向けのリンクなどによって構成されている場合があります。
Vary ヘッダーのパワフルな機能によって、このようにさまざまな種類のキャッシュ可能なオブジェクトを分離することができますが、種類が多すぎる場合は別の方法が必要になります。このような場合、エッジで直接テンプレート化すると非常に便利です。ページを構成するデータの各要素を別々にキャッシュすることができるため、コンテンツのパーツを適切につなぎ合わせて動的ページを組み立てることが可能です。
数か月前、エッジネイティブアプリケーションの新しい構築方法に関する記事を公開しましたが、テンプレート化をエッジに移行するのは、実は結構簡単です。パフォーマンスを改善したいページでぜひ Compute をお試しください。
