ユースケース：外部データソースとカスタムアクションを使用してスループットを制限する limit-throughput
ユースケースの説明
Adobe Journey Optimizer を使用すると、実務担当者は、カスタムアクションとデータソースを使用して、外部システムに API 呼び出しを送信できます。
これは以下を使用して行うことができます。
-
データソース：外部システムから情報を収集し、その情報をジャーニーコンテキストで使用します（例えば、プロファイル都市の天気情報を取得し、それに基づいて専用のジャーニーフローを持つ場合）。
-
カスタムアクション：外部システムに情報を送信します（例えば、プロファイル情報、オーディエンスデータ、ジャーニーコンテキストと共に Journey Optimizer のオーケストレーション機能を使用して外部ソリューションからメールを送信する）。
外部データソースやカスタムアクションを扱う場合は、ジャーニーのスループットを制限して、外部システムを保護する必要が生じる場合があります。単一ジャーニーの場合は最大 5000 インスタンス/秒、オーディエンストリガージャーニーの場合は最大 20,000 インスタンス/秒です。
カスタムアクションの場合、スロットル機能は製品レベルで使用できます。 このページを参照してください。
外部データソースの場合、Journey Optimizer の Capping API を使用して、これらの外部システムに圧倒されるのを回避できるようエンドポイントレベルでキャッピングの制限を定義できます。ただし、制限に到達後、残りのリクエストはすべて破棄されます。この節では、スループットを最適化するために使用できる回避策を見つけます。
外部システムとの統合方法について詳しくは、このページを参照してください。
実装
オーディエンストリガージャーニー では、ジャーニーのスループットに影響を与える「オーディエンスを読み取り」アクティビティの読み取り率を定義できます。詳細情報
この値は、1 秒あたりのインスタンス数 500 件から 20,000 件の範囲で変更できます。1 秒あたり 500 件未満にする必要がある場合は、待機アクティビティと共に「パーセンテージ分割」条件を追加して、ジャーニーを複数の分岐に分割し、特定の時間に実行させることもできます。
例として、10,000 件のプロファイル を持つ母集団を扱う オーディエンストリガージャーニー があり、1 秒あたり 100 件のリクエスト をサポートする外部システムにデータを送信するとします。
-
1 秒あたり 500 プロファイルのスループットでプロファイルを読み取るように、「オーディエンスを読み取り」を定義することができます。つまり、すべてのプロファイルを読み取るのに 20 秒かかります。1 秒目では、そのうち 500 件を読み取り、2 秒目ではさらに 500 件、というように読み取ります。
-
次に、20％の分割を持つ「パーセンテージ分割」条件アクティビティを追加して、各分岐の各秒に 100 件のプロファイルを持つことができます。
-
その後、各分岐で、特定のタイマーを使用して待機アクティビティを追加します。ここでは、それぞれに対して 30 秒の待機を設定しました。毎秒、100 件のプロファイルが各分岐に送られます。
-
分岐 1 では、30 秒待機します。つまり、
- 1 秒目では、100 件のプロファイルが 31 秒目まで待機します
- 2 秒目では、100 件のプロファイルが 32 秒目まで待機し、以下同様に続きます。
-
分岐 2 では、60 秒待機します。つまり、
- 1 秒目では、100 件のプロファイルが 61 秒目（1 分 1 秒）まで待機します
- 2 秒目には、100 件のプロファイルが 62 秒目（1 分 2 秒）まで待機し、以下同様に続きます。
-
すべてのプロファイルを読み取るのに最大 20 秒が必要となることがわかっているため、各分岐間で重複は発生せず、条件にプロファイルが送られるのは 20 秒目が最後となります。31 秒から 51 秒の間に、分岐 1 内のすべてのプロファイルが処理されます。61 秒目（1 分 1 秒）から 81 秒目（1 分 21 秒）の間で、分岐 2 内のすべてのプロファイルが処理されます。
-
ガードレールとして、特に外部システムが 1 秒あたり 100 リクエストしかサポートしていない場合に、1 つの分岐あたり 100 件未満のプロファイルを持つ 6 つ目の分岐を追加することもできます。
-
追加のガードレールとして、キャッピング機能を使用することもできます。