外部システムとの統合 external-systems

このページでは、外部システムと統合するときに Journey Optimizer が提供する、さまざまなガードレールを紹介します。また、キャッピング API で外部システムを最適に保護する方法、ジャーニータイムアウトを設定する方法、再試行の仕組みなどのベストプラクティスも紹介します。

Journey Optimizer では、カスタムデータソースとカスタムアクションを使用して、外部システムへの接続を設定できます。 これにより、例えば、外部の予約システムからのデータを使用してジャーニーを充実させたり、Epsilon や Facebook などのサードパーティシステムを使用してメッセージを送信したりできます。

外部システムを統合する際には、問題がいくつも発生したり、システムが低速になったり、応答が停止したり、大量の処理を行えなくなったりする場合があります。 Journey Optimizer には、システムを過負荷から保護するためにいくつかのガードレールがあります。

外部システムのパフォーマンスはさまざまです。 使用例に合わせて設定を調整する必要があります。

Journey Optimizer が外部 API を呼び出すと、次のようなテクニカルガードレールを実行します。

Capping API と Throttling API capping

Capping API とThrottling API について

データソースやアクションを設定する際は、システムへの接続を確立して、ジャーニーで使用する追加情報を取得するか、メッセージや API 呼び出しを送信します。

ジャーニー API では 1 秒あたり最大 5,000 イベントをサポートしていますが、一部の外部システムや API は同等のスループットを持たない場合があります。これらのシステムの過負荷を防ぐために、Capping API と Throttling API を使用して、1 秒あたりに送信されるイベントの数を制限できます。

API 呼び出しがジャーニーによって実行されるたびに、API エンジンを通過します。API で設定された制限に達すると、Capping API を使用している場合は呼び出しが拒否され、Throttling API を使用している場合は最大 6 時間キューに入れられ、受信した順序でできるだけ早く処理されます。

たとえば、外部システムに対して 1 秒あたり 200 呼び出しまで、というキャッピングルールまたはスロットルルールを定義したとします。システムは、10 件の異なるジャーニーでカスタムアクションによって呼び出されます。1 つのジャーニーで 1 秒間に 300 件の呼び出しを受け取った場合、使用可能な 200 個のスロットを使用し、残りの 100 個のスロットを破棄するかキューに入れます。最大レートを超えたので、他の 9 つのジャーニーにはスロットは残りません。この精度は、外部システムを過負荷やクラッシュから保護するのに役立ちます。

API の使用方法について詳しくは、次の節を参照してください。

API について詳しくは、Adobe Journey Optimizer API ドキュメントを参照してください。

データソースとカスタムアクションの処理能力 capacity

外部データソース ​の場合、1 秒あたりの最大呼び出し回数は 15 に制限されています。この上限を超えると、使用中の API に応じて、追加の呼び出しは破棄されるかキューに入れられます。アドビに連絡して許可リストにエンドポイントを含めることにより、プライベート外部データソースについてこの上限を増やすことができますが、これはパブリック外部データソースの場合に選択できるオプションではありません。* データソースの設定方法についてはこちらを参照してください。

カスタムアクション ​の場合は、外部 API の処理能力を評価しておく必要があります。例えば、Journey Optimizer が 1 秒あたり 1000 件の呼び出しを送信しているのに対して、システムが 1 秒あたり 200 件の呼び出ししかサポートできない場合、システムが飽和状態にならないようにキャッピング設定またはスロットル設定を定義する必要があります。詳しくは、アクションの設定方法を参照してください

タイムアウトと再試行 timeout

キャッピングルールまたはスロットルルールが満たされると、タイムアウトルールが適用されます。

各ジャーニーで、タイムアウト時間を定義できます。 これにより、外部システムを呼び出す時の最大時間を設定できます。 タイムアウト時間は、ジャーニーのプロパティで設定します。 このページを参照してください。

このタイムアウトは、すべての外部呼び出し（カスタムアクションおよびカスタムデータソースの外部 API 呼び出し）に対してグローバルに適用されます。デフォルトでは 30 分に設定されています。

定義されたタイムアウト時間中に、Journey Optimizer は外部システムの呼び出しを試みます。 最初の呼び出しの後、タイムアウト時間の終わりに達するまで、最大 3 回の再試行を実行できます。 再試行の回数は変更できません。

1 つの再試行は、1 つのスロットを使用します。1 秒あたり 100 回のキャッピング（呼び出しの上限）があり、各呼び出しに 2 回の再試行が必要な場合、速度は 1 秒あたり 30 回に低下します（最初の呼び出しと 2 回の再試行で、呼び出しごとに次の 3 つのスロットが使用されます）。

タイムアウト時間の値は、使用例によって異なります。 クライアントがストアに入ったときなど、メッセージをすぐに送信したい場合は、長いタイムアウトを設定しません。 タイムアウトが長いほど、キューに入るアイテムも増えます。これは、パフォーマンスに大きな影響を与えます。 Journey Optimizer が 1 秒あたり 1000 回の呼び出しを実行する場合、データを 5 秒または 15 秒保持すると、システムがすぐに圧迫される可能性があります。

5 秒のタイムアウトの例を見てみましょう。

よくある質問 faq

キャッピングルールまたはスロットルルールはどのようにして設定できますか？デフォルトのルールはありますか？

キャッピングルールまたはスロットルルールを作成する方法について詳しくは、この節を参照してください。デフォルトでは、スロットルルールはありませんが、すべてのカスタムアクションに対して、各ホストおよび各サンドボックスに、1 分間で 300,000 件の呼び出しというキャッピングが定義されています。この制限は、カスタムアクションの対象となる外部エンドポイントを保護することを目的に、顧客の使用状況に基づいて設定されています。適切な読み取り率（カスタムアクションを使用する場合は 1 秒あたり 5,000 件のプロファイル）を定義して、オーディエンスベースのジャーニーでこの点を考慮する必要があります。必要に応じて、Capping API と Throttling API でキャッピングまたはスロットル制限を大きく定義することで、この設定を上書きできます。

再試行は何回行われますか？再試行の回数を変更したり、再試行間の最小待ち時間を定義したりできますか？

特定の呼び出しに対しては、最初の呼び出しの後、タイムアウト時間の終わりに達するまで、最大 3 回の再試行を実行できます。 再試行の回数と各再試行間の時間は変更できません。 この節を参照してください。

タイムアウトはどこで設定できますか？最大値はありますか？

各ジャーニーで、タイムアウト時間を定義できます。 タイムアウト時間は、ジャーニーのプロパティで設定します。 タイムアウト時間は、1 秒から 30 秒の間にする必要があります。 この 節とこのページを参照してください。