フェーズ7：インフラストラクチャ・アズ・コードのアプローチを計画する
このフェーズでは、 Databricksのデプロイと管理を自動化するためのInfrastructure as Code（ IaC ）戦略を設計します。 。
Infrastructure as Code ツールは、 Databricksワークスペースの起動と管理に推奨される方法です。 各クラウドにはそれぞれ独自のIaCツールがあり、クラウドに依存しないツールもいくつか存在する。
Infrastructure as Codeツールを選択する
Terraform (レイクハウスのインフラに推奨)
Terraformは、様々な業界で広く支持されているサードパーティ製のIaCツールです。これは最も人気のあるサードパーティ製のIaCツールであり、Databricksが公式にサポートするTerraformプロバイダーも提供している。TerraformのTerraformプロバイダーのドキュメントには、すぐに使い始めるのに役立つ例とガイダンスが掲載されています。
Terraformの機能
- Databricksアカウント リソース (ワークスペース、ネットワーク、ストレージ構成など) を管理します。
- ワークスペース リソース (クラスター、ジョブ、ノートブック、 Unity Catalogリソースなど) を管理します。
- クラウド非依存：AWS、Azure、GCPのいずれのクラウド環境でも、同じ言語で動作します。
- モジュールとベストプラクティスを備えた大規模なエコシステム。
- Databricksによる公式サポート。
Terraformのデプロイパターン
- アカウントレベルのインフラストラクチャ ：ワークスペース、ネットワーク、ストレージ認証情報、メタストア。
- ワークスペースレベルの構成 : クラスターポリシー、インスタンスプール、ワークスペース設定。
- Unity Catalogリソース : カタログ、スキーマ、外部ロケーション、ストレージ認証情報。
- ノートブックとリポジトリ : ノートブックとGitリポジトリをワークスペースにデプロイします。
- シークレット ：Databricksのシークレットスコープでシークレットを管理します。
Terraformのベストプラクティス
- Terraformモジュールを使用して、組織内で再利用可能なパターンを作成しましょう。
- Terraformの状態をリモートバックエンド（S3、Azure Blob Storage、GCSなど）に状態ロック機能付きで保存します。
- Terraformワークスペースまたは個別の状態ファイルを使用して、環境 (dev、staging、prod など) を分離します。
- Terraformの変数と
tfvarsファイルを使用して、構成をパラメータ化します。 - 変更を適用する前に、 CI/CDパイプラインで計画レビューを有効にします。
- コストの帰属と管理のために、すべてのリソースに一貫したタグを付ける。
- モジュールを文書化し、モジュール登録簿を維持する。
- 公式のDatabricks Terraformプロバイダーのサンプルを参考にしてください。
Terraformプロバイダーのドキュメントと例については、 Databricks Terraform Registryを参照してください。
宣言的自動化バンドル (データおよびAIリソースに推奨)
Declarative Automation Bundles は、 Databricksが提供するファーストパーティのInfrastructure-as-Codeツールで、データとAIの一貫したパッケージングとデプロイを可能にします。 。 公式サポートとDatabricksワークスペースとの統合を提供します。
宣言型自動化バンドルの機能
- ジョブ、パイプライン、ノートブックをデプロイします。
- MLモデルをデプロイおよび管理する。
- 複数の環境（開発環境、ステージング環境、本番環境など）にわたるデプロイメントを管理します。
- Gitとのソースコード管理統合。
- GitHub Actions、Azure DevOps、GitLab CIとのCI/CD統合。
- 一般的なパターンをテンプレート化する。
宣言型自動化バンドルの使用例
- データエンジニアリング ワークフローとLakeFlow Spark 宣言型パイプラインSparkラインをデプロイします。
- 機械学習ワークフローとモデルサービング エンドポイントを展開します。
- ノートブックとSQLクエリをデプロイします。
- 環境固有の設定を管理します。
- 開発からステージング、本番運用までのプロモーションを自動化します。
宣言型自動化バンドルのベストプラクティス
- データおよびAIワークロード（ジョブ、パイプライン、モデルなど）には、宣言型自動化バンドルを使用します。
- インフラストラクチャ リソース (ワークスペース、ネットワーク、 Unity Catalogなど) にはTerraform使用します。
- 一般的なユースケースには、宣言型自動化バンドルのテンプレートを使用してください。
- CI/CDパイプラインと統合して、展開を自動化します。
- 開発環境、ステージング環境、本番環境には、それぞれ環境固有の設定を使用してください。
- Gitにおけるバージョン管理バンドルの定義。
宣言型自動化バンドルに関するドキュメントについては、 「宣言型自動化バンドルとは？」を参照してください。
クラウドネイティブなInfrastructure as Codeツール
各クラウドプロバイダーは、クラウド リソースを管理するためのネイティブな IaC ツールを提供しています。これらのツールは、クラウド特有のインフラストラクチャ構築において、Terraformを補完する役割を果たすことができます。
設計展開アプローチ
購読とアカウントの設定
自動化を実行したり、ワークスペースを手動で作成したりする前に、最初のステップとして、クラウド プロバイダーでDatabricksをサブスクライブします。
GCPサブスクリプション
GCP用のDatabricksアカウントの作成は、 Marketplaceを介して行われます。 これには、請求アカウント ( Databricksアカウントに関連付けられます) と Google クラウド プロジェクト ( Databricksに関連付けられません。同じ請求アカウント内で必要な数のプロジェクトにデプロイできます) が必要です。
GCP Marketplace管理者は、 Databricksリストを通じてDatabricks on Google Cloudにサブスクライブできます（サブスクライブした場所によって、無料トライアル終了後の請求の処理方法が決まります）。 サブスクリプションは無料トライアルを開始します。 無料トライアルを開始する Google アカウントは、自動的にコンソールにアクセスできる最初のDatabricks管理者になります。 GCP請求アカウントごとにDatabricksアカウントを 1 つだけ持つことができます。
Databricksは、アカウントコンソールへのアクセス権を失うことを避けるため、新規ユーザーを迅速に追加することを推奨しています。
無料トライアルの有効期限が切れると、 Databricksの使用量はMarketplaceサブスクリプションに対して選択した Google クラウド請求アカウントに従量課金制で請求され、請求は Google クラウド コンソールで管理します。
ワークスペースの展開
サブスクリプションをアップグレードした後、 Databricksアカウント コンソールを使用してDatabricksアカウントを設定し、ワークスペースを作成できます。 ワークスペースの展開には、Google クラウド リソース (ストレージ、 VPC 、 KMSなど) とDatabricksリソース (ワークスペース、CMEK など) のプロビジョニングが含まれます。 本番運用セットアップの場合は、 Terraformなどの自動インストールを使用します。
管理ワークスペースを備えたBootstrap
自動化を実行したり、ワークスペースを手動で作成したりする前の最初のステップは、管理目的のみに使用される、必要なリージョンごとに 1 つのワークスペースを構築することです (データ プラットフォーム ユーザーはアクセスできません)。
管理用ワークスペースを構築する主な理由
- Unity Catalog APIs : Unity Catalog APIs主にワークスペースAPIsです。カタログや場所などを作成するには、ワークスペースが必要です。
- 管理タスク ：システムテーブルを使用したダッシュボードの実行、セキュリティ分析ツール（SAT）の実行、およびその他の管理操作に使用されます。
- 自動化ハブ ：Terraform、宣言型自動化バンドル、その他の自動化ツールを実行するための中心的な場所。
管理ワークスペースのベストプラクティス
- 地域ごとに管理ワークスペースを1つ作成してください。
- アクセス権限をプラットフォーム管理者のみに制限する。
- このワークスペースはUnity Catalog管理とシステムテーブルのクエリに使用します。
- このワークスペースに自動化ツール（例えば、宣言型自動化バンドル、Terraformランナーなど）をデプロイします。
- 目的とアクセス制限を文書化する。
設計展開パターン
パターン1：ワークスペース展開パターン
ペルソナとユースケースにマッピングされた、一般的なワークスペースのデプロイパターンに対応するTerraformモジュールを作成します。
ワークスペースのパターン例
- データエンジニアリング ワークスペース : Classic コンピュート、カスタマー管理VPC 、 LakeFlow Spark宣言型パイプラインが有効。
- アナリティクス ワークスペース : サーバレス コンピュート、 SQLウェアハウス、 BI統合。
- MLワークスペース : GPUクラスター、 MLランタイム、 MLflowが有効。
- 本番運用ワークスペース : 高可用性、プライベート リンク、顧客管理キー。
利点
- 環境を問わず、一貫したデプロイメントを実現する。
- 設定エラーが減少しました。
- 新しいワークスペースのプロビジョニングが高速化されました。
- ペルソナごとに懸念事項を明確に区別する。
パターン2：環境促進パターン
開発からステージング、そして本番運用までワークロードを促進するためのパターンを作成します。
環境促進ワークフロー
- 開発 : 開発構成を含む宣言型自動化バンドルを使用して開発ワークスペースにデプロイします
- ステージング ：ステージングワークスペースに昇格し、統合テストを実行します。
- 本番運用 : 承認後、本番運用ワークスペースに昇格します
ベストプラクティス
- 環境固有の設定には、宣言型自動化バンドルを使用してください。
- CI/CDパイプラインによるプロモーションの自動化。
- 本番運用の展開には承認ゲートが必要です。
- 本番運用プロモーションの前にステージングでテストします。
パターン3：再利用可能なモジュールパターン
共通パターンを構築するための構成要素として、Terraformモジュールのライブラリを構築する。
サンプルモジュール
- ワークスペース モジュール : ネットワーク、ストレージ、 Unity Catalogアタッチメントを備えたワークスペースを展開します。
- Unity Catalog カタログモジュール : スキーマと権限を含むカタログを作成します。
- クラスターポリシー モジュール : さまざまなチームまたはユースケースに合わせてクラスターポリシーを定義します。
- ネットワークモジュール ：サブネット、NAT、ファイアウォールルールを備えたVPC/VNetを作成します。
利点
- コードの重複を削減します。
- 組織の基準を確立する。
- メンテナンスとアップデートを簡素化します。
- チームによるセルフサービスを可能にします。
インフラストラクチャ・アズ・コードの推奨事項
推奨
- 可能な限り、IaCツールを使用してワークスペースとインフラストラクチャを起動してください。
- インフラストラクチャ リソース (ワークスペース、ネットワーク、 Unity Catalog 、ストレージなど) にTerraform使用します。
- データおよびAIワークロード（ジョブ、パイプライン、ノートブック、モデルなど）には、宣言型自動化バンドルを使用します。
- 各クラウドで利用可能な既存のパターン（Terraformプロバイダーの例など）を使用してください。
- 必要な各地域に管理ワークスペースを1つずつ構築してください。
- ペルソナとユースケースに対応した、再利用可能なTerraformモジュールを作成します。
- IaCの状態を状態ロック機能を使用してリモートバックエンドに保存します。
- IaC導入をCI/CDパイプラインと統合します。
- デプロイメントパターンとモジュールの使用状況を文書化する。
- すべてのリソースで一貫したタグ付けを使用してください。
これらのパターンを避けてください
- 本番運用ではワークスペースを手動で作成しないでください (再現性のためにIaCを使用します)。
- Terraformの状態をローカルに保存しないでください（リモートバックエンドを使用してください）。
- 計画レビューなしにデプロイしないでください（CI/CDで計画承認を有効にしてください）。
- IaCと手動設定を混在させないでください（どちらか一方の方法を選択してください）。
- 独自の構成を持つ、いわゆる「スノーフレークワークスペース」を作成することは避けてください。
第7相の結果
フェーズ7を完了すると、以下のものが得られます。
- IaCツール戦略として、インフラストラクチャにはTerraform、ワークロードには宣言型自動化バンドルを採用しました。
- クラウドネイティブなIaCツール（例えば、CloudFormation、ARM/Bicep）の使用法が定義されています。
- 購読およびアカウント設定の手順を計画しました。
- 管理用ワークスペースのデザインを定義しました（地域ごとに1つ）。
- 設計されたデプロイメントパターン（例えば、ワークスペースパターン、環境プロモーション、再利用可能なモジュールなど）。
- Terraformモジュール ライブラリが計画されています (ワークスペース、 Unity Catalog 、ネットワーク、クラスターポリシー モジュールなど)。
- IaC（Infrastructure as Code）導入のためのCI/CD統合戦略を策定した。
- リモート状態管理戦略を設計しました（例：S3、Azure Blob、GCS）。
- IaC（Infrastructure as Code）で管理されるリソースに対して定義されたタグ付けおよび命名規則。
次のフェーズ :フェーズ 8: コンピュート構成の設計
実装ガイダンス ：IaC戦略を実装するための手順については、 「Databricks Terraformプロバイダー」および「宣言型自動化バンドルとは？」を参照してください。