Functional Workspace Organization on Databricks - The Databricks Blogの翻訳です。
本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。
Databricks管理者基礎コース(1/5)
イントロダクション
このブログは、Databricks環境を管理維持する方にとって重要なトピックにフォーカスする管理者基礎シリーズのパート1です。データガバナンス、opsおよび自動化、管理およびアクセシビリティ、コスト追跡及び管理に関してカバーする今後の記事を楽しみにしていてください！
2020年、DatabricksはEnterprise 2.0(E2)として知られる幾つかのプラットフォームのプライベートプレビューをリリースし始めました。これらの機能は、すでにDatabricksで利用できていたパワーとスピードにマッチするスケーラビリティとセキュリティを提供し、レイクハウスプラットフォームの次のイテレーションを推進しました。Enterprise 2.0が公開された時、最も期待された追加機能は単一のアカウントで複数のワークスペースを作成できる機能でした。この機能によって、コラボレーション、組織間連携、簡素化に対する新たな可能性の扉を開きました。しかし、これに伴って多くの疑問が生じました。さまざまな規模、形態、業態における企業のお客様との体験に基づき、この記事ではDatabricksにおけるワークスペース管理に関する最も一般的な質問に対する回答とベストプラクティスを説明します。基本的なレベルにおいて、これは いつ新規ワークスペースを作成すべきか？ というシンプルな質問に集約されます。特に、ワークスペースを構成する際のキーとなる戦略と、それに対するベストプラクティスにハイライトします。
ワークスペース構成の基本
それぞれのクラウドプロバイダー(AWS、Azure、GCP)の内部アーキテクチャは異なりますが、クラウドに対するDatabricksワークスペースの構成は類似したものとなります。論理的構造のトップレベルは、E2のマスターアカウント(AWS)、あるいはサブスクリプションオブジェクト(Azure Databricks/GCP)となります。AWSにおいては、全てのワークスペースに対して統合された可視性とコントロールを提供する企業単位で単一のE2アカウントを提供します。このようにすることで、SSO、監査ログ、Unity Catalogを用いることで、皆様の管理者の活動が集中管理されるようになります。Azureにおいては、トップレベルのサブスクリプションの作成の制約は少ないですが、Databricksワークスペースの作成に使用するトップレベルのサブスクリプションの数を可能な限りコントロールすることをお勧めします。この記事ではトップレベル構造をアカウントと呼び、これはAWSのE2アカウントあるいはGCP/Azureサブスクリプションとなります。
トップレベルアカウント内には複数のワークスペースを作成することができます。アカウントに対する推奨最大ワークスペース数はAzureにおいては20から50、AWSにおいてはハードリミットとなります。この制限はワークスペース数の増加による管理的オーバーヘッドによるものです。数百のワークスペースに対するコラボレーション、アクセス、セキュリティの管理は、例外的な自動化プロセスを用いたとしても非常に困難なタスクとなります。以下では、Databricksアカウントのトップレベルのオブジェクトモデルを示しています。
企業はマルチテナンシーの要件をサポートするために、クラウドアカウントでリソースを作成する必要があります。新規ユースケースのそれぞれに対応するワークスペース、クラウドアカウントを作成することには、いくつかの明確な利点が存在します。コスト追跡の容易性、ユーザー分離、セキュリティ事故が起きた際の影響範囲の局所化があげられます。しかし、アカウントの急増は、異なる複雑性をもたらします。アカウントの増加に伴い、ガバナンス、メタデータ管理、コラボレーションのオーバーヘッドが急増します。もちろん、重要なのはバランスです。以下では、企業におけるワークスペース構成に対するいくつかの一般的な検討をウォークスルーしてみましょう。そして次に、我々が実際にお客様の中で使用されているのを見た、2つの一般的なワークスペース分離の戦略を見ていきます。LOBベースと製品ベースです。それぞれに強み弱みがあり、ベストプラクティスを説明する前に議論する複雑性があります。
一般的なワークスペース構成に対する検討
皆様のワークスペース戦略を設計する際、我々がよく見かけるのはお客様がマクロレベルの組織的な選択に飛びつくというものです。しかし、同様に重要な低レベルの意思決定が多く存在するのです！我々はこれら適切なものを以下にまとめました。
シンプルな3つのワークスペースのアプローチ
この記事では効率を最大化するためにどのようにワークスペースを分割するのかに多くの部分を費やしていますが、環境として単一かつ統合されたワークスペースがあるので十分なお客様が大多数です。実際のところ、Repos、Unity Catalog、ペルソナベースのランディングページなどの機能の立ち上がりによって、この選択肢はより実践的なものになっています。このような場合でも、我々は開発、QAの観点からステージング、プロダクションのワークスペースに分離することをお勧めしています。これによって、複雑性よりもアジリティに価値を見出す小規模のビジネスやチームにとって理想的な環境を作成することができます。
一連のセットのワークスペースを作成することによるメリットとデメリットを以下に示します。
メリット
- 複数のプロジェクト、チームで複数のアセットをごちゃ混ぜにしたり、コスト/使用量がわからなくなってしまうことで、ワークスペースの内部が散らかる心配がありません。全てが同じ環境に存在します。
- 構成のシンプルさは管理のオーバーヘッドの削減を意味します。
デメリット
- 規模の大きい組織においては、プラットフォームの制限、散らかり、データ分離ができないこと、ガバナンスの懸念によって、一つのdev/stg/prdワークスペースでは継続できないことが考えられます。
一連のセットのワークスペースが、皆様にとって適切なアプローチであるならば、レイクハウスをスムーズにオペレーションし続けるためには、以下のベストプラクティスが役立つことでしょう。
- 複数の環境間においてコードをプッシュするための標準化プロセスを定義します。この場合、一連の環境しかないので、これは他のアプローチよりもシンプルなものになるかもしれません。皆様の環境間移行を自動かつスムーズなものにするための優れたCI/CDプロセスを促進するReposやシークレット、外部ツールのような機能を活用します。
- Databricksアセットにマッピングされるアイデンティティプロバイダーのグループを確立し、定期的にレビューします。この戦略においては、グループがユーザー認証の主要なドライバーとなるため、これらが正確であり、適切に内部のデータと計算資源にマッピングされていることが重要です。例えば、大部分のユーザーはプロダクションワークスペースにアクセスする必要はないでしょう。一握りのエンジニアや管理者のみがアクセス権を持つべきです。
- Databricksのリソースリミットを理解し、使用量に目を配るべきです。お使いのワークスペースの使用量やユーザー数が増加し始めたら、ワークスペースごとの制限を回避するために、より多くのワークスペースを含む構成の戦略を取り入れることをカンゲル必要があるもしれません。コストと使用量のメトリクスを追跡するために、可能であればリソースタグを活用します。
サンドボックスワークスペースの活用
本書を通じて説明されれるいかなる戦略においても、ユーザーが気軽に開発、実験を行いつつも、潜在的に価値にある作業になるように、サンドボックス環境を準備することは優れたプラクティスです。特に、これらのサンドボックス環境では、リアルデータを探索する自由度と、誤ってプロダクションワークロードに影響を与えるような行為に対する防御のバランスを取る必要があります。このようなワークスペースに対する一般的なベストプラクティスは、完全に異なるクラウドアカウントでこれらをホスティングするということです。同時に、シンプルなガードレイル(「遊べる」データ、綺麗なデータセットにのみデータアクセスを制限するクラスターポリシーや、可能であれば外向け接続の遮断)をセットアップすることで、定期的な管理者の監視なしに、ユーザーはやりたいこと(ほぼ)全てを実行するための比較的高い自由度を手に入れることができます。最後に、内部のコミュニケーションも重要です。意図せずしてサンドボックスに数千人のユーザーを惹きつけるような素晴らしいアプリケーションを構築した場合、あるいはこの環境におけるプロダクションレベルのサポートを期待した場合、これらの管理に関する対策効果はすぐに消え去ってしまいます。
サンドボックスに対するベストプラクティスには以下が含まれます。
- センシティブな情報、プロダクションデータを含まない別のクラウドアカウントを使用します。
- 管理屋の監視を必要とすることなしに、ユーザーが環境に対して比較的大きい自由度を手に入れられるようにシンプルなガードレイルをセットアップします。
- サンドボックス環境が「セルフサービス」であることを明確にしてコミュニケーションします。
データの分離と機密性
我々のお客様内では、全ての業種においてセンシティブなデータが急激に増加しています。かつてはヘルスケアプロバイダーやクレジットカード処理者に限られていたデーは、今や患者分析、顧客感情分析、成長市場の分析、新製品のポジショニング、その他思いつくものを理解するためのソースとなっています。この豊富なデータは、増加し続けるデータ漏洩の脅威を伴う潜在的なリスクと一緒にもたらされます。このため、センシティブなデータを分離し保護し続けることは、どのような組織的な戦略を選択したとしても重要なものとなります。Databricksでは、センシティブなデータを保護するためのいくつかの手段(ACLやセキュアなデータ共有など)を提供しており、クラウドプロバイダーツールと組み合わせることで、可能な限り低いリスクでレイクハウスを構築することができます。データ分離と機密性に関わるベストプラクティスには以下が含まれます。
- 皆様固有のデータセキュリティ要件を理解します。これが最も重要なポイントです。それぞれのビジネスには異なるデータが存在し、皆様のデータが皆様のガバナンスを決定します。
- ストレージレベルとメタストアの両方にポリシーとコントロールを適用します。S3ポリシーとADLSのACLは常に最低限アクセスの原則を用いて適用されるべきです。データアクセスに追加の制御レイヤーを適用するためにUnity Catalogを活用します。
- 論理的かつ物理的に非センシティブなデータからセンシティブなデータを分離します。多くのお客様では、センシティブなデータと非センシティブなデータに対して、完全に分離したクラウドアカウント(とDatabricksワークスペース)を使用しています。
DRとリージョン間バックアップ
ディザスターリカバリー(DR)は、AWS、Azure、GCPのいずれを使用していても重要かつ広範なトピックとなります。この記事では全てをカバーしませんが、どのようにDRとリージョンに関する検討がワークスペースの設計に影響するのかにフォーカスします。この文脈でDRは、標準的なプロダクションワークスペースとは異なり、別のリージョンにワークスペースを作成し、維持することを意味します。
DRの戦略はビジネスの要件によって大きく異なります。例えば、何人かのお客様は、一つのワークスペースから補助ワークスペースに全てのアセットが定期的に複製される、アクティブ・アクティブ構成を好みます。これは最大の冗長性を提供しますが、複雑性とコストを引き起こします(クロスリージョンでデータを定期的に転送し、オブジェクトの複製と重複排除する処理は複雑なプロセスです)。一方、何人かのお客様はビジネス継続性を保証するのに必要な最低限のことを行うことを好みます。障害が起きるまでは、補助ワークスペースには最低限のものが含まれるかもしれませんし、より長い周期でのみバックアップされるかもしれません。障害に対する適切なレベルを決定することが重要です。
実装するDRのレベルを問わず、以下をお勧めします。
- クラウド、オンプレミスを問わずお使いのGitリポジトリにコード格納し、可能であればDatabricksと同期するためにReposのような機能を使用します。
- 可能であれば、データを複製するためにDelta Lakeのディープクローンを使用します。これによって、データを効率的にバックアップする容易かつオープンソースの手段を提供します。
- Delta Lakeに格納されていないデータ、外部のデータベース、設定をバックアップするにはクラウドプロバイダーが提供する、クラウドネイティブのツールを使用します。
- ノートブック、シークレット、クラスター、他のワークスペースオブジェクトをバックアップするにはTerraformのようなツールを使用します。
Databricksはリージョンにあるコントロールプレーンのワークスペースのインフラストラクチャには責任を持ちますが、ご自身のワークスペース固有のアセット、皆様のプロダクションジョブが依存するクラウドインフラストラクチャについては皆様が責任を持つことを覚えておいてください。
ラインオブビジネス(LOB)による分離
それでは、企業の文脈でワークスペースの実際の構成にディープダイブしましょう。LOBベースのプロジェクト分離は、従来型の企業指向のITリソースの視点から生まれており、LOB指向のアラインメントによって従来からある多くの強み(と弱み)をもたらします。多くの大規模なビジネスにおいては、ワークスペース管理に対するこのアプローチは自然に生まれてきます。
LOBベースのワークスペース戦略においては、ビジネスのそれぞれの機能ユニットは、一連のセットのワークスペースを利用します。伝統的に、これには開発、ステージング、プロダクションのワークスペースが含まれます。我々は最大10の中間ステージを見たことがあり、これにはそれぞれのワークスペースを割り当てる可能性があります(お勧めしません)！DEVデコードは記述、テストされ、STGに(CI/CD自動化を通じて)昇格され、最後に非推奨になるまでスケジュールジョブとして実行されるPRDに到達します。環境のタイプと独立したLOBが、このモデルにおいて新規ワークスペースを作成する主要な利用となります。全てのユースケースとデータ製品に対してこれを行うことはやりすぎと言えます。
上の図では、LOBベースのワークスペースを構成する方法の一つを説明しています。この場合、それぞれのLOBは異なるクラウドアカウントと、それぞれの環境(dev/stg/prd)ごとのワークスペースを有しており、専任の管理者が存在しています。重要なことですが、これら全てのワークスペースは同じDatabricksアカウントに属しており、同じUnity Catalogを活用しています。いくつかのバリエーションには、クラウドアカウントの共有(場合によっては、背後のVPCやクラウドサービスも共有)やdev/stg/prdに対して異なるクラウドアカウントの使用、LOBごとに異なる外部メタストアを使用するなどが含まれます。これらは全て、ビジネス要件に大きく依存する合理性のあるアプローチとなります。
全体としてLOBのアプローチには、多くのメリットといくつかの欠点が存在します。
メリット
- クラウドの観点、ワークスペースの観点でLOBごとのアセットを分離できます。これにより、シンプルなレポーティング、コスト分析を可能とし、ワークスペースが散らかるのを防ぐことができます。
- 明確なユーザーとジョブの分割は、全体的なレイクハウスのガバナンスを改善し、全体的なリスクを低減します。
- 環境間の昇格の自動化は、効率的かつオーバーヘッドの少ないプロセスを生み出します。
デメリット
- LOB横断のプロセスが標準化され、Databricksアカウント全体がプラットフォームの制限を超えないようにするために事前のプランニングが必要となります。
- 自動化と管理プロセスには環境設定、維持管理するためのスペシャリストが必要となります。
ベストプラクティスとしては、LOBベースのレイクハウスを構築する方には以下をお勧めします。
- ユーザーと環境に対するきめ細かいアクセスコントロルールを用いて、最小権限のアクセスモデルを適用します。通常、最小限のユーザーがプロダクションにアクセスできるべきであり、この環境とのやりとりは自動化され、高度にコントロールされるべきです。これらのユーザー・グループをお使いのアイデンティティプロバイダーで管理し、レイクハウスに同期します。
- クラウドプロバイダーとDatabricksの両方の制限を理解し計画します。これには、例えば、ワークスペースの数、ADLSに対するAPIレートの制限、Kinesisストリームのスロットリングなどが含まれます。
- 可能であれば、強力なアクセスコントロールを有する標準化されたメタストア・カタログを活用します。これによって、分離を妥協することなくアセットの再利用を実現できます。Unity Catalogを用いることで、テーブル、MLflowのエクスペリメントのようなワークスペースのアセットに対するきめ細かいコントロールを実現できます。
- データを複製する労力なしにLOB間でのデータ共有をセキュアに行うために、可能であればDelta Sharingを活用します。
データ製品による分離
LOBが機能横断でコラボレーションする必要がある場合、あるいは、シンプルなdev/stg/prdモデルがご自身のLOBのユースケースに則さない場合、どうすればいいのでしょうか？我々は、厳密なLOBベースのレイクハウスの構造の形式の幾つかを持ち込み、よりモダンなアプローチを取り込むことができます。我々はこのワークスペース分離をデータ製品による分離と呼びます。コンセプトは、LOBで厳密に分離するのではなく、トップレベルのプロジェクトで分離し、それぞれにプロダクション環境を提供します。また、ワークスペースの増加を防ぎ、アセットの共有をよりシンプルなものにするために共有開発環境と組み合わせます。
パッと見ると、これはLOBベースの分離と同じように見えますが、いくつか重要な差異があります。
- トップレベルのプロジェクトごとのワークスペースと共有開発ワークスペース(これは全体として、LOBごとにワークスペースの数が異なる場合があることを意味します)。
- LOB固有のサンドボックスの存在、従来の開発ワークスペースよりも多い自由度、少ない自動化。
- リソース(あるいは/と)ワークスペースの共有。これはLOBベースのアーキテクチャでも可能ですが、より厳密な分離ポリシーによって複雑なものとなってしまいます。
このアプローチは、LOBベースの分離と同じ強み、弱みを共有していますが、優れた柔軟性をて教師、モダンなレイクハウスにおけるプロジェクトの価値を強調します。技術においては、駆動力がコストから価値の生成に軸足が変わっていくにつれて、これがワークスペース構成の「黄金律」となっているのを我々は目撃しています。いつものように、特に大きなプロジェクトに対しては専用のdev/stg/prdを必要とする、LOBプロジェクト横断、クラウドリソースの分離の大小など、ビジネス要件はこのシンプルなアーキテクチャからわずかな修正を必要とするかもしれません。明確な構成に関係なく、以下のベストプラクティスをお勧めします。
- 可能な限りデータとリソースを共有します。インフラストラクチャとワークスペースの分離はガバナンスと追跡には有用ですが、リソースの増加はすぐに重荷になります。事前の注意深い分析は、再利用する料理機の特定に役立ちます。
- プロジェクト間で積極的に共有しない場合でも、Unity Catalogのような共有メタストアと、可能であれば共有コードベース(例えばRepos経由で)を使用します。
- ワークスペースとクラウドインフラストラクチャの作成、管理、削除のプロセスを自動化するために、Terraform(あるいは類似のツール)を使用します。
- サンドボックス環境を通じてユーザーに柔軟性を提供します。しかし、クラスターサイズやデータアクセスに制限をかけるための適切なガードレイルを確実にセットアップします。
まとめ
レイクハウスの全てのメリットを完全に活用し、将来的な成長と管理性をサポートするためには、ワークスペースのレイアウトを注意深く計画する必要があります。この設計を通じて検討されるべき関連アーティファクトには、集中管理されたモデルレジストリ、コードベース、セキュリティを侵害することなしにコラボレーションするためのカタログが含まれます。本書を通じてハイライトされたベストプラクティスをまとめると、キーとなる内容は以下の通りとなります。
ベストプラクティス#1: トップレベルアカウントの数を可能な限り最小化し、コンプライアンス、分離、地理的制約によって分離が必要な時だけワークスペースを作成します。悩んだら、シンプルにしましょう！
ベストプラクティス#2: 必要以上の複雑性を持ち込むことなしに、長期的な柔軟性を適用する分離戦略を決定します。皆様の要件に対して現実的になり、皆様のレイクハウスにワークロードを乗せ始める前に厳密なガイドラインを実装しましょう。言い換えると、2回計測して、1回でカットしましょう！
ベストプラクティス#3: 皆様のクラウドプロセスを自動化しましょう。これは、SSO/SCIM、Terraform、CI/CDパイプライン、Repos、クラウドバックアップ、モニタリングによるインフラストラクチャアズアコード(クラウドネイティブのツール、サードパーティのツールが含まれます)が含まれる皆様のインフラストラクチャの全ての側面に対するものとなります。
ベストプラクティス#4: 企業規模の戦略に対する中央管理されたガバナンスに対するCOEチームを構築すること検討します。ここでは、繰り返し可能なデータと機械学習パイプラインのテンプレート化、自動化が行われ、さまざまなデータチームが適切なガードレールの保護のもとでセルフサービスの機能を活用できます。COEチームは多くの場合軽量なものですが、データチームにとっては重要なハブとなり、他のユーザーを教育するためのドキュメント化、SOP、ハウツー、FAQの維持管理のイネーブラとなります。
ベストプラクティス#5: レイクハウスはデータレイクが提供しないレベルのガバナンスを提供します。活用しましょう！レイクハウスの構築の最初の一歩として、ご自身のコンプライアンス、ガバナンス要件を評価し、リスクを最小化するためにDatabricksが提供する機能を活用します。これには、監査ログのデリバリー、HIPAAとPCI(必要な場合)、適切な侵入コントロール、ACL、ユーザーコントロール、これら全ての定期てなレビューが含まれます。
今後もデータガバナンスからユーザー管理に至るトピックで管理者向けベストプラクティスを提供していきます。そして、ワークスペース管理についての質問があれば、あるいは、Databricksのレイクハウスプラットフォームにおけるベストプラクティスを学びたいのであれば、Databricksアカウントチームにコンタクトしてください！