フェーズ5：ストレージアーキテクチャの設計
このフェーズでは、 DatabricksワークスペースとUnity Catalogのストレージ インフラストラクチャを設計します。
Databricks上でデータを処理するには、クラウドストレージを設定する必要があります。Databricksには2種類のストレージがあります。
- Databricksが管理するストレージ （デフォルトストレージ）：Databricksが所有するクラウドアカウント内のストレージ。サーバレス ワークスペースによってワークスペース ルート ストレージとして使用され、オプションでUnity Catalogカタログにも使用されます。
- 顧客管理のストレージ : 顧客のクラウド アカウント内のストレージ。 ワークスペース ストレージおよびUnity Catalogストレージとしてクラシック ワークスペースによって使用されます。
どちらのストレージタイプも、同じ基盤となるクラウドサービスを使用しています。
ワークスペースのストレージアーキテクチャを設計する
ワークスペース ストレージ アカウント/バケットはDatabricksワークスペースの必須部分であり、次のようないくつかの目的で使用されます。
- このワークスペース用に作成された安心Unity Catalogカタログのストレージ。
- MLflowエクスペリメントおよびMLflowレジストリ モデルの確実な場所、 LakeFlow Spark宣言型パイプラインの確実な場所、クラウド Fetch など、プラットフォーム上のさまざまなサービスによって使用されるその他の内部生成データ。
ワークスペースのストレージパターン
顧客が管理する仮想ネットワークを使用すると、ワークスペースシステムバケットをより詳細に制御できます。最初にルート バケットを作成してから、それをDatabricksワークスペースに割り当て、バケット ポリシーに対する完全な制御を維持しながら、ワークスペースが引き続きバケットにアクセスできるようにします。
ワークスペースのストレージに関するベストプラクティス
- Unity Catalog外部ロケーションを使用して、自作ワークスペースのストレージの場所をオーバーライドします。
- ウェブアプリからのアップロードは、どうしても必要な場合を除き禁止します（管理ページから設定できます）。
- 本番運用顧客データにはワークスペース ルート バケット ( DBFS ) を使用しないでください。
- ルートバケットに関するリスクと回避策を理解する。
DBFS移行
DBFS ( Databricks File System) は、新しい本番運用データには使用しないでください。 既存のデプロイメントの場合：
- 構造化データ : DBFSテーブルをUnity Catalogマネージドテーブルに移行します。
- 非構造化データ ：POSIX形式のファイルアクセスを実現するために、 DBFSからUnity Catalogボリュームへファイルを移行します。
- ワークスペース ファイル : ノートブック、ライブラリ、およびクラスターのログには、引き続きワークスペース ストレージ ( DBFSではない) を使用します。
Unity Catalogのストレージアーキテクチャの設計
Unity Catalogメタストアは、データの保存方法と保存場所を決定する3種類のオブジェクト（管理対象、外部、外部）をサポートしています。
ストレージオブジェクトタイプ
管理対象
管理対象オブジェクトの場合、管理対象ストレージの場所は、マネージドテーブルと管理対象ボリュームのデータを保存するためのクラウド オブジェクト ストレージ内の場所を指定します。 管理対象ストレージの場所を、メタストア、カタログ、またはスキーマに関連付けることができます。マネージドテーブルまたは管理対象ボリュームの作成時に、階層の下位レベルにある管理対象ストレージの場所は、上位レベルで定義されたストレージ場所を上書きします。
デフォルトの場所に依存することは推奨されません。意図しないデータの重複配置につながり、アクセス制御やライフサイクル管理が複雑化する可能性があるためです。カタログまたはスキーマレベルで、ストレージの場所を明示的に定義します。
外部オブジェクト
外部オブジェクトは、データを外部ロケーションに保存します。 外部ロケーションは、Unity Catalogのストレージ認証情報をクラウドオブジェクトストレージコンテナ（例えば、Amazon S3バケット、Azureコンテナ、またはGoogle Cloud Storageバケット）に関連付けます。外部ロケーションは以下の目的で使用されます。
- カタログとスキーマの管理対象ストレージの場所を定義します。
- 外部テーブルと外部ボリュームの場所を定義します。
異物
フォーリンカタログは、リモート テーブルおよびスキーマにアクセスするための外部データ システムへの接続を指定します。 フォーリンカタログを、 Hive metastore 、 AWS Glue 、 Snowflake Horizon などの外部ソースのメタデータに関連付けることができます。 フォーリンカタログはリモート システムのデータベース オブジェクトへの読み取り専用アクセスを提供し、データを複製せずにUnity Catalogを通じて外部テーブルとスキーマをクエリできるようにします。
クラウドストレージアーキテクチャ
GCPストレージアーキテクチャ
GCPアカウントの場合、 Unity Catalogメタストアには次のものがあります。
- メタストア レベルのマネージドテーブル用の 0 または 1 つのGCSバケット。
- マネージドテーブルのカタログ レベルまたはスキーマ レベルの 0 個以上のバケット。
- 外部テーブル用のバケットは0個以上必要です。
ワークスペースと同様に、GCPバケットは異なるGCPプロジェクトに配置できます。GCPサービス アカウントはUnity Catalogがストレージ バケットにアクセスするための認証を提供します。
ストレージ分離パターン
環境別に保管場所を分ける
開発環境、ステージング環境、本番運用環境に異なるストレージ コンテナを使用します。 これにより明確な境界が設けられ、下位環境からの意図しないデータアクセスが防止されます。
事業部門ごとに保管場所を分ける
事業部門がガバナンスや請求目的でデータの完全な分離を必要とする場合は、各事業部門ごとに個別のストレージ認証情報を持つ個別のストレージコンテナを使用してください。
データドメインごとにストレージを分離する
データメッシュアーキテクチャでは、各ドメインは、ドメイン固有のストレージ認証情報によって管理される独自のストレージコンテナを持つべきである。
マルチリージョンストレージ設計
複数のリージョンでDatabricksを使用する場合、ストレージ アーキテクチャはデータの局所性とリージョン間のアクセス パターンを考慮する必要があります。
- パフォーマンス向上のため、ストレージコンテナはメタストアと同じリージョンにデプロイしてください。
- リージョン間でデータを共有するには、 Databricksが管理する（D2D） Delta Sharing使用します。
- 地域間のデータアクセス頻度とデータ量を評価し、データレプリケーションパイプラインが必要かどうかを判断する。
- 地域をまたいでデータにアクセスする際には、データ転送コストを考慮する必要があります。
共有テーブルを外部テーブルとして複数のメタストアに登録しないでください。 リスクとしては、メタストアAへの書き込みによって発生したスキーマ、テーブルプロパティ、コメントへの変更が、メタストアBに全く反映されないことです。メタストアBのテーブルは、正しいスキーマを持つように再作成する必要があり、テーブルプロパティとコメントは完全に切り離された状態になります。 これにより、 Deltaコミット サービスとの一貫性の問題が発生する可能性もあります。 メタストア間でデータを共有するには、D2D Delta Sharing使用します。
アクセスおよび認証戦略の設計
Databricksは、すべてのデータへのアクセス管理にUnity Catalogを使用することを推奨しており、特に可能な限りマネージドテーブルを使用することを推奨しています。Unity Catalogフルマネージド ストレージ レイアウト、メタデータ、マネージド テーブルのガバナンス。
Unity Catalogは、テーブルやボリュームを格納する外部クラウドストレージへのアクセスを管理するために、外部ロケーションを使用します。外部ロケーションは、クラウドストレージへのパスと、そのロケーションにアクセスするために必要な認証情報を定義します。Unity Catalogはクラウドストレージに加えて、テーブル、モデル、その他のアセットのアクセス権限も管理し、外部カタログとの連携も可能です。
クラウドによる認証方法
GCP認証アーキテクチャ
GCPでは、Unity Catalogがストレージアクセス用のサービスアカウントを生成します。
- Unity Catalogでストレージ認証情報を作成します。これにより、コントロール プレーンにGCPサービス アカウントが生成されます。
- サービスアカウントに、GCSバケットに対する適切なIAMロール（例：ストレージオブジェクトビューアー、ストレージオブジェクトクリエーター）を付与します。
- ストレージ認証情報を使用する外部ロケーションを作成する
GCP認証のベストプラクティス
- 異なるGCSバケットまたはデータドメインには、それぞれ別のサービスアカウントを使用してください。
- IAM条件を使用して、最小権限のアクセス許可を適用します。
- Google Cloud Logging を有効にして、 GCSバケットへのアクセスを監査します。
- IAMポリシーを使用してサービス アカウントへのアクセスを制限します。
暗号化戦略の設計
顧客が管理するストレージは、標準的なクラウドの手法を用いて暗号化できます。デフォルトでは、保存データはクラウドプロバイダーの暗号化方式とDatabricksが管理するキーを使用して暗号化されます。
暗号化オプション
Databricksが管理するキー（デフォルト）
デフォルトでは、保存されているデータはクラウドプロバイダーの暗号化方式とDatabricksが管理するキーを使用して暗号化されます。これにより、追加の設定なしで基本的な暗号化機能が提供されます。
顧客管理キー
顧客管理キーを必要とする組織にとって、すべてのクラウドサービスはそれをサポートしています。顧客管理キーは、一般的に次の2つの目的で使用されます。
目的1：制御プレーンおよびマネージドサービスの暗号化
Databricksコントロール プレーン、当然ストレージ、および保管中の顧客データ (常温検索、クエリ結果、コード、シークレットなど) を保存するサポートされているサーバレス サービス内の顧客データを、顧客の管理下にあるキーを使用して暗号化します。 顧客がキーを削除したり、キーへのアクセス権を削除したりすると、コントロールプレーン上のそのワークスペースに関連するすべてのデータにアクセスできなくなります。
目的 2: コンピュートとデータ プレーンの暗号化
特定のサービスの顧客コンピュートおよびデータ プレーン上の顧客データを暗号化します。 Databricksがルートバケットとクラスターに接続されたストレージボリュームを暗号化するために使用する、顧客管理のストレージ暗号化用キーを定義します。
暗号化パターン
高度に規制された環境
コントロール プレーンとコンピュート/データ プレーン暗号化の両方にカスタマー管理のキーを使用して、暗号化キーの完全な制御を維持し、コンプライアンスの要件を満たします。
標準的なエンタープライズ展開
ほとんどのワークロードにはDatabricksで管理されるキーを使用し、機密データを含む本番運用ワークスペース用に顧客管理のキーを予約します。
マルチテナント展開
暗号化の分離性を確保するために、異なる事業部門や環境ごとに、顧客が管理する個別の鍵を使用することを検討してください。
ストレージネットワークのセキュリティ設計
クラウドストレージへのネットワークアクセスを制限することは、追加のセキュリティ層として有効です。認証情報が漏洩した場合でも、ネットワークアクセス制御によってその使用が防止されます。
ネットワークセキュリティパターン
- VPC Service Controlsを使用して、ストレージ リソースの周囲にセキュリティ境界を作成します。
ストレージネットワークセキュリティのベストプラクティス
-
ストレージへのアクセスを特定の仮想ネットワークまたはサブネットに制限します。
-
プライベート接続にはプライベートサービスコネクトを使用してください。
-
アクセス試行を監査するために、ストレージサービスのログ記録を有効にしてください。
-
広範なストレージアクセス権限を付与する前に、ネットワークルールを設定してください。
ハブアンドスポーク型収納デザイン
ハブアンドスポーク型のストレージ設計パターンは、エンタープライズ向けUnity Catalog導入において一般的なアーキテクチャです。 このパターンでは、共有データ資産をハブストレージに一元化しつつ、ドメイン固有のデータをスポークストレージに格納することが可能になります。
ハブアンドスポーク型のストレージ特性
- ハブストレージ ：組織全体で共有されるデータ資産（顧客マスターデータ、参照データ、中央で管理されるデータセットなど）を格納します。
- スポーク ストレージ : ビジネス ユニット (販売アナリティクス、マーケティング キャンペーンなど) が所有および管理するドメイン固有のデータが含まれます。
- ストレージの分離 ：ハブカタログとドメインカタログは、それぞれ専用のストレージと個別のストレージ認証情報を使用します。
- マネージドテーブルの設定 : レイクハウス内の構造化データにはマネージドテーブルを使用します。
- 生データ用ボリューム ：ボリュームを使用して、着陸データ、生データ、または非構造化データにアクセスします（これらのデータは、通常、第三者がこれらのストレージ場所に直接アクセスする必要があるため、レイクハウスの外に保管できます）。
- 共有用の外部テーブル : 外部テーブルを使用して、レイクハウスの外部でデータを共有します ( Delta Sharing使用できない他のシステム、または保管場所に直接アクセスする必要がある他のシステムと)。
ハブアンドスポーク型ストレージ設計のベストプラクティス
- 複数のドメインが利用する組織全体の共有データには、ハブストレージを使用してください。
- 事業部門が所有するドメイン固有のデータには、スポークストレージを使用してください。
- ハブと各スポークのストレージ資格情報と外部ロケーションを分離します。
- Databricksが管理するDelta Sharingを使用して、ハブからスポークへデータを共有します。
- ハブアンドスポーク型ストレージにおけるデータ所有権とリネージを文書化する。
- 注：メタストアストレージは現在オプションであり、使用しないことを推奨します。
ストレージアーキテクチャに関する推奨事項
推奨
- Unity Catalogマネージドテーブルを使用し、バケットへのストレージレベルのアクセスを提供しません。
- メタストアレベルのデフォルト値に頼るのではなく、カタログレベルまたはスキーマレベルでストレージの場所を明示的に定義してください。
- 異なるストレージ コンテナを使用して、環境 (開発、ステージング、本番運用など) ごとにストレージを分離します。
- Unityカタログで保護されたPOSIX（Portable Operating System Interface）形式のファイルパスにはボリュームを使用してください。
- クラウドストレージやインスタンスプロファイルのマウントなど、従来のデータアクセスパターンは可能な限り避けてください。
- 保存データの制御を強化するために、顧客が管理する暗号化キー（マネージドサービスとストレージの両方）が必要かどうかを評価します。
- Databricksが管理するDelta Sharingを使用して、クラウド間およびリージョン間でテーブルを共有します。
避ける
- ルートバケット（DBFS）を顧客データの保存に使用しないでください。
- 本番運用データをDBFS ( Databricks File System) に保存しないでください。
- リージョン（メタストア）をまたいで外部テーブルを登録しないでください。
- ストレージレベルのアクセス権（例えば、S3バケットへのアクセス権、ADLSコンテナへのアクセス権）をユーザーに直接提供しないでください。
- 本番運用データは、メタストア レベルのストレージの場所に依存しないでください。
第5相の結果
フェーズ5を完了すると、以下のものが得られます。
- ワークスペース向けに設計されたストレージアーキテクチャ（顧客管理型とDatabricks管理型）。
- Unity Catalogストレージアーキテクチャを設計しました（管理対象オブジェクト、外部オブジェクト、外部オブジェクト）。
- ストレージ分離戦略が定義されています（環境、事業部門、またはデータドメイン別）。
- 認証戦略を設計します（例：IAMロール、アクセスコネクタ、サービスアカウント）。
- 暗号化戦略が選択されました（Databricks管理キー vs 顧客管理キー）。
- ストレージネットワークのセキュリティパターンが定義されています（例：バケットポリシー、ストレージファイアウォール、VPCエンドポイント）。
- 複数リージョンでのストレージに関する考慮事項を文書化しました（該当する場合）。
- ハブアンドスポーク型のストレージ設計を評価（エンタープライズ展開向け）。
- DBFS移行戦略が計画されています（DBFSデータを使用している既存のデプロイメント向け）。
次の段階 ：フェーズ6： Delta Lake建築設計
実装ガイド ：ストレージ設計を実装するための手順については、 「Unity Catalog を使用してクラウドオブジェクトストレージに接続する」を参照してください。