Azure Event Grid を使用して、顧客にほぼリアルタイムの情報をプッシュするアプリケーションを実装しています。
以下の要件があります：
-
数百種類のイベントタイプを含むイベントを、数千の顧客に送信する必要がある。
-
イベントは、処理前にイベントタイプによってフィルタリングされる必要がある。
-
認証と認可は Microsoft Entra ID（旧 Azure AD）を使用して処理する必要がある。
-
イベントは単一のエンドポイントに公開される必要がある。
Azure Event Grid を実装する必要があります。
解決策： イベントを「イベントドメイン (Event Domain)」に公開します。顧客ごとに「カスタムトピック (Custom Topic)」を作成します。
この解決策は目標を満たしていますか？
正解：B
このソリューションが「いいえ」である理由は、「顧客ごとにカスタムトピックを作成する」という部分が誤りだからです。
なぜ「イベントドメイン」を使うのか？
イベントドメインは、数千ものトピックを持つ大規模なアプリケーションを管理するために設計されたツールです。要件にある「数千の顧客」や「単一のエンドポイントへの公開」を処理するのに最適です。
どこが間違っているのか？
-
イベントドメインの構造: イベントドメイン内では、個別のトピックは「カスタムトピック」ではなく、**「ドメイントピック (Domain Topic)」**と呼ばれます。
-
管理の複雑さ: 顧客ごとに独立した「カスタムトピック」を作成してしまうと、それぞれに異なるエンドポイントや管理コストが発生し、「単一のエンドポイントに公開する」という要件や、大規模なマルチテナント管理が非常に困難になります。
-
正しい構成: 正解は「イベントドメインを作成し、そのドメイン内にドメイントピックを作成する」ことです。これにより、パブリッシャー（公開側）はドメインの単一エンドポイントにイベントを送信するだけで、Event Grid が適切なドメイントピック（顧客）へ振り分けてくれます。
要件との照らし合わせ
-
数千の顧客: イベントドメインは最大 100,000 個のドメイントピックをサポートします。
-
単一エンドポイント: イベントドメインには 1 つの公開用エンドポイントがあります。
-
フィルタリング: ドメイントピック内のイベントサブスクリプションでフィルタ設定が可能です。
-
Entra ID: イベントドメインは Entra ID による RBAC をサポートしています。
コメント