LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

DBU課金の仕組みとコストが膨らむ理由

Databricksのコスト最適化とは、DBU（Databricks Unit、処理能力を標準化した計測・課金単位）^*1の消費量とクラウド基盤費用の両方を、ワークロードの実態に合わせて絞り込む取り組みを指します。DBUは秒単位で計測される正規化されたコンピュート能力の単位で、稼働したクラスターの規模と種類に応じて積み上がります^*1。

Databricksは従量課金制を採用しており、事前の固定費用なしに使った分だけ支払う設計です^*2。裏を返せば、稼働させたままのクラスターや過剰なスペック設定はそのままコスト増につながります。DBUの消費量は、使用したコンピュートリソースの規模と処理したデータ量という2つの処理メトリクスによって決まります^*1。

この仕組みを理解しないまま運用すると、必要以上に大きなクラスターを使い続けたり、終了し忘れたクラスターが課金され続けたりする事態が起こります。まずはDBUが何に対して発生する課金なのかを正確に把握することが、最適化の出発点になります。

All-Purpose・Jobs・SQL Warehouse — クラスター種別で変わるDBU単価

Databricksのコンピュートは大きく3系統に分かれます。ノートブックでの対話的な作業やデータ探索に使うAll-Purpose Compute、Lakeflow Jobsなどバッチ処理の自動実行に使うJobs Compute、SQLクエリとBI（ビジネスインテリジェンス）ワークロードに最適化されたSQL Warehouseです^*3。

公式の選定ガイドでは、ジョブなど自動化されたワークロードにはServerless ComputeまたはJobs Computeを使い、対話的な用途にAll-Purpose Computeを使うことを基本としています^*4。SQLタスクにはSQL Warehouseを使い、All-Purpose Computeの利用は推奨されていません^*4。

SQL Warehouseにはさらに3種類あります。Serverless SQL Warehouseは起動時間が数秒程度と速く、Pro・Classicは起動に数分を要します^*5。Classicは入門レベルの性能に位置づけられ、Serverlessは需要が下がった際に迅速にスケールダウンする設計です^*5。

本番の定型バッチ処理を対話用のAll-Purpose Computeで動かし続けているケースは珍しくありません。ワークロードの性質に合ったクラスター種別へ振り分け直すだけでも、コスト構造は見直せます。

オートスケーリングと自動終了 — アイドル課金を防ぐ2つの設定

オートスケーリング（autoscaling）は、ワーカー数の下限値と上限値を指定しておき、ジョブの負荷特性に応じてDatabricksが自動でワーカーを増減させる機能です^*6。処理が重い局面でワーカーを追加し、不要になれば削減するため、稼働率の向上とコスト削減の両立を狙えます^*6。Premium以上のプランでは最適化オートスケーリングが利用でき、少ないスケーリングイベントで最小構成から上限構成へ到達する仕組みです^*6。

自動終了（auto-termination）は、指定した非活動期間を超えてコマンドが実行されなかった場合に、コンピュートリソースを自動的に終了させる設定です^*6。UIのCreate Compute画面でAll-Purposeクラスターを作成すると、自動終了の既定値は120分に設定されます^*6。

この2つはいずれも初期値のまま放置されがちな設定です。稼働時間帯や用途に応じて非活動期間を短く見直すだけでも、無駄なアイドル課金を抑える余地があります。なお自動終了はSparkの動的リソース割り当て（Dynamic Allocation）との併用が推奨されていない点にも注意が必要です^*6。

Photonエンジンは速いが高い — 導入判断の分かれ目

Photon（Databricks固有のベクトル化クエリエンジン。列指向でデータをバッチ処理し、SQLやDataFrame処理を高速化する仕組み）^*7は、JVMベースのSpark SQLエンジンをネイティブなC++ランタイムに置き換えることで性能を高める技術です^*7。対応領域はSQL分析・BI、ETL（データ抽出・変換・加工）のスキャンや結合・集約、ステートレスなストリーミング、機械学習のDataFrame処理など多岐にわたります^*7。

一方でPhotonを有効にしたクラスターは、同じインスタンスでも標準のSparkランタイムよりDBU消費レートが高くなります。数秒で終わるような軽いクエリでは、性能改善効果が乏しいとも指摘されています^*7。

Photonの検討で重要なのは「Photonにすれば安くなるか」ではなく「処理時間が縮まった分、DBU単価の上昇を吸収できるか」という比較です。CPU負荷の高い結合・集約処理やデータ量の大きいETLでは有効に働く一方、I/O待ちが中心の処理では効果が限定的になりやすい構造です。

Spotインスタンスとインスタンスプールの活用余地

クラウド基盤側のコンピュートには、オンデマンドインスタンスとスポットインスタンス（クラウド事業者の余剰リソースを市場価格に応じて安価に使う購入方式）があります。Databricksのクラシックコンピュートは、標準コンピュート・専用コンピュート・インスタンスプールといった構成を選べる設計です^*3。

スポットインスタンスは中断のリスクを伴うため、途中で止まっても再実行できるバッチジョブのワーカーノードに向いています。障害時に処理が失われると困る本番の対話用途や、ドライバーノードにそのまま適用するのは適していません。

インスタンスプールは、事前に確保したインスタンスを再利用することでクラスター起動時間を短縮する仕組みです。頻繁にクラスターを起動・終了するジョブが多い環境では、起動待ち時間の削減という形で間接的にコスト効率へ寄与します。ただし利用しないインスタンスを保持し続けるとクラウド側の費用が発生するため、プールサイズの設計にも判断が必要です。

クラウド基盤費用との二層構造 — AWS/Azure/GCP側のコスト

Databricksの請求は二層構造になっています。ひとつはDatabricksが課すDBU利用料、もうひとつは基盤となるAWS・Azure・GCP側の仮想マシン・ストレージ・データ転送などの費用です。Databricksは主要クラウド上で稼働するプラットフォームであり、料金体系はクラウド事業者への支払いとは別建てで提供されます^*2。

そのためDBU単価だけを見て最適化を進めても、片側の費用しか改善できません。クラスターに割り当てるインスタンスタイプ、ストレージ層の選択、リージョン間のデータ転送量など、クラウド基盤側の設計もあわせて点検する必要があります。

Databricksは長期利用を前提とした事前コミット契約（Committed Use Contracts）による割引も提供しています^*2。DBU側とクラウド側それぞれで契約形態を見直すことで、恒久的な削減につながる余地があります。ただし契約形態の変更は財務判断を伴うため、利用実態の分析を先に済ませておくことが前提になります。

ジョブ・クエリ単位の最適化で見るべき指標

クラスター設計を整えても、個別のジョブやクエリの書き方が非効率なままではDBU消費は減りません。パーティション設計の見直し、不要なデータのスキャンを避けるフィルタの前倒し、キャッシュの活用などは、コンピュート側の設定変更と並行して点検すべき領域です。

ジョブ実行の履歴からは、実行時間・使用したクラスター構成・DBU消費量を確認できます。同じ処理を繰り返し実行しているジョブほど、わずかな非効率が積み重なって総コストに反映されやすくなります。

クエリのプロファイルを確認し、どの処理段階に時間がかかっているかを特定した上で、クラスターサイズの調整とクエリ自体の見直しの両輪で対応することが必要です。どちらか一方だけでは、最適化の効果は限定的になります。

内製と外注、どちらでコスト最適化を進めるか

Databricksのコスト最適化を内製で行うには、DBU課金の仕組み、クラスター種別ごとの特性、Spark・Photonの実行計画を読む知識、クラウド基盤側のコスト管理という複数領域の知見が要ります。片手間の対応では見落としが生じやすく、設定変更が処理失敗やジョブ遅延を招くリスクも伴います。

設定を誤ると、自動終了の非活動期間を必要以上に短くしてジョブが途中終了したり、オートスケーリングの上限を絞りすぎて処理が遅延したりする可能性があります。コストだけを見て設定を変えると、可用性や処理時間という別の面で不利益が生じかねません。

専門パートナーに依頼した場合は、DBU消費量の分析からクラスター構成の再設計、運用ルールの整備までを一括で任せられる点が内製との違いです。内製では担当者の学習コストと検証工数が先行し、外注では初期の分析・設計フェーズの費用が発生します。自社にDatabricks運用の専任者がいない場合は、まず現状分析だけを外部に依頼し、恒常的な運用は内製に戻すという段階的な進め方も選択肢になります。

LASSICは元請（プライムベンダー）としてシステムの保守・運用を受託する体制を持ち、クラウド基盤の運用設計から個別の構成見直しまでを一貫して支援します。Databricksの費用構造を把握した上で、どこまでを外注し、どこから内製に戻すかという線引きも含めて相談できる点が実務上の強みです。

まとめ：Databricksコスト最適化の3つの判断軸

本稿ではDatabricksのコスト最適化について、DBU課金の仕組みからクラスター種別、Photon、クラウド基盤費用との二層構造までを整理しました。要点を3つに集約すると次の通りです。第一に、ワークロードの性質に合わせてAll-Purpose・Jobs・SQL Warehouseを使い分けることです。第二に、オートスケーリングと自動終了の設定値を稼働実態に合わせて見直すことです。第三に、DBU側とクラウド基盤側の両方を点検しなければ、コスト最適化は片手落ちに終わるという点です。これらの判断は専門知識を要するため、自社の体制に応じて外注も含めた進め方を検討することが現実的な一歩になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Databricks「Databricks technical terminology glossary」（docs.databricks.com）
2. *2　出典：Databricks「Databricks Pricing」（databricks.com）
3. *3　出典：Databricks「Compute」（docs.databricks.com）
4. *4　出典：Databricks「Compute selection recommendations」（docs.databricks.com）
5. *5　出典：Databricks「SQL warehouse types」（docs.databricks.com）
6. *6　出典：Databricks「Compute configuration reference」（docs.databricks.com）
7. *7　出典：Databricks「What is Photon?」（docs.databricks.com）

Tweet