e コマースおよびマーケットプレイスアプリケーション向け CloudFront

e コマースまたはマーケットプレイスアプリケーションは、静的アセット (製品イメージ、CSS、JavaScript)、動的ページ (製品リスト、検索結果)、および API レスポンス (カート、インベントリ、料金) の 3 つの異なるコンテンツタイプを、単一の CloudFront ディストリビューションを通じて提供します。各コンテンツタイプでは、鮮度とパフォーマンスのバランスを取るために、異なるキャッシュ動作、TTL、およびオリジン設定が必要です。

マーケットプレイスおよび e コマースディストリビューションに適用されるセキュリティコントロールについては、「マーケットプレイスディストリビューションのセキュリティチェックリスト」を参照してください。

アーキテクチャの概要

マーケットプレイスの CloudFront ディストリビューションは、複数のキャッシュ動作を使用し、URL パスパターンに基づいてリクエストを適切なオリジンにルーティングします。静的アセットは Amazon Simple Storage Service (Amazon S3) から提供され、動的コンテンツと API リクエストはアプリケーションサーバーの前段にある Elastic Load Balancing (Application Load Balancer) に転送されます。ElastiCache (Valkey) クラスターは、頻繁にアクセスされる製品データ向けに、ALB とデータベースの間にアプリケーションレベルのキャッシュを提供します。

ディストリビューションアーキテクチャのコンポーネント

コンポーネント	提供されるコンテンツ	目的
CloudFront 配信	すべてのコンテンツ (単一ドメイン)	グローバルエッジキャッシュ、TLS の終了、キャッシュ動作を使用したリクエストのルーティング
Amazon S3 オリジン (静的アセット)	製品イメージ、CSS、JS、フォント	オリジンアクセスコントロール (OAC) を使用した耐久性の高いオブジェクトストレージ。長い TTL を持つイミュータブルなコンテンツ。
ALB オリジン (動的コンテンツ)	製品ページ、検索、API エンドポイント	アプリケーションサーバーへのルーティング。パーソナライズされたコンテンツに対しては、短い TTL を設定するか、キャッシュを行いません。
ElastiCache クラスター (Valkey)	製品カタログ、インベントリ数、セッションデータ	ALB とデータベース間のアプリケーションレベルのキャッシュ。頻繁にアクセスされるデータを対象とした 1 ミリ秒未満の読み取り。

e コマースのキャッシュ動作

キャッシュ動作によって、CloudFront が URL パスパターンに基づいてリクエストを処理する方法が決まります。マーケットプレイスでは、適切なキャッシュポリシーと TTL を使用して、コンテンツタイプごとに個別の動作を設定します。

推奨されるキャッシュ動作

パスパターン	Origin	TTL	キャッシュポリシー	根拠
/static/*	Amazon S3	365 日間	CachingOptimized	バージョン管理されたファイル名 (例: app.a1b2c3.js) では、最大 TTL を許可できます。キャッシュの無効化は一切不要です。新しいファイル名で新しいバージョンをデプロイします。
/images/*	Amazon S3	30 日間	CachingOptimized	製品イメージは頻繁に変更されません。販売者がイメージを更新するときは、キャッシュタグの無効化を使用します。イメージ URL が再利用される可能性があるため、静的アセットよりも TTL を低く設定します。
/api/products/*	ALB	60 秒	カスタム (クエリ文字列を含む)	製品リストと検索の API は頻繁に変更されますが、わずかな古さは許容されます。ページ分割とフィルタのキャッシュキーにクエリ文字列パラメータを含めます。
/api/cart/*	ALB	0 (キャッシュなし)	CachingDisabled	カートのオペレーションはユーザー固有であり、常にオリジンに到達する必要があります。キャッシュを完全に無効にします。
/api/inventory/*	ALB	5 秒	カスタム (クエリ文字列を含む)	インベントリ数は、販売イベント中に急速に変化します。非常に短い TTL は、過剰販売を防止しつつ、オリジンの負荷を軽減します。
Default (*)	ALB	0 (キャッシュなし)	CachingDisabled	デフォルトの動作では、キャッシュされていないリクエストをサーバーサイドレンダリングのためにアプリケーションに転送します。パーソナライズされたコンテンツ (推奨事項、ユーザー名) を含むページは、エッジでキャッシュしないでください。

注記

キャッシュ動作を、最も具体的なものから最も具体的でないものの順に並べます。CloudFront は、リストされた順序でパスパターンを評価し、最初に一致したものを使用します。カートリクエストがキャッシュをバイパスするように、/api/* の前に /api/cart/* を配置します。

キャッシュ動作の詳細については、「キャッシュ動作の設定」を参照してください。

マーケットプレイスコンテンツの TTL 戦略

TTL 設定は、CloudFront がオリジンの更新を確認する前に、キャッシュされたコンテンツを提供する期間を決定します。e コマースアプリケーションには、コンテンツの鮮度がカスタマーエクスペリエンスに与える影響に応じて、異なる TTL 戦略が必要です。

イミュータブルなアセット (CSS、JS、フォント)

最大 TTL (365 日) を設定します。コンテンツハッシュファイル名を使用して、各デプロイで新しい URL を作成します。無効化しない – ユーザーが新しいファイル名をロードすると、古いバージョンは自然に期限切れになります。オリジンで Cache-Control: public, max-age=31536000, immutable を設定します。

製品イメージ

TTL を 30 日間に設定し、更新時にキャッシュタグを無効化します。販売者が新しいイメージをアップロードする際は、パスではなく製品のキャッシュタグで無効化します。これにより、広範なワイルドカードの無効化を行わずに、影響を受けるオブジェクトのみを対象にできます。オリジンで Cache-Control: public, max-age=2592000 を設定します。

製品カタログ API

TTL を 60 秒に設定します。製品リスト、説明、および価格では、わずかな古さは許容されます。これにより、トラフィックの急増 (フラッシュセール、製品発売) 時のオリジンの負荷が軽減されると同時に、データが適度に最新の状態に保たれます。CloudFront がバックグラウンドで新しいレスポンスを取得する間に古いコンテンツを提供するよう Cache-Control: public, max-age=60, stale-while-revalidate=30 を設定します。

インベントリと価格 API

TTL を 5 秒に設定します。これらの値は頻繁に変更され、購入の意思決定に影響します。非常に短いキャッシュでも、トラフィック急増時にはオリジンの負荷を桁違いに削減できます。何千人もの同時ユーザーが、それぞれオリジンにアクセスする代わりに、同じ 5 秒間のキャッシュレスポンスを受け取ります。

ユーザー固有のコンテンツ (カート、推奨事項)

キャッシュを無効にします (TTL = 0)。ユーザーごとに異なるコンテンツは、常にオリジンに到達する必要があります。ユーザー固有のコンテンツを誤ってキャッシュすると、CloudFront はあるユーザーのデータを別のユーザーに提供する可能性があります。これらの動作には CachingDisabled マネージドポリシーを使用します。

オリジン設定

静的アセットの Amazon S3 オリジン

製品イメージと静的アセットのオリジンとして、Amazon S3 バケットを使用します。オリジンアクセスコントロール (OAC) を設定して、バケットへの直接アクセスを制限します。この場合、すべてのリクエストは CloudFront を通じて流れる必要があります。

Amazon S3 のオリジン設定

設定	値	根拠
オリジンドメイン	marketplace-assets.s3.amazonaws.com	OAC をサポートするには、(ウェブサイトのエンドポイントではなく) Amazon S3 REST API エンドポイントを使用します。
オリジンアクセス	オリジンアクセスコントロール (OAC)	バケットへのアクセスを CloudFront のみに制限します。アセットへの S3 URL の直接アクセスを防止します。
Origin Shield	有効 (バケットに最も近いリージョン)	エッジロケーションとオリジンの間に一元化されたキャッシュレイヤーを追加します。S3 リクエストのコストを削減し、イメージのキャッシュヒット率を向上させます。
接続の試行	3	デフォルト。一時的な S3 エラーの場合に再試行します。

動的コンテンツの ALB オリジン

Application Load Balancer を動的製品ページ、検索、および API エンドポイントのオリジンとして使用します。ALB は、ターゲットグループを使用して、アプリケーションサーバー (Amazon EC2 インスタンス、Amazon ECS タスク、または Lambda 関数) にルーティングします。

ALB オリジンの設定

設定	値	根拠
オリジンドメイン	ALB DNS 名	ALB DNS 名を直接使用します。ALB の IP アドレスは変わるため、IP アドレスは使用しないでください。
プロトコル	HTTPS のみ	CloudFront とオリジン間のトラフィックを暗号化します。機密データ (ユーザーセッション、支払い情報) に必要です。
オリジンのカスタムヘッダー	X-Origin-Verify: <secret-value>	ALB へのアクセスは、CloudFront からのリクエストのみに制限します。ALB はこのヘッダーを確認して、直接アクセスの試行を拒否します。
接続タイムアウト	10 秒	デフォルト (30 秒) より短くなります。エッジ接続を待機させるのではなく、オリジンで問題が発生した場合に迅速にフェイルファストします。
応答タイムアウト	30 秒	複雑な検索クエリとカタログオペレーションに必要な時間が確保されます。API に長時間実行されるオペレーションがある場合は増やします。
キープアライブタイムアウト	5 秒	ALB への接続を再利用します。その後のリクエストの TLS ハンドシェイクオーバーヘッドを削減します。

ElastiCache (Valkey) を使用したアプリケーションレベルのキャッシュ

CloudFront はコンテンツをエッジでキャッシュしますが、データベースのクエリを必要とする頻繁にアクセスされるデータには、追加のアプリケーションレベルのキャッシュが有効です。Valkey を実行している ElastiCache クラスターは、アプリケーションサーバーとデータベースの間に配置され、製品カタログデータ、インベントリ数、セッション状態を 1 ミリ秒未満で読み取ります。

2 層キャッシュ戦略

Layer	キャッシュされるコンテンツ	TTL	キャッシュミスの場合の動作
CloudFront エッジ	完全な HTTP レスポンス (API JSON、HTML ページ、イメージ)	5 秒～365 日 (動作によって異なる)	ALB オリジンにリクエストを転送する
ElastiCache (Valkey)	アプリケーションデータオブジェクト (製品レコード、インベントリ、セッション)	30 秒～5 分 (データ型によって異なる)	アプリケーションがデータベースにクエリを実行し、結果をキャッシュに書き込む

製品ページリクエストの場合:

1. CloudFront はエッジキャッシュを確認します。キャッシュヒットの場合は、キャッシュされたレスポンスをすぐに返します。

2. キャッシュミスの場合は、リクエストを ALB に転送します。

3. アプリケーションは ElastiCache で製品データを確認します。キャッシュヒットの場合は、キャッシュされたデータからレスポンスを構築します (1 ミリ秒未満)。

4. ElastiCache でキャッシュミスが発生した場合は、データベースに対してクエリを実行し、ElastiCache に書き込んでレスポンスを返します。

5. CloudFront は、動作の TTL 設定に従ってレスポンスをエッジにキャッシュします。

販売者が製品を更新する場合:

1. アプリケーションは ElastiCache の製品キーを無効化します。

2. アプリケーションは、製品のタグに対するキャッシュタグの無効化を CloudFront に送信します。

3. 次のリクエストは、両方のキャッシュレイヤーを通じて新しいレスポンスをトリガーします。

よくある質問

以下のセクションでは、e コマースとマーケットプレイスのワークロードにおけるキャッシュ戦略に関するよくある質問に回答します。

キャッシュを使用して、パーソナライズされたコンテンツを処理するにはどうすればよいですか?

パーソナライズされた要素をキャッシュ可能なコンテンツから分離します。CloudFront キャッシュからページシェル (製品の詳細、イメージ、説明) を配信し、キャッシュをバイパスするクライアント側の API コールを使用して、パーソナライズされた要素 (推奨事項、カート数、ユーザー名) を読み込みます。この方法により、処理負荷の大きいページレンダリングをキャッシュしながら、パーソナライゼーションを最新の状態に保つことができます。

無効化と短い TTL のどちらを選択すればよいですか?

頻繁かつ予測可能な方法で変更されるコンテンツ (インベントリ、料金) には、短い TTL (5〜60 秒) を使用します。ほとんど変更されないが、変更された場合はすぐに更新する必要があるコンテンツ (販売者による編集後の製品イメージ、コンプライアンスレビュー後の製品説明) には、無効化を使用します。無効化にはリクエストごとにコストが発生し、同時実行数の制限があります。これを適切な TTL の代わりに使用しないでください。

フラッシュセールとトラフィックの急増に備えるにはどうすればよいですか?

CloudFront は自動的にスケールしてトラフィックの急増を処理します。セール中のキャッシュヒット率を最大化するには、イベント開始前にリクエストして製品ページを事前ウォームアップし、API TTL を一時的に増やして (例: インベントリ TTL を 5 秒から 15 秒に増やす) エッジでより多くのトラフィックを吸収します。また、ElastiCache クラスターに、増加するキャッシュ書き込みに対応できる十分なメモリヘッドルームがあることを確認します。イベント中に CloudFront キャッシュヒット率メトリクスをモニタリングします。

マーケットプレイスに Origin Shield を使用する必要がありますか?

はい。Origin Shield は、リージョンのエッジキャッシュとオリジンの間に一元化されたキャッシュレイヤーを追加します。e コマースワークロードの場合、一般的な製品のオリジンリクエストを削減し (Origin Shield でのキャッシュヒットがすべてのエッジロケーションに対応するため)、イメージの S3 GET コストを削減し、ALB へのトラフィックの急増を抑えます。オリジンに最も近いリージョンで、これを有効にします。詳細については、「Amazon CloudFront Origin Shield の使用」を参照してください。