目次
- 目次
- 1. はじめに
- 2. Terraform と Databricks 環境管理の課題
- 3. 事前準備（前提条件）
- ４. Terraform プロジェクト構成
- ５. Databricks Terraform Provider の設定
- ６. Terraformでリソースをデプロイする
- 7. Terraform 設定の適用
- 8. リソースの管理と更新
- まとめ
- おわりに
- お知らせ
1. はじめに
1.1 本記事の目的と概要
エーピーコミュニケーションズGDAI事業部Lakehouse部のThida（ティダ）です。
この記事では、Terraform を使って Databricks 環境をゼロから自動構築する方法を解説します。クラスタや SQL ウェアハウス、権限設定などをコード化し、手動操作の手間を削減。さらに、Terraform の状態ファイル（tfstate）を Terraform Cloud に保存して、チーム全員での安全な共同管理までを行います。
2. Terraform と Databricks 環境管理の課題
2.1 手動操作の問題点
Databricks でクラスタ、SQL ウェアハウス、ジョブ構成などのリソースを管理する際、Databricks の UI 上で同じ手順を何度も手動で繰り返すことがよくあります。小規模な環境ではこの方法でも問題ありませんが、チームがワークロードを拡大していくと、時間がかかる上にミスが発生しやすくなります。こうした繰り返しの手作業は、デプロイの不整合を引き起こし、トラブルシューティングやバグ修正を難しくし、進捗を妨げるだけでなく、安定した環境の維持も困難にします。
2.2 環境構築の再現性と安定性の重要性
開発・テスト・本番などの新しい環境を作成する必要がある場合、手作業による構築はわずかな違いを生み、それが思わぬ問題の原因になることがあります。さらに、こうした問題の修正や、環境を安定して再現する作業には、多くの時間とリソースが費やされてしまいます。
新しい環境（開発・テスト・本番など）を用意するたびに手作業で構築していると、設定や構成に微妙な差が生じ、思わぬ不具合につながることがあります。しかも、その修正や環境の再現には、多くの時間と工数が奪われがちです。
2.3 Infrastructure as Code (IaC) のメリット
ここで威力を発揮するのが Infrastructure as Code (IaC) です。Terraform のようなツールを使えば、インフラ構成をコードとして定義でき、毎回同じ状態でリソースをデプロイできます。クラスタや SQL ウェアハウス、権限設定などの作業を自動化することで、設定の不整合リスクを減らし、作業時間を大幅に短縮できます。
Terraform を導入すれば、Databricks のリソース管理は劇的にシンプルになります。更新やスケールも容易になり、バージョン管理で全ての変更履歴を追跡可能に。結果として、インフラ運用はより信頼性が高く、効率的なものになります。
では、実際にどのように始めればよいのかを見ていきましょう。
3. 事前準備（前提条件）
TerraformでDatabricksをコード化管理する前に、以下の準備を済ませておきましょう。
- Terraformのインストール（[ガイドはこちら]）
- Databricksワークスペースの作成とアクセス権の確認
- API認証の設定（PAT または Service Principal）
- Databricks Terraform Providerのインストール
４. Terraform プロジェクト構成
4.1 プロジェクトフォルダの作成とファイル構成
Terraform を構造的に運用する場合、設定を整理するために複数のファイルを使うのが一般的です。わかりやすさとモジュール性を保つために、Databricks 用の専用フォルダ（例：databricks-terraform）を作成し、以下のファイルを配置しましょう。
4.2 main.tf, variables.tf, terraform.tfvars,backend.tfの役割
1.main.tf
・リソースやプロバイダーの主要な設定を記述するファイル。
2.variables.tf
・設定全体で使用する入力変数を定義するファイル。
3.terraform.tfvars
・variables.tf で定義した変数に値を設定するファイル。
4.backend.tf
・Terraform の状態ファイル（tfstate）をどこに保存するかを設定するファイル。
リモートバックエンド（例: Terraform Cloud, S3, Azure Storage）を利用することで、チーム開発時の状態共有や衝突防止が可能になります。
これらのファイルはすべて databricks-terraformsフォルダの下に配置します。こうすることで、プロジェクトを整理しやすくなり、他の環境にも流用できるモジュール性の高い構成を保てます。
project-root/
└── databricks-terraforms/
├── main.tf
├── variables.tf
├── terraform.tfvars
├── backend.tf
５. Databricks Terraform Provider の設定
5.1 Provider設定例
Terraform から Databricks にアクセスできるようにするには、main.tf ファイル内で Databricks Provider を設定します。
このプロバイダー設定により、Terraform は Databricks API と連携し、クラスタやジョブなどのリソースを作成・管理できるようになります。
5.2 Host URLとTokenの管理方法
・Host URL:<your-databricks-workspace-url> は、ご自身の Databricks ワークスペースの URL に置き換えてください。
トークン
・Token: アクセス トークンは、var.databricks_token のように変数で安全に管理しましょう。
terraform.tfvarsファイルにdatabricks_hostとdatabricks_tokenを設定します。
６. Terraformでリソースをデプロイする
Terraform を使って Databricks 上のさまざまなリソースを管理できます。ここでは、クラスタ作成の例を紹介します。
6.1 Databricksクラスタの作成
以下の設定は、最新の Spark バージョンと最小のサポートノードタイプを使って Databricks クラスタを作成します。
Spark Version: 利用可能な最新の Spark バージョンを自動的に取得します。
Node Type：利用可能な中で最も小さいノードタイプを動的に選択します。
Auto-Termination：20分間アイドル状態が続くと、自動的にクラスタをシャットダウンします。
6.2. 先ほど作成したクラスタを使ったジョブの作成
以下の設定は、先ほど作成したクラスタ上で実行する Databricks ジョブを作成します。
実行環境については
通常は Job Cluster でジョブを実行しますが、今回は簡易的な検証のため All-purpose Cluster を利用しています。
All-purpose Cluster は開発やデバッグ向けで、短時間で処理を試せるため、検証段階に適しています。
name：ジョブ名を指定します。
existing_cluster_id：先に作成したクラスタのIDを指定し、そのクラスタ上でジョブを実行します。
max_concurrent_runs：ジョブの同時実行可能な最大数を設定します。
schedule：ジョブの実行スケジュールを設定するブロックです。
・quartz_cron_expression：Cron形式でジョブの実行タイミングを指定します。
・timezone_id：スケジュールのタイムゾーンを指定します（任意）。
task：ジョブの中で実行するタスクを定義します。
notebook_task：Databricksノートブックを実行するタスク設定で、notebook_path に実行したいノートブックのパスを指定します。
6.3. クラスタとジョブへの権限設定
Databricks では、クラスタやジョブなどのリソースに対してユーザーやグループごとに細かいアクセス権限を設定できます。Terraform を使えば、この権限設定もコードとして管理できるため、環境間の差異を防ぎ、変更履歴も追跡可能になります。
以下の例では、
・クラスタ：全ユーザーがアタッチ可能 (CAN_ATTACH_TO) で、特定ユーザーには管理権限 (CAN_MANAGE) を付与。
・ジョブ：特定ユーザーに管理権限 (CAN_MANAGE) を付与
という設定を行っています。
6.4. Terraform Cloud をバックエンドとして利用する設定
Terraform の実行結果や状態は「ステートファイル」として管理されます。
このファイルには作成されたリソースの詳細が含まれるため、
・チームメンバー間で共有
・複数環境の管理
・状態の履歴管理やロールバック
ができるよう、ローカルではなくリモートに安全に保管するのが望ましいです。
Terraform Cloud を利用すれば、ステートファイルをクラウドで一元管理し、
アクセス制御や実行履歴の可視化も可能になります。
terraform Cloudでは組織を作成しておきます。
Remote Execution（デフォルト）では、Terraform コマンドは Terraform Cloud 上の実行環境で走ります。 実行環境を自分のマシンに切り替えるためLocal Execution に変更する必要があります。
Local Execution に変更すると、自分のマシン上で Terraform が実行されるため、ローカルの環境変数や設定ファイルをそのまま利用可能になります。
7. Terraform 設定の適用
すべてのリソース定義が完了したら、以下のコマンドで環境へデプロイできます。
7.1. Terraform の初期化
terraform init
まず、Terraform を初期化して必要なプロバイダやモジュールをダウンロードします。
Initializing terraform with Powershell
7.2 変更内容のプレビュー
Terraform が作成・更新するリソースを事前に確認するには、次のコマンドを実行します。
terraform plan
このコマンドを実行すると、Terraform がこれから適用する変更内容が一覧表示されます。今回の設定例では、以下のリソースが作成または更新される予定です。
・クラスタ：「example」という名前の Databricks クラスタが新規作成されます。
・ジョブ：「example_job」という名前のジョブが新規作成されます。
・クラスタ権限設定：「cluster_permissions」というクラスタ用アクセス権限設定が新規作成されます。
・ジョブ権限設定：「job_permissions」というジョブ用アクセス権限設定が、新しい設定で作成されます。
Terraform plan will show which resources will be created, updated or destroyed
7.3 設定の適用
変更内容を確認し、問題がなければ以下のコマンドで設定を適用します。
実行後、Terraform から「Proceed?」という確認メッセージが表示されますので、yes と入力して確定します。
terraform apply
なお、確認プロンプトをスキップして即時実行したい場合は、以下のように-auto-approve オプションを付与できます。
terraform apply -auto-approve
Output logs
処理が完了すると、クラスタやジョブなどのリソースが Databricks ワークスペースにデプロイされ、利用可能な状態になります。
Cluster()
また、Terraform の状態ファイル（tfstate）は Terraform Cloud に安全に保存され、チームで共有・管理されます。
8. リソースの管理と更新
Terraform を使うことで、インフラリソースの管理がシンプルになります。
-
変更：設定ファイル（
.tfファイル）を修正し、terraform applyを再実行するだけで反映可能です。 -
スケール：変数を活用して、異なるワークロードに応じた環境の動的なスケーリングが行えます。
-
クリーンアップ：構成で定義したすべてのリソースを削除したい場合は、
terraform destroyを実行します。
まとめ
Terraform を利用して Databricks リソースを管理することで、チームはデプロイ作業を自動化し、常に一貫した構成を保てるようになります。
クラスタや SQL ウェアハウス、権限設定のいずれであっても、Terraform によって Databricks 環境の自動化とスケーラビリティが大幅に向上します。
おわりに
Terraform を活用することで、Databricks 環境の構築・運用は効率化され、設定の一貫性やチームでの共同作業が容易になります。 安定したデータ基盤運用を目指す上で、IaC は強力な選択肢です。ぜひ日々の運用に取り入れてみてください。
お知らせ
私たちエーピーコミュニケーションズでは、Databricks を活用したデータ分析基盤の導入から内製化支援まで、幅広くサポートしております。
Databricks にご興味のある方や導入を検討されている方は、ぜひお気軽にお問い合わせください。皆さまのご相談をお待ちしております。
