外部システムとの統合

このページでは、外部システムの統合時にJourney Orchestrationが提供する様々なガードレールとベストプラクティスを示します。キャッピング API を使用して外部システムの保護を最適化する方法、ジャーニーのタイムアウトを設定する方法、再試行の動作方法を説明します。

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

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

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

Journey Orchestrationが外部 API の呼び出しを実行する場合、テクニカルガードレールは次のように実行されます。

  1. キャッピングルールの適用。処理数の上限に達すると、残りの呼び出しは破棄されます。

  2. タイムアウトして再試行：上限ルールが満たされた場合、Journey Orchestrationはタイムアウト時間の終わりに達するまで呼び出しを実行しようとします。

キャッピング

ビルトインのキャッピング API は、外部システムの保護に役立つアップストリームの技術的ガードレールを提供します。

外部データソースの場合、1 秒あたりの最大呼び出し回数は 15 に設定されています。 1 秒あたりの呼び出し回数が 15 を超えると、残りの呼び出しは破棄されます。 プライベート外部データソースに対しては、この上限を増やすことができます。 アドビに連絡して、エンドポイントを許可リストに含めてください。パブリック外部データソースに対しては、この操作は行えません。

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

キャッピングルールは、特定のエンドポイント（呼び出し先の URL）のサンドボックスレベルで定義されます。 実行時に、Journey Orchestrationは、キャッピングルールが定義されているかどうかを検証し、そのエンドポイントへの呼び出し中に、定義された率を適用します。 呼び出しの数が定義された上限を超えると、残りの呼び出しは破棄され、レポートではエラーとしてカウントされます。

1 つのキャッピングルールは 1 つのエンドポイントに固有ですが、サンドボックスのすべてのジャーニーに対してグローバルです。 つまり、キャッピングスロットは、サンドボックスのすべてのジャーニー間で共有されます。

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

キャッピング API の詳細とキャッピングルールの設定方法については、このページを参照してください。

タイムアウトと再試行

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

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

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

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

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

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

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

  • 最初の呼び出しが 5 秒未満続く：呼び出しは成功し、再試行は実行されません。
  • 最初の呼び出しが 5 秒以上続く：呼び出しがキャンセルされ、再試行はありません。 レポートでは、タイムアウトエラーとしてカウントされます。
  • 最初の呼び出しが 2 秒後に失敗する（外部システムがエラーを返す）：キャッピングスロットが使用可能な場合、再試行の残り時間は 3 秒です。
    • 3 回の再試行のうち 1 回が 5 秒以内に成功した場合は、呼び出しが実行され、エラーは発生しません。
    • 再試行中にタイムアウト時間の終わりに達した場合、呼び出しはキャンセルされ、レポートではタイムアウトエラーとしてカウントされます。

よくある質問

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

デフォルトでは、キャッピングルールはありません。 キャッピングルールは、キャッピング API を使用して、特定のエンドポイント（呼び出された URL）のサンドボックスレベルで定義されます。 この節とこのページを参照してください。

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

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

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

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

このページ