外部システムとの統合

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

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

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

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

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

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

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

キャッピング

組み込みのキャッピング API を使用すると上流でテクニカルガードレールを設けることができ、外部システムの保護に役立ちます。

外部データソースの場合、1秒あたりの最大呼び出し数は15に設定されます。 1秒あたりの呼び出し数が15を超えると、残りの呼び出しは破棄されます。 この制限は、プライベート外部データソースに対して増やすことができます。 Adobeに問い合わせて、エンドポイントをホワイトリストに登録します。 パブリック外部データソースに対しては、この操作はできません。

カスタムアクションの場合は、外部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 秒の間にする必要があります。 この このページを参照してください。

このページ