regex 以外のリダイレクトを Nginx ではなく Fastly にオフロードする(ルート)

ここでは、クラウドインフラストラクチャー上のAdobe Commerceで、regex 以外のリダイレクトを Nginx ではなく Fastly にオフロードする場合に発生する可能性のある、一般的なリダイレクトパフォーマンスの問題の解決策について説明します。

影響を受ける製品とバージョン

  • Fastly を活用した環境のクラウドインフラストラクチャー上のAdobe Commerce(すべてのバージョン) Master/Production/Staging

問題

クラウドインフラストラクチャー上のAdobe Commerceでは、regex 以外による大量のリダイレクトや書き換えを Nginx レイヤーで行うことができず、その結果、パフォーマンスの問題が発生する可能性があります。

原因:

.magento/routes.yaml ディレクトリの routes.yaml ファイルは、クラウドインフラストラクチャ上のAdobe Commerceのルートを定義します。

routes.yaml ファイルのサイズが 32 KB 以上の場合、regex 以外のリダイレクトや書き換えを Fastly にオフロードする必要があります。

この Nginx レイヤーは、regex 以外のリダイレクトや書き換えの数が多いと処理できません。そうしないと、パフォーマンスの問題が発生します。

解決策

解決策は、regex 以外のリダイレクトを Fastly にオフロードすることです。 Fastly にリダイレクトする汎用のエラーパスを作成します。

以下の手順では、Nginx ではなく Fastly にリダイレクトを配置する方法について詳しく説明します。

  1. Edge Dictionary を作成します。

    まず、Adobe Commerceの VCL スニペットを使用して、エッジディクショナリを定義できます。 これはリダイレクトを含みます。

    いくつかの注意点を次に示します。

    • 辞書のエントリに対して regex を実行で Fastly ません。 完全に一致するだけです。 これらの制限について詳しくは、edge 辞書の制限に関する Fastly のドキュメントを参照してください

    • Fastly には、1 つの辞書に対するエントリが 1000 個までに制限されています。 この制限は拡大で Fastly ますが、3 つ目の注意点があります。

    • エントリを更新し、その更新を VCL のすべてのノードにデプロイするたびに、辞書の拡張に伴ってジオメトリの読み込み時間が長くなります。つまり、2000 エントリの辞書は実際には 1,000 エントリの辞書よりも 3 倍~4 倍遅く読み込まれます。 ただし、これは VCL をデプロイする(ディクショナリを更新する、または VCL 関数コードを変更する)場合にのみ問題となります。

      リクエストの処理に要する時間には影響 Fastly ません。新しい設定のプッシュに要する時間 Fastly 影響するだけです。

      一般的に、設定の変更には平均して数秒かかり、通常は 5~10 秒以内です。 したがって、ディクショナリ項目の 2 倍の増加は、設定がロールアウトされるまで 30 秒以上かかります。 4 倍の増加には 2 分近くかかります。 これにより、4 つ目の注意事項が追加されます。

    • エッジディクショナリへのエントリは 10,000 個というかなり厳しい制限があります。

    リダイレクトリストを整理することを強くお勧めします。 複数の辞書を使用できますが、VCL ージに対して行う更新は、Fastly ージ全体で実際に入力されるまでに数分かかることに注意してください。

  2. URL を辞書と比較してください。

    URL 検索が発生すると、一致が見つかった場合は比較が行われ、カスタムエラーコードが適用されます。

    別の VCL スニペットを使用して、次のようなものを vcl_recv に追加します。

    code language-none
         declare local var.redir-path STRING;
         set var.redir-path = table.lookup(redirects, std.tolower(req.url), "");
    
         if (var.redir-path != "") {
           error 912 var.redir-path;
         }
    

    ここでは、URL がテーブルエントリに存在するかどうかを確認しています。 発生した場合は、内部 Fastly エラーを呼び出し、そのエラーにリダイレクト URL テーブルから渡されます。

  3. リダイレクトの管理。

    一致が見つかった場合は、その obj.status に対して定義されているアクション(この場合は 301 永続的な移動リダイレクト)が実行されます。

    vcl_error で最終的なスニペットを使用して、301 エラーコードをクライアントに送り返します。

    code language-none
      if (obj.status == 912) {
         set obj.http.location = obj.response;
         set obj.status = 301;
         set obj.response = "Moved Permanently";
         return(deliver);
           }
    

    このブロックでは、vcl_recv から渡されたエラーコードが一致するかどうかを確認しています。一致する場合は、渡されたエラーメッセージの場所を設定し、ステータスコードを 301 に、メッセージを「永続的に移動」に変更します。 この時点で、応答はクライアントに戻る準備ができているはずです。

ステージサービス

WARNING
これらの手順をすべて試す場合は、Adobe Commerce ステージング環境を設定することを強くお勧めします。 これにより、Fastly サービスに対してテストを実行し、すべてが期待どおりに動作することを確認できます。

Adobe Commerce ステージング環境を実行しないが、これらのリダイレクトの外観を確認したい場合は、Fastly で直接ステージアカウントを設定できます。

関連資料

recommendation-more-help
8bd06ef0-b3d5-4137-b74e-d7b00485808a