Skip to main content
このガイドでは、既存の CloudFront ディストリビューションを Dynamic Bot Rendering に接続します。このセットアップでは、ビューワーリクエストに CloudFront Function を 1 つ追加し、対象となる AI アシスタントのページリクエストに対してオリジンを選択します。 このセットアップでは Lambda@Edge を使用しません。この統合は、次の 2 つの特性によって成り立っています。
  • ビューワーの Host 転送が無効になっている場合、CloudFront は Host ヘッダーと TLS の Server Name Indication(SNI)にカスタムオリジンのドメインを使用します。ステップ 3 の両方のポリシーで、この設定を維持してください。
  • Profound の CloudFront エンドポイント自体が cache-control: no-store を返すため、Profound がすでにキャッシュしているコンテンツについて、CloudFront が古い 2 つ目のコピーを保存することはありません。
Profound にルーティングされたリクエストは、CloudFront エンドポイント GET https://concierge.tryprofound.com/v1/concierge/cloudfront/{path} を使用します。この URL を手動で組み立てる必要はありません。オリジンの Origin path 設定によってプレフィックスが付加され、リクエスト URI は変更されずにそのまま渡されます。

この設計の理由

以下のすべての内容は、2 つの CloudFront のルールに基づいています。
  1. ビューワーリクエスト関数では、リクエストが一致するキャッシュビヘイビアを変更できません。CloudFront は関数の実行前にビヘイビアを選択し、URI を書き換えても再照合は行われません。そのため、アシスタントのトラフィックは、独自のキャッシュポリシーを持つ専用のビヘイビアではなく、人間のトラフィックと同じビヘイビアで処理されます。
  2. ビューワーリクエスト関数ではオリジンを切り替えることができ、フェイルオーバー付きのリクエストごとのオリジングループを構築することもできます(cf.createRequestOriginGroup、ランタイム cloudfront-js-2.0)。
ここから、次の 2 つの帰結が導かれます。
  • ルーティングは、ビヘイビアではなくオリジンを切り替えることで行われます。Origin path はオリジンごとの設定であるため、デフォルトオリジンへのフェイルオーバー時には、自動的にプレフィックスなしの元のパスが使用されます。パスの書き換えは不要です。
  • アシスタントと人間のリクエストはビヘイビアのキャッシュポリシーを共有するため、マーカーヘッダーでキャッシュキーを分割する必要があります(ステップ 3)。これを行わないと、CloudFront が人間向けにキャッシュしたコピーをアシスタントに配信したり、その逆が起きたりする可能性があります。

前提条件

  • 既存の CloudFront ディストリビューション
  • CloudFront のディストリビューション、関数、キャッシュポリシーに対する AWS Identity and Access Management(IAM)の権限
  • Dynamic Bot Rendering の API キー、登録済みのドメイン、有効な配信ポリシー、および既知の公開済みテストページ。始める前にを参照してください。
  • パーソナライズされていない公開ページのみが対象です。サンプルでは /、/pricing、/docs、/docs/getting-started を許可しています。これらをレビュー済みの公開ページに置き換えてください。API、認証、アカウント、管理、フレームワークのリソースのパスは含めないでください。
  • ロールバックに備えて、既存の関数の関連付け、オリジン、ポリシーを記録してください。既存のセキュリティ、認証、リライトのロジックは維持してください。組み合わせるためにルーティング設計の変更が必要な場合は、作業を中止し、別途レビューしてください。
  • ファイアウォールのルール、ボットチャレンジ、オリジンの許可リストが、アシスタントのトラフィックと、Profound のオリジン/スクレイパーによる取得の両方を許可していることを確認してください。ループマーカーは、認証やファイアウォールをバイパスするためのものではありません。

セットアップ

1

Profound のオリジンを作成する

CloudFront → Distributions → 対象のディストリビューション → Origins → Create origin を開きます。カスタムオリジンヘッダーを 2 つ追加します。CloudFront はこのオリジンに転送する際、ビューワーが送信した同名のヘッダーを上書きするため、クライアントが API キーやホストを偽装することはできません。多層防御として、ステップ 2 の関数でもこれらのヘッダーを削除します。
このディストリビューションから複数のホスト名を配信していますか? 静的な x-concierge-host は単一の公開ホストでしか機能せず、静的なオリジンヘッダーは関数で設定した値よりも優先されます。マルチドメインのディストリビューションでは、ここでこのカスタムヘッダーを省略し、以下の関数でマークされた行のコメントを外して、ステップ 3 で x-concierge-host をキャッシュキーに含めることで転送もされるようにしてください。転送するだけでは、ホストごとのキャッシュレスポンスは分離されません。複数のホストを有効にする前に、人間向けのレスポンスとフォールバックレスポンスについても、ホストの識別をレビューしてください。
2

ビューワーリクエスト関数を作成する

CloudFront → Functions → Create function を開きます。名前を profound-bot-rendering とし、ランタイムに cloudfront-js-2.0 を選択します。オリジングループには 2.0 ランタイムが必要です。
YOUR_DEFAULT_ORIGIN をディストリビューションの既存のデフォルトオリジン ID に、PUBLIC_HOSTS をこのオリジンの登録済みホストに置き換えてから、Publish を選択します。静的なホストヘッダーを使用する場合は、その 1 つのホストのみを指定してください。公開パスの完全一致の許可リストは、サイトのルートと一致させておいてください。Cookie や認可ヘッダーを含むリクエストは既存のルーティングのまま処理され、関数がそれらを Profound に送ることはありません。この関数がルーティングするのは GET のみで、それ以外のメソッドはすべて既存のルーティングに戻ります。CloudFront のオリジングループは、GET、HEAD、OPTIONS のフェイルオーバーをサポートしています。設定した 503 の条件は接続失敗時のフェイルオーバーを、504 はレスポンスタイムアウト時のフェイルオーバーを有効にします。デプロイ前に、プライマリオリジンの接続試行回数、接続タイムアウト、レスポンスタイムアウトについて、フォールバックリクエストの時間を残せる上限値を設定して記録してください。CloudFront のデフォルトでは、接続試行だけで 30 秒(10 秒 × 3 回)かかる場合があります。結果として生じる合計レイテンシーをテストし、フェイルオーバーが即座に行われると想定しないでください。CloudFront のオリジンフェイルオーバーを参照してください。
3

キャッシュポリシーとオリジンリクエストポリシーを更新する

CloudFront は、ビヘイビアのポリシーに含まれていないビューワーヘッダーやクエリ文字列をすべて削除します。これは関数の判断にかかわらず、オリジンリクエストの前に行われます。ページを配信するビヘイビアには、次の 3 つの設定が必要です。1. x-concierge-route をキャッシュキーのヘッダーに追加します。 AWS マネージドキャッシュポリシーは編集できません。ビヘイビアでマネージドポリシーを使用している場合は、まずすべての設定を新しいカスタムポリシーにコピーしてから、ヘッダーを追加してください。Minimum TTL(有効期間)は 0 のままにしてください。マルチドメイン構成では、信頼済みの x-concierge-host を転送するだけでなく、キャッシュの識別情報にも含めてください。ボットマーカーだけではホストを区別できません。2. ページの内容が変わるクエリ文字列(または「All」)をキャッシュキーに含めます。キャッシュキーのクエリ文字列はオリジンにも届きます。オリジンリクエストポリシーを使えば、キーに含めずに追加のクエリ文字列を転送できますが、その値によって内容が変わるレスポンスがキャッシュエントリーを共有してしまう可能性があります。どちらのポリシーにもクエリ文字列が含まれていない場合、CloudFront はそれを削除します。サポートする各バリアントについて、転送とキャッシュの識別の両方を確認してください。3. オリジンリクエストポリシーでビューワーの User-Agent を転送します。 デフォルトでは、CloudFront はオリジンリクエストの User-Agent を Amazon CloudFront に置き換えます。そうなると、Profound はルーティングされたすべてのリクエストを不明なエージェントとして分類し、常にフェイルオープンするため、レンダリングが配信されることもスケジュールされることもありません。User-Agent と、必要に応じて Accept および Accept-Language(マルチドメインの場合は x-concierge-host も)を対象としたカスタムヘッダー許可リストを使用してください。必要な圧縮設定は維持してください。AllViewer は使用しないでください。ビューワーの Host 転送によってサービスのホスト名が上書きされ、オリジンのルーティングや TLS が機能しなくなる可能性があります。ビューワーの Host、Cookie、Authorization は、キャッシュポリシーとオリジンリクエストポリシーの両方から除外してください。キャッシュキーの値も転送されます。これらのポリシーは人間のトラフィックにも適用されます。既存のビヘイビアでこれらのヘッダーや Cookie が必要な場合は、変更する前に作業を中止し、互換性をレビューしてください。CloudFront は、リクエストオリジングループで hostHeader と sni のオリジンごとの originOverrides について説明しています。別のホストを必要とするお客様のオリジンについては、その互換性を別途レビューする必要があります。このサンプルでは、オーバーライドの選択や追加は行いません。Profound のオリジンフェッチは閲覧者の認証情報を転送せず、公開済みページはセッションごとや言語ごとのバリアントではありません。
このセットアップでは、User-Agent をキャッシュキーではなくオリジンリクエストポリシーに追加します。オリジンリクエストポリシーはビヘイビア全体に適用されるため、CloudFront は人間のリクエストでもビューワーの User-Agent を転送するようになります。オリジンが User-Agent によって HTML を変えている場合(たとえば、モバイルとデスクトップで別々のマークアップを返す場合)に、対応するキャッシュキーのバリエーションがないと、CloudFront がキャッシュされた 1 つのバリアントを他の閲覧者に配信してしまう可能性があります。既存のキャッシュキーがオリジンのバリアントをすでに考慮していることを確認してください。ロケール、地域、その他のヘッダーに依存するコンテンツもレビューが必要です。キャッシュ設計の変更が必要な場合は、デプロイ前に作業を中止してください。生の User-Agent をキーにすると、キャッシュの再利用率が大幅に低下する可能性があります。
4

関数をビヘイビアに関連付ける

Behaviors → 対象のページビヘイビア → Edit を開きます。ステップ 3 のキャッシュポリシーを設定し、Function associations で Viewer request に profound-bot-rendering CloudFront Function を設定します。既存のエッジロジックがないビヘイビアであれば、オリジンリクエストやオリジンレスポンスの関連付けは不要です。既存の関連付けは削除しないでください。この関数を関連付ける前に、既存のビューワーリクエストのロジックを統合して維持してください。設計上の判断が必要な場合は作業を中止してください。保存し、ディストリビューションのデプロイが完了するまで待ちます。
5

検証する

HTTP ステータス、有効な x-concierge-request-id、想定どおりの x-concierge-bot-kind を確認します。既知の公開済みページでは、x-concierge-cache: HIT と想定どおりのレンダリング済みボディも必須です。通常のブラウザートラフィック、GET 以外のメソッド、除外パス、認証情報を含むリクエストについて、既存の動作どおりであることをテストしてください。CDN レベルのフェイルオーバーは、ステージング環境または分離されたディストリビューションでのみテストしてください。元のオリジン設定を記録し、到達不能なテスト用オリジンを設定して、キャッシュされていないアシスタントリクエストを繰り返します。設定したタイムアウト後に、x-concierge-request-id のないデフォルトオリジンのレスポンスが返されることを確認します。元の設定を復元し、反映されるまで待ちます。401 ではフェイルオーバーは発生しませんが、設定した 400 と 403 のステータスでは発生するため、設定エラーが隠れてしまう可能性があります。キャッシュされたフォールバックレスポンスは、TTL が切れるまで残る場合があります。すべてのチェック項目とヘッダーの意味については、検証とトラブルシューティングを参照してください。

キャッシュ分割の動作

  • 関数がクライアントから送られたマーカーを削除するため、人間のリクエストにマーカーが含まれることはありません。マーカーによって人間のエントリーとアシスタントのエントリーは分離されますが、クエリやヘッダーのポリシーを変更すると、人間のキャッシュヒット率に影響する場合があります。
  • 対象となるアシスタントのリクエストには x-concierge-route: bot が付与され、独自のエントリーが作成されます。
  • Profound のレスポンスは cache-control: no-store を設定するため、Minimum TTL が 0 であれば、アシスタント用のキーのエントリーに格納されるのは、ご自身のオリジンからのフェイルオーバーレスポンスのみです。これは正しいコンテンツであり、オリジン自身の TTL で期限切れになります。
Profound が完全に停止している間、フェイルオーバーしたオリジンのレスポンスが、TTL が切れるまでアシスタント用のキーのキャッシュに残る場合があり、復旧後にレンダリング済みコンテンツに戻るまでに遅延が生じます。既存の TTL において、この復旧の遅延が許容できるかどうかを確認してください。フォールバックレスポンスのキャッシュ方法を変更するには、別途設計レビューが必要です。このガイドでは、その動作を変更するためのエッジ関数は追加しません。

ロールバック

記録しておいたビューワーリクエストの関連付けと、このセットアップのために変更したポリシーを復元します。No association は、以前に関数がなかった場合にのみ使用してください。設定が反映されるのを待ってから、元のルーティングとキャッシュの動作を確認します。以前にキャッシュされたフォールバックレスポンスは、TTL が切れるか、通常の手順で無効化されるまで残る場合があります。