Skip to main content
イベントストリームを開発する際に最大限の効果を得るため、Auth0 では以下にまとめたベストプラクティスに従うことを推奨しています。これらのガイドラインは、手戻りや負担を減らし、効率を高め、より優れたイベント活用の実現に役立ちます。

​
イベントの処理には非同期キューを使用する

イベントを受信したら、HTTP 2XX OK (例: 200 OK、202 Accepted、204 No Content) を返して、イベントが正常に配信されたことを示します。この応答がない場合、Auth0 はイベント配信を失敗と見なし、イベント配信失敗時のシステム動作で説明されている動作に従って再試行します。 スケーラビリティの問題を避けるため、受信したイベントを非同期キューで処理するようにハンドラーを構成してください。イベントを同期的に処理すると、Webhook 配信が急増した際に (たとえば、月初にすべてのサブスクリプションが更新されるとき) 、エンドポイントのホストが処理しきれなくなる可能性があります。非同期キューを使えば、同時発生するイベントをシステムで対応可能な速度で処理できます。

​
重複するイベントを無視する

Webhookエンドポイントでは、同じイベントを複数回受信することがあります。処理済みのイベントIDを記録しておくことで、重複したイベントの受信を防げます。

​
順不同で届くイベントを処理する

Auth0 は、イベントが生成された順序どおりに配信されることを保証していません。たとえば、ユーザーが作成された直後に更新され、別のユーザーにリンクされた場合、次のような順序で受信することがあります。
  • user.updated (for User 1)
  • user.created (for User 1)
  • user.deleted (for User 2)
  • user.updated (for User 2)
古い情報でデータを上書きしないようにするには、受信したウェブフックの time 属性を、システム内のデータのタイムスタンプと比較してください。ペイロード内の data.object 属性には、操作固有のタイムスタンプとして created_at フィールドと updated_at フィールドが含まれる場合もあります。詳細については、Event Catalog のイベント詳細を参照してください。

​
特定のイベントタイプのみを受信する

Webhook エンドポイントが、連携に必要なイベントタイプのみを受信するように設定します。不要なイベント (またはすべてのイベント) を受信すると、サーバーに過度な負荷がかかるため、推奨されません。 Webhook エンドポイントが受信するイベントは、イベントストリームを更新することで変更できます。

​
イベント配信の失敗時におけるシステムの動作

現在、Auth0 では、初回の試行と指数バックオフ (1秒、2秒、4秒) による3回の再試行を含め、合計4回までしか試行されません。4XX を受信した場合は、再試行しても応答が変わる可能性が低いため、イベントは再試行されず即座に失敗となります。 この時点までにエンドポイントが正常な応答を返さない場合、そのイベントは失敗としてマークされ、Auth0 は以後その送信を再試行しません。イベントの失敗について詳しくは、イベントストリーム Testing, Observability, and Failure Recoveryを参照してください。

​
障害が発生しているイベントストリームを無効にする

イベントストリームは、次のいずれかの場合に自動的に無効になります。
  • Auth0 が 500 回連続で失敗応答 (つまり、2XX 以外の応答) を受信した場合。
  • イベントストリーム の配信失敗総数が 5000 件に達した場合。
  • Auth0 が 3 回連続で配信試行の失敗 (つまり、2XX 以外の応答) を受信した場合。
    • 配信試行の失敗回数の上限を増やしたい場合は、許可を希望する失敗回数を記載のうえ、サポートチケットを送信してください。Auth0 にてリクエストを確認します。

​
詳細を見る