1. はじめに
こんにちは。株式会社ジールの@RizumuUEDAです。
この度、社内の技術力アップ施策の一環で「Databricksの環境構築」に取り組むにあたり、コスト試算を行いました。はじめてしっかりとコスト試算を行い、有意義な学びを得られたと感じたので共有します。
また、以下についても整理していますのでご参照ください。
- Databricksの料金体系
- Databricks on AWS のシステム構成 ※構想段階のもの
Databricksとは
基盤となるクラウドサービス（AWS、Azure、GCP）上に構築される分析プラットフォームサービス。
レイクハウスという形でデータを一元管理し、ETL処理や機械学習、BIといった様々なデータ活用機能を包括的に提供します。
2. コスト試算の方法と結果
2-1. Databricksの料金体系
まず、料金体系を以下に図式化して整理します。
前述の通り、Databricksは基盤となるクラウドサービス上に構築されるプラットフォームのため、Databricks自体の利用料と基盤インフラコストの合計が課金されます。
Databricks自体の利用料（DBX利用料）
Databricksでは、DBU（Databricks Unit）という単位で計算リソースの使用量を測定します。選択した契約プラン、Computeタイプの組み合わせに応じて単価($/DBU)が決まり、使用量分だけ課金されます。
例えばPremiumプランでAll-purpose（汎用）クラスターの場合、$0.55/DBUです。
DBU消費は、計算リソースのインスタンスタイプに応じて単位消費量(DBU/h)が決まっているため、インスタンスの個数と起動時間だけ乗算して算出します。
例えばm5.large(2CPUs, 8GB)インスタンスの場合、0.34 DBU/hです。
基盤インフラコスト
各クラウドでの計算リソース、ストレージ、ネットワークなどその他関連サービスの課金合計になります。今回はAWSを想定するので、それぞれEC2、S3、VPCエンドポイントなどが相当します。
※ただし、DatabricksのComputeタイプとしてサーバーレスのSQL Warehouseを選択した場合、EC2の料金はDBX利用料に含まれるため、基盤インフラコストとしてはゼロになります。（その分DBU単価が割高です）
料金計算ツール
各クラウドに用意されており、各サービスの設定値を入力するだけで課金額を算出してくれる素敵な便利ツールとなっています。
本記事でも1、2を使用して実際の試算を行いました。
2-2. システム構成
こちらの記事などを参考に、以下の構成図を作成しました。
Databricksのシステムは大きく2つのコンポーネントから構成されますが、ここではデータプレーンを構成します。
-
コントロールプレーン
Notebookやクラスターを管理する。図中右側のDatabricks社のAWS環境に存在。 -
データプレーン
実際のデータや計算リソースが存在する。図中左側の自社のAWS環境に存在。
VPC内に4つのサブネットを作成します。
- Public Subnet
外部からのアクセス用。 - Private Subnet 01,02
計算リソース(EC2インスタンス)の格納用。異なるAZに1つずつ作成。 - Private Subnet 03
コントロールプレーンとのプライベート通信用。
また、ストレージとしてS3バケットをworkspace用、metastore用の2つ作成します。
上記構成図は未実装の構想段階のものであり、正しく動作するか未検証ですのでご了承ください。実装し次第、追記・更新を予定しています。【2025/10/20記】
2-3. 試算結果
上記の構成図に基づき各種パラメータを設定して、2-1の計算式にあてはめたところ、1ヶ月あたりのコストは$102.73（約15,000円）となりました。
今回は環境構築自体が主たる目的であるため、計算リソースのスペックや起動時間、データ量は多めに見積もってこのぐらいだろうという値になります。
参考）各種設定値
| 計上カテゴリ | サービス | パラメータ | 設定値 | 金額[USD/月] |
|---|---|---|---|---|
| DBX利用料 | 契約プラン | Enterprise | 8.84 | |
| クラウド | AWS | |||
| Computeタイプ | All-purpose | |||
| インスタンスタイプ | m5.large(2CPUs, 8GB) | |||
| インスタンス数 | 2 | |||
| 起動時間[Hours/Day] | 1 | |||
| 起動時間[Days/Month] | 20 | |||
| 基盤インフラコスト | Public IPv4 address | 使用中のパブリックIPv4アドレスの数 | 1 | 3.65 |
| AWS PrivateLink | リージョンあたりのVPCインターフェイスエンドポイントの数 | 4 | 40.98 | |
| Amazon EC2 | テナンシー | 専有 | 48.96 | |
| オペレーティングシステム | Windows Server | |||
| ワークロード | Consistance | |||
| インスタンス数 | 2 | |||
| 高度なEC2インスタンス | m5.large | |||
| Pricing Strategy | On-demand | |||
| Utilization | 20 Hours/Month | |||
| S3 Standard | ストレージ | 10GB/月 | 0.3 | |
| 平均オブジェクトサイズ | 100MB | |||
| PUT、COPY、POST、LISTリクエスト数 | 10000 | |||
| GET、SELECT、その他のリクエスト数 | 10000 |
3. 学びになったポイント
上記のコスト試算を通じて、私自身まだまだサービス理解や作業イメージの解像度が低かったなと実感しました。
ここではその理由として、コスト試算を進める中でつまずいた＝新たな学びが得られたと感じたポイントを3つ紹介します。
3-1. サービスの選定
インフラ系のサービスは主に資格勉強で触れていたのみで、類似サービスに対する理解が曖昧だったと実感しました。
今回であれば、参考資料によってPublic Subnetに配置するエンドポイントとして、NATゲートウェイを用いているものと用いていないものがありました。
今まではなんとなくインターネットにつなぐときに使う（結構コスト高なもの）程度の認識でしたが、今回調査して、インターネットへ外向きのアクセス（インストールやアップロードなど）が必要な際に必須のサービスであると知りました。
本ケースでは環境構築が主たる目的のため特殊なライブラリのインストールなども不要と判断し、構成図にはNATゲートウェイを含めませんでした。
3-2. パラメータの設定
インスタンスタイプや契約プランを決める際に知見・調査が不足していたと感じました。
インスタンスタイプであれば、どの程度のスペックがあればどの程度の処理ができるのか、あまりガジェットに興味がなかったため肌感が分からず考えあぐねてしまったなと思います。また契約プランであれば、どのプランはどこまでの制約・サポートがあるのか、しっかり調査して判断することが必要だと感じました。
3-3. 使用状況の想定
リソースの使用時間やデータの使用量については、「このシステムを使って何をするのか」を具体的にイメージする必要があり、案件であればお客様の業務理解に相当すると思いました。「思っていたよりも時間がかかった、ファイル数が多かった」などのズレが生じやすい部分なのかなとも感じたので、上流工程に関わるときには緻密な調査・ヒアリングが必要と感じました。
4. おわりに
コスト試算を実際に行い、Databricks自体に対する知見はもちろん、手を動かすことでサービス理解や作業イメージについて意識すべきポイントを掴むことができました。
コスト試算自体は無料ですし、過去案件の資料など参考になるものも多いので、エンジニアとして今後提案など行うことを見据えてもとても良いトレーニングになると感じました。
また、今後は実際に環境構築しコストの予実比較など行えたらと思います。
ご覧いただきありがとうございました！
株式会社ジールでは、「ITリテラシーがない」「初期費用がかけられない」「親切・丁寧な支援がほしい」「ノーコード・ローコードがよい」「運用・保守の手間をかけられない」などのお客様の声を受けて、オールインワン型データ活用プラットフォーム「ZEUSCloud」を月額利用料にてご提供しております。
ご興味がある方は是非下記のリンクをご覧ください：