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

このページでは、外部システムと統合するときに Journey Optimizer が提供する、さまざまなガードレールを紹介します。また、Capping 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 件の呼び出ししかサポートできない場合、システムが飽和状態にならないようにキャップ設定またはスロットル設定を定義する必要があります。詳しくは、アクションの設定方法を参照してください

応答時間が遅いエンドポイント response-time

エンドポイントの応答時間が 0.75 秒を超える場合、そのカスタムアクションの呼び出しは、デフォルトのサービスではなく、専用の​ 低速カスタムアクションサービス ​を通じてルーティングされます。

この低速カスタムアクションサービスでは、30 秒ごとに 150,000 回の呼び出しというキャップ制限が適用されます。この制限は、30 秒間の任意のミリ秒から開始できるスライディングウィンドウを使用して適用されます。 ウィンドウがいっぱいになると、追加の呼び出しはキャップエラーで拒否されます。システムは、次の固定間隔を待たずに、30 秒のしきい値に達するとすぐにキャップを開始します。

低速エンドポイントは、パイプライン内のキュー内のすべてのアクションに遅延を引き起こす可能性があるので、応答時間が遅いエンドポイントでカスタムアクションを設定しないことをお勧めします。このようなアクションを低速サービスにルーティングすると、システム全体のパフォーマンスを保護し、他のカスタムアクションの待ち時間が増えるのを防ぐことができます。

タイムアウトと再試行 timeout

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

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

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

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

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

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

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

よくある質問 faq

Journey Optimizerと外部システムの統合に関するよくある質問（FAQ）を以下に示します。

さらに詳細が必要ですか？このページの下部にあるフィードバックオプションを使用して、質問を入力するか、Adobe Journey Optimizer コミュニティにアクセスしてください。