Kubernetes 上の Event Grid - 概念
この記事では、Azure Arc を使用する Kubernetes 上の Event Grid での主要な概念について説明します (プレビュー)。
重要
Azure Arc を使用した Kubernetes 上の Event Grid は、現在パブリック プレビュー中です。 このプレビュー バージョンはサービス レベル アグリーメントなしで提供されています。運用環境のワークロードに使用することはお勧めできません。 特定の機能はサポート対象ではなく、機能が制限されることがあります。 詳しくは、Microsoft Azure プレビューの追加使用条件に関するページをご覧ください。
イベント
イベントとは、ソフトウェア システムの操作に関する事実を通知するデータ レコードです。 通常は、イベントにより、システムによって発生したシグナルまたはシステムによって検出されたシグナルによる状態の変化が通知されます。 イベントには、次の 2 種類の情報が含まれます。
Kubernetes 上の Event Grid によって、CloudEvents スキーマ仕様がサポートされています。 CloudEvents スキーマを使用するイベントの例を次に示します。 Event Grid では、最大 1 MB のサイズのイベントがサポートされています。
[{
"specVersion": "1.0",
"type" : "orderCreated",
"source": "myCompanyName/us/webCommerceChannel/myOnlineCommerceSiteBrandName",
"id" : "eventId-n",
"time" : "2020-12-25T20:54:07+00:00",
"subject" : "account/acct-123224/order/o-123456",
"dataSchema" : "1.0",
"data" : {
"orderId" : "123",
"orderType" : "PO",
"reference" : "https://www.myCompanyName.com/orders/123"
}
}]
source
ソース属性により、イベントが発生したコンテキストが説明されます。 ソースはイベントの発生元である場合があります。 ただし、イベントを作成して発行するプロデューサーが存在する場合もあります。 そして、これらのプロデューサーはソースとは異なります。 わかりやすくするため、この記事では、ソースがイベントのプロデューサーであるものとします。
各イベント ソースにより、1 つまたは複数のイベントの種類のイベントが生成されます。 イベントのソースとして、アプリケーションでは、状態の変化を通知する一連の関連イベントを定義します。 すべてのイベントには、イベントの発生元、イベントの発生日時、一意識別子などの一般的な情報が保持されています。 すべてのイベントには、特定のイベントの種類にのみ関連する情報も含まれます。 最大 1 MB のサイズのイベントのサポートは現在、プレビュー段階です。
イベントに含まれるプロパティについては、CloudEvents スキーマに関する記事を参照してください。
ディストリビューターのプロパティ
イベント パブリッシャーは、イベント サブスクライバーに配信されるイベントを Event Grid に送信するアプリケーションまたはシステムです。
トピック
トピックは、Event Grid へのイベントをパブリッシャーが送信する先のエンドポイントを公開する入力チャネルの形式です。
トピックは、関連するイベントを収集するために使用できます。 関連イベントのカテゴリごとにトピックを作成できます。 通常、ソースは密接に関連するイベントの種類のセット ("MyApp.OrderCreated"、"MyApp.OderDeleted"、"MyApp.OrderRejected" など) に関連付けられているため、ソースを使用してイベントをカテゴリに整理できる場合があります。
ユーザー アカウントの管理と注文の処理に関連するイベントを送信するアプリケーションがあるものとします。 1 つのイベント サブスクライバーが両方のカテゴリのイベントを使用することに関心を持つことはあまりありません。 このような場合は、2 つのカスタム トピックを作成し、イベント ハンドラーが自分と関係のあるトピックをサブスクライブできるようにします。 小規模なソリューションの場合、すべてのイベントを 1 つのトピックに送信することをお勧めします。
イベント サブスクライバー
イベント サブスクライバーは、Event Grid によるイベントの配信先であるエンドポイントを公開する、マイクロサービスなどのソフトウェア システムです。
イベントのサブスクリプション
イベント サブスクリプションは、トピックのどのイベントをユーザーが受け取りたいと思っているか (イベント フィルター処理)、およびそれらの送信先 (イベント ルーティング) を、Event Grid に伝えます。 ユーザーは、イベント サブスクリプションを作成するときに、イベントを処理するためのエンドポイントを指定します。 ユーザーは、イベント サブスクリプションでフィルター句を構成することにより、エンドポイントへの配信を希望するイベントを選択できます。
イベント ハンドラー
イベント ハンドラーは、イベントの送信先であるエンドポイントを公開するソフトウェア システムです。 ハンドラーによりイベントが受け取られ、アクションを実行してイベントが処理されます。 Event Grid は、複数の種類のハンドラーをサポートします。 ハンドラーとしては、Kubernetes または Azure でホストされているサポートされる Azure サービス、またはホストされている任意の場所で Webhook (エンドポイント) を公開する独自のソリューションを使用できます。 Event Grid は、ハンドラーの種類に応じたさまざまなメカニズムに従って、イベントの配信を保証します。 送信先のイベント ハンドラーが HTTP Webhook である場合、ハンドラーによって状態コード 200 – OK が返されるまで、イベントは再試行されます。 詳細については、イベント ハンドラーに関する記事を参照してください。
SAS 認証
Kubernetes 上の Event Grid からは、トピックへのイベント発行用に SAS キー ベースの認証が提供されます。
イベント配信
Kubernetes 上の Event Grid から、信頼性の高い配信と再試行のメカニズムが提供されます。 イベントがイベント ハンドラーのエンドポイントによって受信されたことを Event Grid が確認できない場合、イベントは再配信されます。 詳細については、Event Grid のメッセージの配信と再試行に関する記事を参照してください。
バッチ イベントの発行
トピックを使用するときは、イベントを常に配列内で発行する必要があります。 低スループットのシナリオでは、配列に含まれるイベントは 1 つだけです。 高ボリュームのユース ケースでは、効率性を高めるために、発行ごとに複数のイベントをバッチ処理することをお勧めします。 バッチのサイズは最大 1 MB に指定できます。 その場合でも、各イベントは 1 MB 以下にする必要があります。 詳細については、バッチ イベントの配信に関する記事を参照してください。
Kubernetes 上の Event Grid のコンポーネント
Event Grid オペレーターにより、オペレーター パターンが実装されています。 それにより、Kubernetes の API サーバーに対して行われたコントロール プレーン要求の結果として発生する Event Grid リソースの状態変化が監視されます。 Event Grid のいずれかのリソースの状態に影響を与える要求があるときは、Event Grid オペレーターによりその状態が Event Grid ブローカーと同期されます。
Event Grid ブローカーは、コントロール プレーンとデータ プレーンの両方の操作として機能します。
コントロール プレーン サービスとしての役割は、Event Grid の状態を、Event Grid オペレーターから通知された目的の状態にすることです。 たとえば、新しいトピックを作成する要求が行われると、その要求が満たされ、サービス メタデータが更新されます。
データ プレーン サービスとしては、すべてのイベント発行要求を処理し、イベント サブスクリプションで構成されている送信先にイベントを配信します。
次の手順
まず初めに、「トピックとサブスクリプションを作成する」を参照してください。