Databricksサーバーレスコンピュート

Databricksのコンピュートには「自分でクラスタを管理する」従来型と「Databricksに全てを任せる」サーバーレス型があります。2024年以降、Serverless Computeの対象はSQL Warehouseだけでなく、NotebooksやJobsにも拡大しました。この記事では、Serverless Computeの仕組み、3種類のSQL Warehouseの違い、料金体系、制約、セキュリティ、そして「いつServerlessを選ぶべきか」の判断基準を整理します。

SQL Warehouse 3種比較：Classic vs Pro vs Serverless

Databricks SQL Warehouseには3つのタイプがあり、それぞれコスト・性能・管理の特性が異なります。試験ではこの3種の違いが直接問われるため、正確に区別できることが重要です。

試験で最も問われるポイントは「アイドル時の課金の有無」です。ClassicとProは起動中であればアイドルでもDBUが発生しますが、Serverlessはクエリ実行時のみ課金されます。断続的にクエリを実行するBIダッシュボードなどでは、Serverlessのコスト効率が圧倒的に高くなります。

Serverless Notebooks

Serverless Notebooksは、対話型のNotebook実行をサーバーレスで行う機能です。従来はNotebookを使うためにAll-Purpose Clusterを起動し、数分間の待ち時間が必要でした。Serverless Notebooksでは、Notebookにアタッチするコンピュートとして「Serverless」を選択するだけで、数秒以内にセルの実行が開始されます。

対応言語はPython、SQL、Scalaです。Rは現時点で非対応です。Pythonでは%pip installによるPyPIパッケージのインストールが可能ですが、セッション単位のインストールとなり、セッション終了後は再インストールが必要です。

Serverless Notebooksの実体はDatabricksのコントロールプレーン上で管理される短命のコンピュートリソースです。ユーザーはクラスタサイズやインスタンスタイプを一切指定しません。Databricksがワークロードの特性に応じてリソースを自動割り当てします。

Serverless Jobs（Serverless Workflows）

ジョブ（ワークフロー）の実行もサーバーレスで行えます。ジョブのタスク設定でコンピュートタイプとして「Serverless」を選択すると、ジョブ実行時にDatabricksが自動的にコンピュートをプロビジョニングします。

従来のJob Clusterとの最大の違いは、クラスタ起動のオーバーヘッドがほぼゼロになることです。夜間バッチで数十のタスクが順次実行されるワークフローでは、各タスクのクラスタ起動待ち時間が累積して全体のジョブ完了時間を大幅に伸ばしていました。Serverless Jobsではこのオーバーヘッドが解消されます。

ただし、Serverless Jobsでもカスタムinit scriptsやクラスタレベルのライブラリ設定は使用できません。依存ライブラリはタスク定義内で%pip installまたはrequirements.txt経由で指定します。

サーバーレスの4つの利点

Serverless Computeを採用する動機は大きく4つに集約されます。

• 数秒起動：ClassicやProのSQL Warehouseは起動に5〜10分かかりますが、Serverlessは数秒です。All-Purpose Clusterの代わりにServerless Notebooksを使う場合も同様に即時起動します。BIユーザーが「クエリを投げたらすぐ結果が返る」体験を提供できます。
• 自動スケーリング：Serverless SQL Warehouseは負荷に応じて自動的にスケールアウト/インします。ユーザーがクラスタ数の上限・下限を設定する必要がなく、ピーク時の容量計画も不要です。Serverless Jobsもタスクの並列度に応じてリソースが動的に割り当てられます。
• 管理不要：インスタンスタイプの選定、DBRバージョンの管理、パッチ適用、オートスケーリングの調整など、従来型コンピュートで必要だった運用タスクが全て不要になります。プラットフォームチームの運用負荷が大幅に下がります。
• 自動アップグレード：Databricks Runtimeやセキュリティパッチが Databricksによって自動的に適用されます。ユーザーは常に最新の最適化とセキュリティ修正の恩恵を受けられます。「古いRuntimeで動かしていて脆弱性が残っている」というリスクを排除できます。

制約・注意点

Serverless Computeは万能ではありません。以下の制約を理解した上で採用判断を行う必要があります。

料金体系

Serverless Computeの料金はDBU（Databricks Unit）ベースの従量課金です。従来のコンピュートとの最大の違いは「クラウドインフラ費用がDBU単価に含まれる」点です。

• Classic / Pro：DBU課金（Databricksプラットフォーム費用）+ クラウドインフラ費用（EC2 / Azure VM / GCE）が別々に発生。クラスタが起動中であれば、アイドル状態でもDBUとインフラ費用の両方が発生します。
• Serverless：DBU課金のみ（インフラ費用込み）。クエリ実行時のみDBUが消費され、アイドル時の課金はありません。DBU単価はClassicやProより高めに設定されていますが、利用パターンによってはトータルコストが下がるケースが多くあります。

コスト最適化の観点では、「常時高負荷で稼働するワークロード」はClassic/Proの方が割安になる場合があります。一方、「1日に数回クエリを実行するBIダッシュボード」「断続的に実行されるETLジョブ」ではServerlessがコスト面で有利です。

セキュリティモデル

Serverless Computeのセキュリティは従来型と異なるアーキテクチャで実現されています。

• ネットワーク分離：Serverlessコンピュートは各顧客ごとに隔離されたネットワーク環境で実行されます。他のテナントのコンピュートリソースと物理的・論理的に分離されており、マルチテナントによるリスクは排除されています。
• コントロールプレーン管理：コンピュートリソースのライフサイクル（起動・停止・パッチ適用・スケーリング）はDatabricksのコントロールプレーンが管理します。ユーザーのデータプレーン（クラウドアカウント内のストレージ）へのアクセスは暗号化された接続を通じて行われます。
• 暗号化：転送中データ（TLS 1.2以上）と保存データの両方が暗号化されます。Serverlessコンピュートが処理中に使用する一時ストレージも暗号化されています。
• NCC（Network Connectivity Configuration）：Serverless Computeからお客様のデータソース（ストレージ・データベース）へのプライベート接続を構成する仕組みです。従来のVPC Peeringは使えませんが、NCCによってサービスエンドポイント経由のプライベート接続を実現できます。

いつServerlessを使うべきか：判断フローチャート

Serverlessと従来型コンピュートの選択は、ワークロードの特性で判断します。以下のフローで整理できます。

1. カスタムJAR / init scripts / GPUが必要か？ → YesならClassic Computeを使用。Serverlessでは対応できません。
2. R言語が必要か？ → YesならNotebooksはAll-Purpose Clusterを使用。
3. Spark設定の細かいチューニングが必要か？ → YesならClassic Computeを使用。Serverlessではspark.confの自由な変更ができません。
4. BIダッシュボード / アドホッククエリ用途か？ → YesならServerless SQL Warehouseが最適。即時起動とアイドル時無課金の恩恵が最大になります。
5. ETL / データパイプラインで起動オーバーヘッドを減らしたいか？ → YesならServerless Jobsを検討。タスク間のクラスタ起動待ちが解消されます。
6. 対話型のデータ探索・開発作業か？ → YesならServerless Notebooksを検討。数秒で開発開始でき、クラスタ管理が不要です。
7. 常時高負荷で24時間稼働するワークロードか？ → Classic / Proの方がDBU単価ベースで割安になる可能性があります。コスト試算の上で判断してください。

試験出題ポイント

Databricks認定試験（特にData Engineer Associate）では、Serverless Computeに関して以下のパターンで出題されます。

• 3種のSQL Warehouseの違い：Classic / Pro / Serverlessの起動時間、料金体系（アイドル課金の有無）、Photon対応、Intelligent Workload Management対応の違いを問う問題。「BIアナリストが即座にクエリを実行したい場合に最適なWarehouseタイプは？」→ Serverless。
• コスト最適化：「SQL Warehouseが起動しているが誰もクエリを実行していない。コストを削減するにはどうするか？」→ Serverlessに変更（アイドル時課金なし）、またはClassic/Proの自動停止設定を短くする。
• 制約の理解：「カスタムJARライブラリを使用するETLパイプラインに最適なコンピュートは？」→ Serverlessではなく、Classic Compute（Job Cluster）を使用。
• 管理責任：「Serverless SQL Warehouseでは、誰がコンピュートリソースのパッチ適用を行うか？」→ Databricks（ユーザーではない）。

試験対策のコツは「Serverlessの利点」だけでなく「Serverlessでできないこと」を正確に把握することです。選択肢で「Serverlessなら全て解決する」という記述があった場合、制約を思い出して慎重に判断してください。

問題で確認

よくある質問