[Databricks]私的、できるだけ早期から考慮したい管理機能3選

この記事は Databricks Advent Calendar 2024 の 17 日目の記事です🎄

はじめに

筆者は複数の組織で、様々な立場（管理者として導入を推進/導入済みの環境への管理者としての参加/非管理者として導入の俯瞰など）でDatabricksに関わってきました。

その経験の中で、「データ系チームのみで小規模に使用し、徐々に組織に普及させていく」という構想のもと、従来のパブリッククラウド等の管理系サービスやインフラの経験が少ないチーム（例：新卒のデータエンジニアや、データサイエンスを専門とするメンバー）が試行錯誤しながらDatabricksを運用しているケースに遭遇しました。

より具体的には、以下のような問題に直面しているケースが散見されました。

• 権限の問題で作業がストップする
• 退職者のユーザを削除したら既存の処理が失敗するようになった
• コストが高騰しているが対策が取れない

このようなケースは珍しくないのかもしれないと感じ、同様の問題に直面している方々の助けになればと思い、本記事を執筆しました。

本稿では、特に早期から意識したい管理系の機能を3種紹介します。

抽象的で分かりづらいと感じるものについては、筆者における具体例を紹介しておりますのでお役に立てば幸いです。
それでも分かり辛いなどございましたら、ぜひコメントください！大変助かります！

• Databricks関連のドキュメントは、Databricks on AWSのものを使用しています。
• 最新の情報は、公式ドキュメントを参照ください。

1. グループを活用する

早速1つめですが、「グループを活用する」です。

公式のドキュメントにおいても、以下の抜粋の通り「グループ単位で各リソースへのアクセス制御を行うことがベストプラクティス」とされています。

Unity Catalog内のワークスペースとアクセス制御ポリシーへのアクセスを、ユーザーを個別に割り当てるのではなく、グループに割り当てることがベストプラクティスです。

そもそも、Databricksには、以下の3種のIDが存在し、これらのIDで各リソースへのアクセス制御が可能です。

1. ユーザ

• Emailアドレスと紐付く個人用のID

2. サービスプリンシパル（次項で触れます。）

• システム用の（個人と紐つかない）ID

3. グループ

• ユーザ/サービスプリンシパルらのIDの集合

グループ活用のメリット

ユーザ単位でのアクセス制御と比較して、グループ単位での管理には以下のメリットがあります。

• 管理作業の簡素化
• 権限の可視性向上
• 権限変更の容易さ

例えば、ユーザ単位でのアクセス制御は以下の問題があります。

• 「ユーザ数」×「アクセス制御対象のリソース数」分の操作が必要
• ユーザやリソースの増減の度に作業が発生
• 権限の全体像把握が困難

一方でグループ単位でのアクセス制御では以下のメリットがあります。

• 「グループ数」×「アクセス制御対象のリソース数」分の操作
• 一般にグループ数はユーザ数より少なくなるため、変更頻度が低くなる
• グループ名で権限の役割を表現可能

グループ構成の考え方

ここで、どの単位でグループを構成するか？が最も頭を悩ませる点になります。

組織構成/組織の管理思想/ワークロードなど様々なものに依存するため一概にベストと言えるものは無いと考えていますが、筆者の場合、以下のアプローチでグループ構成を検討しています。

1. 「対象」と「認可したい権限」の組み合わせを列挙し分類
2. 組織固有の要件を考慮
3. 実際のグループを設計

具体例

1. 「対象」と「認可したい権限」の組み合わせを列挙し分類

• 管理分類
  • 「すべてのリソース」への「全操作を許可」
• 開発分類
  • 「一部リソース」に対しての「全操作を許可」
  • 「特定リソース」については「削除を禁止」
• 閲覧分類
  • 「特定のリソース」への「閲覧を許可」

2. 固有要件を考慮（例：期間限定メンバーへの対応）

   • 期間限定の開発者（例：データエンジニアインターン生）
   • 期間限定の分析者（例：データアナリストインターン生）

3. グループの実装

   • Admin グループ（管理分類になるユーザが所属）
     • 「すべてのリソース」への「全操作を許可」
   • Developer グループ （開発分類にあたるユーザが所属）
     • 「一部リソース」に対しての「全操作を許可」
     • 「特定リソース」については「削除を禁止」
   • Business グループ（ビジネス分類に当たるユーザが所属）
     • 「特定のリソース」への「閲覧を許可」
   • Engineer Intern グループ（データエンジニアインターン生ユーザが所属）
     • 開発分類をベースに、よりスコープを絞った認可
   • Analyst Intern グループ（データアナリストインターン生ユーザが所属）
     • 閲覧分類をべースに、よりスコープを絞った認可

また、所属するユーザの数が1人となる場合でも、「将来的にユーザが増える可能性があること」「グループ名から役割を想起できること」などの理由から、グループを使うようにしています。

机上ではきれいに見えますが、実運用では、ユーザが複数のグループに所属したり、ネストしたグループにせざるをえないなどと複雑化するケースが多いです。

できるだけシンプルに運用するためにも、グループを定期的に見直すことをおすすめします。（幸いグループ名は変更可能です。）

その他

• グループは、アカウントコンソールにて作成し各ワークスペースへ割り当てる「アカウントグループ」と、ワークスペースコンソールで作成する「ワークスペースローカルグループ（レガシーグループ）」の2種が存在します。「アカウントグループ」の活用が推奨されているため、特別な理由がない限り「アカウントグループ」を使用するようにしましょう。

• 本稿では、IDベースのアクセス制御に触れましたが、 属性ベースのアクセス制御（ABAC） 対応もアナウンスされています。（例：PIIに対するタグベースの行レベルフィルター/列レベルマスク）

2. サービスプリンシパルを使用する

サービスプリンシパルは、システム用のID（システムユーザ）として機能します。公式のドキュメントによると、以下の利点があります。

• API専用のアクセス権限を提供
• ユーザやグループよりも優れたセキュリティを実現
• ユーザの退職やグループ変更時でもジョブの継続性を確保

特に最後の点が重要です。ユーザアカウントが削除されると、そのユーザに紐づく多くのリソースが機能しなくなる可能性があります。

ユーザ削除時の警告画面

ユーザ削除のタイミングをコントロールできるのであれば、事前に移行作業を行うことで問題を回避できます。しかし、そうでない場合、以下のような影響が発生し、ビジネス影響が生じる可能性があります。

• 定期ワークロードの停止
• ダッシュボードの閲覧不可

そのため、継続的な運用が必要なものについては、サービスプリンシパルの使用を推奨します。

実践例

筆者の場合、以下のケースを除き、基本的にサービスプリンシパルを使用しています。

• 個人での検証用途
• 短期的な使用（記事執筆用）

筆者のワークフローの開発は以下のようになっています。

1. ローカルで開発
2. ローカルからDatabricksへ同期し動作確認

• 参考：Databricks extension for Visual Studio Code v2 の環境構築方法

3. CI/CDフロー中でIaCによりリソースをデプロイ

• GitHub Actions中でTerraformを利用しデプロイ
• terraformのaction中でDatabricksへの認証にサービスプリンシパルを利用

その他

• ユーザではなく、サービスプリンシパルを使用するデメリットとして、誰の所有物かわからなくなることが挙げられます。タグやbudget policy tag（サーバレスサービスに対するタグ機能。以降全てタグと呼称。）を用いることでこれを回避できます。筆者の場合、タグのキーとしてOwnerEmail、タグの値として作成者のメールアドレスを入れる運用をしています。こうすることで、使途不明なものを減らす、各人（メールアドレス）ごとの使用コストが算出できるなどのメリットがあります。

• サービスプリンシパルの利用自体に金銭コストは発生しません。しかし、すべてのワークロードを個人に依らないものにしたい（例：サービスプリンシパル→GitHubへの認証も人に依存したくない）場合、関係する外部のサービスにもシステムユーザを作成する必要があります。GitHubの場合、ドキュメントに以下の記載があります。外部のサービスへのユーザ追加は、金銭コストが発生する可能性があるので、各サービスのドキュメントを参照ください。

GitHub の個人アカウントではなく GitHub コンピューター ユーザーを使用することをお勧めします。

3. コストを管理する

Databricksでは、コスト管理のためにダッシュボードが提供されており、アカウントコンソールで閲覧が可能です。
このダッシュボードを各ワークスペースへインポートすることもできます。参考

このダッシュボードをそのまま使っても多くの示唆が得られますが、より深い洞察を得たい場合はタグの併用が重要です。
そのためには、各リソースへのタグ付けが欠かせません。

2.でも触れましたが、タグやbudget policy tag、そしてタグ付けを強制するCompute Policyらを利用し、誰がどのようにコストを使用しているか？を詳細に追跡できるようしておくことがコスト管理、ひいては、コスト削減に効いてきます。

ワークスペースへインポートしたダッシュボードはカスタマイズ可能なので、要求にあったカスタマイズを施した後、予算アラートなどを設定することをおすすめします。

筆者の例

ワークスペースへインポートしたダッシュボードは少し情報が多いので、必要な情報のみを表示するダッシュボードを新規で用意しています。

表示する情報は以下のようなものが多いです。

• 任意の期間を設定するフィルタ
• 任意の期間の日別使用料金
• 任意の期間のユーザ別（プロジェクト別）使用料金
• 前月の使用料

おわりに

本稿では、特に早期から意識したい管理系の機能を3種紹介しました。

これらの管理機能は、早期からの導入が重要です。
後付けでの対応は以下の理由で困難になりがちです。

• グループ管理：既存ユーザーの権限整理が煩雑
• サービスプリンシパル：既存リソースの移行が手間
• コスト管理： 既存のリソースへのタグ付けが手間

これらはビジネスの直接的な成果に結びつきにくいため、後回しにされがちです。
早期からの適切な管理を行い、長期的な運用の成功につなげましょう。