Databricksにおけるコスト管理のベストプラクティス

このブログは、Databricks環境の管理と保守に携わる方々にとって重要なトピックに焦点を当てるAdmin Essentialsシリーズの一部です。追加のトピックに関するブログにもご注目ください。また、以前のブログで紹介したワークスペースと管理者のベストプラクティスもぜひご覧ください！

クラウドプラットフォームを利用する主な利点の1つは、その柔軟性です。Databricks Lakehouse Platformは、ユーザーにほぼ瞬時に水平スケーラブルなコンピューティングへの簡単なアクセスを提供します。しかし、コンピューティングリソースを簡単に作成できる反面、管理されずにガードレールがない状態では、クラウドコストが急増するリスクがあります。管理者として、私たちは常に、法外なインフラコストを回避しつつ、ユーザーが不必要な摩擦なく作業できるようにする完璧なバランスを見つけようとしています。このブログでは、このバランスを見つけ、ユーザーの生産性を低下させることなくコストを管理するためのDatabricks管理者ツールについて説明します。

DBUとは何ですか？

Databricksプラットフォームで利用可能なコスト管理について説明する前に、ワークロードを実行するためのコストの基礎を理解することが重要です。Databricks Unit (DBU) は、プラットフォーム内の消費の基本単位です。SQLウェアハウスを除き、消費されるDBUの量は、ノード数と、それぞれのクラスターを構成する基盤となるVMインスタンスタイプの計算能力に基づいています（SQLウェアハウスは本質的にクラスターのグループであるため、DBUレートはエンドポイントを構成するクラスターのDBUレートの合計です）。最高レベルでは、各クラウドは類似のクラスターに対してわずかに異なるDBUレートを持ちますが（ノードタイプはクラウドによって異なるため）、Databricksのウェブサイトには、サポートされている各クラウドプロバイダー（AWS | Azure | GCP）向けのDBU計算ツールがあります。

DBUの使用量をドルに換算するには、クラスターのDBUレート、および該当するDBUを生成したワークロードタイプ（例：Automated Job、All-Purpose Compute、Delta Live Tables、SQL Compute、Serverless Compute）、そしてサブスクリプションプランのティア（AzureとGCPではStandardとPremium、AWSではStandard、Premium、Enterprise）が必要です。例えば、Enterprise Databricksワークスペースでは、AWSでのJobs DBUのリストレートは20セント/DBUです。3 DBU/時間で実行されるインスタンスタイプの場合、4ノードのジョブクラスターは1時間あたり2.40ドル（0.2ドル * 3 * 4）で課金されます。DBU計算ツールを使用して合計料金を計算でき、リスト価格はSKUとティアを含むクラウド固有のマトリックスにまとめられています（AWS | Azure | GCP）。

コストはコンピューティングリソース、特にクラスターの使用量を通じて計算されるため、クラスターポリシーを通じてDatabricksワークスペースを管理することが不可欠です。次のセクションでは、クラスターポリシーのさまざまな属性がDBU消費をどのように制限し、プラットフォームのコストを効果的に管理できるかについて説明します。続くセクションでは、考慮すべき基盤となるクラウドコストの一部と、Databricksの使用状況と請求を監視する方法についてもレビューします。

クラスターポリシーによるコスト管理

クラスターポリシーとは？

クラスターポリシーを使用すると、管理者は新しいクラスターを作成する際に利用可能な構成のセットを制御でき、これらのポリシーは個々のユーザーまたはユーザーグループに割り当てることができます。デフォルトでは、すべてのユーザーはワークスペース内で「無制限のクラスター作成を許可する」権限を持っています。この権限は、割り当てられたポリシー以外の制限なしにクラスターを作成できるため、管理されていない暴走コストにつながる可能性があるため、めったに使用すべきではありません。

ポリシー内で、管理者は変更不可能な固定値、より許容範囲の広い値の範囲と正規表現、または完全にオープンなデフォルト値を通じて、各構成設定を制限できます。ポリシーは、VMインスタンスタイプなどのより詳細な設定から、1時間あたりの最大許容DBUやクラスターワークロードタイプなどのより高レベルの「合成」属性に至るまで、あらゆるものに制限を設けることで、単一のクラスターが消費できるDBUの量を効果的に制限します。

一見すると、より制限の厳しいクラスターがコスト削減につながるように思えるかもしれませんが、必ずしもそうとは限りません。非常に制限の厳しいポリシーは、タスクをタイムリーに完了できないクラスターにつながり、ジョブの実行時間が長くなることでコストが増加します。したがって、クラスターポリシーを策定する際には、ユースケース駆動型のアプローチを取り、チームのワークロードに適切な量のコンピューティング能力を提供することが不可欠です。これを支援するために、Databricksは最適化されたApache Spark(™)ランタイムや、特にPhotonエンジンなどのパフォーマンス機能を提供し、処理時間の短縮を通じてコスト削減を実現します。ランタイムに関するポリシーについては後続のセクションで説明しますが、まずは水平スケーリングを管理するポリシーから始めましょう。

ノード数の制限、オートスケーリング、オートターミネーション

コンピューティングコストに関してよくある懸念は、利用率の低いクラスターやアイドル状態のクラスターです。Databricksは、これらの懸念を動的に、かつユーザーの直接的な介入なしに軽減するためのオートスケーリングおよびオートターミネーション機能を提供します。これらの機能は、ユーザーが利用できるコンピューティングリソースを妨げることなく、ポリシーを通じて強制することができます。

ノード数の制限とオートスケーリング

ポリシーは、クラスターのオートスケーリング機能が、設定された最小数のワーカーノードで有効になるように強制できます。例えば、以下のポリシーはオートスケーリングが使用されることを保証し、ユーザーが必要な場合にのみ最大10個のワーカーノードを持つクラスターを利用できるようにします。

強制タイプがワーカーの最大数に対する「範囲」であるため、作成時に10未満の値に変更できます。ただし、最小ワーカー数は「固定」で1に設定されているため、クラスターは利用率が低い場合に常に1つのワーカーにスケールダウンし、コンピューティングコストの節約を保証します。ここに示されているもう1つの追加フィールドは「defaultValue」で、その名前が示すように、クラスター構成ページのワーカーの最大設定にデフォルト値を設定します。これは、デフォルトでクラスター内の最大ワーカー数を減らすのに役立ち、作成者がクラスターを10ノードまでスケールアップすることを意図的に許可する必要があるようにします。

ポリシーを作成および割り当てる際のユースケースを理解することは、ノード数の制限とオートスケーリングを強制すべきかどうかに関して非常に重要です。例えば、オートスケーリングの強制は、以下の場合に効果的です。

• 共有の汎用コンピューティングクラスター：チームは、アドホック分析や実験的なジョブ、または機械学習ワークロードのために1つのクラスターを共有できます。
• 複雑度が異なる長時間実行バッチジョブ：ジョブはオートスケーリングを活用して、必要なリソースの程度に応じてクラスターをスケールできます。

オートスケーリングを使用するジョブは、クラスターのスケールアップがノードの起動時間により完了を遅らせる可能性があるため、時間制約があるべきではありません。これを軽減するために、可能な限りインスタンスプールを使用してください。

標準的なストリーミングワークロードは、これまでオートスケーリングの恩恵を受けることができませんでした。単に最大ノード数までスケールし、ジョブの期間中その状態を維持していました。これらの種類のワークロードに取り組むチームにとって、より本番環境に対応したオプションは、Delta Live Tablesと拡張オートスケーリングを活用することです（DLTワークロードは、このブログで後述する「cluster_type」ポリシーで強制できます）。DLTはストリーミングワークロードを念頭に開発されましたが、Trigger.AvailableNowオプションを活用することで、ターゲットテーブルの増分更新を可能にし、バッチパイプラインにも同様に適用可能です。

クラスターサイジングポリシーのもう1つの一般的な構成は、シングルノードポリシーです。シングルノードクラスターは、プラットフォームを探索したい新規ユーザー、非分散型MLライブラリを活用しているデータサイエンスチーム、および軽量な探索的データ分析を行う必要があるユーザーに役立ちます。シングルノードクラスターポリシーの例で示されているように、ポリシーは特定のインスタンスプールを活用するように制限できます。その結果、このポリシーが割り当てられたチームは、プールの最大容量設定に基づいて作成できるシングルノードクラスターの数に制限を受けます。

自動終了

Databricksプラットフォーム内でクラスターを作成する際に設定できるもう1つの属性は自動終了時間であり、これは設定されたアイドル時間の後にクラスターをシャットダウンします。アイドル期間は、Sparkジョブ、Structured Streaming、JDBC呼び出しなど、クラスター上でのあらゆる種類の活動がないことによって定義されます。クラスター上での活動とは見なされない活動は、クラスターへのSSH接続の作成やbashコマンドの実行です。

最も一般的な自動終了ウィンドウは1時間です。例として、固定された1時間のウィンドウで設定されたポリシーを以下に示します。

この例では、「hidden」属性もこのコントロールに追加されており、ユーザーのクラスター構成ページからウィジェットを非表示にします。この属性は、ジョブおよびDLTクラスターは割り当てられたすべてのタスクが完了すると自動的にシャットオフされるため、オールパーパス（多目的）クラスターにのみ適用されます。

クラスターランタイムとPhoton

Databricks Runtimesは、Databricks のパフォーマンス最適化の重要な部分です。お客様は、設定に多くの変更を加えることなく、より新しいランタイムを実行するクラスターに切り替えることで、自動的にメリットを享受できることがよくあります。クラスターポリシーを作成する管理者にとって、クラスター作成者に新しいランタイムを実行することの効果について教育することは、コスト削減のために価値があります。ユーザーが新しいランタイムに移行するにつれて、古いランタイムはポリシーを通じて段階的に廃止され、制限される可能性があります。簡単な例として、ユーザーをバージョン11.0または11.1のDB Runtimesのみに制限する属性「spark_version」を以下に示します。

しかし、このポリシーは、許可リストを拡張するか、正規表現を使用することで、他のバージョン、MLランタイム、Photonランタイム、またはGPUランタイムを許可することで、より柔軟にすることができます。

コスト削減のためにパフォーマンスを最適化する際に考慮すべきもう1つのランタイム機能は、当社のベクトル化されたPhoton engineを使用することです。Photonは、ベクトル化されたSparkエンジンを通じてワークロードの一部をインテリジェントに高速化し、これによりお客様はパフォーマンスが3倍から8倍向上するのを目の当たりにします。この大幅なパフォーマンス向上は、ジョブの高速化と、結果として総コストの削減につながります。

クラウドインスタンスタイプとスポットインスタンス

クラスター作成時、VMインスタンスタイプはドライバーノードとワーカーノードの両方で個別に選択できます。利用可能なインスタンスタイプはそれぞれ異なるDBUレートが計算され、各クラウドのDatabricks料金見積もりページで確認できます（AWS、Azure、GCP）。例えば、AWSでは、2コアと8GBメモリのm4.largeインスタンスタイプは1時間あたり0.4 DBUを消費しますが、64コアと256GBメモリのm4.16xlargeインスタンスタイプは、オールパーパスコンピューティングモードで1時間あたり12 DBUを消費します。コンピューティングリソース間でこれほど大きなDBU使用量の範囲があるため、ポリシーを通じてこの属性を制限することが重要です。

クラウドインスタンスタイプは、「allowlist」タイプ、または「fixed」タイプによって、1種類のインスタンスのみが使用されるように最も便利に制御できます。以下の例は、ユーザーが利用できるワーカーノードタイプにポリシーを設定する属性「node_type_id」と、ドライバーノードタイプにポリシーを設定する「driver_node_type_id」を示しています。

これらのポリシーを作成する管理者として、各チームが実行しているワークロードの種類を把握し、適切なポリシーを割り当てることが重要です。データ量が少ないワークロードは、より低いメモリのインスタンスタイプのみを必要としますが、ディープラーニングモデルのトレーニングは、一般により多くのDBUを消費するGPUクラスターから最も恩恵を受けます。最終的に、インスタンスタイプを制限することはバランスの取れた行動です。チームがポリシー制限のために利用可能なリソースよりも多くのリソースを必要とするワークロードを実行しなければならない場合、ジョブの完了に時間がかかり、結果としてコストが増加する可能性があります。定義されたワークロードのためにクラスターを構成する際に従うべきいくつかのベストプラクティスがあります。例えば、データシャッフルを必要とする多くの広範な変換で構成される複雑なワークロードには、水平スケーリング（ノードの追加）よりも垂直スケーリング（より強力なインスタンスタイプを使用）が推奨されます。とはいえ、経験の少ないチームには、より一般的な複雑でないワークロードでは不必要に強力なVMはあまりメリットを提供しないため、より小さなインスタンスタイプに制限されたポリシーを割り当てるべきです。

Databricksプラットフォームの比較的新しいコスト削減機能の1つは、Arm64命令セットアーキテクチャに基づいて構築されたAWS Graviton対応VMを使用できることです。AWSが提供する調査と、DatabricksがPhotonを使用して実行したベンチマークに基づいて、これらのGraviton対応インスタンスは、AWS EC2インスタンスタイプセットで利用可能な最高の価格性能比の一部を持っています。

スポットインスタンス

Databricksは、スポットインスタンスを使用して、特に基盤となるVMコンピューティングコストを節約できる別の構成を提供します（GCP上のDatabricksを通じて利用できるオプションは、スポットインスタンスに似たプリエンプティブルインスタンスを使用します）。スポットインスタンスは、基盤となるクラウドプロバイダーが提供する余剰VMであり、ライブマーケットプレイスで入札にかけられます。これらのインスタンスは大幅な割引を可能にし、場合によってはインスタンスのコンピューティングコストを最大90%削減できます。スポットインスタンスのトレードオフは、基盤となるクラウドプロバイダーによっていつでも短い通知期間（AWSでは2分、AzureとGCPでは30秒）で回収される可能性があることです。

AWSを使用する場合、スポットインスタンスの使用を含むクラスターポリシーを次のように定義できます。

Azureの場合：

これらの例では、最初のクラスター作成時に、1つのノード（特にドライバーノード）のみがオンデマンドインスタンスになり、クラスター内の他のすべてのノードはスポットインスタンスになります。ここでフォールバックオプションが有効になっているため、クラウドプロバイダーに回収されたスポットインスタンスを置き換えるためにオンデマンドインスタンスが要求されます。GCPのポリシーでは現在「first_on_demand」属性を強制できませんが、プリエンプティブルノードは次のように強制できます。

デフォルトでは、プリエンプティブルインスタンスが有効になっている場合、クラスター起動時にドライバーノードのみがオンデマンドインスタンスを使用します。

信頼性やワークロードの実行時間が優先されない実験的なワークロードやアドホッククエリのようなフォールトトレラントなプロセスを実行する場合、スポットインスタンスはインスタンスコストを抑える簡単な方法を提供します。そのため、スポットインスタンスは開発およびステージング環境に最適です。

スポットインスタンスの強制停止率と価格は、Tシャツサイズやクラウドリージョンによって異なります。そのため、最適なクラスター構成を計画するには、AWS Spot Instance Advisor、Azureアカウントポータル内のAzure Spot Pricing and History、またはGoogle Cloud Pricing Calculatorなど、各クラウドプロバイダーのツールが役立ちます。

Azureにはコスト管理の追加手段があります。リザーブドインスタンスはDatabricksで使用でき、不安定性を追加することなく、別の（潜在的に大幅な）割引を提供します。

クラスターのタグ付け

チームが利用しているリソースを監視する機能は、クラスターのタグ付けによって実現されます。これらのタグはクラウドプロバイダーレベルまで伝播し、Databricksプラットフォームからの使用量とコスト、および基盤となるクラウドコストの両方を帰属させることができます。ただし、クラスターポリシーがない場合、クラスターを作成するユーザーはタグを割り当てる必要がありません。そのため、管理者がDatabricksプラットフォームへのアクセスを要求しているチームのためにポリシーを作成する際には、そのポリシーに、割り当てられるチームに固有のクラスタータグの強制を含めることが不可欠です。

カスタムコストセンタータグを強制するポリシーを作成する例を次に示します。

クラスターを使用するチームを識別するタグが割り当てられると、管理者は使用ログを分析して、DBUと発生したコストをクラスターを利用しているチームに紐付けることができます。これらのタグはVM使用レベルにも伝播し、クラウドプロバイダーのインスタンスコストもチームまたはコストセンターに帰属させることができます。使用ログの一般的な監視オプションについては、以下のセクションで説明します。

クラスタープールを使用する際のクラスタータグに関する重要な違いは、クラスタープールタグのみ（クラスタータグではない）が基盤となるVMインスタンスに伝播することです。クラスタープールの作成はクラスターポリシーによって制限されないため、管理者はチームに利用権限を割り当てる前に、適切なタグを持つクラスタープールを作成する必要があります。チームは、クラスターを作成する際に、ポリシーを通じて該当するプールにアタッチするアクセス権を持つことができます。これにより、プールを使用するチームに関連付けられたタグが、課金のためにVMインスタンスレベルまで伝播されることが保証されます。

ポリシーの仮想属性

クラスター構成ページに表示される設定以外にも、ポリシーによって制限できる「仮想」属性があります。このカテゴリで利用可能な2つの属性は、具体的には"dbus_per_hour" と "cluster_type"です。

「dbus_per_hour」属性を使用すると、DBU使用量がポリシーで設定された制限を下回る限り、クラスターの作成者は構成に柔軟性を持たせることができます。この属性自体は、以前に議論された属性のように基盤となるVMインスタンスに起因するコストを直接制限するものではありません（ただし、DBUレートはVMインスタンスレートと相関することがよくあります）。以下は、ユーザーが1時間あたり10 DBU未満を使用するクラスターを作成するように制限するポリシー定義の例です。

利用可能なもう1つの仮想属性は「cluster_type」で、これを利用してユーザーを異なる種類のクラスターから制限できます。この属性を通じて許可されるタイプは、「all-purpose」、「job」、および「dlt」で、最後のものはDelta Live Tablesを指します。このポリシーの使用例を次に示します。

クラスタータイプの制限は、開発およびデプロイのライフサイクル全体に関わる異なるチームと協力する場合に特に価値があります。新しいETLまたは機械学習パイプラインの開発に取り組むチームは通常、オールパーパス（all-purpose）クラスターへのアクセスのみを必要とし、デプロイエンジニアリングチームはジョブ（job）クラスターまたはDelta Live Tables (DLT)を使用します。これらのポリシーは、開発およびデプロイのライフサイクルの各特定の段階で適切なクラスタータイプが使用されるようにすることで、ベストプラクティスを強制できます。

一般的な悪い慣行の1つは、自動化されたワークロードをオールパーパス（all-purpose）クラスターで共有してデプロイすることです。一見すると、消費量が単一のクラスターに紐付けられるため、より安価なオプションに見えるかもしれません。しかし、この種の構成はリソース競合を引き起こし、クラスターの実行時間を長引かせ、コンピューティングコストを増加させます。代わりに、一度に1つのジョブを実行するように分離されたジョブ（job）クラスターを使用すると、一連のジョブを完了するために必要なコンピューティング時間を短縮できます。これにより、Databricks DBUの使用量が削減され、基盤となるクラウドインスタンスのコストも削減されます。ジョブクラスターが提供するDBUあたりの低コストレートと相まって、パフォーマンスの向上は劇的なコスト削減につながります。お客様の中には、ワークロードのわずか10%をオールパーパス（all-purpose）クラスターからジョブ（job）クラスターに移行するだけで、数万ドルを節約した例もあります。ジョブクラスターの再利用を活用することで、各タスク間のクラスター起動時間をなくし、一連のジョブのタイムリーな完了を保証できます。

チームが適切なワークロードのためにクラスターを作成できるようにするポリシーを策定するには、いくつかのベストプラクティスに従う必要があります。一般的な制限付きポリシーパターンには、シングルノードクラスター、ジョブ専用クラスター、またはチームで共有するためのオートスケーリングオールパーパス（all-purpose）クラスターがあります。完全なポリシーの例はこちらで確認できます。

クラウドプロバイダーのコスト

Databricksの消費量（DBU）の観点からは、すべてのコストは利用されたコンピューティングリソースに帰属させることができます。ただし、基盤となるクラウドのネットワークとストレージに起因するコストも考慮する必要があります。

ストレージ

Databricksのようなプラットフォームを使用する利点は、Azure上のADLS Gen2、AWS上のS3、GCP上のGCSのような比較的安価なクラウドストレージとシームレスに連携することです。これは、Delta Lakeフォーマットを使用する場合に特に有利です。Delta Lakeは、管理が難しいストレージ層に対してデータガバナンスを提供し、Databricksと組み合わせて使用するとパフォーマンス最適化も提供します。

ストレージに関してよくある誤った最適化の1つは、可能な限りライフサイクル管理を使用しないことです。最近のケースでは、約2.5PBの顧客S3バケットを観察しましたが、そのうち真のデータは約800TBのみでした。残りの1.7PBは価値のないバージョン管理されたデータでした。古いオブジェクトをクラウドストレージから削除することは一般的なベストプラクティスですが、これをDelta Vacuumサイクルと整合させることが重要です。ストレージのライフサイクルがDeltaによってバキュームされる前にオブジェクトを削除してしまうと、テーブルが破損する可能性があります。ライフサイクルポリシーを広く実装する前に、必ず非本番データでテストしてください。ポリシーの例は次のようになります。

S3のGlacierやADLSのArchiveのような非標準ストレージティアはDatabricksではサポートされていないため、これらのティアを使用する前に必ずVacuumを実行してください。

ネットワーク

Databricksプラットフォーム内で使用されるデータは、データウェアハウスからKafkaのようなストリーミングシステムまで、さまざまなソースから取得できます。しかし、最も一般的な帯域幅利用者は、S3やADLSのようなストレージ層への書き込みです。ネットワークコストを削減するために、Databricksワークスペースは、リージョン間およびアベイラビリティゾーン間で転送されるデータ量を最小限に抑えることを目標にデプロイする必要があります。これには、可能な限りデータの大部分と同じリージョンにデプロイすることや、必要に応じてリージョンワークスペースを起動することが含まれます。

AWS上のDatabricksワークスペースで顧客管理VPCを使用する場合、VPCエンドポイントを活用することで、インターネットゲートウェイやNATデバイスなしでVPCとAWSサービス間の接続を可能にし、ネットワークコストを削減できます。エンドポイントを使用すると、ネットワークトラフィックによって発生するコストが削減され、接続のセキュリティも向上します。特にゲートウェイエンドポイントはS3やDynamoDBへの接続に、インターフェースエンドポイントはDatabricksコントロールプレーンに接続するコンピューティングインスタンスのコスト削減に同様に使用できます。これらのエンドポイントは、ワークスペースがセキュアクラスター接続を使用している場合に利用可能です。

同様にAzureでは、DatabricksがADLSなどのサービスと通信するためのPrivate Linkまたはサービスエンドポイントを設定して、NATコストを削減できます。GCPでは、Private Google Access (PGA) を活用することで、Google Cloud Storage (GCS) とGoogle Container Registry (GCR) 間のトラフィックがパブリックインターネットではなくGoogleの内部ネットワークを使用し、結果としてNATデバイスの使用も回避できます。

サーバーレスコンピューティング

分析ワークロードの場合、サーバーレスオプションを有効にしたSQLウェアハウスを使用することを検討してください。Serverless SQLでは、Databricksプラットフォームがワークロードが開始されるたびにユーザーに割り当てられる準備ができたコンピューティングインスタンスのプールを管理します。そのため、基盤となるインスタンスのコストは、2つの別々の料金（DBUコンピューティングコストと基盤となるクラウドコンピューティングコスト）ではなく、Databricksによって完全に管理されます。

サーバーレスは、クエリ実行時に即座にコンピューティングリソースを提供することでコスト上の利点をもたらし、利用率の低いクラスターのアイドルコストを削減します。同様に、サーバーレスはより正確なオートスケーリングを可能にし、ワークロードを効率的に完了させることで、パフォーマンスを向上させ、結果としてコストを節約します。サーバーレスオプションはまだポリシーを通じて直接強制することはできませんが、管理者はSQLウェアハウス作成権限を持つすべてのユーザーに対してこのオプションを有効にできます。

使用状況の監視

クラスターポリシーとワークスペースのデプロイ構成を通じてコストを管理することに加え、管理者がコストを監視できることも同様に重要です。Databricksは、使用状況分析に基づいて通知やアラートを自動化する機能を備えたいくつかのオプションを提供しています。具体的には、管理者はDatabricksのアカウントコンソールを使用して使用状況の概要を素早く確認し、使用状況ログを分析してより詳細なビューを取得し、新しいBudgets APIを使用して予算を超過した際にアクティブな通知を受け取ることができます。

アカウントコンソールの使用

Databricks Enterprise 2.0アーキテクチャでは、アカウントコンソールに使用状況ページが含まれており、管理者はDBUまたはドル建ての金額で使用状況を視覚的に確認できます。このチャートは、集計ビュー、ワークスペースごとのグループ化、またはSKUごとのグループ化で消費量を示すことができます。SKUでグループ化する場合、使用状況はジョブクラスター、オールパーパスクラスター、またはSQLコンピューティングなどの例で表示されます。チャートがワークスペースごとに分割されている場合、DBU消費量で上位9つのワークスペースのグループが表示され、最後のグループは他のすべてのワークスペースの合計として表示されます。個々のワークスペースのより詳細な情報を理解するために、ページの下部には各ワークスペースとSKUごとのDBU/$USD金額を個別にリストしたテーブルがあります。このページは、管理者がアカウント下のすべてのワークスペースの使用状況とコストの全体像を把握するのに適しています。

DatabricksはAzureプラットフォーム上のファーストパーティサービスであるため、Azure Cost Managementツールを活用してDatabricksの使用状況を監視できます（Azure上の他のすべてのサービスとともに）。AWSおよびGCP上のDatabricksデプロイメント用のアカウントコンソールとは異なり、Azureの監視機能はタグの粒度レベルまでデータを提供します。Azureのカスタムタグは、クラスターレベルだけでなくワークスペースレベルでも作成できます。これらのタグは、使用状況データを分析する際にグループおよびフィルターとして表示されます。これらのレポートでは、Databricksコンピューティングによって生成された使用状況が、基盤となるインスタンスの使用状況とともに同じビュー内で便利に表示されます。ログは、次のセクションで説明するように、スケジュールに基づいてストレージコンテナに配信され、より自動化された分析とアラートに使用することもできます。

管理者は、アカウントコンソールの使用状況ページから、またはAccount APIを使用して、使用状況ログを手動でダウンロードできます。ただし、これらの使用状況ログを分析するためのより効率的なプロセスは、クラウドストレージへのログの自動配信（AWS、GCP）を設定することです。これにより、各ワークスペースの使用状況を詳細なスキーマで含む日次CSVが生成されます。

3つのクラウドのいずれかで利用状況ログの配信が設定されると、一般的なベストプラクティスは、Databricks内にデータパイプラインを作成し、このデータを毎日取り込み、スケジュールされたワークフローを使用してDeltaテーブルに保存することです。このデータは、利用状況分析に使用したり、消費量が設定されたしきい値に達したときにコストセンターの支出に責任を持つ管理者やチームリーダーに通知するアラートをトリガーしたりするために使用できます。

Budgets API

Databricksコンピューティングコストの予算編成を容易にする今後の機能の1つは、Account API内の新しい予算エンドポイント（現在プライベートプレビュー中）です。これにより、Databricksワークスペースを使用する誰もが、ワークスペース、SKU、またはクラスタータグでフィルタリングされた任意のカスタム期間で予算しきい値に達したときに通知を受け取ることができます。したがって、このAPIを通じて、任意のワークスペース、コストセンター、またはチームの予算を設定できます。

まとめ

Databricks Lakehouse Platformは多くのユースケースとユーザーペルソナにまたがっていますが、私たちは管理者がコスト管理とユーザーエクスペリエンスのバランスを取るのに役立つ統一されたツールセットを提供することを目指しています。このブログでは、このバランスを取るためのいくつかの戦略を説明しました。

1. クラスターポリシーを使用して、どのユーザーがクラスターを作成できるか、およびそれらのクラスターのサイズと範囲を制御します。
2. ストレージやネットワークコストなど、Databricksワークスペースによって発生するDBU以外のコストを最小限に抑えるように環境を設計します。
3. 監視ツールを使用して、コストの期待が満たされていることを確認し、効果的なプラクティスが導入されていることを確認します。

この記事全体にリンクされている他の管理者向けブログもぜひご覧ください。今後公開される追加のブログにもご期待ください。また、Private Link（AWS | Azure）や予算編成などの新機能もぜひお試しください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事