名前空間トピックを使用したメッセージのプッシュ配信と再試行

[アーティクル]
05/21/2024

Event Grid 名前空間プッシュ配信は持続的な配信を提供します。 Event Grid は、一致する各サブスクリプションに対して、最低 1 回は各メッセージを直ちに配信しようとします。サブスクライバーのエンドポイントがイベントの受信を認識しない場合、またはエラーが発生した場合、Event Grid では、固定された再試行スケジュールと再試行ポリシーに基づいて配信を再試行します。既定では、Event Grid によって、サブスクライバーに一度に 1 つのイベントが配信されます。

Note

Event Grid によるイベント配信の順序は保証されません。そのため、サブスクライバーはこれらを順序どおりに受信できない場合があります。

イベントサブスクリプション

イベントサブスクリプションは、1 つの名前空間トピックに関連付けられた構成リソースです。特に、イベントサブスクリプションを使用してイベント選択条件を設定し、特定のトピックで利用できるイベントの全セットの中でサブスクライバーが使用できるイベントコレクションを定義します。イベントサブスクリプションを使用して、イベントが送信される送信先エンドポイントも定義します。また、イベントサブスクリプションでは、イベント配信のランタイムの動作を定義する最大配信再試行回数やイベントの有効期限など、その他のプロパティを設定できます。

再試行のスケジュール

イベント配信の試行に関するエラーを Event Grid で受信した場合は、エラーの種類に基づいて、イベント配信の再試行を行う必要があるかが Event Grid により決定されます。

サブスクライブ済みのエンドポイントによって返されたエラーが、再試行で修正できない構成関連のエラーの場合、Event Grid は構成済みのイベントの配信不能メッセージの送信先にイベントを送信します。配信不能メッセージが構成されていない場合、イベントは削除されます。たとえば、イベントサブスクリプションに構成されたエンドポイントが削除されたために到達できない場合、イベントは配信不能処理されるか、削除されます。次の条件およびエラーでは、配信の再試行は行われません。

条件:

ArgumentException
TimeoutException
UnauthorizedAccessException
OperationCanceledException
SocketException |

エラーコード

404 - NotFound
401 - Unauthorized
403 - Forbidden
400 -BadRequest
414 RequestUriTooLong

Note

エンドポイントに対して配信不能が構成されていない場合、上記のエラーや条件が発生すると、イベントは削除されます。この種のイベントを削除したくない場合は、イベントサブスクリプションに配信不能を構成することを検討してください。配信不能イベントは、配信不能メッセージの宛先が見つからない場合、削除されます。

サブスクライブ済みのエンドポイントによって返された条件やエラーが上記の一覧の中にない場合、Event Grid は次の指数バックオフの再試行スケジュールを使用して、基本作業ベースで再試行します。

0 秒 (即時再試行)
10 秒
30 秒
1 分
5 分

5 分を過ぎると、Event Grid は、イベントが配信されるか、最大試行回数またはイベント時間に達するまで、5 分ごとに再試行を続けます。

再試行ポリシー

次の 2 つのイベントサブスクリプション構成プロパティを使用して、再試行ポリシーをカスタマイズできます。イベントは、どちらかのプロパティが構成済みの上限に達すると、削除される (配信不能メッセージが構成されない) か配信不能メッセージが送信されます。

最大配信数 - この値は 1 から 10 の間の整数で指定してください。既定値は 10 です。プッシュ配信の場合、このプロパティは最大配信試行回数を定義します。
保持 - このプロパティは event time to live としても知られています。値は ISO 8601 期間の値で、分単位の精度である必要があります。このプロパティは、イベントが公開された時刻から、メッセージが期限切れになるまでの時間を定義します。指定できる最小値は "PT1M" (1 分) です。許容される最大値は、7 日または基になるトピックの保持時間のいずれか低い方です。 Azure portal は、日、時間、分を整数で指定するシンプルなユーザーエクスペリエンスを提供します。

Note

Retention と Maximum delivery count の両方を設定した場合、Event Grid はそれらの設定を使用して、イベント配信を停止するタイミングを判別します。どちらかでイベント配信が停止されます。たとえば、保持時間を 20 分、最大配信試行回数を 10 回に設定した場合、イベントが 20 分経っても配信されないか、10 回試みても配信されないかのどちらかが先に発生した場合、そのイベントは配信不能になります。ただし、再試行スケジュールがあるため、最大配信試行回数を 10 回に設定しても、イベントはまず 20 分後に配信不能になるため、影響はありません。これは、20 分で配信試行 #8 (0、10 秒、30 秒、1 分、5 分、10 分、15 分、20 分) が発生しますが、その時点でイベントが配信不能になっているためです。

出力のバッチ処理

送信先エンドポイントの種類として Webhooks を使用する場合、Event Grid は既定で各イベントを個別にサブスクライバーに送信します。高スループットの状況で HTTP のパフォーマンスを向上させるため、イベントを一括配信するように Event Grid を構成することができます。バッチ処理は、既定では無効になっており、イベントサブスクリプションごとに有効にできます。

送信先エンドポイントの種類として Event Hubs を使用する場合、Event Grid は最大効率とパフォーマンスのために常にイベントをバッチ処理します。既定では、Event Grid は Azure Event Hubs に配信する場合のバッチ動作を処理するため、バッチポリシー構成はありません。

バッチ処理のポリシー

一括配信には、次の 2 つの設定があります。

[バッチごとの最大イベント数] - Event Grid によってバッチごとに配信されるイベントの最大数。この値には 1 から 5,000 までの整数を指定してくださいこの数字を超えることはありません。ただし、配信時に配信可能なイベントがない場合は、配信数が少なくなる場合があります。配信できるイベントの数が少ない場合、バッチを作成するために Event Grid でイベントが遅延されることはありません。
優先バッチサイズ (KB 単位) - バッチサイズの目標上限 (KB 単位)。値は 1 ～ 1024 の数値である必要があります。最大イベント数と同様に、配信の時点で使用できないイベントが十分ない場合は、バッチサイズが小さくなることがあります。 1 つのイベントが優先サイズより大きい "場合"、バッチが優先バッチサイズより大きくなることがあります。たとえば、優先サイズが 4 KB で、10 KB のイベントが Event Grid にプッシュされた場合でも、10 KB のイベントは削除されるのではなく、配信されます。

バッチ配信は、ポータル、CLI、PowerShell、または SDK を使用して、イベントごとのサブスクリプションで構成されます。

バッチ処理の動作

すべてまたはなし

Event Grid 操作は、"すべてまたはなし" のセマンティクスです。バッチ配信の一部成功はサポートされていません。サブスクライバーは、バッチごとに 30 秒で合理的に処理できるだけの数のイベントを要求するように注意する必要があります。
オプティミスティックバッチ処理

バッチ処理ポリシー設定は、バッチ処理動作に対する厳密な限界ではなく、ベストエフォートベースで尊重されます。イベントレートが低い場合、バッチのサイズが、バッチごとのイベントの要求した最大数より小さいことがよくあります。
既定値は OFF に設定されています

既定では、Event Grid によって、各配信要求に 1 つのイベントのみが追加されます。バッチ処理をオンにする方法は、バッチ処理ポリシーで説明した設定のいずれかを設定することです。
既定の値

イベントサブスクリプションを作成するときに、両方の設定 (バッチあたりの最大イベント数とキロバイト単位の概算バッチサイズ) を指定する必要はありません。 1 つの設定さえ指定されれば、Event Grid によって既定値が使用されます。既定値と、それらをオーバーライドする方法については、以降のセクションを参照してください。

Azure portal

これらの設定は、[イベントサブスクリプション】ページの [追加機能] タブ、またはイベントサブスクリプションが作成されると、イベントサブスクリプションにアクセスする場合の構成メニューオプションに表示されます。

[バッチ処理] セクションが強調表示されている [イベントサブスクリプション] ページの [追加機能] タブを示すスクリーンショット。

配信不能イベント

Event Grid では、一定の時間内にイベントを配信できない場合、あるいはイベントの配信を一定回数試行したが配信できない場合、イベントがストレージアカウントに送信されます。このプロセスは配信不能処理と呼ばれます。 Event Grid では、次のいずれかの条件に一致したとき、イベントが配信不能処理されます。

イベントが有効期限 (イベントサブスクリプションで定義された保持) 期間内に配信されませんでした。
イベント配信の試行回数が上限を超えている。

いずれかが満たされた場合、イベントは削除されるか、配信不能になります。既定では、Event Grid は配信不能処理を有効にしません。この処理を有効にするには、イベントサブスクリプションの作成時に、配信不能イベントを保持するようにストレージアカウントを指定する必要があります。このストレージアカウントからイベントを読み取って配信を解決します。

Event Grid は、そのすべての再試行を試行し終わると、配信不能の場所にイベントを送信します。 Event Grid で 400 (正しくない要求) または 413 (要求のエンティティが大きすぎます) の応答コードが受信された場合、そのイベントの配信不能処理が即時にスケジュールされます。これらの応答コードは、イベントの配信が決して成功しないことを示します。

Time-To-Live の期限が切れたかどうかは、スケジュールされている次の配信試行時にのみ確認されます。したがって、スケジュールされている次の配信試行の前に Time-To-Live の期限が切れた場合でも、イベントの期限切れは次の配信時にのみチェックされ、その後で配信不能になります。

イベントの配信を最後に試してから、それが配信不能の場所に届くまで、5 分間の遅延があります。この遅延の目的は、BLOB ストレージの操作数を減らすことにあります。配信不能の場所が 4 時間にわたって使用できない場合、そのイベントは破棄されます。

配信不能の場所を設定するには、コンテナーを含むストレージアカウントが必要です。イベントサブスクリプションの作成時に、このコンテナーのエンドポイントを指定します。エンドポイントの形式は次のとおりです。/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Storage/storageAccounts/<storage-name>/blobServices/default/containers/<container-name>

イベントが配信不能の場所に送信されたら通知を受け取るようにすることもできます。 Event Grid を使用して配信不能イベントに応答するには、配信不能 Blob ストレージ用のイベントサブスクリプションを作成します。配信不能 Blob ストレージが配信不能イベントを受信するたびに、Event Grid はハンドラーに通知します。ハンドラーは、配信不能イベントを調整するためのアクションで応答します。

配信不能を構成する場合は、配信不能イベントを保持する Azure Storage アカウントの適切なロールベースのアクセス制御 (RBAC) ロールにマネージド ID を追加する必要があります。詳細については、「サポートされている配信先と Azure ロール」を参照してください。

配信イベントの形式

このセクションでは、名前空間トピックでサポートされているメッセージメタデータ形式である CloudEvents 1.0 スキーマを使用したイベントと配信不能処理されたイベントの例を示します。

CloudEvents 1.0 スキーマ

event

{
    "id": "caee971c-3ca0-4254-8f99-1395b394588e",
    "source": "mysource",
    "dataversion": "1.0",
    "subject": "mySubject",
    "type": "fooEventType",
    "datacontenttype": "application/json",
    "data": {
        "prop1": "value1",
        "prop2": 5
    }
}

配信不能イベント

[
  {
    "deadLetterProperties": {
      "deadletterreason": "Maximum delivery attempts was exceeded.",
      "deliveryattempts": 1,
      "deliveryresult": "Event was not acknowledged nor rejected.",
      "publishutc": "2023-11-01T20:33:51.4521467Z",
      "deliveryattemptutc": "2023-11-01T20:33:52.3692079Z"
    },
    "event": {
      "comexampleextension1": "value1",
      "id": "A234-1234-1234",
      "comexampleothervalue": "5",
      "datacontenttype": "text/xml",
      "specversion": "1.0",
      "time": "2018-04-05T17:31:00Z",
      "source": "/mycontext",
      "type": "com.example.someevent",
      "data": <your-event-data>
    }
  }
]

LastDeliveryOutcome: Probation

イベントサブスクリプションは、その宛先へのイベント配信が失敗し始めた場合、Event Grid によって一定期間プロベーション状態にされます。プロベーションの期間は、宛先エンドポイントから返されるエラーの種類によって異なります。イベントサブスクリプションがプロベーション状態になっている場合、プロベーション状態になっていることが原因で発生したエラーコードに応じて、イベントが配信不能になるか、または配信を試行せずに破棄される可能性があります。

Error	プロベーションの期間
ビジー	10 秒
NotFound	5 分
SocketError	30 秒
ResolutionError	5 分
無効	5 分
[完全]	5 分
TimedOut	10 秒
権限がありません	5 分
Forbidden	5 分
InvalidAzureFunctionDestination	10 分

Note

Event Grid では、配信管理を強化するためにプロベーションの期間を使用していますが、この期間は将来変更される可能性があります。

メッセージの配信状態

Event Grid は、HTTP 応答コードを使用してイベントの受信を確認します。

成功コード

Event Grid は、次の HTTP 応答コードのみを正常な配信と見なします。その他のすべてのステータスコードは配信失敗と見なされ、必要に応じて再試行されるか、配信不能とされます。 Event Grid が正常な状態コードを受信すると、配信が完了したと見なされます。

200 OK
201 Created
202 Accepted
203 権限のない情報
204 No Content

エラーコード

上記のセット (200 ～ 204) にない他のすべてのコードはエラーと見なされ、必要に応じて再試行されます。一部には、以下で説明するように特定の再試行ポリシーが関連付けられていますが、他はすべて標準の再試行スケジュールに従います。重要な注意点としては、Event Grid のアーキテクチャは高度に並列化されているため、再試行の動作は非決定的です。

status code	再試行の動作
400 Bad Request	再試行されません
401 権限がありません	5 分以上後に、Azure のリソースエンドポイントに対して再試行
403 許可されていません	再試行されません
404 見つかりません	5 分以上後に、Azure のリソースエンドポイントに対して再試行
408 要求タイムアウト	2 分以上後に再試行
413 要求のエンティティが大きすぎます	再試行されません
503 サービス利用不可	30 秒以上後に再試行
その他すべて	10 秒以上後に再試行

カスタム配信のプロパティ

イベントサブスクリプションを使用すると、配信されたイベントに含まれる HTTP ヘッダーを設定できます。この機能を使用すると、宛先に必要なカスタムヘッダーを設定できます。イベントサブスクリプションを作成するときに、最大 10 個のヘッダーを設定できます。各ヘッダーの値は、4,096 (4 K) バイトより大きくすることはできません。次の宛先に配信されるイベントにカスタムヘッダーを設定できます。

ウェブフックs
Azure Event Hubs

次のステップ

イベントを Webhook エンドポイントに配信します。

次の方法で共有

名前空間トピックを使用したメッセージのプッシュ配信と再試行

イベントサブスクリプション

再試行のスケジュール

再試行ポリシー

出力のバッチ処理

バッチ処理のポリシー

バッチ処理の動作

Azure portal

配信不能イベント

配信イベントの形式

CloudEvents 1.0 スキーマ

event

配信不能イベント

メッセージの配信状態

成功コード

エラーコード

カスタム配信のプロパティ

次のステップ

フィードバック

フィードバック

その他のリソース

次の方法で共有

名前空間トピックを使用したメッセージのプッシュ配信と再試行

イベント サブスクリプション

再試行のスケジュール

再試行ポリシー

出力のバッチ処理

バッチ処理のポリシー

バッチ処理の動作

Azure portal

配信不能イベント

配信イベントの形式

CloudEvents 1.0 スキーマ

event

配信不能イベント

メッセージの配信状態

成功コード

エラー コード

カスタム配信のプロパティ

次のステップ

フィードバック

フィードバック

その他のリソース

イベントサブスクリプション

エラーコード