メインコンテンツまでスキップ
に最終更新

フェーズ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を補完する役割を果たすことができます。

AWS CloudFormation​

AWS 、 AWS CloudFormation テンプレートを使用して、 S3バケット、 IAMロール、VPC などのクラウド リソースの作成、更新、削除を自動化します。

CloudFormationの機能

  • AWSインフラストラクチャ（VPC、S3バケット、IAMロールなど）を管理する。
  • AWS Lambda関数を使用してカスタムリソースを定義します。
  • 以前はDatabricksアカウントAPI呼び出しをラップするために使用されていました。

CloudFormationの制限事項

  • この方法は、以前はDatabricksアカウント コンソールからワークスペースを起動するために使用されていましたが、現在ではDatabricksワークスペースを起動するための推奨方法ではありません。
  • Databricksワークスペース管理には代わりにTerraform使用してください。

ベスト プラクティス : AWSインフラストラクチャ (VPC、 S3 、 IAM ) には CloudFormation を使用しますが、 DatabricksリソースにはTerraform使用します。

設計展開アプローチ​

購読とアカウントの設定​

自動化を実行したり、ワークスペースを手動で作成したりする前に、最初のステップとして、クラウド プロバイダーでDatabricksをサブスクライブします。

AWSサブスクリプション

Databricks on AWSを使い始めるには、2つの方法があります。

AWSアカウントをお持ちではありません

エクスプレスセットアップを使用すると、クラウドプロバイダーへの事前アクセスなしにDatabricksの使用を開始できます。今すぐ登録して、Databricksを使い始めましょう。高速セットアップでは、レイクハウス プラットフォームの探索を開始するために使用できる、サーバーレス ワークスペースと無料トライアル クレジットが提供されます。 無料トライアル クレジットを使用または期限切れになった後は、支払い方法を追加してアップグレードするまでDatabricksを使用できません。 その後、アカウント内にワークスペースを追加作成できます。

既存のAWSアカウントを使用したい

Databricksのトライアルには 2 つの方法でサインアップできます (サインアップする場所によって、無料トライアル終了後の請求の処理方法が決まります)。

  • Databricks経由でサインアップする : 無料トライアル クレジットが使用された後、または期限切れになった後、 Databricks使用を続けるには支払い方法を入力する必要があります。
  • AWS Marketplace経由でサインアップする : 無料トライアルクレジットが使用されるか期限切れになると、 AWSから請求が行われ、 AWSコンソールで請求を管理します。

サブスクリプション登録後のオンボーディングプロセスの一環として、トライアル用の最初のワークスペースが作成されます。

本番運用のデプロイメント

サブスクリプションをアップグレードした後、 Databricksアカウント コンソールを使用してDatabricksアカウントを設定し、ワークスペースを作成できます。 本番運用セットアップの場合は、 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：環境促進パターン​

開発からステージング、そして本番運用までワークロードを促進するためのパターンを作成します。

環境促進ワークフロー

  1. 開発 : 開発構成を含む宣言型自動化バンドルを使用して開発ワークスペースにデプロイします
  2. ステージング ：ステージングワークスペースに昇格し、統合テストを実行します。
  3. 本番運用 : 承認後、本番運用ワークスペースに昇格します

ベストプラクティス

  • 環境固有の設定には、宣言型自動化バンドルを使用してください。
  • 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プロバイダー」および「宣言型自動化バンドルとは？」を参照してください。