次の方法で共有

マルチカスタマー アプリケーションをサービス プリンシパル プロファイル モデルに移行する

  • [アーティクル]

この記事では、Power BI 埋め込み分析マルチカスタマー アプリをサービス プリンシパル プロファイル モデルに移行することで、スケーラビリティを向上させる方法について説明します。

サービス プリンシパル プロファイルを使用すると、Power BI で組織のコンテンツをより簡単に管理し、容量をより効率的に使用できます。

Note

この記事は、1 つの Power BI テナントの複数の顧客をサポートするアプリを既に持っている組織を対象としています。

すべてのアプリでサービス プリンシパル モデルの利点が得られるわけではありません。 たとえば、次のアプリは移行しないことをお勧めします。

  • 少数のオブジェクトを持つ 1 つのサービス プリンシパルを保持する小規模なアプリ。
  • 顧客ごとに 1 つの、複数のサービス プリンシパルを使用するアプリ

前提条件

移行を開始する前にサービス プリンシパル プロファイルについて確認することが重要です。

次の手順も行う必要があります。

[プロファイルの作成を有効にする] スイッチを示す管理ポータルのスクリーンショット。

サービス プリンシパル プロファイルに移行する

サービス プリンシパル プロファイルへの移行には、次の手順が含まれます。

  1. プロファイルを作成します (顧客ごとに 1 つのプロファイル)。
  2. ワークスペースを整理します。
  3. プロファイルを使用するようにアプリケーション コードを変更します。
  4. プロファイル モデルを使用してアプリケーションをテストします。
  5. 冗長なアクセス許可をクリーンアップします。

プロファイルを作成する (必須)

作成したサービス プリンシパルで Profiles REST API を使用して、顧客ごとに 1 つのプロファイルを作成します。

各データ顧客 ID と対応するプロファイル ID のマッピングをデータベースに保存することをお勧めします。 このマッピングは、後でテナント プロファイルを使用して API 呼び出しを行うために必要になります。

ワークスペースを整理する

顧客ごとに 1 つのワークスペースを維持することが、データを管理する最も簡単な方法です。 アプリで既にこのモデルが使用されている場合は、新しいワークスペースを作成する必要はありません。 ただし、Add Group User API を使用して、対応するワークスペースへの "管理者" アクセス権を引き続き各プロファイルに提供する必要があります。

顧客ごとに 1 つのワークスペースがない場合は、対応するプロファイルを使用して Create Group User API を呼び出し、顧客ごとに新しいワークスペースを作成します。

ワークスペースでアイテムを整理する

これで、顧客ごとにプロファイルとワークスペースが作成されました。 前の手順で新しいワークスペースを作成した場合は、これらのワークスペースに項目 (レポートやセマンティック モデルなど) をインポートする必要があります。 インポートするセマンティック モデルは、現在のソリューションによって異なります。

  • アプリで顧客ごとに個別のセマンティック モデルを使用している場合は、セマンティック モデルの設計をそのまま使用できます。

  • アプリで、行レベル セキュリティ (RLS) を利用する 1 つのセマンティック モデルを使用して異なる顧客に異なるデータを提供する場合は、顧客ごとに個別のセマンティック モデルを作成し、この記事で説明されているようにプロファイルを使用することで、スケーラビリティを向上させることができます。

  • プロファイルと個別のデータ ソースを使用してスケーラビリティの制限を克服した後、プロファイルで RLS を使用することで、さらに多くのデータ分離を実現できます。

    • Dynamic RLS に依存している場合は、DAX 関数 UserName() でプロファイルの名前が返されます。
    • 静的 RLS を使用し、埋め込みトークンの生成時にロールをオーバーライドする場合は、引き続きこれを行うことができます。

項目の準備ができたら、関連するワークスペースにインポートします。 プロセスを自動化する場合は、Import API の使用を検討してください。

プロファイルを使用するようにアプリケーション コードを変更する

関連するワークスペースへの "管理者" アクセス権を持つプロファイルと、どのプロファイルがどの顧客を表すかを示すマッピングを含むデータベースを用意したら、必要なコード変更を行うことができます。 2 つのコード フローを並べておき、プロファイル コード フローを徐々に顧客に公開することをお勧めします。

次のコード変更を行います。

  • 認証コードの変更

    • Microsoft Entra ID アプリで ''マスター ユーザー'' を使用している場合は、取得トークン コードを変更します。 アプリ専用の Microsoft Entra トークンの作成の詳細については、サービス プリンシパルの埋め込みに関するページを参照してください。
    • ''サービス プリンシパル'' を使用していて、プロファイル用に新しいものを作成した場合は、正しいサービス プリンシパル ID とシークレットを使用するようにコードを調整します。

  • 管理コードの変更

    一部のアプリには、登録時に新しい顧客のオンボードを自動化する管理コードがあります。 多くの場合、管理コードでは Power BI REST API を使用してワークスペースを作成し、コンテンツをインポートします。 このコードのほとんどは変わらないはずですが、次の詳細を調整する必要がある場合があります。

    • 新しい顧客テナントを作成するたびに、そのテナントのワークスペースの作成者および管理者となる新しいサービス プロファイルを作成します。
    • Power BI コンテンツを再構成することにした場合は、変更を反映するようにコードを編集します。

  • 埋め込みトークン コードの変更

    API 呼び出し元を置き換えます。 プロファイル モデルでは、特定のプロファイルのみで顧客のコンテンツにアクセスできるため、プロファイルで GenerateToken API を呼び出していることを確認します。

検証

プロファイル モデルに移動する前に、アプリを徹底的にテストすることをお勧めします。 ワークスペースの古いアクセス許可を削除していないため、SaaS アプリケーション コードにバグが存在する場合でも、レポートが読み込まれる可能性があります。

移行後にクリーンアップする

これで移行を完了し、結果を検証したので、不要なものを削除しましょう。

  • コードをクリーンアップする: 古いコード パスを無効にし、プロファイルに依存する新しいコードのみを確実に実行するようにすることができます。
  • Power BI でワークスペースとアクセス許可をクリーンアップする: 新しいワークスペースを作成した場合は、使用されなくなった古いワークスペースを削除できます。 同じワークスペースを再利用した場合は、ワークスペースの古いアクセス許可 (''マスター ユーザー'' のアクセス許可など) を削除できます。

関連するコンテンツ

サービス プリンシパル プロファイルを管理する

他にわからないことがある場合は、 Power BI コミュニティで質問してみてください。