Azure Event Grid を使用して、顧客にほぼリアルタイムの情報をプッシュするアプリケーションを実装しています。
以下の要件があります：
-
数百種類のイベントタイプを含むイベントを、数千の顧客に送信する必要がある。
-
イベントは、処理前にイベントタイプによってフィルタリングされる必要がある。
-
認証と認可は Microsoft Entra ID を使用して処理する必要がある。
-
イベントは単一のエンドポイントに公開される必要がある。
Azure Event Grid を実装する必要があります。
解決策： イベントを「カスタムトピック (Custom Topic)」に公開します。顧客ごとに「イベントサブスクリプション (Event Subscription)」を作成します。
この解決策は目標を満たしていますか？
正解：B
この解決策が「いいえ」である理由は、主に Azure Event Grid の制限（クォータ） にあります。
1. 数千の顧客へのスケーラビリティ不足
-
要件： 数千の顧客に送信する。
-
制限： 1つのトピック（カスタムトピックを含む）に対して作成できるイベントサブスクリプションの数は、デフォルトで 500個 までです。
-
結論： 「数千の顧客」に対して一人ずつサブスクリプションを作成しようとすると、上限に達してしまい、要件を満たすことができません。
2. 認証と認可の粒度
-
要件： Entra ID による認証・認可。
-
詳細： 1つのカスタムトピックにすべての顧客のサブスクリプションを紐付けてしまうと、顧客ごとのアクセス制御（認可）を細かく管理することが困難になります。イベントドメインであれば、トピックレベルでの認可が可能です。
3. イベントドメインとの比較
先ほどの問題でも触れましたが、このような「大規模・マルチテナント（多数の顧客）」のケースでは、イベントドメイン (Event Domain) を使用するのが正解です。
-
カスタムトピック案（今回）： サブスクリプション上限（500）により、数千の顧客に対応不可。
-
イベントドメイン案： 最大 100,000 個のドメイントピックをサポートしており、数千〜数万の顧客にも余裕を持って対応可能。
コメント