Power BI の埋め込み分析でマルチテナントを管理するManage multi-tenancy with Power BI embedded analytics

マルチテナント SaaS アプリケーションを設計するときは、SaaS アプリケーションのニーズに最適なテナント モデルを慎重に選択する必要があります。When designing a multi-tenant SaaS application, you must carefully choose the tenancy model that best fits the needs of your SaaS application. このプロセスは、SaaS アプリケーションの埋め込み分析部分としての Power BI に対しても有効です。This process is also valid for Power BI as an embedded analytics part of your SaaS application. テナント モデルにより、Power BI およびストレージ アカウント内で各テナントのデータがマップおよび管理される方法が決まります。A tenancy model determines how each tenant’s data is mapped and managed within Power BI and the storage account. テナント モデルは、アプリケーションの設計と管理に影響します。Your tenancy model impacts application design and management. 後で別のモデルに切り替えると、コストがかかり、破壊的になる可能性があります。Switching to a different model later may become costly and disruptive.

Power BI Embedded では、テナント間の分離を維持するための基本的な方法が主に 2 つあります。With Power BI Embedded, there are two main fundamental approaches to maintaining separation between tenants.

  1. ワークスペースに基づく分離 - テナントごとに独立した Power BI ワークスペースを作成します。Workspace-based isolation - creating a separate Power BI Workspace per tenant.
  2. 行レベルのセキュリティに基づく分離 - 基になるデータを使用して、ユーザーまたはグループごとにデータへのアクセスを制御および管理します。Row-level security-based isolation - where the underlying data is used to control and manage access to data per user or group.

この記事では、さまざまな方法について説明し、複数の評価基準に従って分析します。This article describes the different approaches and analyzes them according to several evaluation criteria.

概念と用語Concepts and terminology

AAD - Azure Active Directory。AAD - Azure Active Directory.

AAD アプリケーション - AAD でのアプリケーション ID。AAD application - An application identity in AAD. 認証には、AAD アプリケーションが必要です。An AAD application is required for authentication.

SaaS (サービスとしてのソフトウェア) アプリケーション - エンタープライズまたは ISV によって実装されるシステムであり、通常はオンライン サービスです。SaaS application (software-as-a-service) - A system implemented by an enterprise or ISV that is usually an online service. また、複数の顧客テナント (組織) を提供するための関連するソフトウェア システムでもあります。Its also related software systems for serving multiple customer tenants (organizations). この記事では、SaaS アプリケーションで Power BI Embedded を使用して異なるテナントに分析を提供しますFor this article, the SaaS application uses Power BI Embedded to serve analytics to its different tenants. Power BI Embedded は、オンライン接続されているすべての種類のアプリケーションで動作できます。Power BI Embedded can also work for all types of applications when they have an online connection.

テナント – SaaS アプリケーションと、SaaS アプリケーションに自分で格納したリソースやデータを使用する、単一の顧客 (組織)。Tenant – A single customer (organization) that uses the SaaS application and any resources or data that the customer brings to the SaaS application.

Power BI - Power BI Embedded のプラットフォームとして機能する Power BI クラウド サービス。Power BI - The Power BI cloud service that serves as a platform for Power BI Embedded.

Power BI テナント - 単一の AAD テナントに関連付けられている Power BI リソースのセット。Power BI tenant - Is a set of Power BI resources associated with a single AAD tenant.

Power BI ワークスペース - Power BI のコンテンツ用のコンテナー。Power BI workspace - A container for content in Power BI.

Power BI 成果物 – ダッシュボード、レポート、データセット、データフローなど、Power BI ワークスペース内にはいくつかの Power BI 成果物があります。Power BI artifacts – There are several Power BI artifacts in Power BI workspaces such as dashboards, reports, datasets, and dataflows.

Power BI Embedded -Power BI のコンテンツを管理して Power BI の要素を埋め込むアプリケーションを開発者が構築できるようにするパブリック API のセット。Power BI Embedded - A set of public APIs that allow developers to build applications that manage Power BI content and embed Power BI elements.

行レベルのセキュリティ (RLS) - テーブル内の各行のデータへのユーザー アクセスを制御する機能を提供します。Row-level security (RLS) - Gives the ability to control user access to the data for individual rows in a table. データ ソース レベルまたは Power BI のセマンティック モデルで、行レベルのセキュリティを実装することができます。You can implement row-level security at the data source level or in the Power BI semantic model.

マスター ユーザー - Power BI 内の SaaS アプリケーションを表す ID であり、SaaS アプリケーションで Power BI API を呼び出すときに使用されます。Master user - The identity that represents the SaaS application in Power BI and that the SaaS application uses when calling Power BI APIs. Power BI Pro ライセンスを持つ AAD ユーザーである必要があります。Needs to be an AAD user with a Power BI Pro license.

AAD アプリケーション ユーザー (サービス プリンシパル) - Power BI 内の SaaS アプリケーションを表す ID であり、SaaS アプリケーションで Power BI API を呼び出すときに使用されます。AAD Application user (service principal) - The identity that represents the SaaS application in Power BI and that the SaaS application uses when calling Power BI APIs. AAD Web アプリケーションである必要があります。Needs to be an AAD web application. Power BI での認証のために、"マスター" ユーザーの代わりに使用できます。Can replace the use of a master user to authenticate with Power BI.

容量 - Power BI サービス実行専用のリソースのセット。Capacity - A set of resources dedicated to running the Power BI service. Power BI Premium 容量は Power BI を社内で使用する企業を対象としたものですが、Power BI Embedded 容量はサード パーティ向けの SaaS アプリケーションを開発するアプリケーション開発者を対象としています。Power BI Premium capacities Intended for enterprise companies using Power BI internally, while Power BI Embedded capacities intend for application developers to develop SaaS applications for third parties.

Power BI Pro ライセンス - ユーザー ベースのライセンスであり、アプリ ワークスペースへのコンテンツの発行、Premium 容量なしでのアプリの利用、ダッシュボードの共有、ダッシュボードおよびレポートのサブスクライブを行う権限が付与されます。Power BI Pro license - A user-based license, which grants rights to publish content to app workspaces, consume apps without Premium capacity, share dashboards, and subscribe to dashboards and reports.

データ接続モード - 異なるモードで Power BI にデータ ソースを接続できます。Data connectivity modes - Connecting data sources to Power BI that can be done in different modes:

  • インポート - データを取得する最も一般的な方法です。Import - which is the most common way to get data.
  • DirectQuery - ソース リポジトリ内のデータに直接接続します。DirectQuery - connect directly to the data in its source repository.
  • ライブ接続 - Analysis Services のデータ (Azure とオンプレミスの両方) に直接接続するもう 1 つのモードです。Live connection - another mode that connects directly to Analysis Services data (both Azure and on-premises).

評価基準Evaluation criteria

SaaS アプリケーションに適したテナント モデルの最適な選択肢は、具体的なビジネスおよび技術的な要件やデータ アーキテクチャなどによって異なります。The optimal choice for the right tenancy model for your SaaS application varies according to specific business and technical requirements, data architecture and more. これらの要件および使用可能なテナント モデルのオプションとトレードオフをよく理解すると、SaaS アプリケーションに対する堅牢で、高パフォーマンスで、コスト効率に優れた、スケーラブルなアーキテクチャを定義するのに役立ちます。Deep understanding of these requirements along with available tenancy model options and trade-offs can help define robust, performant, cost-effective, and scalable architecture for your SaaS application.

異なるテナント モデルを選択するときに検討すべき点のセットを次に示します。The following are a set of areas to consider when choosing between the different tenancy models.

データのアーキテクチャData architecture

通常、Power BI Embedded を使用してアプリケーションを構築するときは、1 つまたは複数のテナント データベースが既に存在します。Usually, developers building applications with Power BI Embedded already have a single or multi-tenant database. Power BI Embedded には、データベースのテナント モデルと同様のテナント モデルを使用するのが簡単です。It's easier to use a tenancy model for Power BI Embedded which is similar to the tenancy model of the database. データベースのテナント モデルをまだ定義されていない場合は、データ アーキテクチャを決定する前に他の側面を考慮することができます。If the database tenancy model hasn’t been defined yet, you may want to consider other aspects before deciding on your data architecture.

データの分離Data Isolation

格納されるデータの機密性はどれくらいですか。How sensitive is the data being stored? どのような分離レベルで異なる顧客のテナントを分離する必要がありますか。What level of isolation do you need separating different customer tenants? 答えは、さまざまな業界や特定の顧客の具体的な要件によって異なる場合があります。The answer might vary across different industries or specific customers that have certain requirements.

スケーラビリティScalability

最適なソリューションを見つけるには、近い将来に到達するスケールを定義します。To find the best solution, define the scale you reach in the foreseeable future. 今は適切であるように見えるソリューションでも使用量やデータがスケールアップすると適切ではなくなる可能性があることに注意してください。Remember that a solution that might be suitable now might not suffice when usage and data scale up. スケーラビリティを分析するときは、次の一覧を検討してください。When analyzing scalability, consider the following list:

  • テナント (顧客) の数。Number of tenants (customers).
  • 各テナントのレポート、ダッシュボード、データセットの数。Number of reports, dashboards, and datasets for each tenant.
  • 各データセットのデータのサイズと更新の間隔。Size of data on each dataset and frequency of refreshes.
  • ユーザーの数。Number of users.
  • ピーク時の同時実行ユーザーの数。Number of concurrent users in peak times.

SaaS アプリケーションによっては、顧客の数や使用量は少なくても、データ量は多い場合があります。Some SaaS applications might have a low number of customers and low usage, but large amounts of data. または、顧客数や使用量は多くても、顧客ごとのデータやレポートの量は少ないこともあります。Others might have many customers and high usage, but a small amount of data and reports for each customer. このような状況での高い値は、将来のコストと運用の複雑さに影響する可能性があります。High numbers in any of these situations can impact future costs and operational complexity.

自動化と運用の複雑さAutomation & operational complexity

自動化する必要がある頻繁に発生するプロセスを特定します。Identify frequently occurring processes that need automation.

  • 新しいテナントをオンボーディングする頻度はどれくらいですか。What is the frequency of onboarding new tenants? 各テナントを完全にオンボードするにはどのようなアクションが必要ですか。What actions are needed to fully onboard each one?
  • デプロイする必要がある新規または更新された Power BI コンテンツのリリース周期はどれくらいですか。What is the release cadence for new or updated Power BI content, that needs to be deployed?
  • 各テナントにはいくつの行レベル セキュリティ ロールが定義されていますか。How many row-level security roles are defined for each tenant?

これらのプロセスとその対処方法を明らかにすると、各モデルの管理に伴う運用の複雑さを理解するのに役立ちます。Identifying these processes and how you address them can help you understand the operational complexity involved in maintaining each model.

データ所在地の要件と複数の地域をサポートする必要性Data Residency Requirements and the need to support multiple geographies

Power BI Embedded では、Multi-Geo のデプロイ (プレビュー機能) がサポートされています。Power BI Embedded supports multi-geo deployment (preview feature). Multi-Geo を使用すると、Power BI Embedded のリソースを異なる複数のリージョンにデプロイし、特定のコンテンツを特定のリージョンに存在するように割り当てることができます。Multi-Geo enables Power BI Embedded resources to be deployed in different regions with specific content assigned to reside in specific regions. この機能はすべてのモデルで使用できますが、管理するコンテンツの量とコストに影響する場合があります。This feature can be used across all models, but can have an impact on the amount of content to manage and cost. 現在、Multi-Geo はデータ所在地要件を満たすために設計されており、コンシューマーの近くにデータを移動することによるパフォーマンスの向上は行われません。Currently multi-geo is designed for meeting data residency requirements and doesn't improve performance by moving data closer to consumers.

コストCost

Power BI Embedded の購入モデルは Power BI Premium のようなリソース ベースです。Power BI Embedded has a resource-based purchase model, like Power BI Premium. 固定のコンピューティング能力とメモリで 1 つまたは複数の容量を購入します。You purchase one or more capacities with fixed computing power and memory. この容量は、Power BI Embedded を使用するときの主なコスト項目です。This capacity is the main cost item when working with Power BI Embedded. 容量を使用するユーザーの数に制限はありません。There's no limit on the number of users using the capacity. 唯一の制限は、容量のパフォーマンスです。The only limit is the performance of the capacity. マスター ユーザーごと、または Power BI ポータルにアクセスする必要がある特定のユーザーごとに、Power BI Pro ライセンスが必要です。A Power BI Pro license is required for each master user, or specific users that need to access the Power BI portal.

ライブ環境と使用状況をシミュレートし、容量に対してロード テストを実行して、容量で予想される負荷をテストおよび測定することをお勧めします。We recommend testing and measuring the expected load on your capacity by simulating live environment and usage and run load testing on the capacity. Azure 容量または Premium 容量メトリック アプリで使用できるさまざまなメトリックで、負荷とパフォーマンスを測定できます。You can measure the load and performance with the various Metrics available in the Azure capacity or Premium capacity metrics app.

コンテンツのカスタマイズと作成Content customization and authoring

SaaS アプリケーションで、フローの一部としてレポートを編集および作成したり、、サービスにデータをアップロードしたりする機能をユーザーに提供するには、2 つのアプローチがあります。There are two approaches to SaaS applications that give users the ability to edit and create reports or upload data into the service as part of the flow:

  • 埋め込まれた iFrame での編集/作成モード - ユーザーは、SaaS アプリケーション内で、レポートを表示したり、新しい空白のキャンバスを作成したりします。Edit/Create mode in an embedded iFrame - The user gets a view of the report or a new blank canvas inside the SaaS application. この方法では、ユーザーは、Power BI ツール バーを使用し、ワークスペースでのデータセットに基づいてコンテンツを作成できます。This way they can use the Power BI toolbar to create content based on a dataset in the workspace. 使い慣れた環境でのユーザーのコンテキストなので、このオプションをお勧めします。We recommend this option since it’s in the user’s context in a familiar environment. 操作や編集を簡単に始めることができ、ユーザーが作成するレポートは既存のデータセットに関連付けられます。It’s easier to get started working and editing, and the user creates a report attached to an existing dataset.

  • Power BI Desktop を使用してコンテンツを作成し、SaaS アプリケーションの UI を使用してそれをワークスペースにアップロードします。Use Power BI Desktop to create content and upload it through the SaaS application UI to the workspace. このアプローチの方が、ユーザーが Power BI Desktop で使用できるツールは豊富です。In this approach, users have more tools to work with using the Power BI Desktop. ただし、ユーザーは SaaS アプリケーションのコンテキスト外で別のツールを理解する必要があるため、このアプローチはお勧めしません。However, we do not recommend this approach since users need to be familiar with an additional tool outside of the SaaS application context. PBIX ファイルをアップロードするということはデータセットを追加することを意味し、既にワークスペースにあるデータセットと重複する可能性があります。Uploading a PBIX file means the user is adding an additional dataset, that might be a duplicate of datasets already in the workspace.

Power BI ワークスペースに基づく分離Power BI workspace-based isolation

Power BI ワークスペースに基づく分離では、1 つの Power BI テナントからの複数のテナントが SaaS アプリケーションでサポートされます。With Power BI workspace-based isolation, the SaaS application supports multiple tenants from a single Power BI tenant. ワークスペースに基づく分離には、異なるテナントで使用されるすべての Power BI コンテンツが含まれます。Workspace-based isolation contains all the Power BI content that different tenants use. テナントの分離は、複数のワークスペースを作成することにより、Power BI ワークスペースのレベルで実現されます。The separation of tenants is done at the Power BI workspace level, by creating multiple workspaces. 各ワークスペースには、そのテナントの関連するデータセット、レポート、およびダッシュボードが含まれています。Each workspace contains the relevant datasets, reports, and dashboards for that tenant. また、各ワークスペースは、そのテナントのデータにのみ接続されます。Also, each workspace is connected only to that tenant’s data. さらに分離が必要な場合は、ワークスペースとそのコンテンツごとに、"マスター" ユーザーまたはサービス プリンシパルを作成できます。If you need additional isolation, you can create a master user or a service principal for each workspace and its content.

ワークスペース

データのアーキテクチャData architecture

テナントのデータを管理するには 2 つの主な方法があります。There are two main approaches to manage tenant’s data.

  • テナントごとに個別のデータベースA separate database per tenant
  • 1 つのマルチテナント データベースA single multi-tenant database

SaaS アプリケーションのストレージでテナントごとに個別のデータベースが保持されている場合の、Power BI での自然な選択は、シングルテナント データセットと、データセットごとに対応するデータベースを指す接続文字列を使用することです。If the SaaS application storage is keeping a separate database per tenant, then the natural choice is to use single-tenant datasets in Power BI with the connection string for each dataset pointing to the matching database.

SaaS アプリケーションのストレージで、すべてのテナントについてマルチテナント データベースが使用されている場合は、ワークスペースによってテナントを簡単に分離できます。If the SaaS application storage is using a multi-tenancy database for all tenants, it’s easy to separate tenants by workspace. 関連するテナントのデータのみを取得するパラメーター化されたデータベース クエリを使用して、Power BI のデータセットに対するデータベース接続を構成できます。You can configure the database connection for the Power BI dataset with a parameterized database query that only retrieves the relevant tenant’s data. Power BI Desktop を使用するか、またはクエリで APIパラメーターを使用して、接続を更新できます。You can update the connection using the Power BI Desktop or using the API with parameters on the query.

データの分離Data isolation

このテナント モデルのデータは、ワークスペース レベルで分離されます。Data in this tenancy model is separated at the workspace level. ワークスペースとテナントの間の簡単なマッピングにより、あるテナントのユーザーから別のテナントのコンテンツを見ることができないようにします。A simple mapping between a workspace and a tenant prevents users from one tenant seeing content from another tenant. 1 つの "マスター" ユーザーを使用するには、すべての異なるワークスペースに対するアクセス権を持っている必要があります。Using a single master user demands you to have access to all the different workspaces. エンド ユーザーに表示するデータの構成は、埋め込みトークンの生成、エンド ユーザーが見ることのできないバックエンド専用プロセスで、または変更の間に定義されます。The configuration of which data to show an end user is defined during the generation of the embed token, a backend-only process which end users can’t see, or change.

分離を強化するには、アプリケーション開発者は、複数のワークスペースにアクセスできる "マスター" ユーザーまたはアプリケーションではなく、アプリケーションごとの "マスター" ユーザーまたはワークスペースを定義できます。To add additional isolation, an application developer can define a master user or an application per workspace rather than a single master user or application with access to multiple workspaces. これにより、ヒューマン エラーまたは資格情報のリークが発生しても、複数の顧客のデータが漏えいしないようにできます。This way, you can ensure that any human error or credential leak does not cause multiple customers' data to be exposed.

スケーラビリティScalability

このモデルの利点の 1 つは、テナントごとの複数のデータセットにデータを分離することで、単一データセットのサイズ制限 (現在、容量 10 GB) が適用されないことです。One advantage of this model is that separating the data into multiple datasets for each tenant overcomes the size limits of a single dataset (currently 10 GB in a capacity). 容量がオーバーロードになったら、未使用のデータセットを削除して、アクティブなデータセットのためにメモリを解放できます。When the capacity is overloaded, it can evict unused datasets to free memory for active datasets. 1 つの大規模なデータセットでは、このようなことはできません。This task isn't possible with a single large dataset. 複数のデータセットを使用すると、必要に応じて、複数の Power BI 容量にテナントを分離することもできます。Using multiple datasets, it is also possible to separate tenants into multiple Power BI capacities if needed.

このような利点はありますが、将来的に SaaS アプリケーションが達する可能性のあるスケールを考慮する必要があります。Despite these advantages, one must consider the scale that the SaaS application can reach in the future. たとえば、管理できる成果物の数に関する制限に到達する可能性があります。For example, one might reach limitations around the number of artifacts one can manage. 詳細については、この記事で後述されているデプロイに関する制限をご覧ください。See deployment limitations later in this article for more details. 使用されている容量 SKU により、データセットが収まる必要のあるメモリのサイズ、同時に実行できる更新の数、データ更新の最大頻度についての制限が適用されます。The capacity SKU used introduces a limit on the size of memory that datasets need to fit in, how many refreshes can run at the same time and the maximum frequency of data refreshes. 数百または数千のデータセットを管理するときは、テストすることをお勧めします。It's recommended to test when managing hundreds or thousands of datasets. また、平均とピーク時の使用量、および他のテナントとは管理が異なる大きいデータセットを持つ特定のテナントや使用パターンが異なるテナントについて、考慮することをお勧めします。It is also recommended to consider the average and peak volume of usage, as well as any specific tenants with large datasets, or different usage patterns, that are managed differently than other tenants.

自動化と運用の複雑さAutomation & operational complexity

Power BI ワークスペースに基づく分離では、アプリケーション開発者は、数百または何千もの成果物を管理することが必要な場合があります。With Power BI workspace-based isolation, an application developer might need to manage hundreds or thousands of artifacts. アプリケーションのライフサイクル管理で頻繁に発生するプロセスを定義し、このテナント モデルで大規模にこれらの操作を実行するための適切なツール セットがあることを確認することが不可欠です。It’s essential to define the processes that frequently happen in your application lifecycle management, and ensure you have the right set of tools to perform these operations at scale in this tenancy model. 操作の例を次に示します。Some example operations include:

  • 新しいテナント (顧客) の追加Adding a new tenant (customer)
  • 一部または全部のテナントのレポートまたはダッシュボードの更新Updating a report or dashboard for some or all the tenants
  • 一部または全部のテナントのデータ セット スキーマの更新Updating the dataset schema for some or all the tenants
  • 特定のテナントの計画外のカスタマイズUnplanned customizations for specific tenants
  • データセットの更新の頻度Frequency of dataset refreshes

たとえば、新しいテナント用のワークスペースの作成は、自動化を必要とする一般的なタスクです。For example, creating a workspace for a new tenant is a common task, which needs automation. Power BI REST API を使用すると、ワークスペース作成時の完全な自動化を実現できます。With the Power BI REST API, you can achieve full automation when creating workspaces.

Multi-Geo のニーズMulti-Geo needs

Multi-Geo では、目的のリージョンで容量を購入し、その容量にワークスペースを割り当てる必要があります。Multi-geo involves purchasing capacity in the desired regions and assigning a workspace to that capacity. 異なるリージョンで異なるテナントをサポートする必要がある場合は、目的のリージョンで容量にテナントのワークスペースを割り当てる必要があります。If you need to support different tenants in different regions, you need to assign the tenant’s workspace to a capacity in the desired region. このタスクは単純な操作であり、コストは多くても同じ容量にすべてのワークスペースを割り当てる分だけです。This task is a simple operation and one where the cost is not more than having all workspaces in the same capacity. ただし、複数のリージョンにデータを置く必要があるテナントの場合は、ワークスペース内のすべての成果物を各リージョンの容量に複製する必要があり、コストと管理の複雑さの両方が増します。However, if you have tenants that need data resident in multiple regions, all artifacts in the workspace need to be duplicated in each regional capacity, increasing both cost and management complexity.

コストCost

Power BI Embedded を使用するアプリケーション開発者は、運用のための Power BI Embedded 容量を購入する必要があります。Application developers using Power BI Embedded need to purchase Power BI Embedded capacity to go to production. ワークスペースに基づく分離モデルの影響および容量に対するその影響を理解しておく必要があります。It’s important to understand the impact of workspace-based isolation model and their effect on capacities.

ワークスペースに基づく分離モデルは、次の理由で容量に適しています。The workspace-based isolation model sits well with capacities for the following reasons:

  • 容量に独立して割り当てることができる最小のオブジェクトはワークスペースなので (つまり、たとえばレポートを割り当てることはできません)、ワークスペースでテナントを分離すると、最大限の柔軟性で、各テナントとそのパフォーマンスのニーズを管理し、スケールアップ/スケールダウンによって容量の使用を最適化できます。The smallest object you can independently assign to a capacity is a workspace that is, you can’t assign a report, for example), so by separating tenants by workspaces, you get full flexibility in managing each tenant and its performance needs, and optimizing capacity utilization by scaling up/down. たとえば、量が多くて揮発性の高い大規模で重要なテナントは独立した容量で管理することにより一貫したサービス レベルを保証する一方で、小規模なテナントは別の容量にグループ化してコストを最適化できます。For example, large and essential tenants with high volume and volatility can be managed in a separate capacity to ensure a consistent service level, while grouping smaller tenants in another capacity to optimize costs.

  • ワークスペースを分離することは、データセットをテナント間で分離することにより、1 つの大規模なデータセットを使用するのではなく、データ モデルを小さなチャンクにできることも意味にします。Separating workspaces also means separating datasets between tenants so that data models can be in smaller chunks, rather than in a single large dataset. このタスクにより、容量でのメモリの使用をいっそう適切に管理でき、必要のない小さな未使用のデータセットを削除しながら、ユーザーが満足するパフォーマンスを維持できます。This task allows the capacity to manage memory usage better, evicting small, and unused datasets when not needed, while keeping users satisfied with the performance.

複数のデータセットがある場合、更新プロセスで余分な容量が必要になることがあるので、アプリケーション開発者は並列更新の数に対する制限を考慮する必要があります。Application developers need to consider the limit on the number of parallel refreshes, as refresh processes might need extra capacity when you have multiple datasets.

コンテンツのカスタマイズと作成Content customization and authoring

コンテンツ作成の基本的なユース ケースの場合、アプリケーション開発者は、編集機能を持つことができるテナントと、各テナントで編集を行うことができるユーザーの数を、慎重に検討する必要があります。For the primary use cases of content creation, the application developer needs to carefully consider which tenants can have editing capabilities, and how many users in each tenant can edit. 各テナントで複数のユーザーに編集を許可すると、多くのコンテンツが生成される場合があり、データセットごとのレポートの数や、ワークスペース内のデータセットの数など、データセットの制限に達する可能性があります。Permitting multiple users in each tenant to edit can result in many contents being generated, that can reach a dataset limitation such as the number of reports per dataset, or the number of datasets in a workspace. この機能をユーザーに付与する場合は、コンテンツの生成をよく監視し、必要に応じてスケールアップすることをお勧めします。If you give users this capability, we recommend monitoring the content generation closely and scale up as needed. 同じ理由から、コンテンツの個人設定にはこの機能を使用しないことをお勧めします。この場合、各ユーザーがレポートに小さな変更を行って、自分用に保存する可能性があります。For the same reasons, we don’t recommend using this capability for content personalization, where each user can make small changes to a report and save it for themselves. SaaS アプリケーションでコンテンツの個人設定を許可する場合は、ユーザー固有のコンテンツに対するワークスペース保持ポリシーを導入して通知し、エンド ユーザーが異動したり、退職したり、プラットフォームを使用しなくなったりしたときの、コンテンツ削除のフローを容易にすることを検討します。If the SaaS application allows content personalization, consider introducing and communicating workspace retention policies for user-specific content to facilitate the flow of content deletion when end users move to a new position, leaving the company or not using the platform anymore.

行レベルのセキュリティに基づく分離Row-level security-based isolation

行レベルのセキュリティに基づく分離の場合、SaaS アプリケーションでは 1 つのワークスペースを使用して複数のテナントがホストされます。With row-level security-based isolation, the SaaS application uses a single workspace to host multiple tenants. つまり、各 Power BI 成果物のレポート、ダッシュボード、データセットは 1 回だけ作成され、すべてのテナントによって使用されます。It means each Power BI artifact report, dashboard, & dataset, is created once all tenants use it. テナント間のデータの分離は、マルチテナント データセットでの行レベルのセキュリティを使用して実現されます。Data separation between tenants is accomplished using row-level security on the multi-tenant dataset. エンド ユーザーが SaaS アプリケーションにログインしてコンテンツを開くと、そのユーザーのセッションに対して埋め込みトークンが生成され、ロールとフィルターにより、見ることを許可されたデータだけをユーザーが表示できることが保証されます。When end users log into the SaaS application and open content, an Embed token is generated for that user’s session, with the roles and filters that ensure the user only sees the data they are permitted to see. 同じテナントの異なるユーザーが同じデータを表示できないようにする場合は、アプリケーション開発者は、テナント間および同じテナント内の両方に、階層的なロールを実装する必要があります。If users from the same tenant are not permitted to view the same data, the application developer needs to implement hierarchical roles both between tenants and within the same tenant.

行レベルのセキュリティ

データのアーキテクチャData architecture

行レベルのセキュリティに基づく分離の実装は、すべてのテナントのデータが 1 つのデータ ウェアハウスに格納されている場合に最も簡単です。Implementing row-level security-based isolation is most comfortable when all tenants’ data is stored in a single data warehouse. この場合、アプリケーション開発者は、DirectQuery またはデータのインポートを使用して、データ ウェアハウスから Power BI のデータセットに関連するデータのみを渡すことができます。In this case, the application developer can pass only the relevant data from the data warehouse into the Power BI dataset, either via Direct Query or data import. データベース内のデータがテナントごとに分かれている場合は、1 つのデータセットに結合する必要があり、データベース内に存在するテナント間の分離が低下します。If data in the database is separated per tenant, it needs to be combined into a single dataset, which results in a lower degree of separation between tenants that existed in the database.

データの分離Data isolation

行レベルのセキュリティに基づく分離では、データの分離はデータセットでの行レベルのセキュリティの定義を使用して実現され、これはすべてのデータが共存することを意味します。With row-level security-based isolation, data separation is accomplished using row-level security definitions on the dataset, which means all the data coexist. この形式のデータの分離では、開発者のエラーによりデータの漏えいが発生しやすくなります。This form of data separation is more susceptible to data leakage through developer error. 行レベルのセキュリティはバックエンドで行われ、エンド ユーザーからセキュリティで保護されますが、データの機密性が高い場合、または顧客がデータの分離を要求している場合は、ワークスペースに基づく分離を使用する方がよい場合があります。Even though row-level security is done on the backend and secured from an end user, if the data is highly sensitive or customers are asking for data separation, it might be better to use workspace-based isolation.

スケーラビリティScalability

行レベルのセキュリティに基づく分離では、データがデータセットのサイズ制限 (現在は 10 GB) に収まる必要があります。With row-level security-based isolation, the data needs to fit within the dataset size limit, which is currently 10 GB. 増分更新の導入と、予定されている Power BI データセット向け XMLA エンドポイントのリリースにより、データセットのサイズの制限は大幅に増える予定です。With the introduction of incremental refresh and the upcoming release of an XMLA endpoint for Power BI datasets, the dataset size limit is expected to increase significantly. ただし、その場合でも、データは、データ更新を実行するのに十分なメモリを残して、容量のメモリに収まる必要があります。However, the data still needs to fit into the capacity’s memory, with enough remaining memory for data refreshes to run. 大規模なデプロイでは、現在の容量の制限をメモリが超過することでユーザーに対する問題が発生しないように、大きい容量を使用する必要があります。Large-scale deployments need a large capacity to avoid users experiencing issues due to memory exceeding the limits of the current capacity. スケールを処理する別の方法としては、Power BI の容量にすべてのデータをキャッシュするのではなく、 集計 を使用したり、DirectQuery やライブ接続を使用してデータ ソースに直接接続したりすることができます。Alternative ways to handle scale include using aggregations or connecting to the data source directly using DirectQuery or Live connection, rather than caching all the data in the Power BI capacity.

自動化と運用の複雑さAutomation & operational complexity

成果物の管理は、ワークスペースに基づく分離より、行レベルのセキュリティに基づく分離を使用する方がはるかに容易です。これは、テナントごとにバージョンが存在するのではなく、環境 (開発/テスト/運用) ごとに成果物のバージョンが 1 つだけであるためです。Managing artifacts is far more comfortable using row-level security-based isolation than with workspace-based isolation as there is only one version of an artifact for each environment (dev/test/production), instead of a version per tenant. 大規模な環境では、成果物を管理するということは、数千や数万ではなく、数十の成果物を管理および更新することを意味します。At a large scale, managing artifacts means managing and updating tens of artifacts, rather than thousands to ten-thousands.

Power BI には、RLS のロールやルールを変更または作成するための API はまだありません。Power BI doesn’t yet have an API to modify or create RLS roles and rules. ロールの追加または変更は、Power BI Desktop で手動によってのみ行うことができます。Adding or changing roles can only be done manually in the Power BI Desktop. RLS の階層を適用する必要がある場合、慎重に計画しないと、複雑でエラーが発生しやすくなります。If an RLS hierarchy needs to be applied, it can be complicated and error-prone to manage if you don't plan it carefully.

頻繁な作成または更新が必要な多くのロールとロール定義を管理する必要がある場合、行レベルのセキュリティに基づく分離は、管理しやすさの観点からはスケーラブルではありません。If the application developer needs to manage many roles and role definitions that need to be created or updated frequently, row-level security-based isolation isn't scalable, from a manageability perspective.

運用面でのもう 1 つの複雑さは、メモリの使用状況を細かく監視し、ユーザーのエクスペリエンスが円滑になるように、アラートとスケーリングの堅牢なメカニズムを構築する必要があることです。Another operational complexity is the need to closely monitor memory utilization and build a robust mechanism of alerts and scaling to ensure users get a smooth experience.

Multi-Geo のニーズMulti-Geo needs

すべてのデータが 1 つのデータセットに格納されるため、特定の場所に特定のデータをバインドする必要があるデータ所在地の要件を満たすことは困難です。Since all the data is stored in a single dataset, it is challenging to meet data residency requirements that require certain data to be bound to specific locations. また、すべてのデータが各リージョンにレプリケートされて格納されるため、複数のリージョンを使用するとコストも大幅に増加します。It can also significantly increase the cost of using multiple regions as all the data is replicated and stored in each region. 地理的に異なる場所に置く必要があるテナントの数が限られている場合は、上で説明したワークスペースに基づく分離モデルを使用して、それらのテナントのデータだけを異なるリージョンで保持することができます。If only a limited number of tenants need different geographies, you can keep only those tenants’ data in a different region, using the workspace-based isolation model described above.

コストCost

行レベルのセキュリティに基づく分離での主要なコスト要因は、データセットのメモリ占有領域です。The primary cost driver with row-level security-based isolation is the memory footprint of the dataset. データセットを格納し、メモリ需要のピークのための追加メモリ バッファーを保持するのに十分な容量が必要です。You need enough capacity to store the dataset and keep some additional memory buffer for any peaks in memory demand. このような状況を緩和する方法の 1 つは、SQL Server データベースまたは SQL Server Analysis Services キューブにデータを格納し、DirectQuery またはライブ接続を使用して、データ ソースからリアルタイムにデータを取得することです。One way to mitigate this situation is to store the data in a SQL Server database or SQL Server Analysis Services cube and using Direct Query or a Live connection to retrieve the data from the data source in real time. この方法では、データ ソースのコストは増加しますが、メモリのニーズのために容量を大きくする必要性は低下するため、Power BI の容量のコストは減ります。This approach increases the cost of the data sources, but reduces the need for large capacity because of memory needs, hence reducing the cost of Power BI capacity.

コンテンツのカスタマイズと作成Content customization and authoring

エンド ユーザーは、レポートを編集または作成するとき、運用環境のマルチテナント データセットを使用できます。As end users edit or create reports, they can use the production multi-tenant dataset. そのため、レポートの作成または編集には、埋め込み iFrame のオプションだけを使用することをお勧めします。そうすれば、行レベルのセキュリティが適用された同じデータセットに依存できます。For that reason, we advise only using the embedded iFrame option to edit or create reports, as it relies on the same dataset, with row-level security applied. ユーザーに追加のデータセットを含む PBIX ファイルをアップロードさせると、コストがかかり、行レベルのセキュリティに基づく分離を使用した管理が難しくなる場合があります。Having users uploading PBIX files with additional datasets can be costly and difficult to manage with row-level security-based isolation. また、ユーザーが同じワークスペース内で新しいコンテンツを生成するときは、運用ワークスペースが制限に達しないことを確認し、どのコンテンツがどのテナントに接続されているかを区別するための堅牢なメカニズムを構築する必要があります。Also, when users generate new content that is in the same workspace, you need to make sure the production workspace doesn't hit its limits and build a robust mechanism to distinguish which content is connected to which tenant.

各種アプローチの概要の比較Summary comparison of the different approaches

重要

以下の分析は、製品の現在の状態に基づくものです。The following analysis is based on the current state of the product. 毎月新しい機能をリリースすることで、新しい機能の提供と既存の制限や脆弱なスポットへの対応を続けています。As we are releasing new features on a monthly cadence, we continue to provide new capabilities and features that answer existing limitations and weak spots. 毎月のブログ投稿を見て新機能を確認した後、この記事に戻って、テナント モデルの推奨事項に対する新機能の影響を確認してください。Make sure to check our monthly blog posts to see what’s new and come back to this article to see how new features affect the tenancy model recommendation.

評価基準Evaluation Criteria ワークスペース ベースWorkspace-based 行レベルのセキュリティ ベースRow-level security-based
データのアーキテクチャData architecture テナントごとに個別のデータベースがある場合に最も簡単Easiest when there's a separate database per tenant すべてのテナントのすべてのデータが 1 つのデータ ウェアハウス内にある場合に最も簡単Easiest when all the data for all tenants are in a single data warehouse
データの分離Data isolation 良い。Good. テナントごとに専用のデータセットがある。Each tenant has a dedicated dataset. 中程度。Moderate. すべてのデータが同じ共有データセット内にあるが、アクセス制御によって管理される。All data is in the same shared dataset but managed through access-control.
スケーラビリティScalability 中。Medium. データを複数のデータセットに分割することで最適化が可能。Breaking the data into multiple datasets enables optimization. 最低。Lowest. データセットの制限によって制約される。Constrained by dataset limits.
Multi-Geo のニーズMulti-Geo needs ほとんどのテナントが 1 つのリージョンのみに存在するときに好適。Good fit when most tenants are only in one region. 非推奨。Not recommended. データセット全体を複数のリージョンに格納しておく必要がある。Needs to keep the entire dataset stored in multiple regions.
自動化と運用の複雑さAutomation & operational complexity 個々のテナントに対して良好な自動化。Good automation for the individual tenant. 大規模な多数の成果物の管理が複雑。Complex to manage many artifacts at scale. Power BI 成果物の管理は容易だが、大規模な RLS の管理は複雑。Easy to manage Power BI artifacts but complex to manage RLS at scale.
コストCost 低から中。Low-medium. 使用を最適化して、テナントあたりのコストを削減できる。Can optimize utilization to reduce cost-per-tenant. 頻繁な更新が必要なときは増えることがある。Might increase when frequent refreshes are needed. インポート モードを使用する場合は、中から高。Medium- high if using Import mode. DirectQuery モードを使用する場合は、低から中。Low- medium if using Direct Query mode.
コンテンツのカスタマイズと作成Content customization and authoring 好適。Good fit. 大きな規模では制限に達する可能性がある。Might hit limitations at large scale. 埋め込み iFrame でのみコンテンツを生成Content generation in embedded iFrame only

デプロイに関する考慮事項と制限事項Deployment considerations and limitations

Power BI の成果物の制限:Power BI Artifact limits:

  • 1 人のユーザーまたは 1 つのアプリケーションがメンバー/管理者になることのできるワークスペース V1 (グループ) の数は、250 です。The number of workspaces V1 (groups) that a single user/application can be a member/admin of is 250.
  • 1 人のユーザーまたは 1 つのアプリケーションがメンバー/管理者になることのできるワークスペース V2 (フォルダー) の数は、1,000 です。The number of workspaces V2 (folders) that a single user/application can be a member/admin of is 1000.
  • 1 つのワークスペース内のデータセットの数は、1,000 です。The number of datasets in a single workspace is 1000.
  • 1 つのデータセットに接続されるレポート/ダッシュ ボードの数は、1,000 です。The number of reports/dashboards connected to a single dataset is 1000.
  • .pbix ファイルをアップロードするためのデータセット メモリ サイズの制限は、10 GB です。The dataset memory size limit to upload a .pbix file is 10 GB.

Power BI の容量に関する考慮事項と制限事項:Power BI Capacity considerations and limitations:

  • 各容量では、購入した SKU に従って、割り当てられているメモリと仮想コアのみを使用できます。Each capacity can only use its allocated memory and V-cores, according to the SKU purchased.
  • 各 SKU に対して推奨されるデータセットのサイズについては、Premium の大規模なデータセットに関する記事をご覧ください。For the recommended dataset size for each SKU, reference Premium large datasets.
  • 専用容量でのデータセットの最大サイズは、10 GB です。The max dataset size in a dedicated capacity is 10 GB.
  • "インポート モード" のデータセットで 1 日にスケジュールできる更新の数は、48 です。The number of scheduled refreshes for an import mode dataset in a day is 48.
  • "インポート モード" のデータセットでスケジュールされた更新の間隔は、30 分です。The time between scheduled refreshes for an import mode dataset is 30 minutes.
  • 容量に対して同時に実行できる更新の数については、リソースの管理と最適化に関する記事をご覧ください。For the number of refreshes that can run concurrently on a capacity, reference resource management and optimization.
  • 容量のスケーリングの平均時間は、1 ~ 2 分です。The average time of scaling a capacity is between 1-2 minutes. その間、容量は使用できません。During that time, the capacity isn't available. ダウンタイムを回避するため、スケールアウト アプローチを使用することをお勧めします。We recommend using a scale-out approach to avoid downtime.

次の手順Next steps