Unityカタログの分散・非集中管理に向けた自動化ガイド

Terraformで、さまざまなガバナンスモデルに対応したUnity Catalogの大規模デプロイを実現するには？

ヴオン・グエン、ジーシャン・パパ、Mattia Zeni による投稿

December 7, 2022 in プラットフォームブログ

Share this post

Original : An Automated Guide to Distributed and Decentralized Management of Unity Catalog

翻訳： junichi.maruyama

Unity Catalogは、あらゆるクラウド上のレイクハウスにあるすべてのデータとAI資産に対して、統一されたガバナンスソリューションを提供します。顧客がUnity Catalogを採用する際、コードアプローチとしてのインフラストラクチャを使用して、これをプログラム的かつ自動的に行いたいと考えています。Unity Catalogでは、Unity Catalogのオブジェクトの最上位コンテナであるメタストアがリージョンごとに1つ存在します。このメタストアには、データ資産（テーブルとビュー）と、アクセスを制御する権限が格納されています。

このことは、Unity Catalogの管理機能を担うプラットフォーム/ガバナンスチームを一元化していない組織にとって、新たな課題となる。具体的には、これらの組織内のチームは、単一のメタストアについて協力し、連携しなければならなくなりました。つまり、互いに完全に分離した状態でアクセスを管理し、監査を実行する方法です。

このブログポストでは、お客様がDatabricks Terraform providerにおけるUnity Catalogオブジェクトのサポートを活用して、レイクハウス上の分散ガバナンスパターンを効果的に管理する方法について説明します。

私たちは2つの解決策を提示します：

Unity Catalogでアセットを作成する際に、チームに責任を完全に委ねるもの。
チームがUnity Catalogで作成できるリソースを制限するもの

Unity Catalogメタストアの作成

1回限りのブートストラップアクティビティとして、お客様は、運用する地域ごとにUnity Catalogメタストアを作成する必要があります。これは、ブレイクグラスシナリオでのみアクセス可能な高度な特権であるアカウント管理者、すなわち、自動パイプラインで使用するために承認ワークフローを必要とするsecret vaultに保存されたユーザー名とパスワードが必要です。

アカウント管理者は、AWS上でユーザー名＆パスワードを使って認証する必要があります：

または、Azure上で彼らのAADトークンを使用する：

Databricks Account Adminが提供する必要があります：

管理テーブルのデータを保存するデフォルトの場所となる単一のクラウドストレージ（S3/ADLS）
Unity Catalogが(1)のクラウドストレージにアクセスするために使用する、単一のIAMロール/マネージドID

Terraformのコードは以下のようなものになります（AWSの例）

チームでは、個々のカタログごとに管理対象テーブルのロケーションとアイデンティティを設定したり、スキーマレベルでさらに細かく設定することで、テーブルにこのデフォルトのロケーションとアイデンティティを使用しないことを選択できます。管理対象テーブルが作成されると、データはスキーマの場所（存在する場合）を使用してカタログの場所（存在する場合）にフォールバックし、前の2つの場所が設定されていない場合にのみメタストアの場所にフォールバックして保存されます。

メタストア管理者を指名する

メタストアを作成する際に、メタストア管理者としてunity_admin_groupを指名しています。メタストア内のすべてのオブジェクトをリストアップし、アクセスを管理できる中央当局を持つことを避けるために、このグループを空にしておくことにします。

高い管理能力を必要とする例外的なブレークグラス・シナリオ（初期アクセスの設定、カタログ所有者が組織を離れた場合のカタログ所有者の変更など）のために、ユーザーをグループに追加することができます。

チームへの責任委譲

各チームは、独自のカタログを作成し、そのデータへのアクセスを管理する責任があります。各新規チームが独立して活動するために必要な権限を取得するために、最初のブートストラップ活動が必要です。

その後、アカウント管理者は次のことを実行する必要があります：

team-adminsというグループを作成します。
CREATE CATALOG、CREATE EXTERNAL LOCATION、およびDelta Sharingを使用している場合はGRANT CREATE SHARE、PROVIDER、RECIPIENTをこのチームに付与する（オプションとして）

新しいチームがオンボードで参加する場合、信頼できるチーム管理者を team-admins グループに配置します。

team-adminsグループのメンバーは、アカウント管理者やメタストア管理者が操作しなくても、チームのために新しいカタログや外部ロケーションを簡単に作成できるようになりました。

新しいチームのオンボーディング

Databricksに新しいチームを追加するプロセスでは、新しいチームがワークスペースやデータ資産を自由に設定できるように、アカウント管理者による初期作業が必要です：

新しいワークスペースは、チーム X の管理者（Azure）またはアカウント管理者（AWS）により作成されます。
アカウント管理者は、既存のメタストアをワークスペースにアタッチします。
アカウント管理者は、このチーム専用のグループ「team_X_admin」を作成し、オンボーディングされるチームの管理者を含めます。

アカウント管理者は、ストレージクレデンシャルを作成し、所有者を「team_X_admin」グループに変更して使用する。チーム管理者がクラウドテナントで信頼されている場合、クレデンシャルがアクセスできるストレージを制御できます（例：自分のS3バケットやADLSストレージアカウントのいずれか）

その後、アカウント管理者は、新しく作成されたワークスペースをUCメタストアに割り当てます。

チームXの管理者は、必要な数のカタログと外部ロケーションを作成します。
- チーム管理者はメタストア所有者やアカウント管理者ではないので、自分が所有していないエンティティ（カタログ/スキーマ/テーブルなど）、つまり他のチームのものとやり取りすることはできません。

チームへの責任委譲が限定的

組織によっては、中央のメタストアにアセットを作成する際に、チームを自律させたくない場合があります。実際、複数のチームにそのような資産を作成する能力を与えることは、統治が難しく、命名規則を強制することができず、環境をきれいに保つことが困難です。

このようなシナリオでは、各チームが管理者に作成してもらいたいアセットのリストを添えてリクエストを提出するモデルを提案します。そのチームはアセットのオーナーとなり、他者への権限付与を自律的に行うことができるようになります。

このようなリクエストをできるだけ自動化するために、CI/CDを使った方法を紹介します。管理者チームは、自分たちが好むバージョン管理システムの中央リポジトリを所有し、そこに組織内のDatabricksをデプロイするすべてのスクリプトを格納します。各チームはこのリポジトリにブランチを作成し、定義済みのテンプレート（Terraform Module）を使って自分たちの環境のTerraform設定ファイルを追加することができます。チームの準備が整ったら、プルリクエストを作成します。この時点で、中央管理者はプルリクエストをレビューし（適切なチェックで自動化することも可能）、メインブランチにマージする必要があります。

このアプローチでは、個々のチームが行うことをよりコントロールすることができますが、セントラルアドミニストレータのチームではいくつかの（限定的で自動化可能な）活動が必要となります。

このシナリオでは、以下のTerraformスクリプトは、アカウントadminにしたService Principal (00000000-0000-0000-00000000) を使ってCI/CDパイプラインから自動的に実行されます。このようなサービスプリンシパルをアカウント管理者にする単発の操作は、例えば既存のアカウント管理者が手動で実行する必要があります：