GENDAPublicationへの投稿
⚡

Databricksワークスペース、サーバレスとクラシックって何が違うの？整理してみた

さっく
に公開
AWS
クラウド
Serverless
Databricks
データエンジニアリング
tech

はじめに

元々クラシックワークスペースを使っていて、サーバレスワークスペースが出てからは「なんとなくサーバレス」を選んでいました。でも、実際のところ何が違うのかちゃんと理解できていなかったので、この機会に整理してみました。

AWS版Databricksでワークスペースを新規作成するとき、サーバレスワークスペースとクラシックワークスペースの2種類が選べます。最近はサーバレスが推されていますが、「で、具体的に何が違うの？」と聞かれるとうまく答えられない......という方も多いんじゃないでしょうか。

この記事では、その違いを4つの観点で整理しています。自分と同じように「なんとなく選んでるけどモヤモヤする」という方の参考になれば嬉しいです。

そもそもワークスペースとは？（前提整理）

Databricksのアーキテクチャは大きくコントロールプレーンとコンピュートプレーンに分かれます。

クラシックワークスペースでは、コンピュートプレーンがユーザー側のAWSアカウント内に構築されます。一方、サーバレスワークスペースでは、コンピュートプレーンがDatabricksのアカウント内で完全に管理されます。

よくある誤解：「サーバレスWS ≠ サーバレスコンピュート」

ここで最も重要なポイントです。

サーバレスワークスペースとサーバレスコンピュートは別の概念です。

用語 意味
サーバレスワークスペース ワークスペースのデプロイ形態。ユーザー側のAWSアカウントにリソースを作らない
サーバレスコンピュート コンピュートの実行形態。Databricks管理のリソースで即座に起動する

つまり、クラシックワークスペースでもサーバレスコンピュートは使えます。ワークスペースタイプとコンピュートタイプは独立した選択肢です。

セットアップどれくらい楽になる？

ここが一番体感差が大きいところです。

サーバレスの場合

  1. ワークスペース名を入力
  2. リージョンを選択
  3. 「Use serverless compute and default storage」にチェック
  4. Createをクリック

以上。数秒で完了。Unity Catalogも自動セットアップされます。要件は「サーバレスコンピュートをサポートするリージョンであること」だけ。

クラシックの場合

自動構成でも以下のステップが必要です。

  1. AWSアカウントにIAMロール作成を許可
  2. VPC構築（サブネット、セキュリティグループ等）
  3. S3バケット・IAMロール・ポリシーの設定
  4. CloudFormationテンプレートの実行
  5. ワークスペースの作成完了を待つ

さらに前提条件として、AWSアカウントのリソース枠（VPC数、NAT Gateway数など）の確認、us-west-2のSTSエンドポイント有効化、AWS管理者によるアクセス許可が必要です。

インフラ管理の責任範囲

管理対象 クラシック サーバレス
VPC / サブネット / SG ユーザー側 Databricks
NAT Gateway ユーザー側 Databricks
IAMロール / ポリシー ユーザー側 Databricks
S3バケット ユーザー側 Databricks
コンピュートリソース ユーザー側 + Databricks Databricks

サーバレスではユーザー側のAWSアカウントにリソースが一切作成されません。セットアップだけでなく、その後の運用負荷も大幅に減ります。

実体験：SCPでus-west-2がブロックされてハマった話

筆者の環境では、会社のAWS SCP（Service Control Policy）で特定リージョンへのアクセスが制限されていました。

クラシックワークスペース作成時、CloudFormationテンプレートの実行でdatabricks-prod-public-cftsというus-west-2にあるS3バケットへのアクセスが必要なのですが、SCPでブロックされてエラーに。原因特定にかなりの時間を費やしました。

結局、Databricks用のAWSアカウントでSCPのリージョン制限を一時的に解除してもらうことで解決しました。

サーバレスワークスペースではそもそもワークスペース作成時にユーザー側のAWSアカウントにリソースをプロビジョニングしないため、この種の問題は一切発生しません。SCPの設計を気にせずワークスペースを作れるのは、地味ですが大きなメリットです。

何ができて、何ができない？

サーバレスWSはサーバレスコンピュートのみ利用可能です。クラシックWSはクラシッククラスタとサーバレスコンピュートの両方が使えます。

起動時間はクラシッククラスタが5〜12分、サーバレスコンピュートは15〜30秒。普段使いでは体感がかなり違います。

言語とライブラリ

項目 クラシック サーバレス
Python / SQL 対応 対応
Scala / R 対応 非対応
JARライブラリ（Notebook） 対応 非対応

Scala/Rを使っている場合は現時点でクラシック一択です。自分の環境ではPython + SQLで完結しているので困っていませんが、既存のScalaジョブを移行する場合は要注意。

その他の制約

  • ストリーミングはTrigger.AvailableNowのみ（時間ベーストリガー非対応）
  • DBFS制限あり（Unity Catalog Volumes推奨）
  • Spark UI非表示（Query Profileを使用）
  • Databricks Container Services非対応

データの置き場所とセキュリティは？

ストレージ

項目 クラシック サーバレス
メインストレージ ユーザー所有S3 Databricks管理のDefault Storage
外部ストレージ接続 可能 可能（Unity Catalog経由）

サーバレスはDefault Storageがすぐ使えて楽です。ただし、バケットポリシーや暗号化設定を自分で細かくコントロールしたい場合はクラシックの方が自由度が高い。実際のところ、サーバレスWSでもUnity Catalog経由で自分のS3に接続できるので、「データは自社S3に置きたいけどWSはサーバレスがいい」という使い方も可能です。

ネットワーク・セキュリティ

項目 クラシック サーバレス
ネットワーク管理 ユーザー管理VPC Databricks管理
プライベート接続 PrivateLink Network Policies
外部通信制御 NAT Gateway / SG Serverless Egress Policies

既存VPCへの統合やPrivateLinkが必須ならクラシック。サーバレスでもEgress/Network Policiesで外部通信の制御は可能ですが、アプローチがVPCベースからポリシーベースに変わるので、ネットワークチームとの会話が必要かもしれません。

コストはどう変わる？

項目 クラシック サーバレス
基本課金 DBU DBU
インフラコスト EC2, S3, NAT等 Default Storageコスト
クラウドクレジット適用 適用可能 適用外

一番のポイントはクラウドクレジット/割引の適用可否。サーバレスではコンピュートがDatabricks管理のため、AWSのコミット契約やRI割引が適用されません。AWSクレジットを大量に持っている場合は、ここが判断の分かれ目になりそうです。

コスト構造の詳細はDatabricks公式料金ページを参照してください。

まとめ

観点 クラシック サーバレス
セットアップ IAM/VPC/S3の事前準備が必要 4ステップ、数秒で完了
インフラ管理 VPC/IAM/S3などユーザー側管理 すべてDatabricks管理
言語・機能 Python, SQL, Scala, R Python, SQL のみ
ストレージ ユーザー所有S3 Default Storage + 外部接続可
ネットワーク ユーザー管理VPC、PrivateLink Egress/Network Policies
コスト DBU + インフラ（クレジット適用可） DBU + Storage（クレジット適用外）

どっちを選ぶ？判断フローチャート

判断のポイントをまとめると以下のとおりです。

クラシックを選ぶべきケース：

  • Scala / R / JARライブラリをNotebookで使う
  • 既存のVPCにDatabricksを組み込む必要がある
  • PrivateLinkによるプライベート接続が必須
  • 時間ベースのStructured Streamingを利用する
  • レガシーSpark RDDベースのワークロードがある
  • AWSクラウドクレジットを最大限活用したい

サーバレスを選ぶべきケース：

  • Python + SQLで完結するワークロード
  • 素早くワークスペースを立ち上げたい
  • インフラ管理の負荷を最小限にしたい
  • AI/BIダッシュボード、Databricks Apps、Genie Spacesなどの新機能を活用したい
  • 探索的分析やPoC用途

おわりに

整理してみた結論：迷ったらサーバレスから始めて、制約に当たったらクラシックを検討する。これが一番シンプルな戦略だと思います。

ただし注意点として、ワークスペースタイプはあとから変更できません。サーバレス→クラシック（またはその逆）にしたい場合は、新しいワークスペースを作成してリソースを移行する必要があります。とはいえサーバレスは数秒で作れるので、まず試してみるコストは低いです。

Databricks公式ドキュメントでも「Serverless workspaces are the best choice for most use cases」と書かれているので、方向性としては間違っていなさそうです。クラシックが必要なのはScala/R、カスタムVPC、時間ベースストリーミングなど、明確な理由がある場合に限られます。

皆さんの環境ではどちらを使っていますか？ 特にサーバレスに移行した/しなかった理由があれば、コメントで教えてもらえると嬉しいです。

参考文献

GENDA
GENDAPublication

『世界中の人々の人生をより楽しく』をAspiration（大志）に掲げたエンターテイメント企業『GENDA』（ジェンダ）

Discussion