Azure Front Door エッジ アクション (プレビュー) を使用したエッジでのカスタマイズ

適用対象: ✔️ Front Door Standard ✔️ Front Door Premium

Azure Front Door Edge actionsは、組織がMicrosoftのグローバルなAzure Front Door PoP拠点でカスタムJavaScriptロジックを直接実行できるようにする変革的な機能です。 最新のウェブアプリケーション向けに設計されたEdge Actionsは、ユーザーのリクエストや応答に対して超低遅延でビジネスロジックの実行を可能にします。

この機能は、デジタルトランスフォーメーションの時代における安全でスケーラブルかつインテリジェントなコンテンツ配信の需要増加に応えています。 企業が増大する脅威やパフォーマンスの期待に直面する中、Edge Actionsはリクエストとレスポンスの最適化、セキュリティ体制の強化、オリジンロードの削減、そして高い可用性とパフォーマンス基準を維持する強力なソリューションを提供します。

Important

Azure Front Door Edge Actionsは現在プレビュー中です。 ベータ版、プレビュー版、または他の方法で一般公開されていない Azure の機能に適用される法的条件については、Microsoft Azure プレビューの追加利用規約を参照してください。

Azure Front Door エッジアクションを示す図。

サポートされている機能

プレビュー中、Edge Actionsは クライアントリクエスト呼び出しのみをサポートし、以下のシナリオをサポートします:

  • A/B テスト
  • リクエストおよびレスポンスヘッダー操作
  • リクエスト拒否
  • 動的オリジン選択
  • URL 書き換え
  • URL リダイレクト
  • JWTトークン検証

サポートシナリオ向けのJavaScriptコードサンプル

過去のユースケースのサンプルは、Azure/EdgeActionsSamples GitHubコミュニティリポジトリから入手可能です。

エッジアクションのサイズとリソース制限

プレビュー中、各エッジアクションリソースには以下の制約があります:

  • コードサイズ:16 KB
  • バージョン数:3
  • 実行時間:10 ms
  • サブスクリプションあたりの最大エッジアクションリソース数:100

現在 、JavaScript のみがサポートされている言語です。

サービス制限の詳細については、「Azure Front Door Standard and Premium service limits」をご覧ください。

重要な考慮事項

  • リクエストに対して実行されるコードの1つのバージョンをデフォルトバージョンに設定します。
  • コードにサポートされていないメソッドは実装しないでください。
  • このサービスは最大10msのコード実行をサポートします。 この制限を超えると、サービスはコード実行を終了し、Edge Action処理なしでリクエストを送信します。
  • クライアントのリクエストに対して実行される前に、Azure Front DoorルートにEdge Actionを付与する必要があります。
  • Edgeアクションの作成と接続は、ポータルUIやVisual Studio Code拡張機能を使って行えます。

エッジアクションを用いた高レベルフロー

以下の図は、Edge Actionsを使用した場合のAzure Front Doorエンドポイントへの要求と応答の高レベルな流れを示しています。

Edge Actionsが使用されているAzure Front Doorエンドポイントへの高レベルのリクエスト/レスポンスフローを示す図。

ユーザーがAzure Front Doorがフロントするリソースにリクエストを開始すると、そのリクエストはAzure Front Doorのルーティングアーキテクチャに従います。 詳しくは、ルーティング アーキテクチャの概要をご覧ください。 ルートにエッジアクションを付けると、リクエストは次の流れに従います:

  1. リクエストはAzure Front Door edgeのPoP位置のいずれかに届きます。

  2. リクエストはAzure Front Doorのプロファイルに一致します。

  3. ドメインがWAFルールで有効化されている場合、Azure Front Doorがそれらを評価します。 そうでなければ、このステップは省略されます。

  4. リクエストがAzure Front Doorのルールエンジンで設定されたルールと一致すれば、Azure Front Doorが処理します。

  5. リクエストがエッジアクションを呼び出しるルールと一致すると、ルールエンジンはエッジアクションを呼び出し、リクエストはエッジアクションにルーティングされます。

  6. Edge ActionはHyperlightサンドボックスを作成し、以下を読み込みます:

    1. カスタムかつ安全なJavaScriptランタイム。

    2. サーバー変数のすべてのデータ、マッチングされたルート内の健康な起源のリスト、ユーザーのリクエスト発信国コード、リクエストのユーザーエージェントヘッダーからのデバイスタイプ、現在の日付・時刻スタンプを含む不変コンテキスト変数。

    3. デフォルト設定のEdge Actionsコード。 実行フィルターが設定され、対応するヘッダーが設定されていれば、設定されたバージョンが実行されます。

  7. Edge Actionsコードはリクエストを実行し修正し、キャッシュにコンテンツがあれば応答を送信するか、リクエストを発信元に送信して応答します。

エッジアクションの作成と管理

  1. Azure portal にサインインする

  2. ポータル上部の検索ボックスに「 Edge Actions」と入力してください。 検索結果から 「エッジアクション 」を選択してください。

  3. [+ 作成] を選択します。

  4. エッジアクションの作成」で必要な詳細を入力または選択してください。

    エッジアクションを作成するための基本タブを示すスクリーンショットです。

  5. [確認と作成] を選択し、次に [作成] を選択します。

  6. 展開が完了したら、「 リソースへへ行く 」を選択してEdge Actionリソースページに移動します。

    Edge Actionの概要ページを示すスクリーンショットです。

Edge Actionの新しいバージョンを作成

クライアントのリクエストを成功裏に実行するためには、各エッジアクションには少なくとも1つのコードバージョンオブジェクトとアップロードされたJavaScriptファイルを含める必要があります。 バージョンを使うことで、複数のバージョンを同時に利用可能にしつつ、Edge Actionsのアップデートを安全に管理・リリースできます。 新しいバージョンをアップロードしてデフォルトに設定すれば、切り替え時にダウンタイムが発生しません。 最新のコードに問題が発生した場合は、簡単に前のバージョンに戻すことができます。 各エッジアクションごとに 最大3つのバージョン を作成できます。

  1. エッジアクションの設定で「バージョン」を選択してください。

  2. [+ 追加] を選択します。

  3. バージョン名を入力し、JavaScriptコードをアップロードします。

  4. リクエストのデフォルトにしたいなら「 デフォルト設定 」を選択し、作成を完了するには 「OK 」を選びます。

    この操作は新しいバージョンを作成し、JavaScriptコードをアップロードします。 ポータルは両作業の状況を別々に表示します。 (プレビュー期間中は、 アップロードコード 操作に最大10分かかることがあります。)

  5. 新しいバージョンが作成されると、ポータルはプロビジョニング状態を 成功したと表示します。

    バージョンリストを示すスクリーンショットです。

  6. JavaScriptコードの内容を検証したい場合は ダウンロードコードを 選択してください。 EdgeActionCodeというZIPフォルダをダウンロードして、そこにあなたの.jsファイルが入っています。

Azure Front Door ルートにエッジ アクションをアタッチする

この構成の部分が最も重要です。 現在、Edge Actionsを呼び出すのはAzure Front Doorのルート設定のみです。 Edge ActionをAzure Front Doorルートにアタッチする方法は3つあります:

  1. Azure Front Door プロファイルでの簡単なアタッチ体験

  2. Azure Front Door プロファイルで新しいルールセットを作成する

  3. Edge Actionリソースにビューを付ける

Azure Front Door プロファイルでの簡単なアタッチ体験

このフローは、Azure Front Doorルールエンジンに馴染みがなく、Edge ActionをAzure Front Doorに付けたいユーザーにとって有用です。

Note

  • カスタムルールセット名、カスタム条件、アクションなどの高度な操作については、ルールエンジンのUIをご利用ください。
  • 簡単なアタッチ作成フローは、デフォルトのルールセットが存在するかどうかを確認します。
  • 存在しない場合は、デフォルトの呼び出しルールもあわせて作成します。 もしデフォルトのルールセットに別のエッジアクションのデフォルトルールがある場合、フローは新しいエッジアクションを付けるための番号インクリメント付きデフォルトルール(例:002)を作成します。
  1. Azure portal で、Azure Front Door プロファイルに移動します。

  2. 設定で「Front Door Manager」を選択し、そのエンドポイントを選択します。

  3. ルートセクションでルート名を選択してください。

  4. Update route で下にスクロールして、Attach Edge Actions リンクを選択します。 このリンクをクリックするとポップアップペインが表示されます。 そのサブスクリプションで利用可能なすべてのEdge Actionsと対応するデフォルトバージョンが表示されます。

    ルートの更新方法を示すスクリーンショットです。

  5. 付けたいエッジアクションを選択し、その後「 アソシエイト 」を選択して選択を確認します。

    エッジアクションの付け方を示すスクリーンショットです。

  6. 変更をコミットするには 「更新 」を選択してください。

Azure Front Door プロファイルで新しいルールセットを作成する

このフローはより複雑で、エッジアクションをルート構成に関連付ける前にルールセットを手動で作成する必要があります。 大まかに言うと、以下のステップを踏みます:

  1. Azure portal で、Azure Front Door プロファイルに移動します。

  2. 設定の中からルールセットを選択してください。

  3. 新しいルールセットと必要な条件付きルールを作成します。 アクションを「 エッジアクションの呼び出し」として選択してください。

  4. ルールセットの作成を完了するには 「保存」 を選択してください。

    ルールセットの設定を示すスクリーンショットです。

  5. このルールセットは他のルールセットと同様にルートに関連付けます。 詳細については、「 ルールセットの設定」をご覧ください。

Edge Actionリソースにビューを付ける

Attachmentsを通じてエッジアクションにルートを関連付けることができます。

  1. エッジアクションの設定から「添付ファイル」を選択してください。

  2. + 関連付けルート を選択し、対応する Azure Front Door プロファイルを選択します。

    Edge Action Attachmentを使ってルートをアソシエイトする方法を示すスクリーンショットです。

  3. 次へ 」を選択し、その後ルート名を選択します。

  4. 次へ 」を選択してルールセットを設定し、その後「 保存」を選択します。

    ルートの関連付けが完了すると、Edge Actionsの 添付 ファイルビューで追加したルートの詳細を確認できます。

Edge Action が添付されていることを確認します

Azure Front Doorルートで対応するEdge Actionが付加されているかどうかを確認できます。

  1. Azure Front Door の Settings で、Front Door manager を選択してください。

  2. 確認したいルートを選択してください。

  3. ルートの更新「エッジアクション管理」を選択してエッジアクションの詳細を確認するか、切り離してください。

    Edge Actionの詳細を確認する方法を示すスクリーンショットです。

ルートからエッジアクションを切り離す

エッジアクションをルートから切り離すには、前述のルートか、エッジアクション自体から以下の方法で行くことができます。

  1. エッジアクションの設定から「添付ファイル」を選択してください。

  2. 切り離したいエッジアクションを選び、「 Dissociate」を選択してください。

    ルートからエッジアクションを切り離す方法を示すスクリーンショットです。

実行フィルター

実行フィルターは、Azure Front Doorルート上でどのバージョンのエッジアクションを実行するかを制御します:

  • 選択的バージョンルーティング: 実行できる のはデフォルトのバージョン と、実行フィルターが明示的に参照するバージョンのみです。 実行フィルターは デフォルトバージョンを上書きできます。

  • バージョン保護: 実行フィルターが参照するバージョンはアクティブです。 使用中は削除やアップグレードはできません。

  • ゼロダウンタイムスイッチング: 実行フィルターにより、ダウンタイムや複雑な設定更新なしに シームレスなバージョン移行 が可能になります。

実行フィルターは以下のシナリオに適しています:

  • カナリア展開

  • ヘッダーベースルーティングによるA/Bテスト

  • 新しいバージョンの安全な展開と検証

実行フィルターを適用してください

Edge Actionの新バージョンを安全に本番環境に展開するには、以下の手順に従ってください。

  1. Edge Actionの設定でバージョン 」を選択して、持っているバージョンを確認してください。 以下の画像は2つのバージョンを示しています。 最初のバージョンがデフォルトで、第2バージョンがあなたが展開したい新しいバージョンです。

    バージョンの一覧を示すスクリーンショット。

  2. 実行フィルターを選択します。

  3. +追加を選択して、次の画像に示すように、要求に test という名前の HTTP ヘッダーがあり、その値が execution である場合に Second バージョンを実行する新しい実行フィルターを作成します。

    実行フィルターの追加方法を示すスクリーンショットです。

  4. クライアント側では、これらの HTTP ヘッダーをドッグフード リクエストに指定し、対応するバージョンに登録した選択済みの顧客に対して Second バージョンを使用することで、新しい動作をテストします。 すべてが満足のいくものに見えたら、このバージョンをEdge Actionsリソース側のデフォルト設定にしてください。

以下のログでは、 First は通常のリクエストに対して動作し、 Second はリクエストにヘッダーを注入すると実行されていることがわかります:

ログを示すスクリーンショットです。

エッジアクションログ

Edge Action LogはAzure Front Doorのログと同じ方法で設定できます。 詳細については、「 Azure Front Door ログの構成」を参照してください。

  1. 「エッジアクションの監視」で「診断設定」を選択してください。

  2. [+ 診断設定の追加] を選択します。

  3. 診断設定で「allLogs」を選択し、「Log Analytics ワークスペースに送信」のチェックボックスを選びます。 次に、使いたいLog Analyticsワークスペースとそのサブスクリプションを選択します。

    診断設定を示すスクリーンショットです。

  4. 保存を選びます。

EdgeActionConsoleLog テーブルには、次のスキーマがあります。

ColumnName 列の型 説明
TimeGenerated datetime ログが生成されたUTC時間
TrackingReference 文字列 Azure Front Door によって提供される要求を示す一意の参照文字列。 追跡参照はX-Azure-Ref ヘッダーを使ってクライアントおよび発信元に送信されます。 追跡参照は、アクセス ログまたは WAF ログ内の特定の要求を検索する際に使用します。
ログメッセージ 文字列 Edge Actionコードのconsole.log文で指定したメッセージ
EdgeActionVersion 文字列 このログメッセージを生成したEdge Actionバージョン
タイプ 文字列 ログの種類。 現在サポートされているタイプは1つだけです(EdgeActionConsoleLog)。
リソースID 文字列 エッジアクションのリソースID

Azure Front Door のログ

また、Azure Front Doorのログを使ってエッジアクションが実行されたかどうかも確認できます。

Azure Front Doorのログを示すスクリーンショットです。

ColumnName 列の型 説明
エッジアクションステータスコード 文字列 エッジアクションの実行成功を示すステータスコード。
- 200: 成功
- 503:実行中のエラー

Pricing

エッジアクションは、呼び出し回数と各呼び出しの実行時間が1msを超えることに基づくシンプルな2段階の価格モデルに従っています。 エッジアクションの価格設定の詳細については、適用される請求メーターや呼び出し・実行時間に対する使用量に基づく料金を含むAzure Front Doorの価格設定をご覧ください。 詳細については、「Azure Front Door billingの理解:例7」をご覧ください。