次の方法で共有


Microsoft Graph を使用してイベントを迅速に取得する

この記事では、データ損失防止 (DLP) シナリオなど、機密データの安全でない、または不適切な共有、転送、または使用を防ぐために、コラボレーション コンテンツのセキュリティ分析を必要とするビジネス シナリオの一般的な Microsoft Graph 統合パターンについて説明します。

このビジネス シナリオは、ユーザーがさまざまなメッセージング システムと対話することによってトリガーされる変更のデータ フィードを必要とする非対話型のユース ケースです。 Microsoft 365 の機能動作には依存せず、次のアーキテクチャ要件があります。

  • データ統合の種類。
  • Microsoft 365 境界からアプリへの送信データ フロー。
  • 中規模から大企業向けのデータ量が多い。
  • データ損失を最小限に抑えるためのほぼリアルタイムのデータ待機時間。

このシナリオに最適な統合オプションは、Microsoft Graph の変更通知で有効になっている Pub/Sub 統合パターンを使用することです。これにより、イベント通知と共有メッセージの内容を配信でき、Azure Event Hubsに配信されます。 このパターンにより、アプリは変更通知を非同期的に受信でき、Microsoft Graph を受信側アプリケーションに緊密に結合することはできません。 この種類のアプリ操作は、多くの場合、プル モードと呼ばれます。

次の図は、このソリューションのアーキテクチャを示しています。

Microsoft Entra ID、Azure Event Hubs、アプリ サービス、関数アプリ、および移行先サービスと対話する Microsoft Graph 通知サービスを示す図。

ソリューション コンポーネント

ソリューション アーキテクチャには、次のコンポーネントが含まれています。

  • Azure Event Hubs。これにより、待機時間が短い 1 MB 未満の大量の小さなメッセージを 1 秒で取り込み、連続する処理のために格納できます。
  • Azure App Service。これにより、インフラストラクチャを管理することなく、任意のプログラミング言語で Web アプリ、モバイル バックエンド、RESTful API を構築およびホストできます。 自動スケーリングと高可用性を提供し、Windows と Linux の両方をサポートし、GitHub、Azure DevOps、または任意の Git リポジトリからの自動デプロイを可能にします。
  • Microsoft Entra ID。これは Microsoft Graph API の認証を管理するために必要であり、OAuth フローを有効にするために委任されたアクセス許可とアプリケーションのアクセス許可をサポートします。
  • 関数アプリは、新しい通知のバーストのためにスケールアウトできるサーバーレス コンポーネントであり、通知を処理して宛先サービスに送信するビジネス ロジックを備えています。
  • 通知サブスクリプションを管理し、変更通知をクライアントに配信する Microsoft Graph 通知サービス。

考慮事項

次の考慮事項は、この統合パターンの使用をサポートします。

  • 可用性: Azure Event Hubs複数の可用性ゾーン間で高可用性を提供します。

  • 待機時間: Azure Event Hubsは、待機時間が短く、1 秒あたり数百万のイベントを処理できます。

  • スケーラビリティ: Azure Event Hubsは、サービス レベルに応じて最大 90 日間のイベントストレージとリテンション期間を提供するため、カスタム アプリは独自のペースでイベントを使用して処理できます。

  • ソリューションの複雑さ: このソリューションでは、サブスクリプションを維持するためのカスタム コードと、データを処理するための暗号化キーが必要です。 このソリューションは弾力性と予期しないイベント量に対応する機能を必要としないため、プッシュ モードでの Webhook との統合よりも複雑ではありません。 このソリューションは複雑さが中程度です。