Databricks Lakehouse基盤 on AWS
制御/コンピュートプレーン分離・Unity Catalog統制・PrivateLink閉域
可用性 (SLA目標)
Databricks プラン/契約のSLAに準拠(設計目標、構成に依存)
RTO(目標復旧時間)
クラスター再作成・ジョブ再実行に依存(データはS3で永続化)
RPO(目標復旧時点)
ほぼ 0 を目標(Delta Lake / S3 に永続化、設定に依存)
概算コスト
月 数十万円〜(クラスター稼働時間・インスタンスに依存)
構成概要
- 可用性レベル
- マルチAZ
- コンピューティング
- Managed / SaaS
- 想定システム規模
- 大規模(データエンジニア / アナリスト / ML チーム)
- コスト感
- ¥¥¥高コスト
使用AWSサービス
- Databricks Control Plane (Managed)
- Databricks Classic Compute Plane
- Unity Catalog
- Delta Lake
- MLflow
- Jobs / Workflows
- Amazon S3
- AWS PrivateLink
- VPC Endpoint
- AWS IAM (Role)
- AWS KMS
- Amazon CloudWatch
- AWS CloudTrail
概要
Databricks を用いた Lakehouse 基盤を、制御プレーン(Databricks 管理アカウント)と Customer AWS Account(顧客管理VPC内の Classic Compute Plane)に分離して構成します。ノートブック / SQL / ジョブは制御プレーンから提供され、実際のクラスター(Spark)は顧客VPC内で起動。データは Amazon S3 を中心とした Delta Lake(Bronze / Silver / Gold)に蓄積し、Unity Catalog がデータ・モデルの権限と系譜を一元統制します。制御プレーン接続は AWS PrivateLink で閉域化し、S3 へはクロスアカウント IAM Role と VPC Endpoint で最小権限アクセス。データエンジニアリング・BI・ML(MLflow)を一つの基盤に統合します。図では Databricks 管理アカウント / Customer AWS Account / Data Lake の境界を明示しています。可用性・性能・コストは構成・契約・設定に依存します。
★ 設計のポイント
- ▸Databricks 制御プレーンと Customer AWS Account(コンピュート)を明確に分離
- ▸S3 を中心とした Delta Lake(Bronze/Silver/Gold)の Lakehouse
- ▸Unity Catalog によるデータ・モデルのガバナンス(権限・系譜)
- ▸AWS PrivateLink による制御プレーン接続の閉域化 + VPC Endpoint
- ▸データエンジニアリング / BI / ML(MLflow)を統合(設計目標)
システム構成図
周辺・運用機能(クロスカッティング / 全体に適用)
監視・運用
セキュリティ・統制
データ・ML
ガバナンス・コスト
コピーしてすぐ使える IaC
Databricks Lakehouse基盤 on AWSを再現するためのスターターIaCです。事例固有のIP制限、監査、バックアップ、Secret参照は環境に合わせて追加してください。
import * as cdk from "aws-cdk-lib";
import { Construct } from "constructs";
import * as iam from "aws-cdk-lib/aws-iam";
import * as kms from "aws-cdk-lib/aws-kms";
import * as s3 from "aws-cdk-lib/aws-s3";
export class DatabricksLakehouseAwsIntegrationStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
const key = new kms.Key(this, "DataKey", { enableKeyRotation: true });
const bucket = new s3.Bucket(this, "LandingBucket", {
encryption: s3.BucketEncryption.KMS,
encryptionKey: key,
blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
enforceSSL: true,
});
new iam.Role(this, "ExternalPlatformAccessRole", {
assumedBy: new iam.AccountPrincipal("123456789012"),
inlinePolicies: {
S3LandingAccess: new iam.PolicyDocument({
statements: [
new iam.PolicyStatement({
actions: ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
resources: [bucket.bucketArn, bucket.arnForObjects("*")],
}),
],
}),
},
});
}
}この構成を選ぶ理由
Databricks Lakehouse基盤 on AWSは、大規模(データエンジニア / アナリスト / ML チーム)を想定し、AZ障害への耐性と運用現実性を重視する場合に選びやすい構成です。
選定フロー
業務要件を確認する
データ分析・機械学習で求められる可用性、RTO/RPO、データ分類を確認する。
運用体制を確認する
チームが Databricks の運用、監視、権限管理を継続できるかを確認する。
コストと拡張性を比較する
月 数十万円〜(クラスター稼働時間・インスタンスに依存)を許容し、将来のスケールやDR要件に対応できるかを判断する。
代替案との比較
| 候補 | コスト | 運用保守負荷 | スケーラビリティ | 選定すべきケース |
|---|---|---|---|---|
最小構成 | 低い | 単純だが手動復旧が多い | 限定的 | PoC、検証、小規模な開始段階 |
Databricks Lakehouse基盤 on AWS採用 | 高い | 責任分界と外部サービス管理が重要 | 段階的に拡張可能 | データエンジニアリング(ETL / Delta Lake パイプライン) |
上位冗長化構成 | 高い | 設計・監視・訓練が増える | 高い | 厳格なSLA、DR、監査要件がある場合 |
採用時のトレードオフ
設計前提の確認が必要
コストと運用負荷のバランス
🛡 セキュリティ・コンプライアンスのポイント
🏛 エンタープライズ設計観点・統制
業務領域
データ分析・機械学習
プラットフォーム
Databricks
重要度
高(データエンジニアリング / BI / ML の統合基盤)
接続方式
AWS PrivateLink による制御プレーン接続の閉域化 + VPC Endpoint
データ分類
機密(業務データ / 学習データ / モデル)
✔ データ活用・統制の設計目標
- •Databricks 制御プレーンと Customer AWS Account(コンピュート)を分離する
- •AWS PrivateLink で制御プレーン接続を閉域化し、公衆経路を避ける
- •Unity Catalog によるデータ・モデルの一元的なガバナンス(権限・系譜)
- •クロスアカウント IAM Role と VPC Endpoint による最小権限の S3 アクセス
- •CloudTrail / クラスターログによる監査証跡、KMS による暗号化
⚠ 前提条件・留意事項
- •Databricks は AWS ネイティブサービスではなくマネージドプラットフォームであり、責任分界・契約が別途必要
- •可用性・性能はクラスター構成・リージョン・契約・設定に依存する(設計目標)
- •コストはクラスターの稼働時間・インスタンス種別・自動停止設定に強く依存する
- •Unity Catalog / PrivateLink の利用可否はプラン・リージョンに依存する
✓ メリット
- •制御プレーンとコンピュートプレーンの分離で、データを顧客VPC/S3 に保持しやすい
- •Unity Catalog でデータ・モデルの権限と系譜を一元統制
- •Delta Lake により Lakehouse でBI/MLを同一基盤に統合
- •PrivateLink / VPC Endpoint で閉域化し統制要件に対応しやすい
✗ デメリット
- •AWSネイティブではなくマネージドプラットフォームで、責任分界・契約整理が必要
- •クラスター稼働時間・インスタンス種別でコストが膨らみやすい
- •制御/コンピュート分離・Unity Catalog 等の設計/運用に学習コスト
- •可用性/性能は構成・契約・設定に依存する(設計目標)
→ 主なユースケース
- •データエンジニアリング(ETL / Delta Lake パイプライン)
- •全社のセルフサービスBIと機械学習(MLflow)の統合基盤
- •データ・モデルガバナンスが必要なエンタープライズ分析