フェーズ2：ワークスペース戦略の設計

この段階では、組織の構造、セキュリティ要件、および運用上のニーズに合わせてワークスペースのアーキテクチャを設計します。

ワークスペースを理解する

Databricksワークスペースは、チームがワークロードを開発および実行するクラウド リージョンの運用境界です。 これには、コラボレーション アーティファクト (ノートブック、ジョブ、ダッシュボード、リポジトリなど) と、ワークスペースの権限、クラスターポリシー、シークレット、 SQL構成などのワークスペースを対象とした構成が含まれます。 ワークスペースは、実行とコラボレーションのための環境です。永続データは通常、オブジェクトストレージなどのクラウドサービスに保存されます。

管理者は、組織の目標に基づいてワークスペースを作成および構成します。単一のワークスペースを使用する企業もあれば、ドメイン、環境（開発／テスト／本番）、事業分野、地域、または規制上の境界によってワークスペースを分ける企業もある。これらの選択によって、管理範囲、職務分掌、コスト配分、および複製頻度が決定されます。Databricksを小規模で導入する場合は最小限の設定で済みますが、大規模な導入の場合は、将来の要件と、それがチームの業務を支援しながらデータを保護する能力にどのように影響するかを考慮する必要があります。

ワークスペース展開モデルを選択してください

Databricksのワークスペースには、以下の2種類があります。

サーバレスワークスペース

Databricksアカウント内のワークスペース展開。完全なサーバーレス エクスペリエンスを提供するために、サーバーレス コンピュートと当然ストレージが事前構成されています。

サーバレスワークスペースの特徴

• 当然ストレージ : ワークスペースと同じリージョンにある、 Databricksのクラウド アカウント上のクラウド ストレージ。

  • 引き続きサーバレス ワークスペースからクラウド ストレージに接続できます。

• サーバーレス コンピュート : 事前設定されており、すぐに利用可能です。

• 高速スタートアップ : インフラストラクチャのプロビジョニングは必要ありません。

• 自動スケーリング ：ワークロードの需要に応じてスケーリングします。

クラシックなワークスペース

Databricksアカウントにワークスペースを展開すると、既存のクラウド アカウントのストレージとコンピュート リソースをプロビジョニングできます。 サーバレス コンピュートとサービスは従来のワークスペースでも引き続き利用できます。

典型的なワークスペースの特徴

• 顧客管理のストレージ : クラウド アカウント内のストレージ。
• カスタマー管理のコンピュート : クラウド アカウント内のコンピュート インフラストラクチャ。
• ネットワーク制御 ：VPC/VNet構成を完全に制御できます。
• 柔軟性 : サーバレス コンピュートは従来のコンピュートと並行して使用できます。

ワークスペース展開モデルの推奨事項

次の推奨事項を使用して、シナリオにサーバレスとクラシック ワークスペースのどちらを展開するかを決定します。

• サーバレスを利用する場合は、利用予定のリージョンがサーバレスワークスペースおよびサーバレスコンピュートに対応していることを確認してください。
• サーバレス ワークスペースの制限を確認して、要件を満たしていることを確認してください。
• 主なユースケース (オートスケールと細粒クラスター制御など) を評価し、それに応じてサーバレスまたはクラシック ワークスペースを選択します。
• おすすめ ：業務効率化のためにまずはサーバレスワークスペースから始めましょう。
• 次のような場合は、クラシックワークスペースを使用してください 。カスタムネットワーク構成、オンプレミス接続、または特定のコンプライアンス要件が必要な場合。

デザインワークスペース分割戦略

レイクハウスのセットアップを異なるワークスペースに分割する理由はいくつかあります。 ワークスペースのアーキテクチャを設計する際には、これらのパターンを考慮してください。

ワークスペースを分割する理由

データ保護要件に基づいてワークスペースを分離する

厳格なデータ分離が義務付けられている規制の厳しい業界では、ワークスペースを分離することで、リスクの低いワークフローに支障をきたすことなく、機密データの管理を簡素化できます。

異なる事業部門を分離する

組織の境界によって完全な分離が必要な場合、Databricks内のワークスペース資産が事業部門間で共有されないようにしてください。

プラットフォームのニーズが異なるチームを分離する

異なるチームがプラットフォームの異なる機能セットへのアクセスを必要とする場合（例えば、中央管理チームにはすべての機能への完全なアクセスが必要だが、他のチームやプラットフォームテストチームには必要ないなど）、これらのチームはワークスペースによって分離されるべきです。

ソフトウェア開発ライフサイクル（SDLC）環境を分離する

厳格な分離要件がある場合は、開発環境、ステージング環境、本番環境をそれぞれ分離してください。例えば：

• 組織によっては、開発環境、ステージング環境、本番環境をそれぞれ異なる仮想ネットワークに展開しているため、各環境ごとに個別のワークスペースが必要になります。
• 新しいワークスペース設定を本番環境に適用する前にテストするには（機能の有効化や制限など）、本番環境は開発環境やステージング環境とは異なるワークスペースである必要があります。
• また、多くの企業は、さまざまなストレージ コンテナー、仮想ネットワーク、 Databricksワークスペースを使用して、ストレージとコンピュートの観点からこれらの環境を分離しています。

複数のクラウドリージョンで運用する

組織が複数の国や地域でユーザーにサービスを提供したり、データを収集したりする場合、規制や社内ポリシーによって特定のデータをその地域内に保持することが求められることがあり、そのため、各クラウドリージョンにデータを処理または保存するための個別のワークスペースをデプロイする必要が生じます。ワークスペースを地域ごとに分割することで、チームはDatabricksの導入をローカルストレージアカウントや仮想ネットワークと連携させつつ、ガバナンスとセキュリティに関する一般的な企業標準を遵守することができます。

地域ワークスペースはまた、コンピュートをローカル ユーザーとデータ ソースの近くに配置することで、インタラクティブなアナリティクスとデータ アプリケーションのレイテンシを短縮し、ユーザー エクスペリエンスとクエリ パフォーマンスを向上させます。

リソース制限を克服するために分割する

クラウドアカウント（またはサブスクリプション）には、リソース制限があります。ワークスペースを異なるアカウントに展開することは、各ワークスペースで十分なリソースを確実に利用できるようにする方法です。 また、各Databricksワークスペースには、同時に実行できるタスクの数やDatabricks Appsの最大数などの制限があります。 ワークスペースを分割すると、各ワークスペースのワークロードがより多くのリソースにアクセスできるようになります。

クラウドプロバイダーのリソース制限

AWSワークスペースの制限

AWS上のDatabricksアカウントあたりのワークスペースの最大数:

• デフォルトの制限値 ：プレミアムプランは10、エンタープライズプランは50。
• ハードリミット
  • プレミアム層: 50 (増分バッチ 20 で許可)。
  • エンタープライズ層: クラシック ワークスペースの場合は 1000、サーバレス ワークスペースの場合は 2000 (増分バッチ 50 で許可)。

ワークスペースの制限を増やすには、Databricksのアカウントチームの協力が必要です。

重要なクラウドインフラストラクチャの制限

各ワークスペースはAWSアカウント内のVPCにデプロイされるため、特に次のような基本的な制限に注意してください。

• AWSアカウントの数。
• リージョンごとのVPCの数。

ワークスペースを分割する際の注意点

コラボレーションの制限

ワークスペース間でのノートブックの共有（コラボレーション）はできません。Unity Catalogをワークスペース間で活用し、可能な限りデータ共有を促進しましょう。GitHubを使用すれば、ワークスペース間でコードを共有できます。

管理費

ワークスペースの数が多い場合、管理上の負担は相当なものになる可能性がある。100を超えるワークスペースが存在する場合、意図せずして孤立したワークスペースや管理されていないワークスペースが発生し、コスト増加やデータ漏洩のリスクにつながる可能性があります。

自動化要件

複数のワークスペースの場合、セットアップとメンテナンスの両方を完全に自動化する必要があります（Terraform、クラウド固有のツール、またはREST APIなどのツールを使用）。これは、モビリティ目的やディザスタリカバリ (DR) シナリオで特に重要です。このシナリオでは、リージョンまたはクラウド間での迅速なワークスペース プロビジョニング、フェイルオーバー、および構成のレプリケーションが重要な運用要件となります。

ネットワークインフラストラクチャのコスト

すべてのワークスペースをネットワーク層で保護する必要がある場合 (データ漏洩保護など)、ワークスペースが数百ある場合、必要なネットワーク インフラストラクチャは非常に高価になる可能性があります。

機能制限

Unity Catalogマネージド サービスにアクセスする、サーバレス出力制御を備えたサーバレス コンピュートなど、一部の機能にはクロスワークスペース サポートが制限されています。 AI機能、 AWSプライベートリンク、暗号化キーなどの特定の機能は、ワークスペースレベルで定義されます。企業が他のチームに対して異なるセキュリティ設定を必要とする場合、これらの機能の承認によってワークスペースの分割が決定されます。

SDLCとビジネスユニットマトリックス

Dev/Staging/Prod 用にワークスペースを分離し、ビジネス ユニットもワークスペースごとに分離したい場合は、さまざまなクラウド プロバイダーのワークスペースの制限を考慮してください。 このマトリックスは、すぐに多数のワークスペースを生み出す可能性がある。

ワークスペースのセキュリティモードを理解する

Unity Catalogに割り当てられたワークスペースは、クラスターの次のアクセス モードをサポートします。

セキュリティモード	特徴
Standard	複数のユーザーが同じクラスター上で作業できます。一般的なワークロード（例えば、ETL、データ探索）に適しています。SQL、Python、Scalaのみをサポートしています。ビューベースのアクセス許可や属性ベース／テーブルベースのアクセス制御（ABAC）など、きめ細かなアクセス制御（FGAC）をサポートします。機械学習ML DBRはサポートされていません（ただし、多くのML標準DBRにインストールできます）。
専用	ML DBRとすべての言語をサポートします。単一ユーザー専用: クラスターには 1 人のユーザーのみがアクセスできます (クラスターの作成時に割り当てられます)。 単一グループ専用：同じグループの複数のユーザーが同じクラスター上で作業できます（グループはクラスター作成時に割り当てられます）。

ワークスペースの展開例

Databricksの使用を開始するとき、ほとんどの組織は単一のクラウド リージョンに単一のテナント レイクハウスをデプロイします。 しかし、組織が成長するにつれて、管理者は複雑なユースケースに合わせて導入内容をカスタマイズできるようになります。

シングルテナント、シングルリージョン展開

• 1 つの本番運用ワークスペース。
• 1つの開発ワークスペース。
• すべてのリソースが単一のクラウドリージョンに集約されています。

複数地域への展開

• 米国地域の本番運用ワークスペース。
• EU 地域の本番運用ワークスペース ( GDPRコンプライアンス向け)。
• 共有開発ワークスペース。
• Unity Catalogメタストアは、リージョンごとに構成され、リージョン間データアクセス用のD2D Delta Sharingを備えています。

複数事業部門への展開

• 各事業部門（例えば、営業、マーケティング、エンジニアリングなど）ごとに1つのワークスペースを設ける。
• 全チームが共有できる開発ワークスペース。
• カタログレベルの分離機能を備えた、中央集約型のUnity Catalogメタストア。

環境に基づいた展開

• 本番運用ワークスペース（全事業部）。
• ステージング ワークスペース (本番前の運用テスト)。
• 開発ワークスペース（共有開発環境）。
• 各環境ごとにネットワークとストレージを分離する。

ワークスペースの命名規則を定義する

ワークスペースの命名規則を統一し、検索性と管理性を向上させる。

推奨される命名パターン

{organization}-{environment}-{region}-{purpose}

例

• acme-prod-us-west-analytics
• acme-dev-shared
• acme-prod-eu-west-gdpr
• acme-staging-us-east-dataeng

ワークスペースの命名に関するベストプラクティス

• 小文字とハイフンを使用してください。
• 環境指定（例：prod、staging、dev）を含めてください。
• 複数リージョン展開の場合は、リージョンを含めてください。
• 該当する場合は、事業部門または目的を記載してください。
• 名前は50文字以内にしてください。
• 運用マニュアルに命名規則を明記してください。

ワークスペース戦略に関する推奨事項

推奨

• SDLC環境を個別のワークスペースに分割する（少なくとも開発環境と本番環境、要件によってはそれ以上）。
• 人為的ミスを最小限に抑え、再現性のあるデプロイメントパターンを確立するために、可能な限りTerraformなどの自動化ツールを使用してください。
• サーバレス ワークスペースから始めて、特定のネットワークまたはコンプライアンスの要件がある場合にのみ、クラシック ワークスペースに切り替えてください。
• ドキュメントワークスペースの分割戦略と命名規則。
• Unity Catalogリソースを管理するための管理ワークスペースをリージョンごとに作成します。

これらのパターンを避けてください

• 個々のチームまたは小規模プロジェクト用に個別のワークスペースを作成しないでください (代わりに、 Unity Catalogカタログとスキーマを使用して分離します)。
• 十分な根拠と堅牢な自動化がない限り、50～100を超えるワークスペースを展開しないでください。
• ワークスペースを不必要に分割しないでください (分離の必要性と運用の複雑さのバランスをとる)。
• 命名規則に従わずに、場当たり的にワークスペースを作成することは避けてください。

第2相試験の結果

フェーズ2を完了すると、以下のものが得られます。

• 選択されたワークスペース展開モデル (サーバレス vs クラシック ワークスペース)。
• ワークスペース分割戦略は、組織のニーズ（例えば、環境、事業部門、地域、コンプライアンスなど）に基づいて設計されます。
• リソースの制限と緩和戦略についての理解。
• ワークスペースの命名規則を定義しました。
• セキュリティモード（標準モードと専用モード）を理解しました。
• 導入アーキテクチャの例を文書化しました。
• ワークスペースのプロビジョニングに関する自動化戦略が計画されています。

次のフェーズ ：フェーズ3： Unity Catalogアーキテクチャの設計