HTTP によるプル配信
この記事は、「Azure Event Grid とは」および Event Grid の概念に関する記事に基づいており、HTTP 経由で Event Grid のプル配信の使用を開始する前に重要な情報を提供します。 基本的な概念、リソース モデル、サポートされているメッセージ配信モードを対象にしています。 このドキュメントの最後には、Event Grid の使用方法を示す記事や、詳細な概念情報を提供する記事への便利なリンクが記載されています。
Note
このドキュメントは、HTTP プロトコルを使用する Event Grid 機能の使用を開始するのに役立ちます。 この記事は、クラウド上のアプリケーションを統合する必要があるユーザーに適しています。 IoT デバイス データの通信が必要な場合は、「Azure Event Grid での MQTT ブローカー機能の概要」を参照してください。
CloudEvents
Event Grid 名前空間トピックでは、JSON 形式 で HTTP プロトコル バインド を使用して、Cloud Native Computing Foundation (CNCF) のオープン標準の CloudEvents 1.0 仕様に準拠するイベントを受け入れます。
詳しくは、「CloudEvents のサポート」をご覧ください。
CloudEvents コンテンツ モード
CloudEvents 仕様では、使用できる 3 つのコンテンツ モードが定義されています。これらは、バイナリ、構造化、バッチです。
重要
任意のコンテンツ モードで、テキスト (JSON、テキスト/* など) またはバイナリ エンコードされたイベント データを交換できます。 バイナリ コンテンツ モードは、バイナリ データの送信専用に使用されるわけではありません。
コンテンツ モードは、バイナリやテキストに使用するエンコードに関するものではなく、イベント データとそのメタデータが記述および交換される方法に関するものです。 構造化コンテンツ モードでは、JSON オブジェクトなどの 1 つの構造が使用されます。ここでは、コンテキスト属性とイベント データの両方が HTTP ペイロード内にまとめて配置されます。 バイナリ コンテンツ モードでは、HTTP ヘッダーにマップされるコンテキスト属性と、Content-Typeのメディアの種類の値に従ってエンコードされる HTTP ペイロードであるイベント データが分離されます。
詳しくは、「CloudEvents のコンテンツ モード」をご覧ください。
メッセージとイベント
CloudEvent では通常、システム内の事象を通知するイベント データ (つまり、システム状態の変化) が伝送されます。 ただし、CloudEvents を使用する場合は、あらゆる種類のデータを伝達できます。 たとえば、CloudEvents 交換形式を使用して、ダウンストリーム アプリケーションにアクションを要求するコマンド メッセージを送信できます。 もう 1 つの例は、Event Grid の MQTT ブローカーからトピックにメッセージをルーティングする場合です。 このシナリオでは、CloudEvents エンベロープにラップされた MQTT メッセージをルーティングします。
プル配信
プル配信を使用すると、アプリケーションでは Event Grid に接続し、キューに似たセマンティクスを使用して CloudEvent を読み取ります。
プル配信には、次のイベント消費の利点があります。
独自のペースで、アプリケーションがサポートする規模や受信レートでイベントが消費されます。
独自に選択した時点でイベントが消費されます。 たとえば、ビジネス要件によって、メッセージが夜間に処理されます。
データがプライベート IP 空間を使用するように、プライベート リンク経由でイベントが消費されます。
Note
- 名前空間は、単一の種類のトピックを持つ、よりシンプルなリソース モデルを提供します。 現在、Event Grid では、名前空間のトピックを使用した独自のアプリケーション イベントの発行がサポートされています。 名前空間トピックを使用して、Azure サービスまたはパートナー SaaS システムからのイベントを使用することはできません。 また、名前空間にシステム トピック、ドメイン トピック、またはパートナー トピックを作成することもできません。
- 名前空間のトピックでは、CloudEvents JSON 形式がサポートされています。
キュー イベント サブスクリプショ
イベントを受信するとき、またはイベントの状態を管理する操作を使用するとき、アプリケーションでは名前空間 HTTP エンドポイント、トピック名、キュー イベント サブスクリプションの名前を指定します。 キュー イベント サブスクリプションでは、deliveryMode が "queue" に設定されています。 キュー イベント サブスクリプションは、プル配信 API を使用してイベントを消費するために使用されます。 これらのリソースを作成する方法の詳細については、名前空間、 トピック、イベント サブスクリプションの作成に関する記事を参照してください。
イベント サブスクリプションを使用してイベントのフィルター条件を定義し、その際に、そのイベント サブスクリプションを通じて使用できるイベントのセットが実質的に定義されます。 1 つ以上のサブスクライバー (コンシューマー) アプリケーションが、同じ名前空間エンドポイントに接続し、同じトピックとイベント サブスクリプションを使用できます。
プル配信操作
アプリケーションでは、プル配信を処理するときに次の操作を使用します。
- 受信操作は、Event Grid への 1 つの要求を使用して 1 つ以上のイベントを読み取るために使用されます。 既定では、ブローカーはイベントが使用可能になるまで最大 60 秒間待機します。 たとえば、イベントは最初に発行されたときに配信できるようになります。 受信要求が成功すると、0 個以上のイベントが返されます。 イベントが使用可能な場合は、要求されたイベント数まで、可能な限り多くの使用可能なイベントが返されます。 Event Grid は、読み取られたすべてのイベントのロック トークンも返します。
- ロック トークンは、イベントの状態を制御するために使用できる、イベントを識別するハンドルの一種です。
- コンシューマー アプリケーションは、イベントを受信して処理すると、そのイベントを確認します。 この操作により、Event Grid は、そのイベントが別のクライアントに再配信されないように削除するよう指示されます。 コンシューマー アプリケーションは、ロック トークンの有効期限が切れる前に、それらを指定することで 1 つの要求で 1 つ以上のトークンを確認します。
場合によっては、コンシューマー アプリケーションでイベントをリリースまたは拒否する必要があります。
コンシューマー アプリケーションでは、受信したイベントをリリースして、そのイベントを処理する準備ができていないことを Event Grid に通知し、再配信できるようにします。 これは、Event Grid に返されるイベントを識別するロック トークンを使用して、リリース操作を呼び出すことによって行います。 アプリケーションでは、イベントを直ちにリリースするか、またはイベントを再配信できるようにする前に遅延を使用する必要があるかを制御できます。
コンシューマー アプリケーションによるイベント処理を妨げる条件 (永続的な場合を含む) がある場合は、イベントを拒否できます。 たとえば、正しくない形式のメッセージは、正常に解析できないため拒否される可能性があります。 配信不能の宛先が使用可能な場合、拒否されたイベントは配信不能になります。 そうでない場合は削除されます。
プル配信操作を実行するスコープ
受信、確認、リリース、拒否、またはロックの更新の操作を呼び出すと、これらのアクションはイベント サブスクリプションのコンテキストで実行されます。 たとえば、イベントを確認した場合、そのイベントは、確認アクションを呼び出すときに使用されるイベント サブスクリプションを通じて使用できなくなります。 他のイベント サブスクリプションでは、引き続き "同じ" イベントを使用できます。 これは、イベント サブスクリプションでは、発行されたイベントのコピーが取得されるためです。 これらのイベント コピーは、実質的にイベント サブスクリプション間で相互に区別されます。 各イベントには、他のイベントとは独立した独自の状態があります。
プル配信を使用してイベントを受信するときのデータ シェイプ
プル配信を使用してイベントを配信するとき、Event Grid にはオブジェクトの配列が含まれ、その配列に event オブジェクトと brokerProperties オブジェクトが含まれます。 event プロパティの値は、構造化コンテンツ モードで配信される CloudEvent です。 brokerProperties オブジェクトには、配信された CloudEvent に関連付けられているロック トークンが含まれています。 次の json オブジェクトは、2 つのイベントを返す受信操作からの応答のサンプルです。
{
"value": [
{
"brokerProperties": {
"lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
"deliveryCount": 2
},
"event": {
"specversion": "1.0",
"id": "A234-1234-1235",
"source": "/mycontext",
"time": "2018-04-05T17:31:00Z",
"type": "com.example.someeventtype",
"data": "some data"
}
},
{
"brokerProperties": {
"lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
"deliveryCount": 1
},
"event": {
"specversion": "1.0",
"id": "B688-1234-1235",
"source": "/mycontext",
"type": "com.example.someeventtype",
"time": "2018-04-05T17:31:00Z",
"data": {
"somekey" : "value",
"someOtherKey" : 9
}
}
}
]
}
プッシュとプル配信
Event Grid は、HTTP を使用してプッシュとプルのイベント配信をサポートしています。 プッシュ配信では、イベント サブスクリプション、Webhook、または Azure サービス内に、Event Grid がイベントを送信する宛先を定義します。 プル配信では、サブスクライバー アプリケーションは Event Grid に接続してイベントを使用します。 プル配信は、Event Grid 名前空間内のトピックでサポートされています。
重要
Event Hubs は、名前空間トピックへのサブスクリプションの宛先としてサポートされています。 今後のリリースでの Event Grid 名前空間では、Event Grid Basic で現在使用できるすべての宛先と、追加の宛先がサポートされます。
プッシュ配信とプル配信を使用するケース
どのような場合にプル配信またはプッシュ配信を使用するかを決定するのに役立つ一般的なガイドラインを次に示します。
プル配信
- イベントを受信するタイミングを完全に制御する必要があるとき。 たとえば、アプリケーションが常に稼働していないか、十分に安定していないか、特定の時間にデータを処理する場合があります。
- イベントの消費を完全に制御する必要があるとき。 たとえば、コンシューマー アプリケーションのダウンストリーム サービスまたはレイヤーに、イベントの処理を妨げる問題が発生する場合があります。 その場合、プル配信 API を使用すると、コンシューマー アプリが既に読み取ったイベントを後で配信できるように、ブローカーに戻すことができます。
- イベントを受信するときにプライベート リンクを使用する必要があり、これはプッシュ配信ではなく、プル配信でのみ可能です。
- エンドポイントを公開してプッシュ配信を使用する機能はありませんが、Event Grid に接続してイベントを消費できます。
プッシュ配信
- システム状態の変化が発生したことを判別するための定期的なポーリングを回避する必要があるとき。 Event Grid を使用して、状態の変化が発生した時点でイベントを送信するようにできます。
- 送信呼び出しを行うことができないアプリケーションがあるとき。 たとえば、組織がデータ流出を懸念している場合があります。 ただし、アプリケーションはパブリック エンドポイントを経由でイベントを受信できます。
次のステップ
次の記事では、Event Grid の使用方法に関する情報や、概念に関する追加情報を提供します。
その他の便利なリンク
- コントロール プレーンとデータ プレーンの SDK。
- データ プレーン SDK のお知らせと豊富な情報、サンプル、リンク。
- クォータと制限。