メインコンテンツへスキップ
Event Stream を開発する際は、以下にまとめたベストプラクティスに従うことを 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)
古い情報でデータを上書きしないようにするには、受信した webhook データのタイムスタンプを、システム内のデータのタイムスタンプと照合してください。ペイロード内の各 data.object には、created_at フィールドと updated_at フィールドが含まれます。

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

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

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

現在、Auth0 では、初回の試行に加え、指数バックオフ (1 秒、2 秒、4 秒) による 3 回の再試行までの、合計 4 回のみが許可されています。4XX 応答を受信した場合は、再試行せずにそのイベントはただちに失敗となります。再試行しても応答が変わる可能性が低いためです。 この間にエンドポイントから正常な応答が返らない場合、そのイベントは失敗としてマークされ、Auth0 は以後そのイベントの送信を再試行しません。失敗したイベントの詳細については、Event Stream のテスト、可観測性、障害復旧を参照してください。

​
障害が発生している Event Stream を無効にする

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

​
詳細情報