次の方法で共有

Database Watcher の作成と構成 (プレビュー)

  • [アーティクル]

適用対象: Azure SQL Database Azure SQL Managed Instance

この記事では、Azure SQL Database と Azure SQL Managed Instance の Azure portal で Database Watcher を作成、構成、開始する詳細な手順について説明します。

Database Watcher では、監視エージェントやその他の監視インフラストラクチャをデプロイして維持する必要はありません。 Azure SQL リソースのデータベースの詳細な監視を数分で有効にすることができます。

データベース Watcher の作成と構成の詳細な例については、「クイック スタート: Azure SQL を監視するデータベース Watcher を作成する」を参照してください。

Bicep または ARM テンプレートを使用してデータベース ウォッチャーを作成したり構成したりする方法については、「データベース ウォッチャーを作成する」コード サンプルを参照してください。

プログラムでデータベース ウォッチャーを管理するには、データベース ウォッチャー REST API のドキュメントを参照してください。

Note

Database Watcher は現在プレビューの段階です。

前提条件

Database Watcher を使用するには、次の前提条件が必要です。

  • アクティブな Azure サブスクリプションが必要です。 アカウントがない場合は、無料アカウントを作成してください。 リソースを作成できるようにするには、サブスクリプションの共同作成者ロールまたは所有者ロールのメンバー、またはリソース グループのメンバーである必要があります。

  • データベース Watcher を構成し開始するには、既存の SQL ターゲット (Azure SQL データベース、エラスティック プール、または SQL Managed Instance) が必要です。

  • Microsoft.DatabaseWatcher、Microsoft.Kusto、および Microsoft.Network のリソース プロバイダーを、Azure サブスクリプションに登録する必要があります。

    • Azure SQL リソースへの接続に SQL 認証を使用するには、Microsoft.KeyVault リソース プロバイダーも登録する必要があります。 「SQL 認証を使用するための追加の構成」を参照してください。

    サブスクリプション レベルで所有者または共同作成者の RBAC ロール メンバーシップをお持ちの場合、リソース プロバイダーの登録は自動的に行われます。 それ以外の場合は、Watcher を作成して構成する前に、これらのロールのいずれかのユーザーがリソース プロバイダーを登録する必要があります。 詳細については、「リソース プロバイダーを登録する」 を参照してください。

  • Watcher クラスター リソースと Azure Data Explorer クラスター リソースを作成および構成するユーザーは、これらのリソースが作成されるリソース グループまたはサブスクリプションの所有者または共同作成者 RBAC ロールのメンバーである必要があります。

    さらに、SQL 認証を使用する場合、ユーザーはリソース グループの所有者ロールのメンバーであるか、SQL 認証資格情報を格納するキー コンテナーの所有者またはユーザー アクセス管理者ロールのメンバーである必要があります。

  • Watcher を構成するユーザーは、Azure SQL ターゲットへの管理者アクセス権を持っている必要があります。 管理者は Watcher に、SQL 監視ターゲットへの制限付きの特定のアクセス権を付与します。 詳細については、「ターゲットに権利を与える」を参照してください。

  • Watcher に SQL ターゲットへのアクセス権を付与するには、管理者は、SQL Server Management Studio (SSMS)、Azure Data Studio、または Visual Studio Code と SQL サーバー mssql 拡張機能を使用して T-SQL スクリプトを実行する必要があります。

  • Azure リソースへのプライベート接続に Azure Private Link を使用するには、プライベート エンドポイントを承認するユーザーが所有者 RBAC ロールのメンバーであるか、必要な RBAC アクセス許可を持っている必要があります。 詳細については、「プライベート エンドポイントへの RBAC の適用」をご覧ください。

Watcher を作成する

  1. Azure Portal の ナビゲーション メニュー で [すべてのサービス] を選択します。 カテゴリとして [監視] を選択し、[監視ツール] で [Database Watcher] を選択します。 または、ポータル ページの上部にある [検索] ボックスに Database Watcher と入力し、[Database Watcher ] を選択することもできます。

    [Database Watcher] ビューが開いたら、[作成] を選択します。

  2. [基本] タブで、Watcher のサブスクリプションとリソース グループを選択し、Watcher の名前を入力して、Azure リージョンを選択します。

    ヒント

    プレビュー期間中に、Database Watcher がリージョンでまだ使用できない場合は、別のリージョンに作成できます。 詳細については、「リージョン別の提供状況」に関するページをご覧ください。

  3. [ID] タブでは、ウォッチャーのシステム割り当てマネージド ID が既定で有効になっています。 代わりにウォッチャーでユーザー割り当てマネージド ID を使用する必要がある場合は、[追加] ボタンを選択し、使用する ID を見つけて、[追加] ボタンを選択します。 ウォッチャーに対してユーザー割り当て ID を有効にするには、システム割り当てマネージド ID を無効にします。

    データベース ウォッチャーのマネージド ID の詳細については、「ウォッチャー ID を変更する」を参照してください。

  4. Watcher のデータ ストアを選択します。

    既定では、Watcher を作成すると、Azure Data Explorer クラスターも作成され、収集された監視データのデータ ストアとしてそのクラスターにデータベースが追加されます。

    • 既定では、新しい Azure Data Explorer クラスターでは、極小コンピューティング最適化 SKU が使用されます。 これは、引き続きサービス レベル アグリーメント (SLA) を提供する最も経済的な SKU です。 このクラスターは、必要に応じて後でスケーリングできます。

    • または、既存の Azure Data Explorer クラスター、無料の Azure Data Explorer クラスター、または Real Time Analytics でデータベースを使用できます。

      1. [データ ストア] タブで、[データ ストアの選択] オプションを選択し、[追加] を選択します。
      2. Real Time Analytics データベースまたは Azure Data Explorer クラスターを選択します。
      3. 既存の Azure Data Explorer クラスターを使用する場合は、ストリーミング インジェストを有効にする必要があります。
      4. 新しいデータベースの作成や、既存のデータベースを使用します。

      Note

      選択する既存のデータベースは空であるか、以前に Database Watcher データ ストアとして使用したデータベースである必要があります。 Database Watcher によって作成されていないオブジェクトを含むデータベースの選択はサポートされていません。

    • または、この時点でデータ ストアの追加をスキップして、後で追加することもできます。 Watcher を開始するには、データ ストアが必要です。

  5. [SQL ターゲット] タブで、監視する 1 つ以上の Azure SQL リソースを追加します。 Watcher の作成時に SQL ターゲットの追加をスキップし、後で追加することができます。 Watcher を開始する前に、少なくとも 1 つのターゲットを追加する必要があります。

  6. [確認と作成] タブで、Watcher 構成を確認して、[作成] を選択します。 新しいAzure Data Explorer クラスターを作成する既定のオプションを選択した場合、通常、デプロイには 15 分から 20 分かかります。 既存の Azure Data Explorer クラスター、無料の Azure Data Explorer クラスター、または Real Time Analytics でデータベースを選択する場合、通常、デプロイには最大で 5 分かかります。

  7. デプロイが完了したら、Watcher に SQL ターゲットへのアクセス権を付与します。

  8. また、ウォッチャーにデータ ストアへのアクセス権を付与しなければならない場合もあります。

    • ウォッチャー作成ユーザーがクラスターの オーナー RBAC ロールのメンバーである場合、ウォッチャーを作成する時に、新規または既存の Azure Data Explorer クラスターでのデータベースへのアクセス権が自動的に付与されます。
    • ただし、次のデータベースを選択する場合は、KQL コマンドを使用してデータ ストアへ権利を与える必要があります。
      • Microsoft Fabric のリアルタイム分析。
      • 無料の Azure Data Explorer クラスター。

  9. プライベート接続を使用する必要がある場合は、マネージド プライベート エンドポイントを作成して承認します。

    • SQL ターゲット、データ ストア、およびキー コンテナーに対するパブリック アクセスが有効で、パブリック接続を使用する必要がある場合は、パブリック接続の前提条件がすべて満たされていることを確認します。

Watcher を開始および停止する

Watcher が作成されると、追加の構成が必要になる可能性があるため、自動的には起動されません。

Watcher を起動するには、次が必要です。

Watcher が完全に構成されたら、[スタート] ボタンを使用して [概要] ページで データ コレクションを開始します。 数分後に、新しい監視データがデータ ストアとダッシュボードに表示されます。 5 分以内に新しいデータが表示されない場合は、「トラブルシューティング」を参照してください。

Azure SQL リソースをしばらく監視する必要がない場合は、[停止] ボタンを使用して Watcher を停止できます。

Watcher を再起動するには、停止してから、もう一度起動します。

Watcher を変更する

Azure portal では、ターゲットの追加または削除、プライベート エンドポイントの作成または削除が可能です。既存のウォッチャーに別のデータ ストアを使用したり、ウォッチャーのマネージド ID を変更したりすることもできます。

Note

別の方法で説明しない限り、Watcher の構成に加えた変更は、Watcher を停止して再起動した後に有効になります。

Watcher に SQL ターゲットを追加する

Azure SQL データベース、エラスティック プール、または SQL Managed Instanceを監視する Database Watcher を有効にするには、このリソースを SQL ターゲットとして追加する必要があります。

  1. ターゲットを追加するには、[SQL ターゲット] ページで [追加] を選択します。
  2. 監視する Azure SQL リソースを見つけます。 リソースの種類とサブスクリプションを選択し、リソースの一覧から SQL ターゲットを選択します。 SQL ターゲットは、ウォッチャーと同じ Microsoft Entra ID テナント内の任意のサブスクリプションに配置できます。
  3. データベース、エラスティック プール、または SQL マネージド インスタンスのプライマリ レプリカと高可用性セカンダリ レプリカを監視するには、同じリソースに対して "2 つの個別の SQL ターゲット" を追加し、"そのいずれか" の [読み取り目的] ボックスをオンにします。 同様に、geo レプリカとその高可用性セカンダリ レプリカ (存在する場合) に対して 2 つの個別の SQL ターゲットを作成します。
    • [読み取りインテント] ボックスをオンにすると、高可用性セカンダリ レプリカのみをターゲットにするように SQL が構成されます。
    • プライマリ レプリカのみを監視するか、geo レプリカのみを監視する場合、またはこのリソース用の高可用性セカンダリ レプリカが存在しない場合、または読み取りスケールアウト機能が無効になっている場合は、[読み取り目的] ボックスをオンにしないでください。

既定では、Database Watcher は、SQL Database への接続時に Microsoft Entra 認証を使用します。 Watcher で SQL 認証を使用する場合は、[SQL 認証の使用] ボックスをオンにして、必要な詳細を入力します。 詳細については、「SQL 認証を使用するための追加の構成」を参照してください。

Watcher から SQL ターゲットを削除する

1 つ以上のターゲットを削除するには、[SQL ターゲット] ページを開き、一覧から削除するターゲットを選択して、[削除] を選択します。

ターゲットを削除すると、Watcher の再起動時に Azure SQL リソースの監視は停止しますが、実際のリソースは削除されません。

Database Watcher によって監視されている Azure SQL リソースを削除する場合は、対応するターゲットも削除する必要があります。 Watcher にある SQL ターゲットの数には制限があるため、古いターゲットを維持すると、新しいターゲットを追加できなくなる可能性があります。

マネージド プライベート エンドポイントを作成する

SQL ターゲットからのデータ コレクション、データ ストアへのインジェスト、およびキー コンテナーへの接続にマネージド プライベート エンドポイントを作成する必要があり、プライベート接続を使用する場合も同様です。 プライベート エンドポイントを作成しない場合、Database Watcher は既定でパブリック接続を使用します。

Note

データベース Watcher では、Azure リソースに接続するために、独自のマネージド プライベート エンドポイントが必要です。 Azure SQL 論理サーバー、SQL Managed Instance、Azure Data Explorer クラスター、またはキー コンテナーに対して既に存在する可能性のあるプライベート エンドポイントは、Watcherでは使用できません。

Watcher 用のマネージド プライベート エンドポイントを作成するには、次を実行します：

  1. リソース、リソース グループ、またはマネージド プライベート エンドポイントを作成するリソースのサブスクリプションに対して読み取り専用ロックがある場合は、ロックを削除します。 プライベート エンドポイントが正常に作成された後、ロックを再度追加できます。

  2. Azure portal で Database Watcher に移動し、[マネージド プライベート エンドポイント] ページを開き、[追加] を選択します。

  3. プライベート エンドポイントの名前を入力します。

  4. プライベート エンドポイントを作成する Azure リソースのサブスクリプションを選択します。

  5. プライベート エンドポイントを作成するリソースのタイプに応じて、[リソースの種類] と [ターゲット サブリソース] を次のように選択します：

    リソース リソースの種類 ターゲット サブリソース
    論理サーバー Microsoft.Sql/servers sqlServer
    SQL マネージド インスタンス Microsoft.Sql/managedInstances managedInstance
    Azure Data Explorer クラスター Microsoft.Kusto/clusters cluster
    Key Vault Microsoft.KeyVault/vaults vault

  6. プライベート エンドポイントを作成する リソースを選択します。 これは、Azure SQL 論理サーバー、SQL マネージド インスタンス、Azure Data Explorer クラスター、またはキー コンテナーです。

    • Azure SQL Database 論理サーバーのプライベート エンドポイントを作成すると、そのサーバー上のすべてのデータベースおよびエラスティック プール ターゲットに対する Database Watcher のプライベート接続が可能になります。

  7. 必要に応じて、プライベート エンドポイントの説明を入力します。 これは、リソース所有者が要求を承認するのに役立ちます。

  8. ［作成］ を選択します プライベート エンドポイントの作成には数分かかる場合があります。 プライベート エンドポイントは、プロビジョニングの状態が [承認済み] または [実行中] から [成功] に変わると作成されます。 ビューを更新して、現在のプロビジョニングの状態を確認します。

    重要

    プライベート エンドポイントは、保留中の状態で作成されます。 Database Watcher がリソースへの接続に使用する前に、リソース所有者が承認する必要があります。

    リソース所有者がネットワーク接続を制御できるようにするために、Database Watcher プライベート エンドポイントは自動的には承認されません。

  9. リソース所有者は、プライベート エンドポイント要求を承認する必要があります。

プライベート エンドポイントが承認されたときに Watcher が既に実行されている場合は、プライベート接続の使用を開始するために再起動する必要があります。

ヒント

クラスターのパブリック接続が無効になっている場合は、Azure Data Explorer クラスター用の追加のプライベート エンドポイントを作成する必要があります。 詳細については、「データ ストアにプライベートに接続する」を参照してください。

マネージド プライベート エンドポイントを削除する

  1. リソース、リソース グループ、またはマネージド プライベート エンドポイントを削除するリソースのサブスクリプションに対して削除または読み取り専用 lock がある場合は、ロックを削除します。 プライベート エンドポイントが正常に削除された後、ロックを再度追加できます。
  2. Database Watcher の Azure portal ページで、[マネージド プライベート エンドポイント] ページを開きます。
  3. 削除するプライベート エンドポイントを選択します。
  4. [削除] を選択します。

マネージド プライベート エンドポイントを削除すると、このプライベート エンドポイントを使用する SQL ターゲットからのデータ コレクションが停止します。 Azure Data Explorer クラスターのマネージド プライベート エンドポイントを削除すると、すべてのターゲットのデータ コレクションが停止します。 データ コレクションを再開するには、プライベート エンドポイントを再作成するか、パブリック接続を有効にして、Watcher を再起動します。

Watcher のデータ ストアを変更する

Watcher は、データ ストアを 1 つだけ持つことができます。

現在のデータ ストアを変更するには、既存のデータ ストアを削除してから、新しいデータ ストアを追加します。

  • 現在のデータ ストアを削除するには、[データ ストア] ページを開き、グリッドでデータ ストアを選択し、[削除] を選択します。

    • データ ストアを削除しても、Azure Data Explorer クラスターまたは Microsoft Fabric の Real Time Analytics の実際のデータ ストア データベースは削除されません。
    • 削除されたデータ ストアへのデータ コレクションを停止するには、Watcher を停止します。
    • データ ストアを削除する場合は、Watcher をもう一度起動する前に、新しいデータ ストアを追加する必要があります。

  • データ ストアを追加するには、[データ ストア] ページで [追加] を選択し、Azure Data Explorer クラスターまたは Real Time Analytics でデータベースを選択または作成します。

    • 選択するデータベースは空であるか、以前に Database Watcher のデータ ストアとして使用したデータベースである必要があります。 Database Watcher によって作成されていないオブジェクトを含むデータベースの選択はサポートされていません。
    • データ ストアを追加したら、そのデータ ストアを使用するためのアクセス権を Watcher に付与する必要があります。 詳細については、「データ ストアへの権利を与える」を参照してください。
    • Watcher が再起動されると、新しいデータ ストアの使用が開始されます。

ウォッチャー ID を変更する

ウォッチャーには、SQL ターゲット、キー コンテナー、およびデータ ストアに対して認証するためのマネージド ID が必要です。 システム割り当て ID またはユーザー割り当てマネージド ID のいずれかを使用します。 Azure のマネージド ID の詳細については、「Azure リソース用マネージド ID とは」を参照してください。

ウォッチャーのマネージド ID の種類を選択する際に役立つ考慮事項を次に示します。

  • システム割り当て

    • ウォッチャーを作成時に既定で有効になっています。
    • 常に 1 つのウォッチャーに関連付けられています。
    • ウォッチャーを使用して作成および削除されました。
    • ウォッチャーのシステム割り当て ID を無効にすると、その ID に付与されたアクセス権は失われます。 同じウォッチャーに対してシステム割り当て ID を再度有効にすると、異なるオブジェクト (プリンシパル) ID を持つ別の ID が新しく作成されます。 この新しい ID に、SQL ターゲット、キー コンテナー、およびデータ ストアへのアクセス権を付与する必要があります。

  • ユーザー割り当て済み

    • ウォッチャーに対してシステム割り当て ID が無効の場合にのみ有効です。
    • 同じユーザー割り当て ID を複数のウォッチャーに割り当てて、アクセス管理を簡略化できます。たとえば、大規模な Azure SQL 資産を監視する場合などです。 複数のウォッチャーのシステム割り当て ID にアクセス権を付与するのではなく、1 つのユーザー割り当て ID にアクセス権を付与できます。
    • 職務の分離に対応するために、ID の管理とウォッチャーの管理を別にすることができます。 ウォッチャーが作成される前または後に、別のユーザーが、ユーザー割り当て ID を作成し、アクセス権を付与できます。
    • 逆に、ウォッチャーが削除されても、ユーザー割り当て ID とそのアクセス権はそのまま残ります。 その後、同じ ID を新しいウォッチャーに使用できます。
    • ウォッチャーに対して複数のユーザー割り当て ID を指定することはサポートされていません。

ウォッチャーのマネージド ID を変更するには、ウォッチャーの [ID] ページを開きます。

  • システム割り当て ID を使用するには、[システム割り当て ID] トグルを有効にします。

  • ユーザー割り当て ID を使用するには、[システム割り当て ID] トグルを無効にします。 [追加] ボタンを選択して、既存のユーザー割り当て ID を検索して追加します。

    新しいユーザー割り当て ID を作成するには、「ユーザー割り当てマネージド ID を作成する」を参照してください。

  • ウォッチャーからユーザー割り当て ID を削除するには、それを一覧から選択し、[削除] を選択します。 ユーザー割り当て ID が削除されたら、別のユーザー割り当て ID を追加するか、システム割り当て ID を有効にする必要があります。

    削除されたユーザー割り当て ID は、Microsoft Entra ID テナントからは削除されません。

[保存] ボタンを選択して変更を保存します。 これによりウォッチャーが ID を持たないことになる場合、ID の変更は保存できません。 有効なマネージド ID がないウォッチャーはサポートされていません。

ヒント

ウォッチャーのマネージド ID の表示名は、Microsoft Entra ID テナント内で一意にすることをお勧めします。 ウォッチャーのユーザー割り当て ID を作成するときに、一意の名前を選択できます。

システム割り当て ID の表示名は、ウォッチャー名と同じです。 システム割り当て ID を使用する場合は、ウォッチャー名が Microsoft Entra ID テナント内で一意であることを確認します。

マネージド ID の表示名が一意でない場合、ウォッチャーに SQL ターゲットへのアクセス権を付与する T-SQL スクリプトが、表示名の重複エラーで失敗します。 詳細と回避策については、「Microsoft Entra ログインと一意ではない表示名を持つユーザー」を参照してください。

ID の変更が保存されるとすぐに、ウォッチャーは、現在のマネージド ID を使用して、SQL ターゲット、キー コンテナー (使用されている場合)、およびデータ ストアに再接続します。

Watcher を削除する

ウォッチャー、そのリソース グループ、またはそのサブスクリプションに削除または読み取り専用 lock がある場合は、ロックを削除します。 ウォッチャーが正常に削除された後、ロックを再度追加できます。

システム割り当てマネージド ID が有効になっているウォッチャーを削除すると、その ID も削除されます。 これにより、この ID に付与したアクセス権が削除されます。 ウォッチャーを後で再作成する場合は、各リソースへの認証を行うために、新しいウォッチャーのシステム割り当てマネージド ID へのアクセス権を付与する必要があります。 これには、次のものが含まれます。

同じ Watcher 名を使用する場合でも、再作成された Watcher への権利を与える必要があります。

ウォッチャーを削除しても、その SQL ターゲットおよびデータ ストアとして参照されている Azure リソースは削除されません。 収集された SQL 監視データはデータ ストアに保持され、後で新しいウォッチャーを作成する場合は、データ ストアと同じ Azure Data Explorer または Real-Time Analytics データベースを使用できます。

SQL ターゲットへの権利を与える

Watcher が SQL 監視データを収集できるようにするには、Watcher 固有の制限付き SQL アクセス許可を付与する T-SQL スクリプトを実行する必要があります。

  • Azure SQL データベースでスクリプトを実行するには、監視するデータベースとエラスティック プールを含む論理サーバーへのサーバー管理者アクセス権が必要です。

    • Azure SQL データベースでは、作成するすべての Watcher に対して論理サーバーごとに 1 回だけスクリプトを実行する必要があります。 これにより、Watcher には、そのサーバー上のすべての既存および新しいデータベースとエラスティック プールへのアクセス権が付与されます。

  • Azure SQL Managed Instance でスクリプトを実行するには、sysadmin または securityadmin のサーバー ロールのメンバーであるか、SQL Managed Instance に対する CONTROL サーバー アクセス許可を持っている必要があります。

    • Azure SQL Managed Instance では、監視する各インスタンスでスクリプトを実行する必要があります。

  1. Azure portal で Watcher に移動し、SQL ターゲットを選択し、[アクセス権の付与] リンクのいずれかを選択して T-SQL スクリプトを開き、スクリプトをコピーします。 ターゲットの種類と使用する認証の種類に適したリンクを選択してください。

    重要

    Azure portal の Microsoft Entra 認証スクリプトは、ウォッチャーに固有です。これにはウォッチャーのマネージド ID の名前が含まれているためです。 Watcher ごとにカスタマイズできるこのスクリプトの汎用バージョンについては、「T-SQL スクリプトを使用して SQL ターゲットへの権利を与える」を参照してください。

  2. SQL Server Management Studio、Azure Data Studio、またはその他の SQL クライアント ツールで、新しいクエリ ウィンドウを開き、ターゲットを含む Azure SQL 論理サーバー上の master データベース、または SQL Managed Instance ターゲット上の master データベースに接続します。

  3. T-SQL スクリプトを貼り付けて実行し、Watcher への権利を与えます。 このスクリプトは、Watcher が接続に使用するログインを作成し、監視データを収集するための特定の制限付きアクセス許可を付与します。

    1. Microsoft Entra 認証スクリプトを使用する場合、ウォッチャーでシステム割り当てマネージド ID が使用されているときは、そのウォッチャーは、スクリプトの実行時に既に作成されている必要があります。 ウォッチャーによってユーザー割り当てマネージド ID が使用される場合は、ウォッチャーの作成前または後にスクリプトを実行できます。

    マネージド ID へのアクセス権を付与する T-SQL アクセス スクリプトを実行するときは、Microsoft Entra 認証に接続する必要があります。

後で Watcher に新しいターゲットを追加する場合は、これらのターゲットが既にアクセスが許可されている論理サーバー上に存在しない限り、同様の方法でこれらのターゲットへの権利を与える必要があります。

T-SQL スクリプトを使用して SQL ターゲットへの権利を与える

Microsoft Entra 認証と SQL 認証、および Azure SQL データベース と Azure SQL Managed Instance のターゲットには、さまざまなスクリプトがあります。

重要

指定されたスクリプトを常に使用して、Database Watcher への権利を与えます。 別の方法でアクセスを許可すると、データ コレクションがブロックされる可能性があります。 詳細については、「Watcher 認可」を参照してください。

スクリプトを実行する前に、スクリプトに存在する可能性があるプレースホルダーのすべてのインスタンス (例: login-name-placeholder および password-placeholder) を実際の値に置き換えます。

Microsoft Entra 認証済み Watcher への権利を与える

このスクリプトでは、Azure SQL データベース の論理サーバーに Microsoft Entra (旧称 Azure Active Directory) 認証ログインが作成されます。 Watcher のマネージド ID に対してログインが作成されます。 このスクリプトは、論理サーバー上のすべてのデータベースとエラスティック プールから監視データを収集するために必要かつ十分なアクセス許可を Watcher に付与します。

ウォッチャーによってシステム割り当てマネージド ID が使用されている場合は、ウォッチャー名をログイン名として使用する必要があります。 ウォッチャーによってユーザー割り当てマネージド ID が使用されている場合は、ID の表示名をログイン名として使用する必要があります。

スクリプトは、論理サーバー上の master データベースで実行する必要があります。 サーバー管理者である Microsoft Entra 認証ログインを使用してログインする必要があります。

CREATE LOGIN [identity-name-placeholder] FROM EXTERNAL PROVIDER;

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [identity-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [identity-name-placeholder];

SQL 認証済み Watcher への権利を与える

SQL 認証を使用する場合は、追加の手順が必要です。「SQL 認証を使用するための追加の構成」を参照してください。

このスクリプトでは、Azure SQL データベースの論理サーバーに SQL 認証ログインを作成します。 論理サーバー上のすべてのデータベースとエラスティック プールから監視データを収集するために必要かつ十分なアクセス許可をログインに付与します。

論理サーバー管理者であるログインを使用して、論理サーバー上の master データベースでスクリプトを実行する必要があります。

CREATE LOGIN [login-name-placeholder] WITH PASSWORD = 'password-placeholder';

ALTER SERVER ROLE ##MS_ServerPerformanceStateReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER [login-name-placeholder];
ALTER SERVER ROLE ##MS_DatabaseConnector## ADD MEMBER [login-name-placeholder];

SQL 認証を使用するための追加の構成

認証資格情報を安全に格納するために、Database Watcher で SQL 認証を使用するには、追加の構成が必要です。

ヒント

より安全で、シンプルで、エラーが発生しにくい構成を実現するには、Azure SQL リソースに対して Microsoft Entra 認証を有効にし、SQL 認証の代わりに使用することをお勧めします。

SQL 認証を使用してターゲットに接続するように Database Watcher を構成するには、次の手順に従います。

  1. Azure Key Vault にコンテナーを作成するか、使用できる既存のコンテナーを識別します。 コンテナーでは、RBAC アクセス許可モデルを使用する必要があります。 RBAC アクセス許可モデルは、新しい Vault の既定値です。 既存の Vault を使用する場合は、古い アクセス ポリシー モデルを使用するように 構成 されていないことを確認します。

    コンテナーへのプライベート接続を使用する場合は、[マネージド プライベート エンドポイント] ページでプライベート エンドポイントを作成します。 [リソースの種類] として Microsoft.KeyVault/vaults を、[ターゲット サブリソース] として vault 選択します。 Watcher を起動する前に、プライベート エンドポイントが承認済みの状態であることを確認します。

    パブリック接続を使用する場合は、コンテナーですべてのネットワークからのパブリック アクセスが有効になっている必要があります。 パブリック コンテナーの接続を特定のネットワークに制限することは、Database Watcher ではサポートされていません。

  2. 監視する Azure SQL 論理サーバーまたは Managed Instance ごとに SQL 認証ログインを作成し、アクセススクリプトを与えられた、特定の制限されたアクセス許可を付与します。 スクリプトで、ログイン名とパスワードのプレースホルダーを実際の値に置き換えます。 強力なパスワードを使用してください。

  3. Vault で、2 つのシークレットを以下のように作成します: ログイン名の シークレット とパスワード用の 別の シークレット。 任意の有効な名前をシークレット名として使用し、T-SQL スクリプトで使用したログイン名またはパスワードをシークレット用シークレット値として入力します。

    たとえば、2 つのシークレットの名前は database-watcher-login-name および database-watcher-password の可能性があります。 シークレットの値は、ログイン名と強力なパスワードになります。

    シークレットを作成するには、Key Vault Secrets Officer RBAC ロールのメンバーである必要があります。

  4. ウォッチャーに SQL ターゲットを追加します。 ターゲットを追加するときに、[SQL 認証の使用] ボックスチェックし、ログイン名とパスワード シークレットが格納されているコンテナーを選択します。 ログイン名とパスワードのシークレット名を対応するフィールドに入力します。

    SQL ターゲットを追加するときは、実際のログイン名とパスワードを入力しないでください。 前の例を使用して、database-watcher-login-name シークレット名と database-watcher-password シークレット名を入力します。

  5. Azure portal で SQL ターゲットを追加すると、現在のユーザーがキー コンテナーの所有者ロールまたはユーザー アクセス管理者ロールのメンバーである場合、ウォッチャーのマネージド ID に、キー コンテナー シークレットへの必要なアクセス権が自動的に付与されます。 それ以外の場合は、次の手順に従って、必要なアクセス権を手動で付与します。

  6. 各シークレットの [アクセス制御 (IAM)] ページで、キー コンテナー シークレットのユーザー RBAC ロールに Watcher のマネージド ID のロールの割り当てを追加します。 最小限の特権の原則に従うには、コンテナー全体ではなく、シークレットごとにこのロールの割り当てを追加します。 [アクセス制御 (IAM)] ページは、Vault が RBAC アクセス許可モデルを使用するように構成されている場合にのみ表示されます。

異なる SQL ターゲットでさまざまな SQL 認証資格を使用する場合は、複数のペアのシークレットを作成する必要があります。 同じ Vault または異なる Vault を使用して、各 SQL ターゲットのシークレットを格納できます。

Note

Watcher の実行中に、キー コンテナー内のログイン名またはパスワードのシークレット値を更新すると、Watcher は 15 分以内に新しい SQL 認証資格情報を使用してターゲットに再接続します。 新しい資格情報の使用をすぐに開始する場合は、Watcher を停止して再起動します。

データ ストアへの権利を与える

データベース スキーマをデータ ストアで作成および管理し、監視データを取り込むには、データベース ウォッチャーは、Azure Data Explorer クラスターのデータ ストア データベース、または Real Time Analytics で 管理 RBAC ロールのメンバーシップを必要とします。 Database Watcher では、Azure Data Explorer クラスターへのクラスター レベルのアクセスや、同じクラスターに存在する可能性がある他のデータベースへのアクセスは必要ありません。

クラスターの所有者 RBAC ロールのメンバーで、Azure Data Explorer クラスター上のデータベースをデータ ストアとして使用している場合、このアクセス権は自動的に付与されます。 それ以外の場合は、このセクションの説明に従ってアクセス権を付与する必要があります。

Real-Time Analytics または無料の Azure Data Explorer クラスターでデータベースを使用する場合は、KQL を使用してアクセス権を付与する必要があります。

Azure portal を使用して Azure Data Explorer データベースへの権利を与える

Azure portal を使用して、Azure Data Explorer クラスター上のデータベースへの権利を与えることができます。

  1. Azure Data Explorer クラスター上のデータベースの場合は、リソース メニューの [セキュリティとネットワーク] で [アクセス許可] を選択します。 クラスターの [アクセス許可] ページは使用しないでください。
  2. [追加] を選択し、[管理] を選択します。
  3. [新しいプリンシパル] ページで、[エンタープライズ アプリケーション] を選択します。 ウォッチャーによってシステム割り当てマネージド ID が使用されている場合は、[検索] ボックスにウォッチャーの名前を入力します。 ウォッチャーによってユーザー割り当てマネージド ID が使用されている場合は、[検索] ボックスにその ID の表示名を入力します。
  4. ウォッチャーのマネージド ID のエンタープライズ アプリケーションを選択します。

KQL を使用して Azure Data Explorer データベースへの権利を与える

Azure portal を使用する代わりに、KQL コマンドを使用してデータベースへの権利を与えることもできます。 この方法を使用して、Real Time Analytics または無料の Azure Data Explorer クラスター上のデータベースへの権利を与えます。

  1. Kusto エクスプローラー または Azure Data エクスプローラー Web UI を使用して、Azure Data Explorer クラスター上のデータベースに接続します。

  2. 次のサンプル KQL コマンドでは、テーブルに記載されているとおり、次の 3 つのプレースホルダーを置き換えます:

    .add database [adx-database-name-placeholder] admins ('aadapp=identity-principal-id-placeholder;tenant-primary-domain-placeholder');
    プレースホルダー 代替
    adx-database-name-placeholder Azure Data Explorer クラスターまたは Real Time Analytics のデータベースの名前。
    identity-principal-id-placeholder ウォッチャーの [ID] ページにあるマネージド ID (GUID) のプリンシパル ID 値。 システム割り当て ID が有効になっている場合は、その プリンシパル ID 値を使用します。 それ以外の場合は、ユーザー割り当て ID のプリンシパル ID 値を使用します。
    tenant-primary-domain-placeholder ウォッチャー マネージド ID の Microsoft Entra ID テナントのドメイン名。 これは、Azure portal の Microsoft Entra ID [概要] ページで確認できます。 テナント プライマリ ドメインの代わりに、テナント ID の GUID 値も使用できます。

    コマンドのこの部分は、Real-Time Analytics または無料の Azure Data Explorer クラスターでデータベースを使用する場合に必要です。

    Azure Data Explorer クラスター上のデータベースの場合、ドメイン名またはテナント ID の値 (および、その前にあるセミコロン) は省略できます。これは、クラスターがウォッチャー マネージド ID と常に同じ Microsoft Entra ID テナントにあるためです。

    次に例を示します。

    .add database [watcher_data_store] admins ('aadapp=9da7bf9d-3098-46b4-bd9d-3b772c274931;contoso.com');

詳細については、「Kusto ロールベースのアクセス制御」に関するページを参照してください。

ユーザーとグループにデータストアへのアクセス権を付与する

Azure portal または KQL コマンドを使用して、Azure Data Explorer クラスターまたは Real Time Analytics のデータベースへのアクセス権をユーザーとグループに付与することができます。 アクセス権を付与するには、データベースの 管理 RBAC ロールのメンバーである必要があります。

この方法を使用して、無料の Azure Data Explorer クラスター上、または Real Time Analyticsのデータベースへの権利を与えます。 最小限の権限の原則に従うには、既定では 閲覧者 以外の RBAC ロールにユーザーとグループを追加しないことをお勧めします。

重要

Database Watcher によって収集された SQL 監視データを表示する権利を与える場合は、データのプライバシーとセキュリティの要件を慎重に検討してください。

Database Watcher には、SQL データベースのユーザー テーブルに格納されているデータを収集する機能はありませんが、アクティブ セッション、インデックス メタデータ、欠落インデックス、クエリ ランタイム統計、クエリ待機統計、セッション統計、テーブル メタデータなどの特定のデータセットには、テーブル名やインデックス名、クエリ テキスト、クエリ パラメーター値、ログイン名など、機密性の高いデータが含まれている可能性があります。

SQL データベースでこのデータを表示するアクセス権を持たないユーザーにデータ ストアへのビュー アクセス権を付与することで、他の方法では表示できない機密データを表示できるようにすることができます。

Azure portal を使用してデータ ストアへの権利を与える

Azure portal を使用して、Azure Data Explorer クラスター上のデータベースへのアクセス権をユーザーとグループに付与できます。

  1. Azure Data Explorer クラスターのデータベースの場合は、リソース メニューの [セキュリティとネットワーク] で [アクセス許可] を選択します。 クラスターの [アクセス許可] ページは使用しないでください。
  2. [追加] を選択し、[閲覧者] を選択します。
  3. [新しいプリンシパル] ページで、[検索] ボックスにユーザーまたはグループの名前を入力します。
  4. ユーザーまたはグループを選択します。

KQL を使用してデータ ストアへの権利を与える

Azure portal を使用する代わりに、KQL コマンドを使用してユーザーとグループにデータベースへのアクセス権を付与することもできます。 次の KQL コマンドの例では、特定のテナント ID 値を持つ Microsoft Entra ID テナント内の mary@contoso.com ユーザーと SQLMonitoringUsers@contoso.com グループにデータ読み取りアクセスを許可します。

.add database [watcher_data_store] viewers ('aaduser=mary@contoso.com');

.add database [watcher_data_store] viewers ('aadgroup=SQLMonitoringUsers@contoso.com;8537e70e-7fb8-43d3-aac5-8b30fb3dcc4c');

詳細については、「Kusto ロールベースのアクセス制御」に関するページを参照してください。

データ ストアへのアクセス権を別のテナントのユーザーとグループに付与するには、Azure Data Explorer クラスターでテナント間認証を有効にする必要があります。 詳細については、「テナント間のクエリとコマンドの許可」を参照してください。

ヒント

Microsoft Entra ID テナント内のユーザーとグループへのアクセス権を付与できるように、テナント間認証は Real Time Analytics と無料の Azure Data Explorer クラスターで有効になっています。

データ ストアの管理

このセクションでは、スケーリング、データ保持、その他の構成など、監視データ ストアを管理する方法について説明します。 このセクションのクラスター スケーリングに関する考慮事項は、Azure Data Explorer クラスターでデータベースを使用する場合に関連します。 データベース を Fabric のReal Time Analyticsで使用する場合、スケーリングは自動的に管理されます。

Azure Data Explorer クラスターをスケーリングする

必要に応じて、Azure Data Explorer クラスターをスケーリングできます。 たとえば、サービス レベル アグリーメント (SLA) が必要ない場合や、クエリとデータ インジェストのパフォーマンスが許容範囲にとどまる場合は、クラスターを Extra small、Dev/test SKU にスケールダウンできます。

多くの Database Watcher デプロイでは、既定の極小コンピューティング最適化の 2 インスタンス クラスター SKU で無期限に十分です。 場合によっては、構成とワークロードの経時変化に応じて、十分なクエリ パフォーマンスを確保し、データ インジェストの待機時間の短縮を維持するためにクラスターのスケーリングが必要になる場合があります。

Azure Data Explorer では、垂直方向と水平方向のクラスター スケーリングがサポートされています。 垂直方向のスケーリングでは、クラスター SKU を変更します。これによって、インスタンス (ノード) あたりの vCPU、メモリ、キャッシュの数が変更されます。 水平方向のスケーリングでは、SKU は同じままですが、クラスター内のインスタンスの数は増減されます。

次の現象の 1 つ以上に気付いた場合は、クラスターをスケール アウト (水平方向に) または スケール アップ(垂直方向に) する必要があります。

  • ダッシュボードまたはアドホック クエリのパフォーマンスが遅すぎます。
  • クラスターで多数の同時実行のクエリを実行し、調整エラーを観察します。
  • データ インジェストの待機時間は、許容されるよりも一貫して高くなります。

一般に、データ ストア内のデータ量が時間の経過と同時に増加するため、クラスターをスケーリングする必要はありません。 これは、ダッシュボード クエリと最も一般的な分析クエリでは、クラスター ノード上のローカル SSD ストレージにキャッシュされている最新のデータのみが使用されるためです。

ただし、より長い時間の範囲にまたがる分析クエリを実行すると、収集されたデータの総量が増加し、ローカル SSD ストレージに収まらなくなると、時間の経過と同時に遅くなる可能性があります。 その場合、適切なクエリ パフォーマンスを維持するために、クラスターのスケーリングが必要になる場合があります。

  • クラスターをスケーリングする必要がある場合は、最初にクラスターを水平方向にスケーリングして、インスタンスの数を増やすことをお勧めします。 これにより、スケーリング プロセス中にクエリとインジェストでクラスターを利用可能な状態に維持します。

    • 最適化されたオートスケールを有効にして、ワークロードの変化や季節的な傾向に応じてインスタンスの数を自動的に減らすか、増やすことができます。

  • クラスターを水平方向にスケール アウトした後でも、一部のクエリは期待どおりに動作しない場合があります。 これは、クラスターのインスタンス (ノード) で使用可能なリソースによってクエリのパフォーマンスがバインドされている場合に発生する可能性があります。 その場合は、クラスターを垂直方向にスケールアップします。

    • 垂直クラスターのスケーリングには数分かかります。 そのプロセス中にダウンタイムが発生し、Watcher によりデータ コレクションが中止される可能性があります。 その場合は、スケーリング操作の完了後に Watcher を停止して再起動します。

無料の Azure Data Explorer クラスター

無料の Azure Data Explorer クラスターには、元の圧縮されていないデータのストレージ容量制限など、特定の容量制限があります。 無料の Azure Data Explorer クラスターをスケーリングして、コンピューティング容量またはストレージ容量を増やすことはできません。 クラスターがストレージ容量に近づくか、容量に達すると、 無料クラスター ページに警告メッセージが表示されます。

ストレージ容量に達している場合、新しい監視データは取り込まれませんが、既存のデータにはデータベース ウォッチャー ダッシュボードで引き続きアクセス可能です。KQL または SQL クエリを使用して分析することもできます。

無料クラスターの仕様が要件に対して十分でない場合は、完全な Azure Data Explorer クラスターにアップグレードすれば、収集されたデータすべてを保持することができます。 アップグレード中にダウンタイムが発生する可能性があるため、アップグレードが完了したら、Watcher を停止して再起動し、データ コレクションを再開する必要がある場合があります。

無料の Azure Data Explorer クラスターを引き続き使用するには、データ保持の管理機能によって古いデータを自動的に削除し、新しいデータのための領域を確保します。 ストレージ スペースが使用可能になった後、データ収集を再開するには、ウォッチャーの停止と再起動が必要になる場合があります。

データ保持を管理する

古いデータを必要としない場合は、データ アイテム保持ポリシーを構成して自動的に消去できます。 デフォルトでは、Azure Data Explorer クラスターまたは Real Time Analytics の新しいデータベースのデータ保持期間は 365 日に設定されます。

  • データベース レベルで、またはデータベース内の個々のテーブルのデータ保持期間を短縮できます。
  • 監視データを 1 年以上保存する必要がある場合は、保持期間を増やすこともできます。 データ保持期間に上限はありません。
  • 異なるテーブルに対して異なるデータ保持期間を構成した場合、古い時間範囲ではダッシュボードが期待どおりに機能しない可能性があります。 これは、一部のテーブルにデータがまだ存在するが、同じ期間の他のテーブルで既に消去されている場合に発生する可能性があります。

データ ストアに取り込まれる SQL 監視データの量は、SQL ワークロードと Azure SQL 資産のサイズによって異なります。 次の KQL クエリを使用すると、1 日に取り込まれたデータの平均量を表示し、ストレージ消費量の推移を見積もり、データ保持ポリシーを管理することができます。

.show database extents
| summarize OriginalSize = sum(OriginalSize),
            CompressedSize = sum(CompressedSize)
            by bin(MinCreatedOn, 1d)
| summarize DailyAverageOriginal = format_bytes(avg(OriginalSize)),
            DailyAverageCompressed = format_bytes(avg(CompressedSize));

Database Watcher データ ストアのスキーマとアクセスの変更

時間の経過と同時に、Microsoft は新しい Database Watcher データセットを導入したり、既存のデータセットを拡張したりする可能性があります。 つまり、データ ストア内の新しいテーブルや、既存のテーブルの新しい列が自動的に追加される可能性があります。

これを行うには、データベース Watcher のマネージド ID がデータ ストアの 管理 RBAC ロールのメンバーである必要があります。 このロール メンバーシップを取り消すか、他の RBAC ロールのメンバーシップに置き換えると、Database Watcher データ コレクションとスキーマ管理に影響を与える可能性があるため、サポートされていません。

同様に、Database Watcher データ ストアでのテーブル、外部テーブル、具体化されたビュー、関数などの新しいオブジェクトの作成はサポートされていません。 クラスター間クエリとデータベース間クエリを使用して、他の Azure Data Explorer クラスターまたは同じクラスター上の他のデータベースから、データ ストア内のデータに対してクエリを実行できます。

重要

データ ストアへの Database Watcher アクセスを変更する場合、またはデータ インジェストに影響するデータベース スキーマまたは構成の変更を行う場合は、新しい空のデータベースにその Watcher のデータ ストアを変更し、Watcher にこの新しいデータベースへのアクセス権を付与してデータ コレクションを再開し、サポートされている構成に戻す必要がある場合があります。

停止状態にある Azure Data Explorer クラスター

コストを節約するなどの目的で、Azure Data Explorer クラスターを停止できます。 既定では、Azure portal で作成された Azure Data Explorer クラスターは、数日間非アクティブになった後に自動的に停止されます。 たとえば、クラスター上の唯一のデータベースにデータを取り込む Watcherを停止し、このデータベースでクエリを実行しない場合に発生する可能性があります。

新しいウォッチャーの作成時に既定のオプションを使用して新しい Azure Data Explorer クラスターを作成すると、自動停止動作が無効になり、データ コレクションが中断されなくなります。

クラスターが停止すると、データベース 監視データ収集も停止します。 データ収集を再開するには、クラスターを開始する必要があります。 クラスターが実行されたら、Watcher を再起動します。

クラスターが非アクティブなときでも引き続き利用可能にする場合、自動停止動作を無効にすることができます。 これにより、クラスター コストが増加する可能性があります。

ストリーミング インジェスト

Database Watcher では、データ ストア データベースを含む Azure Data Explorer クラスターでストリーミング インジェストが有効になっている必要があります。 ストリーミング インジェストは、新しい Watcher の作成時に作成された新しい Azure Data Explorer クラスターに対して自動的に有効になります。 これは、Real Time Analytics と無料の Azure Data Explorer クラスターでも有効になります。

既存の Azure Data Explorer クラスターを使用する場合は、まずストリーミング インジェストを有効にする必要があります。 これには数分かかるので、クラスターが再起動されます。

データ ストアへのプライベート接続

Azure Data Explorer クラスター パブリック アクセス が無効になっている場合は、ブラウザーからクラスターに接続し、ダッシュボードで SQL 監視データを表示したり、データに直接クエリを実行したりするためのプライベート エンドポイントを作成する必要があります。 このプライベート エンドポイントは以下の管理されたプライベート エンドポイントに加えて、Watcher が監視データを Azure Data Explorer クラスター上のデータベースに取り込むために作成されます。

  • Azure VM から Azure Data Explorer クラスターに接続する場合は、Azure VM が配置されている Azure Virtual Network 内の Azure Data Explorer クラスターのプライベート エンドポイントを作成します。

  • オンプレミスのマシンから Azure Data Explorer クラスターに接続する場合は、次のことができます:

    1. Azure VPN Gateway または Azure ExpressRoute を使用して、オンプレミス ネットワークから Azure 仮想ネットワークへの接続を確立する。
    2. VPN または ExpressRoute 接続が終了するか、他の Azure Virtual Network でマシンのオンプレミスからトラフィックが到達可能なら、Azure Virtual Network 内の Azure Data Explorer クラスター用の別のプライベート エンドポイントを作成します。
    3. プライベート エンドポイントの DNS を構成する。

プライベート接続は、無料の Azure Data Explorer クラスターや Microsoft Fabric の Real Time Analytics では使用できません。

大規模な資産を監視する

大規模な Azure SQL 資産を監視するには、複数の Watcher を作成することが必要な場合があります。

各 Watcher には、Azure Data Explorer クラスター上のデータベース、またはデータ ストアとしての Real Time Analytics が必要です。 作成する Watcher は、単一データベースを共通のデータ ストアとして使用することも、個別のデータベースを個別のデータ ストアとして使用することもできます。 次の考慮事項は、監視シナリオと要件に最適な設計選択を行うのに役立ちます。

一般的なデータ ストアに関する考慮事項:

  • Azure SQL 資産全体を 1 つのウィンドウで表示できます。
  • Watcher のダッシュボードには、データが他の Watcher によって収集された場合でも、データ ストア内のすべてのデータが表示されます。
  • データ ストアにアクセスできるユーザーは、Azure SQL 資産全体の監視データにアクセスできます。

個別のデータ ストアに関する考慮事項:

  • Azure SQL 資産のサブセットは個別に監視されます。 Azure portal のデータベース Watcher ダッシュボードには、1 つのデータ ストアからのデータが表示されます。
  • 複数のデータ ストアにアクセスできるユーザーは、クラスター間またはデータベース間の KQL クエリを使用して、1 つのクエリを使用して複数のデータ ストアの監視データにアクセスできます。
  • Azure Data Explorer と Real Time Analytics のデータ アクセスはデータベースごとに管理されるため、資産のサブセットの監視データへのアクセスを細かく管理できます。
  • 複数のデータベースを同じ データ エクスプローラー クラスターに配置してクラスター リソースを共有し、コストを節約しながら、各データベースでデータを分離することができます。
  • Azure Data Explorer クラスターへのネットワーク アクセスなど、環境を完全に分離する必要がある場合は、異なるクラスターに異なるデータベースを配置できます。

関連するコンテンツ