Power BI Premium のアーキテクチャ
Premium でのアーキテクチャの変更 (特に、CPU リソースの割り当ておよび使用方法に関する変更) により、オファリングにおける汎用性やライセンス モデルにおける柔軟性の向上が可能になります。 たとえば、この新しいアーキテクチャにより、Premium をユーザーごとに Premium Per User として提供することができます。 このアーキテクチャはまた、顧客により高いパフォーマンスを提供すると共に、その Power BI の経費に対するガバナンスや制御も向上させることができます。
Premium のアーキテクチャでの最も重要な更新は、容量の仮想コアの実装方法です。
Power BI Premium の元のバージョンでは、顧客のライセンス SKU に応じ仮想コアの数やオンボード メモリの量が異なる、クラウド内の予約済みの物理コンピューティング ノードが、仮想コアでした。 顧客管理者は、Premium Metrics アプリを使用して、これらのノードのビジー状態を追跡する必要がありました。 これらの管理者は、このアプリやその他のツールを使用して、ユーザーのコンピューティング ニーズを満たすために必要な容量を決定する必要がありました。
Premium では、仮想コアは、クラウド内の物理ノードのリージョン クラスターに実装されます。これは、その Power BI リージョン内の Premium 容量を使用しているすべてのテナントによって共有されます。 このリージョン クラスターはさらに、各グループが異なる Power BI ワークロード (セマンティック モデル、データフロー、またはページ分割されたレポート) を処理する特殊なノード グループに分割されます。 これらの特殊なノード グループは、同じノードで実行されている基本的に異なるワークロード間のリソース競合を回避するために役立ちます。
注意
Power BI Premium を使用すると、さまざまな顧客間でデータの論理的な分離が行われるとともに、ISO 27017 に準拠します。 詳細については、ISO/IEC 27017:2015 を参照してください。
管理者は容量のワークロード設定を調整して構成できます。 これを使用すると、ワークロード (セマンティック モデル、データフロー、ページ分割されたレポート、AI) 間のリソースの競合を減らし、容量の使用パターンに基づいてメモリの制限やタイムアウトなど、その他の設定を調整できます。
Premium 容量に割り当てられているワークスペースのコンテンツは、組織の容量のストレージ層に格納されます。これは、Premium の元のバージョンと同様に、容量固有の Azure Storage BLOB コンテナー上に実装されます。 このアプローチにより、BYOK などの機能をデータに使用できるようになります。
コンテンツの表示または更新が必要になると、そのコンテンツがストレージ層から読み取られ、コンピューティングのために Premium ノードに配置されます。 Power BI では、コンピューティング ノードの適切なグループ内の最適なノードが選択されることを保証する配置メカニズムを使用します。 このメカニズムでは通常、最も多いリソースへのアクセスを取得することによって表示または更新操作を最適に実行できるように、新しいコンテンツを、そのコンテンツが読み込まれた時点で使用可能なメモリが最も多いノードに配置します。
容量でより多くのコンテンツがレンダリングされ更新されるようになると、それぞれが操作を迅速かつ正常に完了できるだけの十分なリソースが持つ、より多くの計算ノードが使用されるようになります。 これはご自分の容量で、複数の計算ノードが使用される場合があることを意味し、場合によっては Power BI サービスがノードまたはリソース間で内部の負荷分散を行うために、ノード間でコンテンツを移動することさえあります。 このような負荷分散が実行される場合、Power BI では、コンテンツの移動がエンドユーザー エクスペリエンスに影響を与えないようにします。
コンテンツ (セマンティック モデル、データフロー、ページ分割されたレポート、その他のワークロード) の処理を複数のノードに分散することで、いくつかの良い結果が得られます。
共有ノードは、少なくとも元の Premium P3 ノードと同じ大きさです。つまり、どの操作を実行するにもより多くの仮想コアが存在するため、元の Premium P1 と比較した場合、パフォーマンスが最大 16 倍に向上する可能性があります。
ユーザーの処理がどのノードで実行されている場合でも、この配置メカニズムでは、該当する容量のメモリ制約内で、メモリがユーザーの操作を完了できる状態に維持されることが保証されます。 (メモリ制約の詳細については、このドキュメントの制限事項のセクションを参照)。
ワークロード間のリソース競合は、共有ノードを特殊なワークロード グループに分離することによって防止されます。 この分離の結果、ページ分割されたレポート ワークロードを制御できなくなります。
さまざまな容量 SKU に対する制限は、Premium の元のバージョンのときのような物理的な制約に基づいているわけではなく、Power BI Premium サービスで適用される、予測される明確な一連のルールに基づいています。
合計容量の CPU スループットは、ユーザーが購入した容量に含まれている仮想コアで可能なスループット以下になります。
表示および更新操作に必要なメモリ消費量は、ユーザーが購入した容量のメモリ制限内に維持されます。
この新しいアーキテクチャのため、顧客管理者はその容量を監視してリソースの制限に近づいている兆候がないかどうかを確認する必要はなく、代わりに、このような制限が満たされたときには明確な兆候が提供されます。 これにより、最適な容量パフォーマンスを維持するために容量管理者に必要になる労力やオーバーヘッドが大幅に削減されます。
関連するコンテンツ
他にわからないことがある場合は、 Power BI コミュニティで質問してみてください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示