Microsoft Purview アカウントのアーキテクチャとベスト プラクティス
Microsoft Purview ガバナンス ソリューション (Microsoft Purview データ マップや Data Catalog など) を環境内で有効にするには、Azure portal で Microsoft Purview (旧称 Azure Purview) アカウントをデプロイします。 このアカウントは、クラウド環境とオンプレミス環境の両方にまたがるデータ資産全体のデータ ガバナンスを一元管理する目的で使用されます。 Microsoft Purview を一元化されたデータ ガバナンス ソリューションとして使用する場合は、Azure サブスクリプション内に 1 つ以上の Microsoft Purview アカウントをデプロイする必要があります。 Microsoft Purview インスタンスの数は、最小限に維持することをお勧めします。ただし、ビジネスのセキュリティやコンプライアンス要件を満足するために、より多くの Microsoft Purview インスタンスが必要になる場合もあります。
1 つの Microsoft Purview アカウント
組織全体に最小数の Microsoft Purview (旧称 Azure Purview) アカウントをデプロイすることを検討してください。 このアプローチにより、プラットフォームの価値が、そのプラットフォーム内に存在するデータの関数として指数関数的に増加する "ネットワーク効果" が最大限に活用されます。
1 つの Microsoft Purview アカウント内に組織のデータ管理構造をレイアウトするには、Microsoft Purview Data Map コレクションの階層を使用します。 このシナリオでは、Azure サブスクリプション内に 1 つのアカウントがデプロイされます。 Microsoft Purview 内では、1 つ以上の Azure サブスクリプションのデータ ソースを登録してスキャンできます。 また、オンプレミス環境またはマルチクラウド環境のデータ ソースを登録してスキャンすることもできます。
複数の Microsoft Purview アカウント
組織によっては、複数の Microsoft Purview アカウントの設定が必要になる場合があります。 Microsoft Purview アカウントのアーキテクチャを定義するときのいくつかの例として、次のシナリオを確認してください。
新しい機能のテスト
分離された環境でスキャンの構成または分類をテストするときは、新しいアカウントを作成することをお勧めします。 一部のシナリオでは、用語集などのプラットフォームのいくつかの領域に "バージョン管理" 機能がありますが、予測される機能を自由にテストするための Microsoft Purview の "破棄可能な" インスタンスを使用した後、その機能を運用インスタンスにロールアウトするように計画する方が簡単です。
さらに、ロールバックを実行できない場合は、テスト用の Microsoft Purview アカウントを使用することを検討してください。 たとえば、用語集の用語属性は現在、Microsoft Purview アカウントに追加された後は Microsoft Purview インスタンスから削除できません。 この場合は、まず、テスト用の Microsoft Purview アカウントを使用することをお勧めします。
運用環境と非運用環境の分離
環境ごとにデータの個別のインスタンスがある場合は特に、開発、テスト、運用の各環境に Microsoft Purview アカウントの個別のインスタンスをデプロイすることを検討してください。
このシナリオでは、運用および非運用データ ソースを対応する各 Microsoft Purview インスタンス内で登録してスキャンできます。
必要な場合は、1 つのデータ ソースを複数の Microsoft Purview インスタンスで登録することもできます。
コンプライアンス要件の実現
Microsoft Purview Data Map でデータ ソースをスキャンすると、そのメタデータに関連した情報が取り込まれ、Microsoft Purview アカウントがデプロイされている Azure リージョンのデータ マップ内に格納されます。 メタデータを特定の地理的な場所に格納することさえも含む特定の規制およびコンプライアンス要件がある場合は、Microsoft Purview の個別のインスタンスをデプロイすることを検討してください。
組織が複数の地域にデータを保有しており、メタデータを実際のデータと同じリージョンに保持する必要がある場合は、複数の Microsoft Purview インスタンス (地域ごとに 1 つ) をデプロイする必要があります。 この場合は、各地域のデータ ソースを、そのデータ ソースの地域または地理に対応する Microsoft Purview アカウントで登録してスキャンする必要があります。
複数のテナントにまたがるデータ ソースの分散
現在、Microsoft Purview ではマルチテナントをサポートしていません。 Azure データ ソースが、異なる Azure Active Directory テナントにある複数の Azure サブスクリプションにまたがって分散されている場合は、各テナントで個別の Microsoft Purview アカウントをデプロイすることをお勧めします。
VM ベースのデータ ソースと Power BI テナントには例外が適用されます。テナント間の Power BI を 1 つの Microsoft Purview アカウントでスキャンして登録する方法の詳細については、テナント間の Power BI の登録とスキャンに関するページを参照してください。
既定の Microsoft Purview アカウント
テナント内に複数の Microsoft Purview アカウントを持つことは、Power BI テナントやAzure Synapseなどの他のすべてのサービスに接続する必要がある Microsoft Purview アカウントの課題です。
このような場合に、既定の Microsoft Purview アカウントが役立ちます。 Azure グローバル管理者 (またはテナント管理者) は、Microsoft Purview アカウントを、テナント レベルで既定の Microsoft Purview アカウントとして指定できます。 どの時点でも、1 つのテナントに設定できる既定のアカウントはゼロか 1 つだけです。 これが設定されると、組織内のユーザーは、Microsoft Purview に接続するときに、このアカウントが "正しい" アカウントであることを明確に理解することができます。
テナントの既定のアカウントを管理する
既定のフラグを "Yes" に設定できるのは、アカウントが作成された後のみです。
正しくない既定のアカウントを設定するとセキュリティに影響する可能性があるため、テナント レベルの Azure グローバル管理者 (テナント管理者) のみが既定のアカウント フラグを "Yes" に設定できます。
既定のアカウントの変更は、2 つのステップのプロセスです。 最初に現在のデフォルトの Microsoft Purview アカウントに対してフラグを 「No」 に変更してから、新しいMicrosoft Purview アカウントに対してフラグを 「Yes」 に設定する必要があります。
デフォルトのアカウントの設定はコントロール プレーンの操作であるため、アカウントが既定値として定義される場合に、Microsoft Purview スタジオでは何も変化が起きません。 ただし スタジオ では、デフォルトの Microsoft Purview アカウントのアカウント名に「(既定)」 が追加されていることを確認できます。
課金モデル
予算編成モデルを定義し、組織のアーキテクチャを設計する場合は、Microsoft Purview の価格モデルを確認してください。 Microsoft Purview アカウントがデプロイされているサブスクリプション内の 1 つの Microsoft Purview アカウントに対して 1 つの課金が生成されます。 このモデルはまた、Microsoft Purview Data Map 内のメタデータのスキャンや分類などの他の Microsoft Purview のコストにも適用されます。
一部の組織には、多くの場合、個別に運営される多数の事業単位 (BU) があり、場合によっては、これらの事業単位では課金さえ互いに共有されません。 このような場合、組織は BU ごとに Microsoft Purview インスタンスを作成することになります。
チャージバックおよびショーバック モデルでのクラウド コンピューティングのコスト モデルの詳細については、クラウド会計の概要に関するページを参照してください。
Azure リージョンの選択
Microsoft Purview は、サービス としての Azure プラットフォーム ソリューションです。 任意のサポートされている Azure リージョンの Azure サブスクリプション内に、Microsoft Purview アカウントをデプロイできます。
プライマリ Azure リージョンで Microsoft Purview を使用できない場合は、Microsoft Purview アカウントをデプロイするセカンダリ リージョンを選択するときに、次の要因を考慮してください。
データ ソースがデプロイされているプライマリ Azure リージョンと、Microsoft Purview アカウントがデプロイされるセカンダリ Azure リージョン間の待機時間を確認します。 詳細については、「 Azure ネットワークラウンドトリップ待機時間の統計」を参照してください。
データ所在地の要件を確認します。 Microsoft Purview Data Map でデータ ソースをスキャンすると、そのメタデータに関連した情報が取り込まれ、Microsoft Purview アカウントがデプロイされている Azure リージョンのデータ マップ内に格納されます。 詳細については、「メタデータが格納されている場所」を参照してください。
ユーザー アクセスまたはメタデータ インジェスト用のプライベート ネットワーク接続が必要な場合は、ネットワークとセキュリティの要件を確認します。 詳細については、「Microsoft Purview がプライマリ リージョンで使用できない場合」を参照してください。
その他の考慮事項と推奨事項
管理オーバーヘッドの軽減のために、Microsoft Purview アカウントの数を少ない状態に維持してください。 複数の Microsoft Purview アカウントの作成を予定している場合は、Microsoft Purview アカウントにまたがる追加のスキャン、アクセス制御モデル、資格情報、ランタイムの作成と管理が必要になることがあります。 さらに、Microsoft Purview アカウントごとに分類や用語集の用語の管理が必要になることもあります。
予算と財務上の要件を確認してください。 可能な場合は、Azure サービスを使用するときにチャージバックまたはショーバック モデルを使用し、Microsoft Purview のコストを組織全体にわたって分割して Microsoft Purview アカウントの数を最小限に維持してください。
組織のビジネス ユーザー、データ管理およびガバナンス チームのために Microsoft Purview Data Map 内のメタデータ アクセス制御を定義するには、コレクションを使用します。 詳細については、「Microsoft Purview でのアクセスの制御」を参照してください。
新しい Microsoft Purview アカウントをデプロイする前に、Microsoft Purview の制限を確認してください。 現在、リージョンあたり、テナントあたりの Microsoft Purview アカウント (すべてのサブスクリプションを結合) の既定の制限は 3 です。 Microsoft Purview の追加のインスタンスをデプロイする前に、Microsoft サポートに連絡してサブスクリプションまたはテナントでこの制限を増やすことが必要になる可能性があります。
使用している環境で新しい Microsoft Purview アカウントをデプロイする前に、Microsoft Purview の前提条件を確認してください。