イベントハウスと KQL データベース使用量

イベントハウスとKQL データベースはフル マネージド Kusto エンジンで動作します。 イベントハウスまたはKQL データベースを使用する場合、5 秒から 10 秒以内の分析に使用できるコンピューティングを期待できます。 コンピューティング リソースは、データ分析ニーズに応じて増加します。 この記事では、KustoUpTime やストレージを含めて、Microsoft Fabric での KQL データベースのコンピューティング使用状況レポートについて説明します。

Fabric の容量を使用すると、使用料金は、Azure portal で Microsoft Cost Management のサブスクリプションの下に表示されます。 Fabric の課金について理解するには、「Azure の請求書で Fabric の容量を把握する」を参照してください。

重要

Microsoft Fabric ワークロード使用率の変化

従量課金制は、いつでも変更される可能性があります。 Microsoft は、電子メールまたは製品内通知を介して通知を提供するために、合理的な努力を行います。 変更は、Microsoft のリリース ノートまたは Microsoft Fabric ブログに記載されている日付に有効になるものとします。 Microsoft Fabric ワークロード使用率に変化があり、特定のワークロードを使用するために必要な容量ユニット (CU) が大幅に増加する場合、お客様は、選択した支払い方法で提供されているキャンセル オプションを使用できます。

容量

Fabric で購入された容量 SKU に基づいて、すべての Fabric ワークロード間で共有される一連の容量ユニット (CU) に対する権利が得られます。 サポートされているライセンスの詳細については、「Microsoft Fabric ライセンス」を参照してください。

''容量'' は、特定の時点で使用できるリソースの専用セットです。 容量では、アクティビティを実行したり、出力を生成したりするリソースの機能が定義されます。 リソースによって、異なる時間に CU が消費されます。 KQL データベースによって使用される容量は、KustoUpTime 操作に基づきます。

KustoUpTime

イベントハウスのKustoUpTime は、イベントハウスによって使用される仮想コアの数に対してイベントハウスがアクティブになっている秒数です。 自動スケーリング メカニズムは、イベントハウスのサイズを決定するために使用されます。 このメカニズムにより、実際の使用パターンに基づいて確実にコストとパフォーマンスが最適化されます。 複数の KQL データベースがアタッチされているイベントハウスには、イベントハウス項目の KustoUpTime だけが表示されます。 KQL データベース サブ項目の使用状況は表示されません。

たとえば、30 秒間アクティブな仮想コア 4 個を使用する 4 KQL データベースを備えたイベントハウスでは、120 秒の容量ユニットが使用されます。

KQLデータベースのKustoUpTime は、データベースによって使用される仮想コアの数に対して KQL データベースがアクティブになっている秒数です。 自動スケーリング メカニズムは、KQL データベースのサイズを決定するために使用されます。 このメカニズムにより、実際の使用パターンに基づいて確実にコストとパフォーマンスが最適化されます。

たとえば、30 秒間アクティブな仮想コア 4 個を使用するデータベースでは、120 秒の容量ユニットが使用されます。

Note

KQL データベースがイベントハウスのサブ項目である場合には、KustoUpTime はイベントハウス項目に再変換され、データベース項目は一覧に表示されません。

KustoUpTime を監視する

Microsoft Fabric Capacity Metric アプリを使用して、KustoUpTime を監視できます。 Metric アプリのコンピューティング ページを理解する方法については、メトリック アプリのコンピューティング ページの理解に関するページを参照してください。 この例では、KustoUpTime の監視に固有の情報を示します。

Note

容量の使用状況を監視するには、容量管理者である必要があります。 詳細については、「Microsoft Fabric 管理者ロールを理解する」を参照してください。

次の図は、Fabric Capacity Metric アプリで 容量を監視して得られたサンプル コンピューティング ページを示しています。

以下に、例から得られる分析情報の一部を示します。

• 調査対象となっている容量は、rtafielddemo という名前です。
• 選択した日の容量ユニットは、RTA フィールド デモと呼ばれる 1 つのワークスペースによって使用されました。
• [アイテム] ビューがフィルター処理され、イベントハウスと KQL データベースの両方が表示されます。
• イベントハウス項目などの 1 つの項目を選択すると、CU の使用状況が操作ごとに分割されます。
• アプリの右側にある使用率グラフは、長時間にわたり、ほぼ 100% の CU 使用率を示しています。 この高い使用率は、ユーザーが経験したクエリ調整の原因を説明することだでき、容量ユニットを増やす必要があることを示しています。

ストレージの課金

ストレージは、Fabric または Power BI Premium 容量ユニットとは別に課金されます。 KQL データベースに取り込まれたデータは、OneLake Cache Storage と OneLake Standard Storage というふたつ のストレージ層に格納されます。

• OneLake Cache Storage は、最速のクエリ応答時間を提供するために使用される Premium のストレージです。 キャッシュ ポリシーを設定すると、このストレージ層に影響があります。 たとえば、通常 7 日間でクエリを実行して戻す場合、最適なパフォーマンスを得るためにキャッシュ保持を七日間に設定できます。 このストレージ層は、Azure ADLS (Azure Data Lake Storage) の Premium レベルに相当します。

Note

最小消費を有効にすると、OneLake Cache Storage に対して課金されません。 最小容量が設定されている場合には、イベントハウスは常にアクティブになり、KustoUpTime が 100% になります。

• OneLake Standard Storage は、クエリ可能なすべてのデータを持続させ、格納するために使用される Standard のストレージです。 アイテム保持ポリシーを設定すると、このストレージ層に影響があります。 たとえば、クエリ可能なデータを 365 日間維持する必要がある場合は、保持期間を 365 日に設定できます。 このストレージ層は、Azure ADLS (Azure Data Lake Storage) の ホット層に相当します。

OneLake Storage を監視する

Microsoft Fabric Capacity Metric アプリを使用すると、容量管理者は OneLake Storage を監視することができます。 Metric アプリのストレージ ページを理解する方法については、メトリック アプリのストレージ ページの理解に関するページを参照してください。

次の図は、Fabric Capacity Metric アプリで KQL データベースを監視して得られたサンプル ストレージ ページを示しています。

関連するコンテンツ

• Microsoft Fabric の概念とライセンス
• Microsoft Fabric Capacity Metrics アプリとは?
• KQL データベースを作成する