次の方法で共有

Microsoft Fabric 容量を評価して最適化する

  • [アーティクル]

この記事では、Microsoft Fabric 容量にかかる負荷を評価し、最適化する方法について説明します。 また、過負荷に対処するための戦略についても説明し、各 Fabric エクスペリエンスのコンピューティングを最適化するのに役立つガイダンスを提供します。

Fabric 容量モデルではセットアップが簡素化され、コラボレーションに対応していますが、容量が共有するコンピューティング リソースが枯渇する可能性も高くなります。 また、必要以上に多くのリソースを消費してしまっている場合もあります。 そうした問題は、一部の Fabric エクスペリエンスの設計がベスト プラクティスに沿っていない場合に起こる場合があります。

重要なのは、共有リソースである Fabric を管理サービスとして使い切ってしまうリスクを軽減することです。このリスクには、次の 2 つの方法を取ることで対処を自動化できます。

  • バーストとスムージングでは、CPU に負荷のかかるアクティビティを、多くの SKU を使用せずに短時間で（なおかつ 1 日の任意の時間に）完了させることができます。
  • 調整機能では、容量が CPU に対して持続的かつ需要が高い (SKU の制限を超えている) 状態になった場合に実行を遅らせたり、拒否したりすることで対処します。

スムージングを使用すると、調整が行われる可能性は減ります (まったく実行されないわけではありません)。 スムージングは上限に対して使用量の割り当てを定義する方法ですが、ジョブの実行とは無関係です。 スムージングはパフォーマンスを変えるのではなく、消費するコンピューティングの割合を長時間かけて分散させる処理です。そのためピーク時のコンピューティングに対処するために SKU を増やす必要はありません。

Fabric 容量の詳細については、「Microsoft Fabric の概念とライセンス」および「Fabric 容量 - 新機能と今後の展開について知っておくべきすべてのこと」を参照してください。

設計と予算作成のツール

容量のサイズを設計するのは簡単ではない場合があります。 その理由は、実行される操作、実行の程度 (たとえば、DAX クエリの効率やノートブックでの Python コードの動作)、コンカレンシーのレベル次第で求められるコンピューティングが大きく変わる可能性があるためです。

適切な容量サイズを決定するために、試用できる容量や従量課金制の F SKU をプロビジョニングすることで、F SKU 予約インスタンスを購入する前に実際に必要となる容量の目安を確認できます。

ヒント

まずは小さいサイズから始め、必要に応じて徐々に容量のサイズを大きくしていく方法をお勧めします。

容量の監視

容量を最大限に活用するには、使用率の監視が不可欠です。 特に重要なのは、Fabric の操作が対話型とバックグラウンド型のどちらであるかを理解することです。 たとえば、Power BI レポートからデータを抽出する DAX クエリは、オンデマンドのリクエストによる対話型操作になりますが、セマンティック モデルの更新はバックグラウンド操作で実行されます。 操作と Fabric 内のリソースの使用方法については、「Fabric の操作」を参照してください。

監視を行うことで調整機能が働いていることがわかります。 調整は大量の対話型操作や、実行時間の長い対話型操作が実行されている場合に動作する場合があります。 通常、SQL と Spark のエクスペリエンスに関連するバックグラウンド操作はスムージングで処理されます。つまり 24 時間の間分散処理されます。

Fabric Capacity Metrics アプリは、最近の使用率を監視して視覚化するのに効果的なツールです。 項目をタイプ (セマンティック モデル、ノートブック、パイプラインなど) に分け、高度なコンピューティングを使用する項目や操作を特定する (これにより最適化を可能にする) のに役立ちます。

管理監視ワークスペースを利用すれば、管理者は使用頻度の多い項目 (および全体の導入状況) を確認できます。 テナント内の現在のアクティビティと、最近のアクティビティを確認できる監視ハブというツールもあります。 一部の操作の詳しい情報については、Log Analytics やオンプレミス データ ゲートウェイのログからも取得できます。

大規模なコンピューティング使用量の管理

容量の使用率が高く、調整動作や実行拒否が確認されるようになり始めた場合、その状態を解消する方法には最適化、スケールアップ、スケールアウトの 3 つの戦略があります。

容量の使用率が設定しきい値を超えた場合に機能する通知設定をすることをお勧めします。 またワークロード別の設定を利用して、操作のサイズを制限すること (Power BI クエリのタイムアウトや行の制限や Spark ワークスペースの設定など) を検討してください。

最適化

コンテンツ作成者は必ず Fabric の項目設計を最適化し、可能な限り使用コンピューティング リソースの使用量を抑えられるように効率化する必要があります。 各 Fabric エクスペリエンスの具体的なガイダンスについては、この記事の中で後述します。

スケールアップ

容量をスケールアップして SKU サイズを一時的または永続的に増やすことで、コンピューティング容量を増強します。 スケールアップによって、すべての項目で十分なコンピューティング リソースを容量に対して使用できるようになり、調整が動作しないように対処できます。

また、消費パターンに合わせて Fabric F SKU のサイズ変更や一時停止、再開を行うこともできます。

スケール アウト

スケールアウトは、ワークスペースや項目の一部を別の Fabric 容量に移動し、ワークロードを分散させることで実現します。 さまざまな容量戦略や設定に対応でき、管理者の必要に応じて利用するのにも適した方法です。 また、複数の容量をプロビジョニングするのは、優先順位の高い項目のコンピューティングを分離する上で効果的な戦略であり、セルフサービスや開発コンテンツにも有効です。 たとえば組織の経営陣がレポートやダッシュボードに期待するのは、応答性の良さです。 経営陣向けにそのようなレポートやダッシュボード用の容量を別に確保することができます。

コンテンツに継続してアクセスできる Power BI Pro ライセンスを利用者が持っている場合は、Power BI ワークスペースを共用の容量に移すことを検討してもよいでしょう。

Fabric エクスペリエンスによるコンピューティングの最適化

Fabric のエクスペリエンスと項目は動作が異なるため、必ずしも同じように最適化されるとは限りません。 このセクションではエクスペリエンスに応じた Fabric 項目と、項目を最適化するために実行できるアクションの一覧を示します。

Fabric データ ウェアハウス

データ ウェアハウスはサーバーレス アーキテクチャを使用しており、サービスによって自動的にノードが管理されます。 容量の使用量は、フロントエンド ノードとバックエンド ノードがプロビジョニングされている時間ではなく、アクティブなクエリごとの容量ユニットの秒数に基づいて計算されます。

すべてのデータ ウェアハウス操作はバックグラウンド操作であり、24 時間にわたってスムージングされます。

SQL 分析エンドポイントは、デフォルトのエクスペリエンスでパフォーマンスを発揮することを目的としています。 そのため、使用できるクエリ チューニング オプションの種類は、SQL Server や Azure Synapse Analytics 専用の SQL プールと比べると少なくなります。

コンピューティングを最小限に抑えるために考慮すべきいくつかのポイントを次に示します。

  • できる限り最適な T-SQL を使用してクエリを記述します。 クエリのリソース使用量が不必要に増える可能性のある列、計算、集計などの操作の数をできるだけ抑えます。
  • 可能な限り最小のデータ型を使用するようにテーブルを設計します。 データ型の選択は、SQL エンジンによって生成されるクエリ プランに大きく影響する可能性があります。 たとえば、VARCHAR フィールドの長さを 500 から 25 に減らしたり、DECIMAL(32, 8) を DECIMAL(10, 2) に変更したりすると、クエリに割り当てられるリソースが大幅に減少する可能性があります。
  • スター スキーマ設計を使用して読み取り行の数を減らし、クエリの結合を最小限に抑えます。
  • 統計があり、なおかつ最新の状態であることを確認します。 統計は最適な実行プランを生成する上で重要な役割を果たします。 統計は実行時に自動的に作成されますが、特にデータの読み込みや更新後には、手動で更新しなければならない場合があります。 サンプリングを使用する自動生成の統計に頼るのではなく、FULLSCAN オプションを使用して統計を作成することを検討してください。
  • 組み込みのビューを利用してクエリと使用状況を監視します。特に問題のトラブルシューティングを行うときに活用してください。
    • sys.dm_exec_requests 動的管理ビュー (DMV) では、アクティブに実行されている全クエリに関する情報を得られます。ただし履歴情報は格納されません。 Fabric Toolbox にはこの DMV を利用するクエリが用意されており、他のビューと結合することでクエリテキストなどの詳細を提供し、クエリの結果をユーザーフレンドリにしてくれます。
    • Fabric データ ウェアハウスの機能であるクエリ分析情報では、SQL 分析エンドポイントでのクエリのアクティビティに関する包括的な履歴情報を得られます。 具体例として、queryinsights.exec_requests_history ビューでは、完全な SQL リクエストそれぞれに関する情報を確認できます。 各クエリの実行に関連するすべての詳細が表示され、容量メトリック アプリで見つかった操作 ID と関連付けることができます。 容量の使用状況を監視する上でもっとも重要な列が distributed_statement_id、コマンド (クエリ テキスト)、start_time、end_time です。

Fabric Data Engineering と Fabric Data Science

Data Engineering と Data Science のエクスペリエンスでは、Spark のコンピューティングを使用して Fabric Lakehouse のデータを処理、分析、格納します。 Spark コンピューティングの設定と測定は、仮想コアの観点から行われます。 ただし Fabric では、Spark ノートブック、Spark ジョブ定義、Lakehouse ジョブなど、さまざまな項目で使用されるコンピューティングの基準として CU が使用されます。

Spark では 1 つの CU が、コンピューティング用の Spark 仮想コア 2 つに変換されます。 たとえば F64 SKU を購入した場合、Spark エクスペリエンスで 128 個の Spark 仮想コアを使用できます。

すべての Spark 操作はバックグラウンド操作であり、24 時間にわたってスムージングされます。

詳細については、「Fabric Spark の請求および活用レポート」を参照してください。

コンピューティングを最小限に抑えるために考慮すべきいくつかのポイントを次に示します。

  • 常に効率的な Spark コードを記述するように努めます。 詳細については、「Azure Synapse Analytics で Apache Spark ジョブを最適化する」と「Apache Spark における書き込みの最適化の必要性について」のページを参照してください。
  • Spark ジョブに必要な Executor を予約し、他の Spark ジョブやワークロードのリソースを解放します。 リソースを解放しないと Spark ジョブが HTTP 430 ステータスで失敗する可能性が高まります。このエラーが発生する場合、容量に対してリクエストが多すぎることを意味します。 Fabric 監視ハブでは、ハブ内のノートブックに割り当てられている Executor の数や、ノートブックで実際に使用される Executor の数を確認することもできます。 Spark ジョブは必要なノードのみを予約し、SKU の制限内で並列送信を可能にします。
  • Spark プールは SKU でサポートされている仮想コアの最大数のみを使用するように構成することができます。 ただし、SKU の制限内で並列 Spark ジョブを受け入れることで、データ エンジニアリング ワークロードをスケールアウトできます。 この手法は一般にバースト係数と呼ばれ、Spark ワークロードではデフォルトで容量レベルで有効になっています。 詳細については、「コンカレンシーの調整とキューイング」に関する記事を参照してください。
  • アクティブな Spark セッションでは、容量に対する CU 使用率が上昇する可能性があります。 このため、使用されていない場合は、アクティブな Spark セッションを停止しておくことが重要です。 Spark のデフォルトのセッション有効期間は、20 分に設定されています。 ノートブックまたは Spark ジョブ定義のセッション タイムアウトは、ユーザーが変更できます。

リアルタイム インテリジェンス

KQL データベースの CU の使用量は、データベースがアクティブな秒数と、使用されている仮想コアの数に基づいて計算されます。 たとえば、データベースが 4 つの仮想コアを使用し、10 分間アクティブになっている場合、2,400 (4 x 10 x 60) 秒の CU を消費します。

KQL データベース操作はすべて対話型の操作です。

自動スケーリング メカニズムは、KQL データベースのサイズを決定するために使用されます。 これにより使用パターンに基づいてコストが最適化され、最適なパフォーマンスを発揮できます。

他の Fabric エンジンでデータを使用できるように、KQL データベースは OneLake と同期します。 KQL データベースが実行する読み取りと書き込みのトランザクションの数に基づいて、容量から CU が使用されます。 これには、Azure Data Lake Storage (ADLS) Gen2 アカウントの読み取り操作および書き込み操作と同等の OneLake 読み取り/書き込みメーターを利用します。

Data Factory

このセクションでは、Data Factory でのデータフローとデータ パイプラインの最適化について説明します。

すべての操作はバックグラウンド操作であり、24 時間にわたってスムージングされます。

コンピューティングを最小限に抑えるために考慮すべきいくつかのポイントを次に示します。

  • 非効率な Power Query ロジックをなくし、マージや並べ替えなど、コストのかかるデータ変換を最小限に抑えて最適化します。
  • 可能な限りクエリ フォールディングが行われるように務めます。 クエリ フォールディングによってデータ ソースと転送先の間で転送の必要があるデータの量が減り、データフローのパフォーマンスを向上させることができます。 クエリ フォールディングが行われない場合、Power Query はデータ ソースからすべてのデータを取得してローカルで変換を実行しますが、これは非効率的で処理に時間がかかる場合があります。
  • 小規模なデータ量を操作する場合や単純な変換を実行する場合は、ステージングを無効にします。 データ ウェアハウスを読み込む場合など、ステージングが必要になる場合もあります。
  • データ ソースが必要とする以上の頻度でデータを更新しないようにします。 たとえば、データ ソースの更新が 24 時間に 1 回しか行われない場合、1 時間おきにデータを更新しても値はそれ以上変化しません。 頻繁に更新するのではなく、データが最新かつ正確であることを確認するために、適切な頻度でデータを更新することを検討してください。

Power BI

Power BI の操作は対話型かバックグラウンド型のどちらかになります。

通常、次のような対話型操作では、コンピューティングの使用率は高くなります。

  • ベスト プラクティスに沿っていないセマンティック モデル。 たとえば、一対多リレーションシップのスター スキーマ設計を採用していないものや、 複雑でコストの高い行レベル セキュリティ (RLS) フィルターが含まれているものが考えられます。 ベスト プラクティスに従うかどうかを判断するにあたっては、表形式エディターとベスト プラクティス アナライザーの使用を検討してください。
  • 非効率的な DAX メジャー。
  • 表示される視覚的要素が多すぎるため、視覚効果の更新が遅くなる可能性があるレポート ページ。
  • 表示される結果のカーディナリティが高い (行または列が多すぎる)、またはメジャーが多すぎるレポートの視覚的要素。
  • 容量サイズに対してユーザーが多すぎるために、その容量におけるコンカレンシーが高い状態。 クエリのスケールアウトを有効にして、コンカレンシーの高いセマンティック モデルのユーザー エクスペリエンスを改善することを検討してください (ただし、コンピューティングの総量は増えません)。

通常、次のようなバックグラウンド型操作では、コンピューティングの使用率は高くなります。

  • Power Query ロジックによる非効率的または過度に複雑なデータ変換。
  • ファクト テーブル のサイズが大きいのにクエリ フォールディングや増分更新が行われていない。
  • 多数の Power BI レポートまたはページ割り付けレポートが同時に生成されるレポートのバースト動作。

関連するコンテンツ

その他の質問 Fabric コミュニティに質問してみましょう。