Databricks での機能的なワークスペース編成

はじめに

このブログは、Databricks 環境の管理と保守を担当する方々にとって重要なトピックに焦点を当てた、管理者向け基本情報シリーズのパート 1 です。データガバナンス、運用と自動化、ユーザー管理とアクセス可能性、コスト追跡と管理に関する追加ブログも近日公開予定ですので、ご期待ください！

2020 年、Databricks は、総称して Enterprise 2.0 (または E2) と呼ばれるいくつかのプラットフォーム機能のプライベートプレビューのリリースを開始しました。これらの機能は、Lakehouse プラットフォームの次のイテレーションを提供し、Databricks で既に利用可能なパワーとスピードに匹敵するスケーラビリティとセキュリティを創出しました。Enterprise 2.0 が一般公開されたとき、最も期待されていた追加機能の 1 つは、単一のアカウントから複数のワークスペースを作成できる機能でした。この機能は、コラボレーション、組織の連携、および簡素化のための新しい可能性を開きました。しかし、私たちが経験してきたように、それは多くの疑問も提起しました。あらゆる規模、形状、業種のエンタープライズ顧客にわたる私たちの経験に基づき、このブログでは Databricks 内のワークスペース管理に関する最も一般的な質問への回答とベストプラクティスを提示します。根本的なレベルでは、これは単純な質問に集約されます。新しいワークスペースはいつ作成すべきか？具体的には、ワークスペースを整理するための主要な戦略と、それぞれのベストプラクティスを強調します。

ワークスペース編成の基本

各クラウドプロバイダー (AWS、Azure、GCP) は異なる基盤アーキテクチャを持っていますが、クラウド全体での Databricks ワークスペースの編成は似ています。論理的な最上位の構造は、E2 マスターアカウント (AWS) またはサブスクリプションオブジェクト (Azure Databricks/GCP) です。AWS では、すべてのワークスペースに対する統一された可視性と制御のペインを提供する、組織ごとに 1 つの E2 アカウントをプロビジョニングします。このように、管理アクティビティは集中化され、SSO、監査ログ、および Unity Catalog を有効にする機能があります。Azure は、最上位のサブスクリプションオブジェクトの作成に関して比較的制限が少ないですが、Databricks ワークスペースの作成に使用される最上位サブスクリプションの数を可能な限り制御することを引き続き推奨します。このブログ全体を通して、AWS E2 アカウントまたは GCP/Azure サブスクリプションのいずれであっても、最上位の構造をアカウントと呼びます。

最上位アカウント内で、複数のワークスペースを作成できます。Azure では、アカウントあたりの推奨最大ワークスペース数は 20 から 50 ですが、AWS にはハードリミットがあります。この制限は、ワークスペース数の増加に起因する管理オーバーヘッドから生じます。数百のワークスペースにわたるコラボレーション、アクセス、およびセキュリティの管理は、優れた自動化プロセスがあっても、非常に困難な作業になる可能性があります。以下に、Databricks アカウントの高レベルなオブジェクトモデルを示します。

エンタープライズは、マルチテナンシー要件をサポートするためにクラウドアカウント内にリソースを作成する必要があります。新しいユースケースごとに個別のクラウドアカウントとワークスペースを作成することには、コスト追跡の容易さ、データとユーザーの分離、およびセキュリティインシデント発生時の影響範囲の縮小といった明確な利点があります。しかし、アカウントの急増は、それ自体に複雑さをもたらします。ガバナンス、メタデータ管理、およびコラボレーションのオーバーヘッドは、アカウント数とともに増加します。もちろん、鍵はバランスです。以下では、まずエンタープライズワークスペース編成に関する一般的な考慮事項をいくつか説明します。次に、顧客の間で見られる 2 つの一般的なワークスペース分離戦略、すなわち LOB ベースと製品ベースについて説明します。それぞれに長所、短所、および複雑さがあり、それらを説明してからベストプラクティスを提供します。

一般的なワークスペース編成の考慮事項

ワークスペース戦略を設計する際、顧客が最初に飛びつくのはマクロレベルの編成上の選択ですが、それと同様に重要な低レベルの決定も数多くあります。最も関連性の高いものを以下にまとめました。

シンプルな 3 ワークスペースアプローチ

このブログの大部分でワークスペースを最大限の効果を発揮するために分割する方法について説明しますが、単一の統合ワークスペースが環境ごとに十分である Databricks 顧客のクラス全体が存在します！実際、Repos、Unity Catalog、ペルソナベースのランディングページなどの機能の台頭により、これはますます実用的になっています。そのような場合でも、検証と QA の目的で、開発、ステージング、および本番ワークスペースの分離を推奨します。これにより、アジリティを複雑さよりも重視する中小企業やチームに最適な環境が作成されます。

単一のワークスペースセットを作成することの長所と短所は次のとおりです。

単一のワークスペースセットが適切なアプローチであると思われる場合は、次のベストプラクティスが Lakehouse を円滑に運用するのに役立ちます。

• さまざまな環境間でコードをプッシュするための標準化されたプロセスを定義します。環境は 1 セットしかないため、他のアプローチよりも簡単になる可能性があります。Repos や Secrets などの機能や、優れた CI/CD プロセスを促進する外部ツールを活用して、移行が自動的かつスムーズに発生するようにします。
• ID プロバイダーグループを Databricks アセットにマッピングして確立し、定期的にレビューします。これらのグループは、この戦略におけるユーザー認証の主なドライバーであるため、正確であり、適切な基盤となるデータおよびコンピューティングリソースにマッピングされていることが重要です。たとえば、ほとんどのユーザーは本番ワークスペースにアクセスする必要はないでしょう。少数のエンジニアまたは管理者にのみ権限がある場合があります。
• Databricks のリソース制限に注意し、ワークスペースの使用量やユーザー数が変動し始めたら、ワークスペースごとの制限を回避するために、より詳細なワークスペース構成戦略を採用することを検討する必要があるかもしれません。コストと使用量のメトリクスを追跡するために、可能な限りリソースのタグ付けを活用してください。

サンドボックスワークスペースの活用

この記事全体で言及されている戦略のいずれにおいても、サンドボックス環境は、ユーザーが形式的ではないものの、依然として価値のある可能性のある作業をインキュベートおよび開発できるようにするための良いプラクティスです。極めて重要なのは、これらのサンドボックス環境が、実際のデータを探索する自由と、運用ワークロードに意図せず（または意図的に）影響を与えることから保護することのバランスを取る必要があるということです。このようなワークスペースの一般的なベストプラクティスは、完全に別のクラウドアカウントでホストすることです。これにより、ワークスペース内のユーザーの影響範囲が大幅に制限されます。同時に、簡単なガードレール（クラスターポリシー、データアクセスを「プレイ」またはクリーンアップされたデータセットに制限する、可能な場合はアウトバウンド接続を閉じるなど）を設定することは、ユーザーが管理者の継続的な監視を必要とせずに（ほぼ）何でも自由にできることを意味します。最後に、社内コミュニケーションも同様に重要です。ユーザーがサンドボックスで素晴らしいアプリケーションを構築し、数千人のユーザーを引き付けたり、この環境での作業に対して運用レベルのサポートを期待したりした場合、管理コストはすぐに消えてしまいます。

サンドボックスワークスペースのベストプラクティスには以下が含まれます。

• 機密データや運用データを含まない別のクラウドアカウントを使用してください。
• ユーザーが管理者の監視なしに環境を自由に使えるように、簡単なガードレールを設定してください。
• サンドボックス環境は「セルフサービス」であることを明確に伝えてください。

データ分離と機密性

機密データは、すべての業種のお客様の間で重要性が増しています。かつては医療提供者やクレジットカード処理業者に限定されていたデータが、現在では患者分析や顧客センチメントの理解、新興市場の分析、新製品のポジショニング、その他考えられるほぼすべてのもののソースとなっています。この豊富なデータには高い潜在的リスクが伴い、データ侵害の脅威は増大しています。このため、どの組織戦略を選択しても、機密データを分離して保護することが重要です。Databricks は、機密データを保護するためのいくつかの手段（ACL やセキュアな共有など）を提供しており、クラウドプロバイダーのツールと組み合わせることで、構築した Lakehouse を可能な限り低リスクにすることができます。データ分離と機密性に関するベストプラクティスの一部を以下に示します。

• 独自のデータセキュリティニーズを理解してください。これが最も重要な点です。すべてのビジネスには異なるデータがあり、データがガバナンスを推進します。
• ストレージレベルとメタストアレベルの両方でポリシーと制御を適用します。S3 ポリシーと ADLS ACL は、常に最小権限の原則を使用して適用する必要があります。Unity Catalog を活用して、データアクセスに追加の制御レイヤーを適用します。
• 機密データと非機密データを論理的および物理的に分離してください。多くの顧客は、機密データと非機密データのために完全に別のクラウドアカウント（および Databricks ワークスペース）を使用しています。

DR とリージョンバックアップ

AWS、Azure、またはGCPのいずれを使用する場合でも、災害復旧（DR）は重要な広範なトピックです。このブログではすべてを網羅しませんが、代わりに DR とリージョンに関する考慮事項がワークスペース設計にどのように影響するかを中心に説明します。この文脈では、DR は標準の運用ワークスペースとは別のリージョンにワークスペースを作成および維持することを意味します。

DR 戦略は、ビジネスのニーズによって大きく異なります。たとえば、一部の顧客はアクティブ/アクティブ構成を維持することを好みます。この場合、一方のワークスペースのすべての資産が常にセカンダリワークスペースに複製されます。これにより、冗長性が最大になりますが、複雑さとコストも伴います（クロスリージョンでのデータの継続的な転送、オブジェクトの複製と重複排除は複雑なプロセスです）。一方、一部の顧客は、事業継続性を確保するために必要な最小限のことのみを行うことを好みます。セカンダリワークスペースには、フェイルオーバーが発生するまでほとんど含まれないか、または時折バックアップされるだけかもしれません。適切なレベルのフェイルオーバーを決定することが重要です。

実装する DR のレベルに関係なく、以下をお勧めします。

• コードは、オンプレミスまたはクラウドのいずれかの Git リポジトリに保存し、可能な限りReposなどの機能を使用して Databricks に同期してください。
• 可能な限り、Delta Lake とDeep Cloneを組み合わせてデータレプリケーションを行ってください。これにより、データを効率的にバックアップするための簡単でオープンソースの方法が提供されます。
• クラウドプロバイダーが提供するクラウドネイティブツールを使用して、Delta Lake に格納されていないデータ、外部データベース、構成などのバックアップを実行してください。
• Terraformなどのツールを使用して、ノートブック、ジョブ、シークレット、クラスター、その他のワークスペースオブジェクトをバックアップしてください。

覚えておいてください。Databricks はコントロールプレーンのリージョンワークスペースインフラストラクチャの維持を担当しますが、ワークスペース固有の資産と、運用ジョブが依存するクラウドインフラストラクチャの責任は、お客様にあります。

事業部門（LOB）による分離

次に、エンタープライズコンテキストでのワークスペースの実際の構成について説明します。LOB ベースのプロジェクト分離は、IT リソースを従来のエンタープライズ中心の視点から発展させたものであり、LOB 中心の連携の多くの従来の強み（および弱み）も引き継いでいます。そのため、多くの大企業では、このワークスペース管理アプローチは自然に受け入れられるでしょう。

LOB ベースのワークスペース戦略では、ビジネスの各機能ユニットがワークスペースセットを受け取ります。従来は開発、ステージング、運用のワークスペースが含まれますが、最大 10 の中間ステージがあり、それぞれに独自のワークスペースがある顧客もいます（推奨されません）。コードは DEV で記述およびテストされ、次に STG にプロモートされ（CI/CD 自動化経由）、最後に PRD に配置され、そこでスケジュールジョブとして実行され、廃止されるまで続きます。このモデルで新しいワークスペースを開始する主な理由は、環境タイプと独立した LOB です。すべてのユースケースまたはデータ製品に対してこれを行うのは過剰かもしれません。

上記の図は、LOB ベースのワークスペースの構成方法の 1 つの可能性を示しています。この場合、各 LOB は 1 つのワークスペース（開発/ステージング/運用）を各環境に持ち、専用の管理者を擁する個別のクラウドアカウントを持っています。重要なのは、これらのワークスペースはすべて同じ Databricks アカウントの下にあり、同じ Unity Catalog を活用していることです。バリエーションとしては、クラウドアカウント（および VPC やクラウドサービスなどの基盤となるリソース）の共有、個別の開発/ステージング/運用クラウドアカウントの作成、または LOB ごとに個別の外部メタストアの作成などが考えられます。これらはすべて、ビジネスニーズに大きく依存する妥当なアプローチです。

全体として、LOB アプローチには多くの利点といくつかの欠点があります。

ベストプラクティスとして、LOBベースのLakehouseを構築する際には、以下のことをお勧めします。

• ユーザーと環境に対してきめ細かなアクセス制御を使用した、最小権限のアクセスモデルを採用してください。一般的に、本番環境へのアクセスを持つユーザーはごく少数にとどめ、この環境とのやり取りは自動化され、厳密に管理されるべきです。これらのユーザーとグループをIDプロバイダーでキャプチャし、Lakehouseに同期してください。
• Lakehouse全体のクラウドプロバイダーとDatabricksプラットフォームの制限を理解し、計画してください。これには、例えば、ワークスペースの数、ADLSでのAPIレート制限、Kinesisストリームでのスロットリングなどが含まれます。
• 可能な限り、強力なアクセス制御を備えた標準化されたメタストア/カタログを使用してください。これにより、分離を損なうことなくアセットを再利用できます。Unity Catalogを使用すると、テーブルやワークスペースアセット（MLflow実験などのオブジェクトを含む）に対してきめ細かな制御が可能になります。
• 可能な限りデータ共有を活用し、労力を重複させることなくLOB間でデータを安全に共有してください。

データプロダクトの分離

LOBが部門横断的に連携する必要がある場合や、単純な開発/ステージング/本番モデルがLOBのユースケースに合わない場合はどうすればよいでしょうか？厳格なLOBベースのLakehouse構造の形式性を一部緩和し、よりモダンなアプローチを採用することができます。これをデータプロダクトによるワークスペース分離と呼びます。その考え方は、厳密にLOBで分離するのではなく、トップレベルのプロジェクトで分離し、それぞれに本番環境を与えるというものです。また、ワークスペースの乱立を避け、アセットの再利用を容易にするために、共有開発環境も組み合わせています。

一見すると、これは上記のLOBベースの分離と似ていますが、いくつかの重要な違いがあります。

• 共有開発ワークスペースがあり、各トップレベルプロジェクト（つまり、LOBごとにワークスペースの総数が異なる場合があります）ごとに個別のワークスペースがあります。
• サンドボックスワークスペースの存在。これはLOB固有であり、従来の開発ワークスペースよりも自由度が高く、自動化が少ない環境です。
• リソースやワークスペースの共有。これもLOBベースのアーキテクチャで可能ですが、より厳格な分離によって複雑になることがよくあります。

このアプローチは、LOBベースの分離と同じような長所と短所を多く共有していますが、より柔軟性を提供し、モダンなLakehouseにおけるプロジェクトの価値を強調しています。テクノロジーが単なるコストドライバーから価値創出へと移行するにつれて、これはますます「ゴールドスタンダード」のワークスペース組織化になりつつあります。常に、ビジネスニーズにより、特に大規模なプロジェクト、LOBをまたいだプロジェクト、クラウドリソースの分離度合いの増減など、このサンプルアーキテクチャからわずかに逸脱する場合があります。正確な構造に関わらず、以下のベストプラクティスをお勧めします。

• 可能な限り、データとリソースを共有してください。インフラストラクチャとワークスペースの分離は、ガバナンスと追跡に役立ちますが、リソースの乱立はすぐに負担となります。事前に慎重に分析することで、再利用できる領域を特定するのに役立ちます。
• プロジェクト間で広範に共有しない場合でも、可能な限り、Unity Catalogのような共有メタストアや、共有コードベース（例：Repos経由）を使用してください。
• Terraform（または同様のツール）を使用して、ワークスペースとクラウドインフラストラクチャの作成、管理、削除プロセスを自動化してください。
• サンドボックス環境を通じてユーザーに柔軟性を提供してください。ただし、クラスターサイズやデータアクセスなどを制限するための適切なガードレールが設定されていることを確認してください。

概要

Lakehouseのすべてのメリットを最大限に活用し、将来の成長と管理性をサポートするためには、ワークスペースレイアウトを慎重に計画する必要があります。この設計中に考慮する必要があるその他の関連アーティファクトには、コラボレーションを促進しつつセキュリティを損なわないための、集中化されたモデルレジストリ、コードベース、カタログが含まれます。この記事全体で強調されたベストプラクティスを要約すると、主なポイントは以下のとおりです。

ベストプラクティス #1：可能な限り、トップレベルアカウント（クラウドプロバイダーとDatabricksレベルの両方）の数を最小限に抑え、コンプライアンス、分離、または地理的な制約のために分離が必要な場合にのみワークスペースを作成してください。迷ったら、シンプルに保ちましょう！

ベストプラクティス #2：過度の複雑さを伴わずに長期的な柔軟性を提供する分離戦略を決定してください。ニーズを現実的に評価し、ワークロードをLakehouseにオンボードする前に厳格なガイドラインを実装してください。つまり、二度測って一度切れ、ということです！

ベストプラクティス #3：クラウドプロセスを自動化してください。これには、インフラストラクチャのすべての側面（多くは今後のブログで取り上げます！）が含まれます。SSO/SCIM、Terraformのようなツールを使用したInfrastructure-as-Code、CI/CDパイプラインとRepos、クラウドバックアップ、および監視（クラウドネイティブおよびサードパーティツールの両方を使用）が含まれます。

ベストプラクティス #4：エンタープライズ全体の戦略のセントラルガバナンスのためにCOEチームを設立することを検討してください。ここでは、データと機械学習パイプラインの繰り返し可能な側面がテンプレート化および自動化され、さまざまなデータチームが十分なガードレールを備えたセルフサービス機能を使用できるようにします。COEチームは、多くの場合、データチームにとって軽量でありながら重要なハブであり、ドキュメント、SOP、ハウツー、FAQを維持して他のユーザーを教育するエンブレイサーとして自身を位置づけるべきです。

ベストプラクティス #5：LakehouseはData Lakeにはないレベルのガバナンスを提供します。それを活用してください！Lakehouseの確立の最初のステップの1つとして、コンプライアンスとガバナンスのニーズを評価し、Databricksが提供する機能を利用してリスクを最小限に抑えるようにしてください。これには、監査ログ配信、HIPAAおよびPCI（該当する場合）、適切な流出制御、ACLおよびユーザー制御の使用、および上記すべての定期的なレビューが含まれます。

今後、データガバナンスからユーザー管理までのトピックに関する、さらに多くの管理者向けベストプラクティスブログを提供する予定です。それまでの間、ワークスペース管理に関する質問がある場合や、Databricks Lakehouse Platformでのベストプラクティスについてさらに詳しく知りたい場合は、Databricksアカウントチームにお問い合わせください！

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事