Microsoft Fabric 導入ロードマップ: システム監視

[アーティクル]
11/24/2023

Note

この記事は、"Microsoft Fabric 導入ロードマップ" シリーズ記事の一部です。シリーズの概要については、「Microsoft Fabric 導入ロードマップ」を参照してください。

システム監視 (Fabric 管理とも呼ばれます) は、継続的で日常的な管理アクティビティです。具体的には、次のことに関係します。

ガバナンス: ガバナンスのガイドラインとポリシーを施行して、セルフサービスおよびエンタープライズのデータおよびビジネスインテリジェンス (BI) のシナリオをサポートします。
ユーザーエンパワーメント: 内部のユーザーコミュニティに可能な限り権限を与える内部のプロセスとシステムの実現を促進してサポートするのと同時に、組織の規制や要件に準拠します。
導入: 効果的なガバナンスとデータ管理の実施により、Fabric をより幅広く組織的に導入できるようにします。

重要

組織のデータカルチャの目標は、ガバナンスに関する意思決定の方向性を提供することです。これによって、Fabric 管理のアクティビティがどのように、誰によって行われるかが決まります。

システム監視は広範囲で奥深いトピックです。この記事の目的は、組織的導入という目的を成功に導くうえで役立つ、最も重要な考慮事項とアクションをいくつか紹介することです。

Fabric 管理者

Fabric 管理者ロールは、Microsoft 365 で定義されているロールで、管理アクティビティのサブセットを委任するものです。 Microsoft 365 のグローバル管理者は、暗黙的に Fabric 管理者です。 Power Platform 管理者は、暗黙的に Fabric 管理者でもあります。

ガバナンスに関する重要な決定事項は、誰を Fabric 管理者として割り当てるかです。これは、テナント全体に影響を及ぼす一元化されたロールです。理想的なのは、Fabric を管理することができる人が組織内に 2-4 人いる状態です。管理者は、センターオブエクセレンス (COE) と緊密に連携する必要があります。

高い特権を持つロール

Fabric 管理者ロールは、以下の理由で、高い特権を持つロールです。

ユーザーエクスペリエンス: Fabric 管理者によって管理される設定は、ユーザー機能とユーザーエクスペリエンスに大きな影響を及ぼします。詳細については、「テナント設定の管理」を参照してください。
完全なセキュリティアクセス: Fabric 管理者は、テナント内のワークスペースのアクセス許可を更新できます。その結果、管理者は、適切と思われるときに、データやレポートを表示またはダウンロードするためのアクセス許可を付与できます。詳細については、「テナント設定の管理」を参照してください。
個人用ワークスペースへのアクセス:Fabric 管理者はコンテンツにアクセスし、任意のユーザーの個人用ワークスペースを管理できます。
メタデータ: Fabric 管理者は、Fabric ポータルで発生するすべてのユーザーアクティビティを含め、すべてのテナントメタデータを (下の監査と監視に関するセクションで説明するように) 表示できます。

重要

Fabric 管理者が多すぎることは、リスクとなります。承認されない、意図しない、または一貫性のないテナントの管理が発生する可能性が高くなります。

ロールと責任

管理者が日常的に行うアクティビティの種類は、組織によって異なります。何が重要であるかと、データカルチャにおける所定の優先順位が、ビジネス主導のセルフサービス、管理されたセルフサービス、エンタープライズのデータおよび BI のシナリオをサポートするために管理者が実行する作業内容に大きく影響を及ぼします。詳細については、「コンテンツの所有権と管理」の記事を参照してください。

ヒント

Fabric 管理者としての役目を果たすのに最適な種類の人は、セルフサービスユーザーが何を達成する必要があるかを理解するためにツールとワークロードに関する十分な知識を持っている人です。この知識を活かして、管理者はユーザーのエンパワーメントとガバナンスのバランスを取ることができます。

Fabric 管理者に加えて、"管理者" という用語を使用するロールが他にもあります。次の表で、通常、決まって使用されるロールについて説明します。

Role	スコープ	説明
Fabric 管理者	テナント	Fabric ポータルでテナント設定とその他の設定を管理します。この記事での "管理者" への一般的な参照はすべて、この種類の管理者を指しています。
容量管理者	1 つの容量	ワークスペースとワークロードを管理し、Fabric 容量の正常性を監視します。
データゲートウェイ管理者	1 つのゲートウェイ	ゲートウェイデータソースの構成、資格情報、ユーザーの割り当てを管理します。ゲートウェイのソフトウェア更新プログラムを扱うこともあります (または、更新に関してインフラストラクチャチームと共同作業を行います)。
ワークスペース管理者	1 つのワークスペース	ワークスペースの設定とアクセスを管理します。

ワークロードの Fabric エコシステムは、広範で深さがあるものです。 Fabric を他のシステムやプラットフォームと統合する方法は多数あります。時折、他の管理者や IT プロフェッショナルと共同作業する必要が生じます。詳細については、「他の管理者との共同作業」を参照してください。

この記事の残りの部分では、Fabric 管理者が行う最も一般的なアクティビティの概要を説明します。組織的導入に対して戦略的アプローチを実施する場合に、効果的に実行することが重要であるアクティビティに焦点を当てます。

サービス管理

テナントを監視することは、すべてのユーザーが Power BI の良好なエクスペリエンスを得られるようにするための重要な側面です。 Fabric 管理者が受け持つ主要なガバナンス責任には、次のようなものがあります。

テナント設定: どの Power BI 機能を、組織内のどのユーザーグループに対して有効にするかを制御します。
ドメイン: 同様の特性を持つ 2 つ以上のワークスペースをグループ化します。
ワークスペース: テナント内のワークスペースを確認および管理します。
埋め込みコード: どのレポートがインターネット上で一般公開されているかを管理します。
組織のビジュアル: 組織のビジュアルを登録および管理します。
Azure 接続: Azure サービスと統合して追加の機能を提供します。

詳細については、テナント管理に関するページを参照してください。

ユーザーのマシンやデバイス

Fabric の導入は、コンテンツ作成者とコンシューマーが必要なツールとアプリケーションを持っているかどうかに直接左右されます。考慮すべきいくつかの重要な質問を次に示します。

ユーザーはどのような方法で新しいツールへのアクセスを要求しますか? ライセンス、データ、トレーニングへのアクセスは、ユーザーがツールを効果的に使用するのに役立ちますか?
他のユーザーによって公開されたコンテンツをコンテンツ消費者はどのような方法で表示しますか?
コンテンツ作成者はどのような方法でコンテンツを開発、管理、公開しますか? どのユースケースに最適なツールとアプリケーションを決定するための基準は何ですか?
ツールはどのような方法でインストールし、セットアップしますか? それには前提条件やデータ接続コンポーネントが含まれますか?
ツールとアプリケーションの継続的更新はどのような方法で管理しますか?

詳細については、「ユーザーのツールとデバイス」を参照してください。

アーキテクチャ

Fabric のコンテキストにおけるアーキテクチャは、データアーキテクチャ、容量管理、データゲートウェイのアーキテクチャと管理に関連します。

データのアーキテクチャ

"データアーキテクチャ" とは、どのようなデータを収集し、どのようにデータの取り込み、格納、管理、統合、モデル化、利用を行うかを定義して管理するための、原則、業務、手法を指します。

データアーキテクチャについては決めるべきことが多数あります。多くの場合、COE がデータアーキテクチャの設計と計画に関与します。データベースまたは Azure インフラストラクチャを管理する場合は特に、管理者も参加するのが一般的です。

重要

データアーキテクチャに関する決定は、Fabric の導入、ユーザー満足度、個々のプロジェクトの成功率に大きな影響を及ぼします。

導入に影響する、データアーキテクチャに関する考慮事項の一部を以下に示します。

Fabric は組織のデータアーキテクチャ全体の中でどのように位置付けられますか。その他に、計画の要因として考慮することが重要な、エンタープライズデータウェアハウス (EDW) やデータレイクなどの既存のコンポーネントが存在しますか。
Fabric はデータの準備、データモデリング、データ表示のためにエンドツーエンドで使用されますか。または Fabric はこれらの機能の一部のみに使用されますか。
データの再利用性とレポート作成者の柔軟性の最適なバランスを見つけるために、管理されたセルフサービスパターンに従っていますか。
ユーザーはどこでコンテンツを利用しますか。一般に、コンテンツを提供する主な方法は 3 つあります。Fabric ポータル、Power BI Report Server、カスタムアプリケーションへの埋め込みです。さらに、Microsoft Teams は、Teams で多くの時間を費やしているユーザーには便利な代案となります。
データアーキテクチャの管理と保守を担当するのは誰ですか。一元化されたチームですか、それとも分散型のチームですか。このチームでは、COE はどのように表されますか。特定のスキルセットが必要とされますか。
最も重要なデータソースは何ですか。どのような種類のデータを取得しますか。
ユースケースに最適なのは、どのようなセマンティックモデル接続モードとストレージモードの選択肢 (Direct Lake、インポート、ライブ接続、DirectQuery、複合モデルフレームワークなど) ですか。
レイクハウス、ウェアハウス、共有セマンティックモデルを使用するデータの再利用は、どの程度推奨されますか。
データパイプライン、ノートブック、データフローを使用するデータ準備ロジックと高度なデータ準備の再利用は、どの程度推奨されますか。

管理者は、アーキテクチャに関する決定を下す前に、Fabric の技術的な機能、および関係者のニーズと目標を十分に知っておくことが重要です。

ヒント

前提やアイデアをテストするために技術的な概念実証 (POC) を完了するというよい習慣を身に付けてください。組織によっては、小さな作業単位を完了することが目標である場合、それらは "マイクロプロジェクト" とも呼ばれます。 POC の目標は、できるだけ早期に不明な部分に対処してリスクを軽減することです。 POC は、1 回限りの作業とする必要はありませんが、その範囲は限定しておく必要があります。ベストプラクティスのレビューは、メンタリングとユーザーの有効化に関する記事で説明されているように、重要なアーキテクチャ上の決定を下すコンテンツ作成者の助けとなる、別の便利な方法です。

キャパシティ管理

容量には、分析ソリューションを大規模に提供するための機能が含まれています。 Fabric 組織ライセンスには、Premium per User (PPU) と容量の 2 種類があります。容量ライセンスにはいくつかの種類があります。容量ライセンスの種類によって、Fabric ワークロードがサポートされるかどうかが決まります。

重要

この記事では、Power BI Premium またはその容量サブスクリプション (P SKU) に言及することがあります。現在、Microsoft は購入オプションを統合し、容量あたりの Power BI Premium SKU を廃止していることに注意してください。新規および既存のお客様は、代わりに Fabric 容量サブスクリプション (F SKU) の購入をご検討ください。

詳細については、「Power BI Premium ライセンスに関する重要な更新」と「Power BI Premium のよく寄せられる質問」を参照してください。

容量の使用は、コンテンツの作成、管理、発行、および配布に関する戦略において重要な役割を果たします。容量に投資する理由には、次のようなものがあります。

多数の読み取り専用ユーザーへの無制限の Power BI コンテンツ配布。無料の Power BI ライセンスを持つユーザーによるコンテンツ消費は、PPU ではなく Premium 容量でのみ利用できます。無料ユーザーによるコンテンツ消費は、F64 Fabric 容量ライセンス以上でも利用できます。
エンドツーエンドの分析を生成するための Fabric エクスペリエンスへのアクセス。
開発、テスト、運用の各ワークスペースへのコンテンツの発行を管理するためのデプロイパイプライン。リリースの安定性を向上させるため、重要なコンテンツにはこれらを強くお勧めします。
XMLA エンドポイント。これは、セマンティックモデルの管理や発行を行ったり、任意の XMLA 準拠ツールからセマンティックモデルのクエリを行ったりするための業界標準プロトコルです。
大規模なセマンティックモデルのサポートを含め、モデルサイズの上限が引き上げられます。
データ更新の頻度が高められます。
ホームリージョンとは異なる特定の地理的領域内のデータストレージ。

上記の一覧はすべてを網羅したものではありません。完全な一覧については、「Power BI Premium の機能」を参照してください。

Fabric 容量を管理する

Fabric 容量の正常性の監視は、管理者にとって欠くことのできない継続的アクティビティです。各容量 SKU には、一連のリソースが含まれます。容量ユニット (CU) は、SKU ごとにコンピューティングリソースを測定するために使用されます。

注意事項

管理が不十分で容量リソースの制限を超過する状態が続くと、多くの場合、パフォーマンスの課題やユーザーエクスペリエンスの課題につながる可能性があります。どちらの課題も、適切に管理されていない場合、導入の取り組みに悪影響を及ぼすおそれがあります。

Fabric 容量管理時の推奨事項:

容量の管理を担当するユーザーを定義します。実行されるアクション、理由、タイミング、担当者が明確になるように、ロールと責任を確認ししてください。
容量に発行されるコンテンツのために、特定の条件のセットを作成します。これは、容量が適切に管理されていないと他のユーザーが切断される可能性があるため、単一の容量が複数の部署によって使用される場合に特に関連性があります。運用環境の容量に新しいコンテンツを発行する前に、ベストプラクティスのレビュー (妥当なセマンティックモデルサイズや効率的な計算など) を要求することを検討してください。
Fabric 容量のメトリックアプリを定期的に使用して、容量のリソース使用率とパターンを理解します。最も重要なのは、ユーザーの中断の一因となる、使用過多の一貫したパターンを探すことです。使用パターンの分析により、容量が十分活用されているかどうかも認識可能になるはずなので、投資からより多くの価値を得られる可能性が示されます。
容量が過負荷になったり、停止やインシデントが発生したりした場合は Fabric から通知を受け取るようにテナント設定を設定します。

Autoscale

自動スケーリングは、容量の使用レベルでの、時折または予期せず発生する急激な利用増を処理することを意図したものです。自動スケーリングでは、増加したワークロードをサポートするために CPU リソースを自動的に増やすことで、これらの急激な利用増に対応できます。

自動スケーリングを利用すると、コスト面の影響と引き換えに、パフォーマンスとユーザーエクスペリエンスの課題に伴うリスクが軽減されます。容量が十分に管理されていない場合、予期したよりも頻繁に自動スケーリングがトリガーされる可能性があります。この場合は、メトリックアプリが、基にある問題を特定し、キャパシティプランニングを行うために役立ちます。

分散型の容量管理

容量管理者は、特定の容量に対してワークスペースを割り当てる役割を担います。

ワークスペース管理者が PPU ライセンスを所有している場合は、ワークスペース管理者も PPU にワークスペースを割り当て可能であることに注意してください。ただし、ワークスペース内の Power BI コンテンツで共同作業または表示を行うには、他のワークスペースユーザーもすべて PPU ライセンスを持っている必要があります。 PPU に割り当てられたワークスペースに、他の Fabric ワークロードを含めることはできません。

異なるビジネスユニットによる分散管理が容易になるように、複数の容量を設定することが可能です。 Fabric の一定の側面を分散管理することは、機敏性と制御のバランスを取る優れた方法です。

容量を管理できる方法の 1 つを説明する例を次に示します。

Microsoft 365 で P3 容量ノードを購入します。これには 32 個の仮想コアが含まれています (仮想コア)。
16 個の仮想コアを使用して、1 番目の容量を作成します。これは、営業チームが使用します。
8 個の仮想コアを使用して、2 番目の容量を作成します。これは、運用チームが使用します。
残りの 8 個の仮想コアを使用して、3 番目の容量を作成します。これは、一般的な使用をサポートします。

上記の例には、いくつかの長所があります。

容量ごとに個別の容量管理者を設定できます。そのため、分散管理の状況が容易になります。
1 つの容量が適切に管理されていない場合、影響が及ぶのはその容量のみです。その他の容量は影響を受けません。
他の事業単位への請求とチャージバックは簡単です。
異なるワークスペースを個別の容量に簡単に割り当てることができます。

ただし、上記の例には短所もあります。

容量ごとの制限が低くなります。セマンティックモデルのために指定できる最大メモリサイズは、購入された P3 容量のノードサイズ全体と同じではありません。そうではなく、セマンティックモデルがホストされる場所に割り当てられている容量サイズになります。
ある時点で、小さい容量の 1 つをスケールアップする必要が生じる可能性が高くなります。
テナントで管理する容量が他にもあります。

Note

容量あたりの Power BI Premium のリソースは、仮想コアと呼ばれます。ただし、Fabric 容量では、それらを容量ユニット (CU) と呼びます。 SKU と仮想コアのスケールは SKU ごとに異なります。詳細については、Fabric のライセンスに関するドキュメントを参照してください。

データゲートウェイのアーキテクチャと管理

データゲートウェイを使用すると、組織のデータソースと Fabric サービスとの間のデータ転送をセキュリティで保護し、効率化することが容易になります。データソースが以下に該当する場合は、オンプレミスまたはクラウドサービスへのデータ接続にはデータゲートウェイが必要です。

エンタープライズデータセンター内に配置されている。
ファイアウォールの背後に構成されている。
仮想ネットワーク内にある。
仮想マシン内にある。

ゲートウェイには 3 つの種類があります。

オンプレミスデータゲートウェイ (標準モード) は、多くのユーザーが使用するために登録されるデータソースへの接続がサポートされるゲートウェイサービスです。ゲートウェイソフトウェアのインストールと更新プログラムは、お客様が管理するマシンにインストールされます。
オンプレミスデータゲートウェイ (個人用モード) は、データ更新のみがサポートされるゲートウェイサービスです。このゲートウェイモードは、一般にコンテンツ作成者の PC にインストールされます。 1 人のユーザーによる使用のみがサポートされます。ライブ接続や DirectQuery 接続はサポートされません。
仮想ネットワークデータゲートウェイは、多くのユーザーのための接続がサポートされる Microsoft マネージドサービスです。具体的には、Premium 容量または Premium Per User に割り当てられたワークスペースに格納される、セマンティックモデルとデータフローのための接続がサポートされます。

ヒント

誰がゲートウェイソフトウェアをインストールできるかの決定は、ガバナンス上の決定です。ほとんどの組織では、標準モードのデータゲートウェイ、または仮想ネットワークデータゲートウェイを使用することを強くお勧めします。個人用モードのデータゲートウェイよりもはるかにスケーラブルで、管理と監査を行いやすくなります。

分散型ゲートウェイ管理

オンプレミスデータゲートウェイ (標準モード) と仮想ネットワークデータゲートウェイでは、接続の詳細や資格情報の格納方法と共に登録することができる、特定の種類のデータソースがサポートされます。ユーザーにゲートウェイデータソースを使用するアクセス許可を付与して、更新をスケジュールしたり、DirectQuery クエリを実行したりできるようにすることができます。

ゲートウェイ管理の特定の側面は、機敏性と制御のバランスを取るために、分散型ベースで効果的に実行できます。たとえばオペレーショングループで、セルフサービスのコンテンツ作成者とデータ所有者から成るチーム専用のゲートウェイを用意できます。

分散型ゲートウェイ管理は、以下のような共同作業である場合に最適です。

分散しているデータ所有者によって管理される:

部門データソースの接続情報とプライバシーレベル。
部門データソースに格納される資格情報 (定期的なパスワード変更を更新する業務が含まれます)。
各データソースの使用が許可される、部門データソースのユーザー。

一元化されたデータ所有者によって管理される (組織全体で広く使用されるデータソースが含まれます。管理は、データソースの重複回避するために一元化されています):

一元化されたデータソースの接続情報とプライバシーレベル。
一元化されたデータソースに格納される資格情報 (定期的なパスワード変更を更新する業務が含まれます)。
各データソースの使用が許可される、一元化されたデータソースのユーザー。

IT によって管理される:

ゲートウェイソフトウェアの更新 (ゲートウェイの更新プログラムは通常、毎月リリースされます)。
ドライバーとカスタムコネクタ (ユーザーマシンにインストールされるのと同じもの) のインストール。
ゲートウェイクラスターの管理 (高可用性、ディザスターリカバリー、ユーザーの重大な中断の原因となる場合がある単一障害点の解消を目的とした、ゲートウェイクラスター内のマシンの数)。
サーバーの管理 (オペレーティングシステム、RAM、CPU、ネットワーク接続など)。
ゲートウェイの暗号化キーの管理とバックアップ。
スケールアップまたはスケールアウトが必要なタイミングを評価するためのゲートウェイログの監視。
ゲートウェイマシンでのダウンタイムまたは永続的なリソース不足のアラート。

ヒント

分散型チームがゲートウェイの特定の側面を管理できるようにすることは、チームがより迅速に行動できることを意味します。分散型ゲートウェイ管理のトレードオフは、それぞれが組織の特定領域に専念できるよう、より多くのゲートウェイサーバーを実行することになる点です。 IT がゲートウェイ管理を全面的に実施する場合は、データソースを追加したり、ユーザーの更新を適用したりする要求をすばやく処理するために、優れたプロセスを導入しておく必要があります。

ユーザーライセンス

すべてのユーザーに、Microsoft Entra の ID と統合される商用ライセンスが必要です。ユーザーライセンスは、Free、Pro、または Premium Per User (PPU) です。

ユーザーライセンスは、開始日と終了日がある一定数のライセンスを認可するサブスクリプションを介して取得します。

Note

ライセンスは各ユーザーに必要ですが、Pro または PPU ライセンスが必要なのは Power BI コンテンツを共有する場合のみです。無料ライセンスを持つユーザーは、Power BI 項目以外の Fabric コンテンツを作成して共有できます。

サブスクリプションを購入する方法は 2 つあります。

一元化: Microsoft 365 の課金管理者が、Pro または PPU のサブスクリプションを購入します。これは、サブスクリプションの管理とライセンスの割り当てを行う最も一般的な方法です。
分散化: 個々の部門がセルフサービスでの購入によってサブスクリプションを購入します。

セルフサービスでの購入

ガバナンス上の重要な決定は、セルフサービスでの購入がどの程度まで許可または推奨されるかに関連します。

セルフサービスでの購入は、以下のような場合に有用です。

購入権限があってクレジットカードで支払いを直接処理する必要がある、分散されたビジネスユニットを持つ大規模な組織。
月額コミットメントでのサブスクリプションの購入をできるだけ簡単にするつもりである組織。

以下の場合はセルフサービスでの購入を無効にすることを検討してください。

規制、セキュリティ、ガバナンスの要件を満たすための一元化された調達プロセスが導入されている。
EA (Enterprise Agreement) を通して割引価格が得られる。
企業内配賦を処理するための既存のプロセスが導入されている。
グループベースのライセンス割り当てを処理するための既存のプロセスが導入されている。
承認、理由付け、トレーニング、ガバナンスポリシーの要件など、ライセンスを取得するための前提条件を満たす必要がある。
規制上の要件など、アクセスを詳細に制御する正当な必要性がある。

ユーザーライセンス試用版

ガバナンス上のもう 1 つの重要な決定は、ユーザーライセンス試用版が許可されるかどうかです。既定では、試用版は有効にされます。つまり、コンテンツが同僚と共有されるときには、受信者が Pro または PPU ライセンスを持っていないと、コンテンツを表示するために試用版を起動するよう求めるメッセージが表示されます (そのコンテンツが容量によってサポートされているワークスペース内にない場合)。試用版のエクスペリエンスは利便性を目指しており、ユーザーが通常のワークフローを続行できます。

一般に、試用版を無効にすることは推奨されません。データをエクスポートしたり、サポートされているツールやプロセスの外部で作業したりすることで、ユーザーに回避策の探索を促すことができます。

以下の場合にのみ試用版を無効にすることを検討してください。

試用期間の終わりに完全なライセンスを付与する可能性が低くなるような、コスト上の重大な懸念がある。
ライセンスを取得するための前提条件を満たす必要がある (承認、理由付け、トレーニングの要件など)。試用期間中にこの要件を満たすだけでは十分ではない。
規制上の要件など、Fabric サービスへのアクセスを詳細に制御する正当な必要性がある。

ヒント

Fabric ライセンスの取得に対してあまり多くの障壁を設けないでください。仕事をやり遂げる必要があるユーザーは方法を見つけるので、そのような方法には理想的でない回避策が伴うことがあります。たとえば、Fabric を使用するライセンスがないと、ユーザーははるかに優れたアプローチを利用できるときに、ファイルシステム上やメールを介したファイルの共有に頼りすぎてしまう可能性があります。

コスト管理

Fabric などのクラウドサービスのコストの管理と最適化は、重要なアクティビティです。以下に、検討できるいくつかのアクティビティを示します。

割り当てられた Fabric ライセンスを使用しているユーザーと使用していないユーザー (より重要です) を分析し、必要な調整を行います。 Fabric の使用状況は、アクティビティログを使用して分析します。
容量や Premium Per User のコスト効果を分析します。追加の機能に加えて、費用対効果分析を実行して、利用者が多数であるときに容量ライセンスの方がコスト効果が高いかどうかを判断します。
注意深く Fabric 容量の監視と管理を行います。長期的な使用パターンを理解することで、追加の容量を購入する時期を予測できるようになります。たとえば、1 つの容量を P1 から P2 にスケールアップするか、1 つの P1 容量から 2 つの P1 容量にスケールアウトするかを選択できます。
使用率のレベルが急増することがある場合は、Fabric で自動スケーリングを使って、ユーザーエクスペリエンスが中断されないようにすることをお勧めします。自動スケーリングでは、容量のリソースが 24 時間スケールアップされ、その後、スケールダウンして通常のレベルに戻されます (持続的アクティビティが存在しない場合)。仮想コアの最大数を制限したり、Azure で使用制限を設定したりして、自動スケーリングのコストを管理します。その価格モデルが理由で、自動スケーリングは、時折発生する使用量の計画外の増加に対処する場合に最適です。
Azure データソースについては、可能な場合は常に、お使いの Fabric テナントと同じリージョンにそれらを併置します。これにより、Azure エグレス料金の発生を避けられます。データエグレス料金は最小限ですが、大規模になると、かなりの計画外のコストになるおそれがあります。

セキュリティ、情報保護、データ損失防止

セキュリティ、情報保護、データ損失防止 (DLP) は、すべてのコンテンツ作成者、コンシューマー、管理者の共同責任です。一部の例を挙げると、個人データ、顧客データ、顧客が作成したデータ、保護された健康情報、知的所有権、独自の組織情報など、あらゆる場所に機密情報が存在するため、それは小さなタスクではありません。政府、業界、契約上の規制が、セキュリティに関連して作成するガバナンスのガイドラインとポリシーに重大な影響を及ぼす可能性があります。

Power BI のセキュリティホワイトペーパーは、Microsoft が管理する側面を含め、さまざまな考慮事項を理解するうえで優れたリソースです。このセクションでは、お客様が管理を担当するいくつかのトピックを紹介します。

ユーザーの責任

組織によっては、ユーザーがセルフサービスを受け入れるよう、Fabric ユーザーに依頼することがあります。これは、組織のデータを保護するためのユーザーの責任と期待事項について説明するドキュメントです。

その実装を自動化する方法の 1 つは、Microsoft Entra の利用規約ポリシーを利用することです。ユーザーが初めての Fabric ポータルへのアクセスを許可されるには、このポリシーを表示して同意する必要があります。また、年間契約の更新のように、定期的に同意を要求することもできます。

データのセキュリティ

クラウドの共同責任モデルでは、データのセキュリティを保護することは、常にお客様の責任です。セルフサービスデータプラットフォームでは、セルフサービスコンテンツ作成者が、同僚と共有したコンテンツを適切にセキュリティで保護する責任を負います。

COE は、(特に、極度に機密性が高いデータを扱う状況での) ベストプラクティスを利用してコンテンツ作成者を支援するうえで適切なドキュメントとトレーニングを提供する必要があります。

管理者は、自分自身がベストプラクティスに従うことで支援することができます。また、管理者は、ワークスペースの管理、ユーザーアクティビティの監査、ゲートウェイ資格情報とユーザーの管理を行う際に問題が見つかった場合に、懸念を発することもできます。また、一部のユーザーを除いて通常は制限されるテナント設定もいくつか存在します (たとえば、Web に公開する機能や、組織全体にアプリを発行する機能)。

外部のゲストユーザー

パートナー、顧客、ベンダー、コンサルタントなどの外部ユーザーは、一部の組織では一般的ですが、その他の組織ではまれです。外部ユーザーを扱う方法は、ガバナンス上の決定事項です。

外部ユーザーのアクセスは、テナント設定と、Microsoft Entra ID の特定の設定で制御されます。外部ユーザーに関する考慮事項について詳しくは、「Microsoft Entra B2B を使用して外部ゲストユーザーに Power BI コンテンツを配布する」のホワイトペーパーをご覧ください。

情報保護とデータ損失防止

Fabric では、次の方法で情報保護とデータ損失防止 (DLP) の機能がサポートされています。

情報保護:Microsoft Purview 情報保護 (旧称 Microsoft Information Protection) には、データを検出、分類、保護するための機能が含まれています。重要な原則は、データを分類するとその保護を強化できることです。データを分類するための重要な構成要素は、秘密度ラベルです。詳細については、Power BI 計画でのデータ保護に関する記事を参照してください。
Power BI でのデータ損失防止: Microsoft Purview データ損失防止 (旧称 Office 365 データ損失防止) では、Power BI の DLP ポリシーがサポートされています。秘密度ラベルまたは機密情報の種類を使用して、Power BI の DLP ポリシーは、組織が機密性の高いセマンティックモデルを見つけるのに役立ちます。詳細については、Power BI の計画でのデータ損失防止に関する記事を参照してください。
Microsoft Defender for Cloud Apps:Microsoft Defender for Cloud Apps (旧称 Microsoft Cloud App Security) では、ユーザーが Power BI サービスを操作するときのリアルタイム制御など、データを保護するのに役立つポリシーがサポートされています。詳細については、Power BI の計画での Defender for Cloud Apps に関する記事を参照してください。

データの保存場所

地理的領域内にデータを格納するという要件がある組織の場合、Fabric 容量を、Fabric テナントのホームリージョンとは異なる特定のリージョンに対して設定できます。

暗号化キー

Microsoft は Microsoft データセンターで、透過的なサーバー側の暗号化と証明書の自動ローテーションを使用して、保存データの暗号化を処理しています。 Premium の暗号化キー自体を管理するための規制要件があるお客様の場合、Azure Key Vault を使用するように Premium 容量を構成できます。 bring-your-own-key や BYOK とも呼ばれるカスタマーマネージドキーの使用は、サービスオペレーターによる人的エラーが発生した場合に、顧客データを公開できないようにするための予防措置です。

Premium Per User (PPU) では、Fabric テナント全体に対して有効になっている場合にのみ BYOK がサポートされることに注意してください。

監査と監視

監査データを利用して、導入作業の分析、使用パターンの理解、ユーザーの教育、ユーザーのサポート、リスクの軽減、コンプライアンスの向上、ライセンスコストの管理、パフォーマンスの監視を実行することが重要です。データの監査が重要な理由について詳しくは、監査と監視の概要に関する記事をご覧ください。

監査と監視には、役割と目的に応じてさまざまな方法があります。以下の記事では、さまざまな考慮事項と計画アクティビティについて説明しています。

レポートレベルの監査: レポート作成者が、作成、発行、共有するレポートをどのユーザーが使っているかを把握するために使用できる手法。
データレベルの監査: データ作成者が、作成、発行、共有するデータ資産のパフォーマンスや使用パターンを追跡するために使用できる手法。
テナントレベルの監査: エンドツーエンドの監査ソリューションを構築するために、管理者がとることができる主な決定事項とアクション。
テナントレベルの監視: 更新やお知らせなど、Power BI サービスを監視するために管理者がとることができる戦術的なアクション。

REST API

Power BI REST API と Fabric REST API を使用して、Fabric テナントに関するさまざまな情報が提供されます。 REST API を使ってデータを取得することは、Fabric 実装の管理と制御において重要な役割を果たします。監査に REST API を使うための計画について詳しくは、テナントレベルの監査に関する記事を参照してください。

監査データを取得して、監査ソリューションを構築したり、プログラムでコンテンツを管理したり、ルーチンアクションの効率を高めたりすることができます。次の表に、REST API で実行できるいくつかのアクションを示します。

操作	ドキュメントリソース
ユーザーアクティビティを監査する	アクティビティイベントを取得するための REST API
ワークスペース、アイテム、アクセス許可を監査する	テナントインベントリを取得するための非同期メタデータスキャン REST API のコレクション
組織全体に共有されているコンテンツを監査する	広く共有されているリンクの使用をチェックするための REST API
テナント設定を監査する	テナント設定をチェックするための REST API
コンテンツを発行する	デプロイパイプラインからアイテムをデプロイする、または別のワークスペースにレポートを複製するための REST API
Manage content	セマンティックモデルを更新する、またはセマンティックモデルの所有権を引き継ぐための REST API
ゲートウェイのデータソースの管理	ゲートウェイデータソースの資格情報を更新するための REST API
コンテンツのエクスポート	レポートをエクスポートするための REST API
ワークスペースを作成する	新しいワークスペースを作成するための REST API
ワークスペースのアクセス許可を管理する	ワークスペースへのユーザーのアクセス許可を割り当てるための REST API
ワークスペースの名前または説明を更新する	ワークスペース属性を更新するための REST API
ワークスペースを復元する	削除されたワークスペースを復元するための REST API
プログラムによってセマンティックモデルからクエリ結果を取得する	セマンティックモデルに対して DAX クエリを実行するための REST API
容量にワークスペースを割り当てる	ワークスペースを容量に割り当てるための REST API
プログラムによってデータモデルを変更する	表形式オブジェクトモデル (TOM) API
カスタムアプリケーションに Power BI コンテンツを埋め込む	Power BI 埋め込み分析のクライアント API

ヒント

他にも多くの Power BI REST API があります。完全な一覧については、「Power BI REST API を使用する」を参照してください。

変更のための計画

Microsoft では毎月、新しい Fabric の機能をリリースしています。効果を上げるには、システム監視に関わる全員が最新の情報を把握することが重要です。詳しくは、テナントレベルの監視に関する記事をご覧ください。

重要

最新の状態を把握することの重要性を過小評価しないようにしてください。お知らせが数か月遅れた場合、Fabric を適切に管理し、ユーザーをサポートすることが困難になるおそれがあります。

考慮事項と主なアクション

チェックリスト - 以下は、システム監視のために実行できる考慮事項と主なアクションです。

システム監視を改善する:

Fabric 管理者であることが許可されているユーザーを確認する: Fabric 管理者ロールが付与されている人数が数名より多い場合は、可能であれば人数を減らします。
不定期の管理者用に PIM を使用する: Fabric 管理者権限が "時折" 必要なユーザーがいる場合は、Microsoft Entra ID の Privileged Identity Management (PIM) を実装することを検討します。これは、数時間後に有効期限が切れるジャストインタイムのロールアクセス許可を割り当てるように設計されています。
管理者をトレーニングする: Fabric 管理の責任を扱うために、導入されているクロストレーニングとドキュメントの状態を確認します。一貫した方法でタイムリーにニーズを満たすことができるように、必ずバックアップ担当者がトレーニングされているようにします。

Fabric サービスの管理を改善する:

テナント設定をレビューする: すべてのテナント設定をレビューして、それらがデータカルチャの目標とガバナンスのガイドラインおよびポリシーに沿っていることを確認します。各設定にどのグループが割り当てられているかを確認します。
テナント設定を文書化する: 社内 Fabric コミュニティのテナント設定のドキュメントを作成し、それを中央ポータルに投稿します。ユーザーが、ある機能を使用できるようになるためには、どのグループを要求する必要が生じるかを含めます。 [Get Tenant Settings REST API] (テナント設定 REST APIの取得) を使用して、プロセスをより効率的にし、定期的に設定のスナップショットを作成します。
[ヘルプを取得] リンクをカスタマイズする: ユーザーリソースが確立されたら、メンタリングとユーザーの有効化に関する記事で説明されているように、テナント設定を更新して [ヘルプを取得] メニューオプションの下のリンクをカスタマイズします。これによってユーザーは、お使いのドキュメント、コミュニティ、ヘルプに移動されます。

ユーザーのマシンやデバイスの管理を改善する:

一貫したオンボードプロセスを作成する: 新しいコンテンツ作成者のオンボードがどのように処理されるかについて、お使いのプロセスをレビューします。 Power BI Desktop などのソフトウェアやユーザーライセンス (Free、Pro、または PPU) に対する新しい要求を一緒に処理できるかどうかを判断します。新しいコンテンツの作成者は何を要求すべきか常にわかっているとは限らないため、オンボードを簡素化できます。
ユーザーマシンの更新を処理する: すべてのユーザーが同じバージョンを確実に入手できるように、ソフトウェア、ドライバー、設定のインストールと更新を行う自動化されたプロセスが導入されるようにします。

データアーキテクチャの計画:

エンドツーエンドのデータアーキテクチャがどのようになっているかを評価する: 以下の点が明確になるようにします。
- 組織内のさまざまな部署によって Fabric が現在どのように使用されているか。それに対比して、Fabric がどのように使用されるのが望ましいか。ギャップがあるかどうかを判断します。
- 対処する必要がある何らかのリスクが存在するか。
- 対処する必要がある何らかのメンテナンスが頻発する状況があるか。
- Fabric ユーザーにとってどれが重要なデータソースであり、それらがどのように文書化され、検出されているか。
既存のデータゲートウェイを確認する: 組織全体で使用されているゲートウェイを確認します。ゲートウェイ管理者とユーザーが正しく設定されていることを検証します。誰が各ゲートウェイをサポートしているかを確認し、ゲートウェイサーバーを最新の状態に保つための信頼できるプロセスが導入されていることを確認します。
個人用ゲートウェイの使用を確認する: 使用中の個人用ゲートウェイの数と、その利用者を調べます。かなりの使用状況である場合は、標準モードゲートウェイの使用に向けて移行する対策を講じます。

ユーザーライセンスの管理を改善する:

ユーザーライセンスを要求するプロセスを確認する: ユーザーがライセンスを取得するためのプロセスがどのようなものであるかを、前提条件を含めて、明確にします。プロセスに改善できる点があるかどうかを判断します。
セルフサービスライセンス購入の処理方法を確認する: セルフサービスライセンスの購入が有効になっているかどうかを明確にします。それらがライセンスの購入方法に関する意図と一致していない場合は、設定を更新します。
ユーザー試用版の処理方法を確認する: ユーザーライセンス試用版が有効になっているか、無効になっているかを確認します。ユーザー試用版はすべて Premium Per User であることに注意してください。それらは試用版にサインアップする Free ライセンスユーザーと、Premium Per User 試用版にサインアップする Pro ユーザーに適用されます。

コスト管理の改善:

コスト管理の目標を定める: コスト、機能、使用パターン、リソースの効率的な利用のバランスを取る方法を検討します。少なくとも年単位でコストを評価するための定期的プロセスをスケジュールします。
アクティビティログデータを取得する: コスト分析を支援するために、アクティビティログデータにアクセスできることを確認します。これを使って、自分に割り当てられたライセンスを使用している (または使用していない) ユーザーを把握できます。

セキュリティとデータ保護を改善する:

データ保護に関する正確な想定事項を明確にする: 秘密度ラベルの使用法など、データ保護に関する想定事項を文書化し、ユーザーに伝えるようにします。
外部ユーザーの処理方法を定める: Fabric コンテンツを外部ユーザーと共有することに関連する組織のポリシーを理解して文書化します。 Fabric の設定で、外部ユーザーに関するポリシーを確実にサポートするようにします。
監視を設定する: Fabric におけるユーザーの行動とアクティビティを監視するための、Microsoft Defender for Cloud Apps の使い方を調査します。

監査と監視を改善する:

監査のニーズを計画する: 監査ソリューションの主要なビジネス要件を収集して文書化します。監査と監視の優先順位を検討します。監査ソリューションの種類、アクセス許可、使用するテクノロジ、データのニーズに関連する重要な決定を行います。 IT 担当者と相談して、現在どのような監査プロセスが存在しているか、新しいソリューションを構築するための要件にはどのような優先順位があるかを明確にします。
役割と責任を検討する: 監査データの継続的な分析に加えて、監査ソリューションの構築に関与するチームを特定します。
ユーザーアクティビティデータを抽出して格納する: 現在生データを抽出して格納していない場合は、ユーザーアクティビティデータの取得を開始します。
テナントインベントリデータのスナップショットを抽出して格納する: メタデータの取得を開始して、すべてのワークスペースとアイテムを記述するテナントインベントリを構築します。
ユーザーとグループのデータのスナップショットを抽出して格納する:ユーザー、グループ、サービスプリンシパルに関するメタデータの取得を開始します。
キュレーションされたデータモデルを作成する: 生データのデータクレンジングと変換を実行して、監査ソリューションの分析レポートをサポートするキュレーションされたデータモデルを作成します。
監査データを分析し、結果に対応する: 分析レポートを作成して、キュレーションされた監査データを分析します。どのようなアクションが、誰によって、いつ実行される必要があるかを明確にします。
追加の監査データを含める: 長い期間をかけて、追加の監査データがアクティビティログデータを補完するために役立つかを判断します (セキュリティデータなど)。

ヒント

詳細については、「テナントレベルの監査」を参照してください。

REST API を使用する:

REST API の使用を計画する: Power BI REST API と Fabric REST API から取得するうえで最も役立つデータを検討します。
概念実証を実施する: 小さな概念実証を実施して、データのニーズ、テクノロジの選択、アクセス許可を検証します。

確認事項

以下のような質問を使用して、システムの監視を評価します。

特殊な管理設定が有効または無効になっているか? たとえば、組織全体の Web への公開が許可されているなどです (この機能を制限することを強くお勧めします)。
管理の設定とポリシーは、ユーザーのビジネスの方法と一致するか、それともビジネスを妨げているか?
新しい設定を慎重に評価し、設定方法を決定するプロセスはあるか? または、最も制限の厳しい設定のみを予防措置として設定しているか?
誰が何をできるかを管理するために、Microsoft Entra のセキュリティグループが使われているか?
中央のチームは、効果的な監査および監視ツールを可視化しているか?
監視ソリューションは、データ資産、ユーザーアクティビティ、またはその両方に関する情報を示しているか?
監査および監視ツールは実行可能か? 明確なしきい値とアクションが設定されているか、監視レポートでデータ資産の内容を説明するだけか?
Azure Log Analytics は、Fabric 容量の詳細な監視に使用されている (または使用予定) か? Azure Log Analytics の潜在的なベネフィットとコストは意思決定者にとって明確か?
秘密度ラベルとデータ損失防止ポリシーは使用されているか? これらの潜在的なベネフィットとコストは意思決定者にとって明確か?
管理者は現在のライセンス数とライセンスコストを知っているか? Fabric 容量、Pro、PPU ライセンスが占める BI 総支出のうちの割合は何か? 組織が Power BI コンテンツに対して Pro ライセンスのみを使用している場合、ユーザー数と使用パターンはコスト効率に優れた Power BI Premium または Fabric 容量への切り替えを保証できるか?

成熟度レベル

Power BI システム監視の現在の状態を評価するのに、以下の成熟度レベルが役立ちます。

Level	システム監視の状態
100: 初期	• テナント設定は、1 人または複数の管理者によって、彼らの最適な判断に基づいて個別に構成されます。 • ゲートウェイや容量などのアーキテクチャ上のニーズは、必要に応じて満たされます。ただし、戦略的な計画はありません。 • Fabric アクティビティログは、未使用であるか、戦術的目的で選択的に使用されます。
200: 反復可能	• テナント設定は、確立されたガバナンスガイドラインとポリシーに整合するように意図を持って調整されます。すべてのテナント設定は、定期的に確認されます。 • 少数の特定の管理者が選抜されています。すべての管理者は、ユーザーが Fabric で何を達成しようとしているかを適切に理解しているため、ユーザーをサポートするのに適した状態にあります。 • ユーザーがライセンスやソフトウェアを要求するための、適切に定義されたプロセスが存在します。ユーザーは簡単に要求フォームを見つけることができます。セルフサービス購入の設定が指定されています。 • Microsoft 365 で秘密度ラベルが構成されています。ただし、ラベルの使用法には一貫性がないままになっています。データ保護の利点は、ユーザーに十分に理解されていません。
300: 定義済み	• テナント設定は、ユーザーが参照する一元化されたポータルで完全に文書化されています。それには、適切なグループへのアクセスを要求する方法が含まれます。 • 管理者が継続性、安定性、一貫性を確保するためのクロストレーニングとドキュメントが存在しています。 • 秘密度ラベルは、コンテンツに一貫して割り当てられています。データ保護に秘密度ラベルを使用する利点は、ユーザーに理解されています。 • レポート作成や監査のために Fabric のアクティビティログや API データを安全な場所にエクスポートする、自動化されたプロセスが導入されています。
400: 可能	• 管理者は、COE およびガバナンスチームと緊密に共同作業を行って、Fabric を監視しています。ユーザーのエンパワーメントとガバナンスのバランスがうまく取られています。 • データアーキテクチャ (ゲートウェイや容量管理など) の分散管理は、機敏性と制御のバランスを取るうえで効果的に処理されています。 • データ損失防止のため、Microsoft Defender for Cloud Apps で、自動化されたポリシーが設定され、積極的に監視されています。 • アクティビティログと API データは、Fabric アクティビティの監視と監査のために積極的に分析されています。データに基づいて事前対応型のアクションが実行されます。
500: 効率的	• Fabric 管理者は、COE と緊密に共同作業を行い、積極的に最新情報を把握しています。今後の変更を計画するために、Fabric 製品チームによるブログ記事とリリース計画を頻繁に確認しています。 • ユーザーニーズがコスト効果が高い方法で満たされるようにするため、定期的なコスト管理分析が行われます。 • Fabric REST API は、テナント設定値を定期的に取得するために使用されます。 • アクティビティログと API データは、導入とガバナンスの取り組みに関する情報提供と改善のために積極的に利用されます。

システムの監視と Fabric 管理の詳細については、以下のリソースを参照してください。

Microsoft Fabric 導入ロードマップシリーズの次の記事では、効果的な変更管理について説明します。

Microsoft Fabric 導入ロードマップ: システム監視