Microsoft AZ-204: Azure のイベントベースとメッセージングソリューション — 学習ガイド

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

こちらの一部です： Microsoft Azure Developer Associate AZ-204 — 学習ガイド. 検証済みの解答で練習： Microsoft試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

Azureのイベントおよびメッセージングポートフォリオは、リアクティブなイベント処理のためのEvent Grid、高スループットのストリーミングインジェストのためのEvent Hubs、エンタープライズメッセージングとワークフロー連携のためのService Bus、モバイルプッシュのためのNotification Hubsという、4つの補完的なサービスで構成されています。各サービスを習得するには、それぞれのコアとなる抽象化、配信と再試行のセマンティクス、スケーリングモデルを理解し、pub/sub、コマンド処理、テレメトリインジェスト、デバイスやユーザーへの通知といった典型的なアプリケーションパターンにおいて、いつどれを優先すべきかを知る必要があります。

Event Grid: トピック、サブスクリプション、スキーマ、フィルタリング、デッドレタリング

Event Gridは、個別イベントのためのフルマネージドなプッシュベースのpub/subファブリックです。パブリッシャーはイベントをトピックに送信し、サブスクライバーはトピックにイベントサブスクリプションを登録して、サポートされているハンドラー（HTTPS Webhook、Azure Functions、Logic Apps、Service Bus、Storage Queues、Event Hubsなど）で一致するイベントを受信します。Event Gridは2つのパブリッシャーモデルを定義しています。システムトピックはAzureが管理するトピックリソースで、サブスクリプションやリソースグループ内でイベントを発行するファーストパーティのAzureサービス（例：Storage BLOBの作成、Key Vaultシークレットのローテーション、Resource Managerイベント）を表します。カスタムトピックは、ユーザーが作成するトピックエンドポイントで、アプリケーションがここに発行することで、独自のサービスやドメインを横断したイベント駆動パターンを可能にします。システムトピックはパブリッシャー側のコードを必要とせず、Azureリソースとリアクティブなハンドラーとの接続を簡素化します。一方、カスタムトピックでは、イベントコントラクトとライフサイクルを完全に制御できます。

Event Gridのイベントは、ネイティブのEvent GridスキーマまたはCloudEvents v1.0仕様を使用できます。Event Gridスキーマでは、各イベントにid（一意の識別子）、eventType（アクション）、subject（フィルタリングをサポートする階層パス）、eventTime（UTC）、data（ペイロード）、dataVersion、metadataVersion、topicが含まれます。CloudEventsは、id、source、type、time、subject、dataなどの標準化された属性セットを提供します。CloudEventsを選択するとプラットフォーム間の相互運用性が向上します。Event Gridスキーマは、Azureから発行されるイベントとの互換性を保ち、subjectに対する豊富なフィルタリング機能を提供します。

イベントサブスクリプションは、ルーティング、配信オプション、フィルターを定義します。基本的なフィルターには、イベントタイプの包含やsubjectのプレフィックス/サフィックス（subjectBeginsWith、subjectEndsWith）があり、階層的なリソース命名に効率的です。高度なフィルターは、トップレベルのイベントフィールドやdata内のフィールド（例：数値範囲比較、文字列の大文字小文字を区別しない包含、ブール値の一致、配列の包含）で照合します。フィルターを組み合わせることで、正確なファンアウト制御が可能になり、ダウンストリームの作業とエグレスを最小限に抑えることができます。

配信はプッシュ方式で、at-least-once（少なくとも1回）のセマンティクスを持ちます。Event Gridはエクスポネンシャルバックオフで再試行します。最大再試行回数とイベントのtime-to-live（有効期間）を設定できます。配信が最終的に失敗するか、イベントが期限切れになると、Event Gridはサブスクリプションで指定したBlob Storageコンテナーにイベントをデッドレター化できます。デッドレタリングは、監査や再処理のためにペイロードとメタデータを保持します。必要に応じて、別のプロセスを使用してイベントを復元し、再生します。Webhookエンドポイントは、所有権を証明するための検証ハンドシェイクに参加します。ネットワークに制約がある場合は、パブリックに公開する必要がなく、Azure ADベースの認可を使用できるマネージドAzureエンドポイント（Functions、Service Bus、Storage Queue）を選択することが推奨されます。

Event Hubs: パーティション、コンシューマーグループ、スループット、キャプチャ、および信頼性の高い消費

Event Hubsは、大量のテレメトリとログストリームを低レイテンシーで取り込みます。データはパーティションに追加されます。パーティションは、独立した順序付きのコミットログです。パーティションは、スループットを並列化するために作成時に選択されます。プロデューサーはキーごとの順序を維持するためにパーティションキーを割り当て、サービスがキーをハッシュ化してパーティションに振り分けます。複数のリーダーがパーティションを並列で処理できます。パーティション内では、順序が保証されます。

コンシューマーグループはストリームの独立したビューを提供し、異なる処理アプリケーションが互いに干渉することなく自身の位置を維持できるようにします（例えば、リアルタイムの異常検出器とアーカイブ用パイプラインなど）。リーダーを水平にスケールするには、パーティションの所有権のバランス調整が必要です。SDKのEventProcessorClientが、インスタンス間でのパーティションの割り当てと再調整をコーディネートします。

Standardレベルのスループットユニット（TU）はキャパシティを定義します。各TUは、イングレスとエグレスの帯域幅クォータを付与します。自動インフレート機能は、ピークに合わせてTUを自動的にスケールアップできます。Premiumでは、専用のコンピューティングと予測可能なレイテンシーを持つプロセッシングユニットを使用します。スロットリングのメトリクスを監視して、プロビジョニングを検証します。Event Hubsは同じエンドポイントでKafkaプロトコルをサポートしており、ブローカーを実行することなくKafkaクライアントからのリフトアンドシフトを簡素化します。

プロデューサーはAMQPまたはHTTPSを使用できます。AMQP（ポート443でのAMQP-over-WebSocketsを含む）は、多重化された永続的な接続と効率的なバッチ処理を提供し、送受信の両方で推奨されます。HTTPSは、単純または散発的な送信には適していますが、受信にはサポートされていません。ロングポーリングは利用できず、効率性とフロー制御が犠牲になります。制限のある企業ネットワークでは、AMQP-over-WebSocketsは、一般的なアウトバウンドプロキシを通過しながらパフォーマンスを維持します。

チェックポイントとオフセット管理は、正確性のために非常に重要です。各イベントには、パーティションごとにシーケンス番号とオフセットがあります。レシーバーはストリームを進み、バッチの処理に成功した後、その位置を永続ストレージ（通常はEventProcessorClientを介したAzure Blob Storageコンテナー）にチェックポイントします。再起動またはフェイルオーバー時には、プロセッサは最後のチェックポイントから再開し、べき等なハンドラーによって少なくとも1回の処理（at-least-once processing）を実現します。チェックポイントがない場合、コンシューマーはデフォルトの位置（最新または最古）から開始し、イベントの再処理やスキップのリスクがあります。

キャプチャ機能は、設定可能な時間またはサイズのウィンドウに基づいて、バッチ化された追記専用のAvroファイルをAzure Blob StorageまたはAzure Data Lake Storage Gen2に自動的に書き込むことで、サーバーサイドのアーカイブを提供します。これにより、コールドパス分析のためのカスタムバッチャーが不要になり、下流のツール（Spark、Synapse）が、キャプチャパイプラインに対して厳密に1回のセマンティクス（exactly-once semantics）で不変のストリームセグメントを消費できるようになります。

Service Bus と Queue Storage: コマンド、ワークフロー、セッション、ポイズンメッセージ処理

Service Bus は、高度な配信保証を必要とするコマンド、ワークフロー、および統合シナリオ向けのエンタープライズグレードのメッセージブローカーです。キューはポイントツーポイントのメッセージングを実装します。1つの競合するコンシューマーが各メッセージを受信します。サブスクリプション付きのトピックは pub/sub を可能にします。パブリッシャーはトピックに送信し、独立したサブスクリプションがルールに基づいてコピーを受信します。サブスクリプションルールには、SQL フィルター、相関フィルター、またはブール値の true フィルターがあり、メッセージごとの包含を計算し、アクションを介してメッセージプロパティを追加または変更できます。

セッションは、関連するメッセージの順序付けられた排他的な処理を提供します。一緒に属するメッセージには SessionId を割り当てます（例：注文 123 のすべてのステップ）。受信側はセッションロックを受け入れ、そのセッションのメッセージを到着順に処理し、オプションのセッション状態を維持した後、セッションを解放して次のコンシューマーが所有権を取得できるようにします。これは、大規模な FIFO を実現するための推奨パターンです。セッションがない場合、競合するコンシューマー間での順序は保証されません。

Service Bus は PeekLock モードと ReceiveAndDelete モードをサポートしています。PeekLock は信頼性のためのデフォルトモードです。コンシューマーはメッセージをロック期間中ロックし、処理した後、Complete によって確定します。処理が失敗した場合、コンシューマーは Abandon（メッセージを再び利用可能にする）、Defer（シーケンス番号によって後で取得するように延期する）、または Dead-letter（理由とエラーの説明を付けてエンティティの個別の配信不能サブキューに移動する）を実行できます。ReceiveAndDelete は、受信直後にメッセージを削除することで、信頼性と引き換えにスループットを向上させます。

主要なプロパティがライフサイクルを制御します。Time to Live (TTL) はエンティティのデフォルトとして設定でき、メッセージごとに上書き可能です。期限切れのメッセージは、構成に基づいて配信不能キューに移動されるか、破棄されます。ロック期間は、メッセージが処理のためにロックされたままでいる時間を制御します。SDK は、最大制限内で長時間の作業のためにロックを自動更新できます。最大配信回数はキューまたはサブスクリプションごとに構成されます。その回数の配信試行（Abandon またはロックの喪失）の後、メッセージは自動的に配信不能キュー（DLQ）に移動されます。オペレーターは、診断や修正ロジックによる再処理のために DLQ からメッセージを取り出します。

Azure Queue Storage は、REST インターフェースを備えた、よりシンプルで大規模にスケーラブルなキューイングサービスであり、基本的なデカップリング、高いファンアウト、およびコスト重視のワークロードに最適です。少なくとも1回の配信、処理中にメッセージを非表示にするための可視性タイムアウト、およびメッセージごとの TTL（デフォルトは7日間で、無期限を含めて構成可能）を提供します。個々のメッセージのサイズは制限されており、セッション、トランザクション、順序保証、重複検出、配信不能サブキュー、高度なフィルターなどの機能は利用できません。シンプルなバックグラウンド作業や、低コストで非常に高いスループットが必要な場合は、Queue Storage を選択してください。高度なルーティング（トピック/サブスクリプション）、セッションによる FIFO、スケジュール配信、遅延、エンティティ間のトランザクション、重複検出ウィンドウ、AMQP サポートが必要な場合、または統合の信頼性とガバナンスが重要な場合は、Service Bus を選択してください。一般的なパターンは、Event Grid または Queue Storage を介して軽量なイベントをファンインし、Service Bus 上でビジネスクリティカルなコマンドと状態遷移を調整することです。

Notification Hubs: プッシュルーティングとプラットフォーム資格情報管理

Notification Hubsは、大規模なデバイス登録を管理し、ターゲットを絞った通知をApple (APNs)、Android (FCM)、Windows (WNS)などのプラットフォームにルーティングする、クロスプラットフォームのプッシュエンジンです。アプリケーションは、タグとタグ式を使用してデバイスを登録し、正確なオーディエンス選択を可能にします（例：user:42 AND region:emea OR topic:promotions）。テンプレートを使用すると、単一のローカライズされたペイロードを送信でき、プラットフォーム固有のレンダラーがそれを展開するため、サーバーロジックが削減され、最小限のバックエンド分岐でデバイスごとのパーソナライズが可能になります。Installationモデルは、プラットフォームハンドル、タグ、テンプレートをデバイスごとに単一のリソースにカプセル化することで、デバイスのライフサイクル管理を効率化します。

プラットフォームの資格情報管理は、信頼性の高い配信の中心です。APNsの場合、証明書ベースまたはトークンベースの資格情報（Key ID、Team ID、.p8トークンを含む）をアップロードし、ハブまたは名前空間ごとにサンドボックスまたは本番環境のエンドポイントを選択して、環境を分離します。FCMの場合、適切なサーバー資格情報を構成します（HTTP v1の場合は、OAuth2スコープを持つGoogleサービスアカウントを使用します）。WNSの場合、アプリを登録してPackage SIDとクライアントシークレットを取得します。資格情報は定期的にローテーションされます。ローテーションをスケジュールし、無効なデバイスハンドルに関するフィードバックチャネルを監視してください。Notification Hubsは、アプリサーバーからのハブレベルの認証にSASを使用し、Azure ADロールが管理操作を保護します。タグ付け規則を使用してマルチテナントアプリをパーティション分割し、スケジュールされたプッシュまたはバッチプッシュで送信をスロットリングして、プラットフォームのクォータを満たします。

実践的な問題シナリオ

スターバックスは、グローバルなモバイルオーダー体験を展開しています。この体験では、注文の準備ができたときに顧客に通知し、バリスタのワークフローのステップを確実に処理し、予防的メンテナンスのために機器のテレメトリを分析する必要があります。

Event Gridでイベント駆動型の注文ライフサイクルを構築

カスタムのEvent GridトピックOrderEventsを作成し、OrderPlaced、PaymentAuthorized、OrderReadyなどの個別のドメインイベントを発行します。/stores/{storeId}/orders/{orderId}のようなサブジェクトパスを使用して、店舗ごとのプレフィックスフィルタリングを可能にします。サブスクリプションを構成します。1つはワークフロー処理用のService Busトピックへ、もう1つは軽量なエンリッチメント用のAzure Functionへ。Event Gridが選ばれる理由は、低レイテンシのファンアウト、スキーマの正規化（CloudEvents）、そして不要なダウンストリームの呼び出しを回避する効率的なフィルタリングです。

Service Busのトピックとセッションでバリスタのワークフローを調整

Service BusトピックOrdersを定義し、処理ステージ（準備、受け渡し）ごとにサブスクリプションを作成し、それぞれにeventTypeに対する相関フィルターまたはSQLフィルターを設定します。SessionId = {orderId}を持つメッセージとしてコマンドを発行し、注文ごとのFIFOを保証します。コンシューマーは、自動ロック更新付きのPeekLockを使用し、成功時にはCompleteを実行します。一時的な障害ではAbandonが再試行をトリガーし、永続的な障害や有害メッセージの場合は、Max delivery countに達すると後で調査するためにDLQに移動されます。ステージ固有のメッセージにTTLを設定することで、閉店後に古い作業が残るのを防ぎます。Service Busが選ばれる理由は、順序付けられた信頼性の高いコマンド処理、豊富なセトルメント機能、ルールベースのpub/subです。

Event Hubsで機器のテレメトリを取り込み、アーカイブ

Event Hub Telemetryをプロビジョニングし、deviceIdによる並列化のために十分なパーティションを確保し、ピークを吸収するためにTUの自動インフレートを有効にします。デバイスゲートウェイは、企業のプロキシを効率的に通過するために、AMQP-over-WebSockets経由で送信します。Blob Storageのチェックポイント機能を持つEventProcessorClientを使用して、ほぼリアルタイムで異常検出とアラートを実行します。Synapseでのオフライン分析をサポートする不変のAvroアーカイブのために、ADLS Gen2へのキャプチャを有効にします。Event Hubsが選ばれる理由は、持続的な高スループットの取り込み、永続的なオフセット、そして簡単なコールドパスへのエクスポートです。

Notification Hubsでプッシュ通知をターゲティング

Installationモデルを使用してモバイルデバイスを登録し、それぞれにuser:{userId}、store:{storeId}、およびプラットフォームタグを付けます。iOS用にAPNsトークン資格情報、Android用にFCMサービスアカウントをアップロードします。資格情報とフィードバックを分離するために、開発用と本番用のハブを分けます。OrderReadyイベントが到着すると、Azure Functionはuser:{userId} AND store:{storeId}というタグ宛に、単一のテンプレート通知をNotification Hubsに送信します。Notification Hubsが選ばれる理由は、プラットフォームに依存しないルーティング、タグ式、そしてグローバル規模での一元的な資格情報管理です。

可観測性と回復力の確保

配信不能なイベントを監査および再生のために保持するため、Event Gridの配信不能レターをBlobコンテナーに構成します。Service BusのDLQを監視し、修正されたメッセージをトリアージして再キューイングするためのオペレーターワークフローを公開します。メトリクスを介してEvent Hubsのコンシューマーラグを追跡し、チェックポイント処理を検証し、バックログが増加したときにプロセッサーをスケールアウトします。この組み合わせは、エンドツーエンドの永続性を提供します。つまり、ハッピーパスを高速かつコスト効率よく保ちながら、例外的な状況に対応するための再生パスを備えた、at-least-once（少なくとも1回）の配信を実現します。

このアーキテクチャは、関心事を明確に分離します。Event Gridはリアクティブなオーケストレーションを駆動し、Service Busはワークフローの正確性と順序性を保証し、Event Hubsは大規模な継続的テレメトリを処理し、Notification Hubsは最小限のバックエンドの複雑さで、正確でプラットフォーム固有の顧客通知を配信します。

← Azure API Management · すべてのドメイン · Azure のキャッシュ、CDN、およびパフォーマンス →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →