キャッシュコネクテッドコンテンツの応答
コネクテッドコンテンツの応答は、異なるキャンペーンやメッセージにわたって (同じワークスペース内で) キャッシュして、送信速度を最適化できます。
Brazeは、コネクテッドコンテンツのレスポンス本文を恒久的に記録または保存しない。メッセージのレンダリング中、応答は一時的に保持されることがある(例えばメモリ内やキャッシュ内)。これによりBrazeはLiquidをレンダリングし、メッセージを送信できる。
キャッシュを防止するには、:no_cache を指定できます。これにより、ネットワークトラフィックが増加する可能性があります。システムのトラブルシューティングと健全性監視を支援するため、Brazeはコネクテッドコンテンツのリクエストメタデータ(完全にレンダリングされたリクエストURLやレスポンスステータスコードなど)を、成功した呼び出しと失敗した呼び出しの両方について記録する。これらのログは最大30日間保持されます。
Connected Content rendering and data handling (advanced)
このセクションでは、BrazeがLiquidおよびコネクテッドコンテンツをどのようにレンダリングするか、またメッセージ送信前にデータが一時的に存在する可能性のある場所について、より詳細なエンドツーエンドの視点を提供する。これはプライバシーとデータ処理の審査に役立つかもしれない。
保存されるものと保存されないもの
- コネクテッドコンテンツのレスポンス本文:Brazeによって恒久的に保存されない。一時的にメモリに保持され、キャッシュのイネーブルメントが有効な場合、有効期限(TTL)付きでキャッシュに保存される。
- コネクテッドコンテンツのリクエストメタデータ:リクエストのメタデータ(完全にレンダリングされたURL、HTTPステータスコード、応答時間など)は、トラブルシューティングと監視のために記録される。これらのログは最大30日間保持されます。
- 最終レンダリングされたメッセージ:レンダリング中にメモリ内に存在する。設定やチャネルによっては、別の場所に保存される場合もある(例:メッセージアーカイブやコンテンツカード)。
レンダリングの流れ(概要)
以下のフローは、Brazeがメール、SMS、プッシュ通知などのプロバイダーベースのチャネル向けにメッセージをレンダリングし送信する方法を説明する。SDK経由で配信されるコンテンツカードのようなチャネルは、基盤となるLiquidとコネクテッドコンテンツのレンダリングを同じように利用するが、コンテンツが生成されるタイミングと配信方法が異なる。
- バックグラウンドワーカーは、メッセージが配信準備状態になった際に、そのメッセージのLiquidテンプレートをレンダリングする。
- コネクテッドコンテンツタグは、Liquidレンダリング中に評価される。
- 各コネクテッドコンテンツタグについて、Brazeは多層キャッシュをチェックする。キャッシュされた値が存在しない場合(またはキャッシュが無効化されている場合)、Brazeはあなたのエンドポイントを呼び出し、応答を受け取る。
- 応答はLiquidテンプレートに挿入され、メッセージは完全にレンダリングされる。
- プロバイダベースのチャネルでは、レンダリングされたメッセージはチャネルプロバイダに送信され、その後ユーザーに送信される。コンテンツカードなどのSDK経由で配信されるチャネルでは、レンダリングされたコンテンツはBraze SDKと同期される。このコンテンツは初回インプレッション時または表示時に生成され、その時点でユーザーに表示される。
コネクテッドコンテンツの応答が一時的に存在できる場所
Brazeは、コネクテッドコンテンツの応答に対してマルチティアキャッシュを使用する。TTLは5分から4時間の間で設定され、これは以下の使用:cache_max_age状況やその他のキャッシュルールによって異なる:
- プロセス内メモリキャッシュ:ワーカープロセス内のトランジェントキャッシュ。データはジョブの期間中のみ存続する(ワーカーのタイムアウトに基づき最大約11分間)。
- ローカルマシンキャッシュ:ワーカーごとのキャッシュ。例えばローカルのMemcachedインスタンスのようなものだ。
- クラスタ全体のキャッシュ:ワーカー間で共有される分散キャッシュ。例えばMemcachedクラスターのようなものだ。
これらのキャッシュ層は揮発性であり、設定されたTTLよりも早くデータを追い出すことがある。
それを使うと何が変わるのか :no_cache
Brazeインフラストラクチャ内でホストされていないエンドポイントに対しては、`HTTP/1.1 200 204 NOT FOUND` を使用することで、コネクテッドコンテンツのレスポンスボディ:no_cacheがMemcachedに保存されるのを防ぐ。これらのケースでは、レスポンスはレンダリングジョブの実行時間中(最大約11分間)のみワーカープロセスのメモリ内に存在する。Braze内部のホストに解決されるエンドポイントについては、キャッシュ破棄で説明されているように、応答がキャッシュされる可能性がある。
最終的にレンダリングされた出力が置かれる場所
- メッセージのアーカイブ化:メッセージアーカイブイネーブルメントが有効な場合、Brazeは最終的にレンダリングされたメッセージを、設定済みのクラウドストレージバケットに書き込むことがある。コネクテッドコンテンツの応答がレンダリングされたメッセージに含まれている場合、それはアーカイブされたコピーにも含まれる。
- ユーザー端末:配信後、完全にレンダリングされたメッセージの内容は、ユーザー端末上で未知の期間保存されることがある。
- コンテンツカード:コンテンツカードのレンダリング済みコンテンツは、カードが期限切れになるまでBrazeデータベースに保存される。
デフォルトのキャッシュ設定
キャッシュ存続期間は最大5分 (300秒) です。コネクテッドコンテンツの呼び出しに :cache_max_age パラメーターを追加することで、この動作を更新できます。例は次のとおりです。
1
{{ {% connected_content [https://example.com/webservice.json] :cache_max_age 900 %}}}
GET リクエストがキャッシュされます。この設定は、コネクテッドコンテンツ呼び出しに:no_cacheパラメータを追加することで行える。
POST リクエストはキャッシュされません。これを強制するには、コネクテッドコンテンツ呼び出しに:cache_max_ageパラメータを追加すればよい。最小キャッシュ時間は5分、最大キャッシュ時間は4時間である。
キャッシュ設定は保証されません。キャッシュによってエンドポイントへの呼び出しが減ることがあります。このため、キャッシュに過度に依存するのではなく、キャッシュ期間内にエンドポイントごとに複数の呼び出しを使用することをお勧めします。
キャッシュサイズの制限
コネクテッドコンテンツの応答本文の最大サイズは1 MBです。1 MB を超える応答本文はキャッシュされません。
キャッシュ時間
コネクテッドコンテンツは、GET エンドポイントから返される値を最低5分間キャッシュします。キャッシュ時間が指定されていない場合、デフォルトのキャッシュ時間は5分である。
コネクテッドコンテンツのキャッシュ時間は、次の例に示す:cache_max_age,ように長く設定できる。最小キャッシュ時間は5分、最大キャッシュ時間は4時間である。コネクテッドコンテンツデータは、Memcachedなどの揮発性キャッシュシステムを使用してインメモリでキャッシュされます。
その結果、指定されたキャッシュ時間に関係なく、コネクテッドコンテンツデータは指定された時間よりも早く Braze のインメモリキャッシュから削除される可能性があります。これは、キャッシュ期間が提案であり、実際にBrazeによってデータがキャッシュされる期間を保証するものではないことを意味します。また、指定されたキャッシュ期間で予想されるよりも多くのコネクテッドコンテンツリクエストが発生する可能性があります。
指定秒間のキャッシュ
この例は900秒(または15分)キャッシュされます。
1
{% connected_content https://example.com/webservice.json :cache_max_age 900 %}
キャッシュバスティング
コネクテッドコンテンツによる、GET リクエストからの戻り値のキャッシュを防ぐには、:no_cache 構成を使用します。ただし、Braze 内部のホストからの応答は引き続きキャッシュされます。
1
{% connected_content https://example.com/webservice.json :no_cache %}
このオプションを使用する前に、指定したコネクテッドコンテンツのエンドポイントが集中的な大量のトラフィックを処理できることを確認してください。そうしないと、Brazeがすべてのメッセージについてコネクテッドコンテンツのリクエストを行うため、送信遅延の増加 (リクエストから応答までの遅延や時間間隔の増加) が発生する可能性があります。
POST では、キャッシュバスティングを行う必要はありません。これは、Braze は POST リクエストの結果をキャッシュすることがないためです。
知っておくべきこと
- キャッシュは、コネクテッドコンテンツの呼び出しの重複を削減するのに役立ちます。ただしユーザーあたりのコネクテッドコンテンツ呼び出しが1回になるとは限りません。
- コネクテッドコンテンツのキャッシュは、URL とワークスペースに基づいて行われます。コネクテッドコンテンツ呼び出しの呼び出し先が同一の URL であれば、キャンペーンやキャンバス間でキャッシュすることができます。
- キャッシュはユーザー ID やキャンペーンではなく、ユニーク URL に基づいて行われます。つまり、キャッシュされたコネクテッドコンテンツ呼び出しは、URL が同じであれば、ワークスペース内の複数のユーザーやキャンペーンで使用される可能性があります。
GitHub でこのページを編集