コネクテッドコンテンツのレスポンスをキャッシュする

このセクションでは、Brazeがリキッドコンテンツとコネクテッドコンテンツをどのようにレンダリングするのか、また、メッセージが送信される前にデータが一時的に存在する場所について、より詳細なエンドツーエンドのビューを提供する。これはプライバシーやデータ取り扱いの見直しに役立つかもしれない。

何が保存され、何が保存されないのか

• コネクテッドコンテンツのレスポンスボディ：Brazeが永久に保存するわけではない。一時的にメモリに保持することができ、キャッシングがイネーブルメントの場合、TTL（time-to-live）でキャッシュに保存される。
• コネクテッドコンテンツのリクエストメタデータ：完全にレンダリングされたURL、HTTPステータスコード、レスポンシブ時間などのリクエストメタデータは、トラブルシューティングやモニタリングのために記録される。これらのログは最大30日間保持されます。
• 最後にレンダリングされたメッセージ：レンダリング中にメモリ上に存在する。また、設定やチャネルによっては、別の場所に保存されることもある（メッセージアーカイブやコンテンツカードなど）。

レンダリングの流れ（ハイレベル）

以下のフローでは、メール、SMS、プッシュなどのプロバイダーベースのチャネルに対して、Brazeがどのようにメッセージをレンダリングし、送信するかを説明する。コンテンツカードのようなSDK配信チャネルは、同じ基礎となるリキッドとコネクテッドコンテンツのレンダリングを使用するが、コンテンツが生成されるタイミングと配信方法が異なる。

1. バックグラウンドワーカーは、メッセージが配信される準備ができたときに、メッセージの Liquid テンプレートをレンダリングする。
2. コネクテッドコンテンツのタグは、Liquidレンダリング中に評価される。
3. コネクテッドコンテンツのタグごとに、Brazeは多階層のキャッシュをチェックする。キャッシュされた値が存在しない（またはキャッシュが無効になっている）場合、Brazeはエンドポイントを呼び出し、レスポンスを受け取る。
4. レスポンスは Liquid テンプレートに注入され、メッセージは完全にレンダリングされる。
5. プロバイダベースのチャネルの場合、レンダリングされたメッセージはチャ ネル・プロバイダに送信され、次にユーザーに送信される。コンテンツカードのようなSDK配信チャネルの場合、レンダリングされたコンテンツはBraze SDKに同期され、ファーストインプレッションまたは表示時に生成することができ、その時点でユーザーに表示される。

コネクテッドコンテンツのレスポンシブが一時的に生きる場所

Brazeは、コネクテッドコンテンツのレスポンスに、:cache_max_age やその他のキャッシュルールの使用状況に応じて、TTLが5分～4時間の多層キャッシュを使用する：

• インプロセス・メモリ・キャッシュ：ワーカープロセス内の一時キャッシュ。データはジョブの間（ワーカータイムアウトに基づき最大11分まで）しか保存できない。
• ローカルマシンのキャッシュ：ローカルのMemcachedインスタンスなど、ワーカーごとのキャッシュ。
• クラスタ全体のキャッシュ：Memcachedクラスタのような、ワーカー間で共有される分散キャッシュ。

これらのキャッシュ層は揮発性であり、設定されたTTLよりも早くデータを消去することができる。

を使うと何が変わるのか？ :no_cache

Brazeインフラ内部でホストされていないエンドポイントでは、:no_cache 、コネクテッドコンテンツのレスポンスボディがMemcachedに保存されないようにする。このような場合、レスポンシブはレンダリングジョブの間（最大11分）だけワーカープロセスのメモリに存在する。Braze内部のホストに解決するエンドポイントの場合、キャッシュバストで説明したように、レスポンシブがキャッシュされることがある。

最終的なレンダリング出力をどこに置くか

• メッセージアーカイブ：メッセージアーカイブがイネーブルメントの場合、Brazeは最終レンダリングメッセージを設定したクラウドストレージバケットに書き込むことができる。コネクテッドコンテンツのレスポンスがレンダリングメッセージに含まれている場合、それはアーカイブされたコピーに含まれる。
• ユーザー機器：配信後、完全にレンダリングされたメッセージ・コンテンツは、ユーザー・デバイス上で未知の時間持続する可能性がある。
• コンテンツカード:コンテンツカードのレンダリングコンテンツは、カードの有効期限が切れるまでBrazeのデータベースに保存される。