Real-Time 2.0は、高スループットのイベント取り込み、低レイテンシのパーソナライゼーション、大規模なトリガーアクティベーションのために設計されています。システムの安定性と予測可能なパフォーマンスを確保するために、特定の制限とサービスレベルアグリーメント(SLA)が設定されています。このドキュメントでは、リアルタイムワークロードを運用する際の期待される動作とパフォーマンス特性を概説します。
パフォーマンスと制限
| カテゴリ | 制限 / 動作 | 注記 |
|---|---|---|
| イベントテーブル | ペアレントセグメントあたり最大100個のイベントテーブル | バッチおよびリアルタイムのイベントテーブルの両方を含みます。 |
| IDステッチングキー | ステッチングのために最大100個のIDを設定可能 | 例: email、user_id、td_client_id。 |
| イベント定義 | ハード制限なし | 結合されたフィルター長は1000文字以内である必要があります。 |
| リアルタイムアトリビュート | プロファイルあたり最大200個のアトリビュート(それぞれ500バイト以下) | 単一値、リスト、カウンターアトリビュートを含みます。 |
| 取り込みペイロード | バッチあたり1〜500イベント、イベントあたり1MB、バッチあたり5MB | ストリーミング インジェスト APIとSDKに適用されます。 |
| パーソナライゼーションAPI | レスポンスサイズ: リクエストあたり10KB以下 | より大きなペイロードはレイテンシを増加させる可能性があります。 |
| 取り込みスループット | デフォルト: 顧客あたり2,000イベント/秒 | グローバルに100k+イベント/秒まで水平スケール。 |
| 意思決定スループット | 顧客あたり8,000イベント/秒 | 水平スケール、顧客あたり予想上限100倍。 |
| トリガーアクティベーション | 顧客あたり8,000アクティベーション/秒 | 水平スケール、顧客あたり予想上限100倍。 |
| パーソナライゼーションAPI SLA | 最大20アトリビュートに対して100ms以下(p95)のレスポンスタイム | SLA保証にはエンタープライズサポートが必要です。 |
| トリガーアクティベーションSLA | アクティベーションの配信まで最大3分 | 評価、IDステッチング、アクティベーションディスパッチを含みます。 |
| データ同期 | バッチ → リアルタイム: サポート。リアルタイム → バッチ: サポートされていません | RTアトリビュートはバッチストレージに同期されません。 |
| スケーラビリティ | すべてのコアコンポーネントが水平スケール | 非常に大規模なデプロイ(100+ペアレントセグメント)はPoCで検証する必要があります。 |
水平スケールアウト: Real-Time 2.0は、トラフィックスパイクを管理するためにインフラストラクチャ全体で自動的にスケールします。非常に大規模なデプロイは、概念実証(PoC)フェーズ中に検証を受ける必要があります。
レイテンシの期待: パーソナライゼーションのレスポンスは、通常100ms(p95)以内でほぼ瞬時です。トリガーアクティベーションはエンドツーエンドで最大3分かかる場合があります。取り込みは、線形スケーラビリティで持続的な高スループットをサポートするように設計されています。
データ同期の特性: リアルタイムアトリビュートとバッチアトリビュートは補完的であり、データはバッチからリアルタイムにのみ流れます。リアルタイムアトリビュートはバッチストレージに書き戻されません。
エラー処理: すべてのAPIは冪等であり、再試行セーフです。リクエストを安全に再試行できます。システム制限を超えた場合、標準のHTTPコードと明確なメッセージでエラーが返されます。
極端なスケール(例: 100+ペアレントセグメントまたは10M+イベント/秒)で運用している顧客は、パフォーマンスを徹底的に検証するために段階的なロールアウトを計画する必要があります。
記載されている制限のいずれかを超えることが予想される場合は、Treasure Dataサポートに連絡して、潜在的な設定調整またはスケーリングオプションについて相談してください。
リアルタイムジャーニー内のA/Bテストやアトリビュート/プロファイルの削除などの特定の高度な機能は、現在開発中であり、将来変更される可能性があります。