opensearch-personalize-caching-strategies

マーケットプレイスのリサーチ：OpenSearch と Personalize のキャッシュのベストプラクティス

AWS OpenSearch（検索）と AWS Personalize（マイクロサービス経由のレコメンデーション）を運用する両面マーケットプレイス向けの、キャッシュ戦略をまとめたリファレンスです。9 カテゴリにわたる 52 のルールを、カスケード効果の順に並べています。上流の「キャッシュするかどうか」という判断から、キー設計、パーソナライズの境界、戦略の選択、TTL 設計、スタンピード対策、可観測性、そしてカスケードの下流にあたるネガティブキャッシュと階層構成までを扱います。各ルールでは、理由（コスト、レイテンシ、または正確性に関わる仕組み）を説明し、不適切なコードと適切なコードの例を示します（マイクロサービスレイヤーは TypeScript/Node、バッチ処理と分析は Python、OS 固有のクエリは OpenSearch JSON、CDN/Kubernetes は YAML）。さらに、標準的な出典として、AWS Personalize/OpenSearch/ElastiCache のドキュメント、XFetch の論文（Vattani et al. VLDB 2015）、RFC 5861（stale-while-revalidate）、キャッシュインフラストラクチャチームの技術ブログ（Netflix EVCache、Pinterest Cachelib、Twitter Twemcache、Cloudflare）を引用します。

これは opensearch-function-scoring-algorithms を補完するものです。あちらのスキルが「ランキングでは何を計算すべきか？」に答えるのに対し、このスキルでは「OpenSearch や Personalize に過度な負荷をかけることなく、本番トラフィックに対応するにはどうスケールすればよいか？」に答えます。

適用するタイミング

次のような場合に、このスキルを活用してください：

• 検索またはレコメンデーションの画面に初めてキャッシュを導入する場合は、decide-cache-roi-calculation と decide-hot-key-distribution から始めます
• ホームページまたはカテゴリページに5つ以上のレコメンダーが表示され、トラフィックよりも速いペースでPersonalizeの請求額が増えている場合 — decide-amplification-multiplier、pers-recommender-fan-out-coalescing、pers-cohort-precomputation
• キャッシュヒット率が不自然に低く（30〜40％未満）、原因がわからない場合 — key-canonicalize-query、key-strip-volatile-params、key-bucket-numerical-ranges、obs-key-cardinality-tracking
• トラフィックの急増時にPersonalizeがスロットリングされる（HTTP 429）場合 — decide-personalize-quota-budget、neg-cache-throttled-personalize、stamp-circuit-breaker-on-origin-error
• TTLの境界でp99が急増する場合 — stamp-coalesce-concurrent-misses、stamp-probabilistic-early-expiration、stamp-serve-stale-on-rebuild、ttl-soft-and-hard、ttl-jitter-to-prevent-thundering
• モデルの再トレーニング後もレコメンデーションが古いままの場合 — key-version-the-model、ttl-personalize-solution-version、strat-async-warm-up
• 読み取り直後に書き込みを行う画面で古いデータが表示される場合（ユーザーのお気に入り、保存済み検索など）— strat-write-through-mutations、ttl-event-driven-invalidation
• キャッシュに関する判断を財務部門に説明できる根拠が必要な場合 — decide-cache-roi-calculation、obs-cost-attribution、obs-cache-simulation-from-logs
• 匿名トラフィックとログイン済みトラフィックが同じルートに混在する場合 — pers-anonymous-vs-logged-split、tier-cdn-for-anonymous
• キャッシュのメモリが逼迫しており、容量を増やすか、TTLを短くするか、戦略を変更するか判断したい場合 — decide-hot-key-distribution、tier-l2-elasticache-redis、obs-cache-simulation-from-logs
• 一般的なクエリでOpenSearchのCPU使用率が高い場合 — tier-opensearch-request-cache、tier-opensearch-filter-context、neg-cache-empty-results
• バイラルリンクやクローラーによるトラフィック急増でオリジンに負荷がかかっている場合 — neg-bloom-filter-against-misses、neg-cache-empty-results、stamp-circuit-breaker-on-origin-error このルールは、アプリケーションマイクロサービスを前段に配置した、OpenSearch と Personalize を利用するあらゆる AWS ベースのマーケットプレイスに適用されます。対象となる分野は、宿泊、フードデリバリー、ファッション、サービス、求人、中古品、不動産などです。適用のきっかけとなる項目には、「キャッシュヒット率」、「キャッシュミスの嵐」、「Personalize のスロットリング」、「Personalize のコスト」、「複数レコメンダーのページ」、「コホートキャッシュ」、「シングルフライト」、「stale-while-revalidate」、「XFetch」、「OpenSearch の低速クエリ」、「ElastiCache のサイジング」、「CloudFront の検索キャッシュ」、「ブルームフィルターによるキャッシュ浸透」、「サンダリングハード」などがあります。

キャッシュパイプライン

カテゴリは、リクエスト時のキャッシュパイプラインに基づいています。前段のステージは後続のステージに連鎖的に影響します。「キャッシュするかどうか」の判断を誤ると、その後のすべてが無駄になります。キーを正規化しなければ、ヒット率は達成可能な上限の一部にとどまります。可観測性がなければ、どのルールが役立ったのかを判断できません。

Request → [1] Decide → [2] Key construction → [3] Personalisation boundary
        → [4] Strategy (read/write path) → [5] TTL/freshness → [6] Stampede protection
        → [8] Negative/defensive → [9] Tier composition (L1/L2/CDN/OS-internal) → Response
                                                ↑
                                [7] Observability (meta-layer applied to all stages:
                                    hit rate by key class, latency-with-and-without,
                                    cost-per-1k, cardinality, staleness, log-replay)

優先度別のルールカテゴリ

優先度	カテゴリ	影響	プレフィックス	ルール数
1	判断とコストの計算	CRITICAL	decide-	7
2	キャッシュキーの設計	CRITICAL	key-	7
3	パーソナライズの境界	HIGH	pers-	6
4	戦略と書き込みパス	HIGH	strat-	6
5	TTL と鮮度	HIGH	ttl-	6
6	スタンピード対策	HIGH	stamp-	5
7	可観測性と実測	HIGH	obs-	6
8	ネガティブキャッシュと防御的キャッシュ	MEDIUM-HIGH	neg-	4
9	階層型キャッシュとエッジキャッシュ	MEDIUM-HIGH	tier-	5

クイックリファレンス

1. 判断とコストの計算（CRITICAL）

• decide-cache-roi-calculation — キャッシュを追加する前にキャッシュの ROI を計算する
• decide-cardinality-floor — トラフィック分布が平坦な場合はキャッシュを避ける
• decide-personalize-quota-budget — キャッシュ戦略を選ぶ前に Personalize の TPS 予算をモデル化する
• decide-latency-budget — オリジンの p99 がレイテンシ予算を超える場合にのみキャッシュする
• decide-amplification-multiplier — 複数レコメンダーのページによる増幅を考慮する
• decide-hot-key-distribution — キャッシュのサイズを決める前にトラフィック分布をプロファイルする
• decide-search-vs-personalize-asymmetry — 検索では候補セットを、Personalize ではペイロード全体をキャッシュする

2. キャッシュキーの設計（CRITICAL）

• key-canonicalize-query — クエリをハッシュ化する前に正規化する
• key-segment-not-user — ユーザー数がコホート数を上回る場合は、コホート単位でレコメンダーのキーを設定する
• key-version-the-model — キャッシュキーに Personalize ソリューションのバージョンを含める
• key-locale-currency-explicit — キーでロケール、通貨、タイムゾーンを明示する
• key-strip-volatile-params — ハッシュ化する前に変動するパラメーターとトラッキングパラメーターを取り除く
• key-bucket-numerical-ranges — ハッシュ化する前に連続値のフィルターをバケット化する
• key-stable-hash-algorithm — カーディナリティの高いキーには MD5 ではなく SHA-256 を使用する

3. パーソナライズの境界（高）

• pers-cohort-precomputation — コホートごとのレコメンデーションをオフラインで事前計算する
• pers-anonymous-vs-logged-split — 匿名トラフィックはグローバルキャッシュに、ログイン済みユーザーはコホートキャッシュにルーティングする
• pers-cold-start-cache-priority — コールドスタートのユーザーには人気度キャッシュから配信し、パーソナライズをスキップする
• pers-recommender-fan-out-coalescing — 複数のレコメンダーへのファンアウトをまとめ、バッチ呼び出しにする
• pers-shared-candidates-private-ranking — 検索候補をグローバルにキャッシュし、キャッシュからユーザーごとに再ランク付けする
• pers-session-vector-write-through — すべてのイベントでライトスルーし、セッションベクトルをキャッシュに保持する

4. 戦略と書き込みパス（高）

• strat-cache-aside-default — 読み取り中心のパスでは、デフォルトの戦略としてキャッシュアサイドを使用する
• strat-refresh-ahead-hot-keys — 人気キーの上位1%に限り、リフレッシュアヘッドを使用する
• strat-write-through-mutations — ユーザーの変更が直後に再読み込みされる場合は、ライトスルーを使用する
• strat-precompute-batch — 人気の高い割合のデータをバッチジョブで事前計算する
• strat-tiered-promotion — L2 でヒットしたら、L1 のプロセス内キャッシュに昇格させる
• strat-async-warm-up — デプロイ、再起動、モデルの再トレーニング後に非同期でウォームアップする

5. TTL と鮮度（高）

• ttl-by-content-volatility — エンジニアリング上の都合ではなく、コンテンツの変動性に基づいて TTL を設定する
• ttl-soft-and-hard — ソフト TTL（非同期更新）とハード TTL（同期ミス）を分ける
• ttl-jitter-to-prevent-thundering — TTL にランダムなジッターを加え、同期した期限切れを防ぐ
• ttl-personalize-solution-version — TTL を実時間ではなく、Personalize ソリューションのバージョンに固定する
• ttl-event-driven-invalidation — 鮮度が重要な場合は、TTL とイベント駆動型の無効化を併用する
• ttl-bound-by-staleness-tolerance — デフォルト値ではなく、プロダクトで許容できる古さに基づいて TTL に上限を設ける

6. スタンピード対策（高）

• stamp-coalesce-concurrent-misses — 同時に発生したミスをまとめ、オリジンへの呼び出しを1回にする
• stamp-probabilistic-early-expiration — 人気キーに XFetch の確率的な早期期限切れを使用する
• stamp-serve-stale-on-rebuild — 更新処理中は古いデータを配信する
• stamp-circuit-breaker-on-origin-error — オリジンエラー時にサーキットブレーカーを作動させ、古いデータにフォールバックする
• stamp-distributed-lock-rebuild — 分散ロックを使用して、インスタンス間のキャッシュ再構築を調整する

7. オブザーバビリティと実測（HIGH）

• obs-hit-rate-by-key-class — キークラスごとにヒット率を追跡し、集計値だけを見ることは避けます
• obs-latency-histograms-with-without — ヒット時とミス時のレイテンシーヒストグラムを個別に測定します
• obs-cost-attribution — キャッシュの有無それぞれについて、リクエスト1,000件あたりのコストを算出します
• obs-key-cardinality-tracking — キーのカーディナリティを毎日サンプリングし、急増時にアラートを出します
• obs-stale-served-ratio — 古いデータの提供率を測定し、TTL の選択を検証します
• obs-cache-simulation-from-logs — TTL や戦略を変更する前に、本番ログをキャッシュシミュレーターで再生します

8. ネガティブキャッシュと防御的キャッシュ（MEDIUM-HIGH）

• neg-cache-empty-results — 空の検索結果を短い TTL でキャッシュします
• neg-cache-throttled-personalize — Personalize がスロットリングされた場合、最後に確認された正常な結果を返します
• neg-bloom-filter-against-misses — ブルームフィルターを使用して、高カーディナリティのキャッシュミスの集中を防ぎます
• neg-poison-pill-detection — キャッシュエントリーにチェックサムを付与し、汚染された書き込みを検出して拒否します

9. 階層型キャッシュとエッジキャッシュ（MEDIUM-HIGH）

• tier-l1-in-process — ミリ秒未満の読み取りを実現するため、プロセス内 LRU を L1 として使用します
• tier-l2-elasticache-redis — インスタンス間のワーキングセットに合わせて L2 ElastiCache のサイズを決定します
• tier-cdn-for-anonymous — 匿名トラフィックには CDN を使用し、Cookie がある場合はバイパスします
• tier-opensearch-request-cache — 集計中心のクエリで OpenSearch リクエストキャッシュを有効にします
• tier-opensearch-filter-context — 再利用可能な述語をフィルターコンテキストに配置し、セグメントレベルでキャッシュします

使い方

「これはキャッシュすべきですか？」「ヒット率が低いのはなぜですか？」「Personalize のスロットリングをどう乗り切ればよいですか？」といった明確な質問がある場合は、該当するルールに直接進んでください。それぞれに、理由、コード、引用が含まれています。

新しいサーフェスや問題を抱えているサーフェスについて、キャッシュ設計全体をレビューする場合は、カテゴリを上から順に確認してください。このカスケードは実際に影響します。decide-cache-roi-calculation を誤ると、採算の取れないキャッシュにエンジニアリングの労力を費やすことになります。key-canonicalize-query に漏れがあると、達成可能なヒット率に上限が生じます。pers-cohort-precomputation がないと、Personalize の請求額は MAU に比例したままです。ヒット率が 90% を超えたら、スタンピード対策とオブザーバビリティは必須です。サンダリングハードで残りの 10% のミスがオリジンをダウンさせます。また、キーのクラスごとのヒット率ダッシュボードがなければ、状況を把握できません。

既存のキャッシュを実測値に基づいて調整する場合は、まず obs-cache-simulation-from-logs（ログを What-if 設定で再生）を確認し、ダッシュボード用に obs-hit-rate-by-key-class、obs-cost-attribution、obs-stale-served-ratio と組み合わせてください。この 3 つで、キャッシュが役割を果たしているか、コストはいくらか、ユーザーに古いデータが表示されているかがわかります。

特に複数レコメンダーを使うホームページの問題（Personalize のコストが急増する最も一般的なパターン）では、優先順位は次のとおりです。decide-amplification-multiplier → pers-cohort-precomputation → pers-recommender-fan-out-coalescing → pers-anonymous-vs-logged-split。これら 4 つにより、コンシューマー向けマーケットプレイスでは、通常 Personalize の支出を 70～90% 削減できます。

「負荷がかかると Personalize でスロットリングが発生する」インシデントでは、優先順位は次のとおりです。stamp-circuit-breaker-on-origin-error → neg-cache-throttled-personalize → decide-personalize-quota-budget。最初の 2 つでユーザーへの影響を抑えます。3 つ目で minProvisionedTPS を適正化し、再発を防ぎます。

関連スキルとの相互参照については、opensearch-function-scoring-algorithms を参照してください。このスキルでは、OpenSearch で何を計算するか（function_score、kNN、RRF、rank_feature、decay、LTR、MMR、評価）を扱います。このスキルでは、本番トラフィックにクラスターが耐えられるよう、それをどうキャッシュするかを扱います。

カスケードによる影響の根拠についてはセクションの定義を、新しいルールを追加する際はルールのテンプレートを参照してください。

関連スキル

• opensearch-function-scoring-algorithms — OpenSearch 向けの、調査に裏付けられたランキング、検索、評価のルールです。「何を計算するか」を扱い、このスキルは「それをどうスケールさせるか」を扱います。

参考ファイル

ファイル	説明
references/_sections.md	カテゴリの定義と、カスケードへの影響に基づく順序
AGENTS.md	簡潔な目次ナビゲーション（自動生成。手動で編集しないでください）
assets/templates/_template.md	新しいルールを作成するためのテンプレート
metadata.json	バージョンと正式な参考 URL