3人の管理者の物語

このブログは、Databricks管理者に適したトピックを議論する管理者基本シリーズの一部となります。他の記事には、ワークスペース管理のベストプラクティス、DR Strategies with Terraformなどがあります！間もなく公開されるコンテンツも楽しみにして下さい。過去の管理者向けブログでは、事前の設計とDR、CI/CDのような自動化の観点、システムのヘルスチェックを通じた強固なワークスペース構成をどのように確立、維持するのかを議論しました。管理において同様に重要な観点は、特にレイクハウスにおいて多数の異なるタイプの管理者のペルソナが存在する場合には、ワークスペース内をどのように組織立てるのかということになります。この記事では、以下の方法などワークスペースを管理する際の管理観点での検討事項について説明します。

新たなユーザーやユースケースを長期にわたって対応できる様にオンボーディングするためのポリシーとガードレールのセットアップ
リソース使用量のガバナンス
許可されたデータアクセスの保証
投資を最適にするための計算資源使用量の最適化

それぞれのロールを理解するために、我々は最初にアカウント管理者とワークスペース管理者の違い、これらのロールが管理する固有のコンポーネントを理解する必要があります。

アカウント管理者 vs ワークスペース管理者 vs メタストア管理者

管理的な検討事項は、アカウント(多くの場合あなたの組織と1:1にマッピングされるハイレベルの構成要素)とワークスペース(LOBなどさまざまな方法でマッピングされるより詳細な分離レベル)の両方に分割されます。これらの3つのロールにおける役目の違いを見ていきましょう。

図1: アカウントコンソール

これを別の方法で説明するために、以下の様にアカウント管理者の主要な責任範囲をブレークダウンすることができます。

アカウントレベルのプリンシパル(グループ/ユーザー/サービス)とSSOのプロビジョニング。アイデンティティフェデレーションは、アカウントから直接ワークスペースにアカウントレベルのアイデンティティを割り当てることを意味します。
メタストアの設定。
監査ログのセットアップ。
アカウントレベルの使用量(DBU、課金)のモニタリング。
必要な組織論に沿ったワークスペースの作成。
その他のワークスペースレベルオブジェクト(ストレージ、認証情報、ネットワークなど)の管理。
プロダクションワークロードから人間の介在を排除するためにIaaCを用いた開発ワークロードの自動化。

図2 アカウントのアーティファクト

一方、ワークスペース管理者の主要な検討事項は以下のとおりとなります。

ワークスペースレベルで適切なロール(ユーザー/管理者)をプリンシパルに割り当て。
ワークスペースレベルで適切な資格情報(ACL)をプリンシパルに割り当て。
(オプション)ワークスペースレベルでのSSOの設定。
プリンシパルが以下を行えることを許可するためのクラスターポリシーの定義。
- 計算リソース(クラスター/ウェアハウス/プール)の定義
- オーケストレーション(ジョブ/パイプライン/ワークフロー)の定義
ワークスペースレベルの機能のオン/オフ。
資格情報をプリンシパルに割り当て。
- データアクセス(内部/外部Hiveメタストアを用いている場合)
- プリンシパルの計算リソースへのアクセスの管理。
Reposの様な機能向け外部URLの管理(許可リストを含む)。
セキュリティ、データ保護のコントロール
- 誤ってチームにデータを公開してしまうことを防ぐためにDBFSのオフあるいは制限。
- データ漏洩を防ぐために(ノートブックやDBSQLから)結果データのデータダウンロードの抑止。
- アクセスコントロール(ワークスペースオブジェクト、クラスター、プール、ジョブ、テーブルなど)の有効化。
クラスターレベルのログデリバリーの定義(理想的にはクラスターポリシーを通じたクラスターログのストレージ設定)。

図3 ワークスペースのアーティファクト

アカウント管理者とワークスペース管理者の違いを要約するために、以下のテーブルではいくつかのキーとなる次元における二つのペルソナの違いをまとめています。

	アカウント管理者	メタストア管理者	ワークスペース管理者
ワークスペース管理	ワークスペースの作成、アップデート、削除他の管理者追加も可能	対象外	ワークスペース内のアセットのみを管理
ユーザー管理	ユーザー、グループ、サービスプリンシパルの作成、あるいは、IDPからデータを同期するためにSCIMを使用 Permission Assignment APIによるワークスペースへのプリンシパルの許可	対象外	お使いの全ての(セキュリティ保護可能な)データ資産に対する中央ガバナンスとしてUCを使うことをお勧めします。Unity Catalog(UC)にリンクされた全てのワークスペースでアイデンティティフェデレーションがオンになります。アイデンティティフェデレーションが有効化されたワークスペースに対しては、全てのプリンシパルに対してアカウントレベルのSCIMをセットアップし、ワークスペースレベルのSCIMをストップします。非UCのワークスペースにおいてはワークスペースレベルでSCIMを使うことができます(しかし、これらのユーザーもアカウントレベルのアイデンティティにプロモーションされます)。ワークスペースレベルで作成されたグループは「ローカルの」ワークスペースレベルのグループと見做され、Unity Catalogにアクセスすることはできません。
データのアクセスと管理	メタストアの作成メタストアへのワークスペースへのリンクメタストアのオーナーシップをメタストア管理者/グループに委任	Unity Catalogを用いることで以下のことが可能となります。メタストアにある全てのセキュリティ保護可能なオブジェクト(カタログ、スキーマ、テーブル、ビュー)に対する権限の管理データスチュワード/オーナーに対してカタログ、スキーマ(データベース)、テーブル、外部ロケーション、ストレージ認証情報へのアクセスの許可(委任)	現在Hiveメタストアを使用しているお客様は、AWSのインスタンスプロファイル、Azureのサービスプリンシパル、テーブルACL、クレディンシャルパススルーの様なさまざまな方法でデータアクセスを保護することができます。 Unity Catalogを用いることで、これはアカウントレベルで定義され、全てのセキュリティ保護可能オブジェクトに対して、ACLにANSIのGRANTを使用することができます。
クラスター管理	対象外	対象外	DE/ML/SQL向けにS/M/Lサイズのワークロードを行うために、さまざまなペルソナ/サイズでのクラスターを作成します。デフォルトのユーザーグループからクラスター作成権限を削除します。クラスターポリシーを作成し、適切なグループにポリシーへのアクセスを許可グループに対してSQLウェアハウスの使用権限を付与します。
ワークフロー管理	対象外	対象外	ジョブ/DLT/all-purposeクラスターポリシーが存在し、グループがそれらにアクセスできることを確実にします。ユーザーが再起動できるall-purposeクラスターを事前に作成しておきます。
予算管理	ワークスペース/sku/クラスタータグごとのよさオンをセットアップします。アカウントコンソールごとの使用量をモニタリングします。(ロードマップ) DBSQL経由でクエリーするための課金使用量システムテーブル(ロードマップ)	対象外	対象外
最適化/チューニング	対象外	対象外	計算資源の最大化、最新のDBRの活用、Photonの活用インフラストラクチャの投資を最大限に活用できる様にベストプラクティスと最適化に従うために、LOBやCOEと連携

図4 Databricksの管理者ペルソナの責任範囲

計算資源需要のピークに合わせたワークスペースのサイジング

クラスターノードの最大数は、VPC内で利用できるIPの再代数によって決定されるので、適切にVPCをサイジングすることは設計時の重要な検討事項となります。それぞれのノードは2つのIP(AzureとAWSの場合)を必要とします。お使いのクラウドにおける詳細情報があります：AWS、Azure、GCP。これを説明するために、ここではAWS上のDatabricksの例を使用します。CIDRをIPにマッピングするためにこちらを使います。E2ワークスペースで許可されているVPCのCIDRレンジは/25 - /16です。少なくとも2つの異なるアベイラビリティゾーンで2つのプライベートサブネットが設定される必要があります。サブネットマスクは、/16 - /17の間にある必要があります。VPCは論理的な分離ユニットであり、2つのVPCが通信する、すなわちピアリングする必要がないのであれば、同じレンジを持つことができます。しかし、通信する必要がある場合には、IPのオーバーラップを避ける必要があります。CIDRレンジ/16のVPCの例を見てみましょう。

VPC CIDR /16	このVPCの最大IP数: 65,536	シングルノード、マルチノードのクラスターはサブネットで起動します。
2つのAZ	それぞれのAZが /17 である場合: => 32,768 * 2 = 65,536のIPとなり、他のサブネットは作成不可となります。	32,768 IP => それぞれのサブネットで最大16,384ノードとなります。
	代わりにそれぞれのAZが /23 である場合: => 512 * 2 = 1,024のIPとなり、65,536 - 1,024 = 64,512IPが残ります。	512 IP => サブネットごとに最大256ノードとなります。
4つのAZ	それぞれのAZが /18である場合: 16,384 * 4 = 65,536のIPとなり、他のサブネットは作成不可となります。	16,384 IP => サブネットごとに最大8192ノードとなります。

ワークスペース管理者によるコントロールと敏捷性のバランスを取る

計算資源が、クラウドインフラストラクチャの投資においてもっとも高価なコンポーネントとなります。データの民主化によって、イノベーションとセルフサービスの促進がデータドリブンの文化に向けた第一歩となりました。しかし、マルチテナントの環境においては、経験の少ないユーザーや不注意によるヒューマンエラーによって、コストの浪費や不用意な露出が生じる場合があります。コントロールが厳密すぎると、アクセスのボトルネックを生み出し、イノベーションを押し殺すことになります。このため、管理者は、固有のリスクなしにセルフサービスを可能とするガードレールを設定する必要があります。さらに、これらのコントロールに対する準拠状況をモニタリングできる様になっているべきです。ここで、ユーザーが許可された範囲内でオペレーションを行い、彼らの意思決定プロセスを大幅にシンプルにする様に、ルールを定義し資格情報をマッピングするクラスターポリシーが非常に役に立ちます。不要なカオスを回避するために、プロセスによって一過性の例外を管理できる様に真に効率的になるようにプロセスにってバックあっっぷされるべきであることに注意する必要があります。このプロセスにおける重要なステップの一つが、ワークスペースにあるデフォルトのusersグループからallow-cluster-createの資格を削除し、ユーザーがクラスターポリシーで管理された計算資源のみを活用できる様にするというものです。以下に、クラスターポリシーのベストプラクティスにおける重要な推奨事項を要約します。

標準的なクラスターテンプレートを提供するためにTシャツサイズを使用します。
- ワークロードの規模ごと(スモール、ミディアム、ラージ)
- ペルソナごと(DE/ML/BI)
- 習熟度ごと(シチズン/高度)
以下を利用を強制することがでガバナンスを管理します。
- タグ：チーム、ユーザー、ユースケースごとの属性
  - ネーミングは標準化すべきです
  - 一貫性のあるレポートのためにいくつかの属性を必須にします
以下を制限することでコンサンプションをコントロールします。
- DBU消費率とポリシーの目的
- 自動停止のタイムアウト、スケーリングの最小、最大サイズ

計算資源の検討

固定されたオンプレミスの計算インフラストラクチャと異なり、クラウドではワークロードや対象のSLAにおいて適切な計算資源にマッチするための柔軟性と弾力性を提供します。以下の図ではさまざまなオプションを示しています。入力はワークロードタイプや環境のようなパラメータであり、出力はベストフィットする計算資源のタイプやサイズとなります。

図5 適切な計算資源の決定

例えば、望ましくは最新のDBRを用いた自動化ジョブクラスターでプロダクションのDEワークロードを実行すべきです。以下のテーブルでは、いくつかの一般的なシナリオを示しています。

ワークフローの検討

計算資源の要件を明確にしたので、以下のことを検討する必要が出てきます。

ワークフローをどの様に定義してトリガーするのか。
どの様にタスクが計算資源を再利用できるのか。
どの様にタスクの依存関係を管理するのか。
どの様に失敗したタスクのリトライを行うのか。
どの様にバージョンをアップグレードし、パッチを適用するのか。

これらはユースケースを取り巻くデータエンジニアリングとDevOpsの検討事項であり、多くの場合管理者にとっての直接の懸念事項となります。以下の様にモニタリングすべき検疫タスクが存在します。

ワークスペースには設定ジョブの総数に制限があります。しかし、これらのジョブの多くは呼び出されず、実際に使用されるジョブにスペースを提供するためにクリーンアップする必要があります。
全てのプロダクションジョブはサービスプリンシパルとして実行されるべきであり、プロダクション環境へのユーザーのアクセスは強く制限されるべきです。ジョブのアクセス権をレビューしてください。
ジョブは失敗することがあるので、全てのジョブには失敗時のアラートとオプションとしてリトライを設定すべきです。こちらにあるemail_notifications、max_retriesや他のプロパティをレビューしてください。
全てのジョブはクラスターポリシーに関連づけられ、課金のために適切にタグづけされるべきです。

DLT: 大規模高信頼パイプラインにおける理想のフレームワークの例

さまざまな業界の数千の大小のクライアントと取り組みをする中で、開発や本格運用における共通のデータの課題が明らかとなり、これを解決するためにDatabricksはDelta Live Tables(DLT)を開発しました。これは、どのようにではなく何を指定する宣言型パイプラインを作成できる様にすることで、ETLワークロードの開発と維持をシンプルにするためのマネージドプラットフォームです。こによって、データエンジニアのタスクをシンプルにし、管理者にとってはサポートケースが削減されることになります。

図6 DLTはパイプライン管理の管理者のロールをシンプルにします

DLTは定期的なoptimize & vacuumジョブのような一般的な管理機能を、追加のケアをすることなしにメンテナンスジョブとしてパイプライン定義に組み込みます。DLTはリネージュ、モニタリング、データ品質チェックの様なシンプルなオペレーションに対するパイプラインの深い可視性を提供します。例えば、クラスターが停止すると、プラットフォームはデータエンジニアが明確にプロビジョニングしなくても、(Productionモードでは)自動リトライを行います。強化オートスケーリングは、クラスターのアップサイズを必要とする突然のデータバーストをハンドリングすることができ、適切にダウンスケールします。言い換えると、自動化されたクラスターのスケーリングとパイプラインの耐障害性はプラットフォームの機能となっています。ターンテーブルのレーテンシーによって、パイプラインをバッチやストリーミングで実行し、コードではなく設定を管理することで開発用パイプラインを比較的容易にプロダクションに移行することができます。DLT固有のクラスターポリシーを活用することで、お使いのパイプラインのコストをコントロールすることができます。また、DLTはランタイムエンジンを自動でアップグレードするので、管理者やデータエンジニアの責任範囲を削減し、ビジネス価値の創出によりフォーカスできる様にします。

UC: 理想的なデータガバナンスフレームワークの例

Unity Catalog(UC)を用いることで、企業はこれまでは不可能であったシンプルなGRANT文を通じて単一のアカウント配下のすべてのワークスペースのテーブルとファイルに対して共通のセキュリティモデルを導入することができます。DE/DSクラスターやSQLウェアハウスからデータ、テーブル、ファイルに対するアクセスを許可・監査することで、企業はクラウドごとのプリミティブに依存することなしに、自身の監査、モニタリング戦略をシンプルにすることができます。UCが提供する主要な機能には以下の様なものが含まれます。

図7 UCはデータガバナンス管理に対する管理者のロールをシンプルにします

UCは定義の集中管理、モニタリング、メタストアのデータに対する検索可能性によって管理者の作業(アカウントレベル、ワークスペースレベルの両方において)をシンプルにし、アタッチされるワークスペースの数に関係なしに容易にセキュアにデータを共有できるようにします。一度定義すればどこでもセキュアにするモデルを活用することで、あるワークスペースにおいて誤ってユーザーに権限を付与することで、意図しない形でデータが利用されるようなシナリオにおいて、誤ったデータ露出を回避するために更なる利点を提供します。これらすべては、アカウントレベルのアイデンティティとデータのアクセス権を活用することで達成されています。UCの監査ログによって、すべてのオブジェクトに対するすべてのレベルのすべてのユーザーによるすべてのアクション、もし、verbose audit loggingを有効化しているのであれば、ノートブックやDatabricks SQLで実行された個々のコマンドもキャプチャされます。セキュリティ保護可能オブジェクトに対するアクセスは、メタストア管理者あるいはオブジェクトのオーナー、オブジェクトを格納するカタログやスキーマのオーナーによって許可されます。アカウント管理者は、唯一の役割が適切なアクセス権限を許可することであるメタストア管理者にグループを指名することで、メタストアのロールを委任することをお勧めします。

推奨事項とベストプラクティス

アカウント管理者、メタストア管理者、ワークスペース管理者のロールと責任範囲は適切に定義され、互いに補完し合うものです。自動化、変更リクエスト、エスカレーションのようなワークフローは、ワークスペースがLOBごとにセットアップされているのか、中央のCOEによって管理されているのかに応じて、適切なオーナーに割り当てられるべきです。
すべてのワークスペースのプリンシパルの集中管理を実現し、管理をシンプルにできるので、アカウントレベルのアイデンティを有効化すべきです。アカウントレベルでSSO、SCIM、監査ログの様な機能をセットアップすることをお勧めします。SSOフェデレーション機能が利用できる様になるまでは、依然としてワークスペースレベルのSSOが必要となります。
クラスターポリシーは効果的なセルフサービスのためのガードレールを提供するパワフルなレバーであり、ワークスペース管理者のロールをシンプルなものにします。いくつかのサンプルポリシーをこちらで提供しています。アカウント管理者は、主にペルソナ/Tシャツサイズに基づき、理想的にはTerraformのような自動化ツールを通じてシンプルなデフォルトポリシーを提供すべきです。ワークスペース管理者はそのリストに対して、より細かいコントロールを追加することができます。適切なプロセスと組み合わせることで、すべての例外シナリオに適切に対応することができます。
アカウント管理者はアカウントコンソールからすべてのワークスペースのすべてのワークロードタイプの現在のコンサンプションを確認し、トラッキングします。課金や分析のために、すべての情報が中央のクラウドストレージにデリバリーされる様に利用課金ログデリバリーをセットアップすることをお勧めします。アカウントレベルでBudget API(プレビュー)を設定することで、管理者はワークスペース、SKU、クラスタータグレベルで閾値を作成し、割り当てられた予算内に収まる様にタイムリーなアクションを取れる様にコンサンプションのアラートを受け取れる様にすべきです。計算リソースの利用率に関して改善が必要になった際に、改善対象を特定に役立つようにさらにきめ細かいレベルで使用量を追跡するためにOverwatchの様なツールを活用してください。
Databricksプラットフォームでは、共通する管理者の機能をプラットフォームの中で抽象化することでさまざまなデータペルソナの作業を改革しシンプルにし続けています。我々のお勧めは新たなパイプラインにはDelta Live Tablesを用い、すべてのユーザーとデータアクセス管理にはUnity Catalogを使うというものです。

最後になりますが、これらのベストプラクティスの大部分、この記事で述べた事柄の大部分においては、調整、チームワークが成功の同義語となります。アカウント管理者とワークスペース管理者がサイロの中に存在することは理論上は可能ですが、これは一般的なレイクハウスの原則に反するだけでなく、関連するすべての人の日々が困難なものとなります。本書から持ち帰るべき最も重要な提言は、企業のアカウント / ワークスペース管理者 + プロジェクト / データリード + ユーザーをつなげることです。Teams/Slackチャンネル、メールエイリアスの様なメカニズム、週次のミートアップなどが有効であることが証明されています。我々Databricksが目撃した最も効果的な組織においては、技術におけるオープンさを受け入れるだけでなく、オペレーションにおけるオープンさについても重きを置いています。間も無く公開されるロギングやデータ漏洩に関する推奨事項や管理にフォーカスしたプラットフォーム機能に関する管理者向け記事を楽しみにしていて下さい。

Databricks 無料トライアル

Databricks 無料トライアル