2023年7月29日

クラウドエンジニアがAWSにDatabricksをデプロイするためのベストプラクティスとガイダンス：パート3

AWS上でのDatabricksデプロイの自動化

によって JD Braun 、 Tony Bo による投稿

Archived. This article has not been updated since the publish date above. The dynamic nature of information means that previously accurate content can become outdated or even obsolete over time. Readers are advised to exercise due diligence and cross-check any information found in this blog post before making decisions or adopting any practices based on said information.

翻訳：Junichi Maruyama. - Original Blog Link

クラウドエンジニアがAWSにDatabricksをデプロイするためのベストプラクティスとガイダンスシリーズの最終回として、重要なトピックである自動化を取り上げます。このブログポストでは、デプロイで使用される3つのエンドポイントを分解し、CloudFormationやTerraformのような一般的なInfrastructure as Code (IaC)ツールの例を説明し、自動化のための一般的なベストプラクティスで締めくくります。

しかし、これから参加される方には、Databricks on AWSのアーキテクチャとクラウドエンジニアにとっての利点について説明したpart oneを読まれることをお勧めします。またpart twoでは、AWS 上でのデプロイとベストプラクティス、そして推奨事項について説明します。

クラウド・オートメーションのバックボーン

クラウドエンジニアであれば、クラウド自動化のバックボーンが様々なクラウドサービスとやり取りするためのアプリケーションプログラミングインターフェース（API）であることをよくご存知だろう。最新のクラウドエンジニアリングスタックでは、様々な外部サービスや内部ツールなどをデプロイし管理するために、組織が何百もの異なるエンドポイントを使用することがあります。APIエンドポイントを使って自動化するというこの一般的なパターンは、Databricks on AWSのデプロイメントでも変わりません。

Databricks on AWSデプロイメントのAPIエンドポイントの種類：

Databricks on AWSのデプロイは、3種類のAPIエンドポイントに集約される：

AWS：このブログシリーズのパート2で説明したように、AWSエンドポイントではいくつかのリソースを作成できる。これらにはS3バケット、IAMロール、VPC、サブネット、セキュリティグループなどのネットワークリソースが含まれる。
Databricks - アカウント： Databricks の組織階層の最上位にあるのが Databricks アカウントです。アカウントエンドポイントを使用して、クラウドリソースをカプセル化したコンフィギュレーション、ワークスペース、アイデンティティ、ログなどのアカウントレベルのオブジェクトを作成することができます。
Databricks ワークスペース : 最後に使用するエンドポイントの種類はワークスペースエンドポイントだ。ワークスペースが作成されると、そのワークスペースに関連するすべてのことにそのホストを使用できる。これには、クラスタ、シークレット、リポジトリ、ノートブック、ジョブなどの作成、管理、削除が含まれます。

さて、Databricks on AWSのデプロイにおける各エンドポイントの種類を説明しました。それでは、デプロイプロセスの例を通して、やり取りされる各エンドポイントを呼び出してみましょう。

デプロイ・プロセス：

標準的なデプロイプロセスでは、上記の各エンドポイントとやり取りすることになる。私はこれを上から下に並べ替えたい。

最初のエンドポイントはAWSです。AWSエンドポイントから、Databricksワークスペースのバックボーンインフラを作成します。これには、ワークスペースのルートバケット、クロスアカウントIAMロール、およびVPC、サブネット、セキュリティグループなどのネットワークリソースが含まれます
これらのリソースが作成されたら、DatabricksアカウントAPIにレイヤーを移動し、一連の設定として作成されたAWSリソースを登録します：クレデンシャル、ストレージ、ネットワークです。これらのオブジェクトが作成されたら、それらの構成を使ってワークスペースを作成します。
ワークスペースの作成後、そのエンドポイントを使用してワークスペースのアクティビティを実行します。これには、クラスタやウェアハウスの作成、権限の割り当てなどの一般的なアクティビティが含まれます。

それで終わりだ！標準的なデプロイプロセスは、3つの異なるエンドポイントに分けることができる。しかし、いきなりPUTとGETの呼び出しは使いたくないので、顧客がデプロイメントに使用する一般的なIaC（Infrastructure as Code）ツールについて説明しよう。

よく使われるIaCツール：

上述したように、AWS上でDatabricksワークスペースを作成すると、単に様々なエンドポイントを呼び出すだけです。つまり、このブログポストでは2つのツールについて説明しますが、これらに限定されるわけではありません。

例えば、このブログポストでは AWS CDK については触れませんが、Databricks on AWS のデプロイでも同じコンセプトが適用されるでしょう。

お好きな IaC ツールにビルド済みのリソースがあるかどうかについてご質問がある場合は、Databricks の担当者にお問い合わせいただくか、コミュニティフォーラムに投稿してください。

HashiCorp Terraform:

2014年にリリースされたTerraformは、現在最も人気のあるIaCツールの1つだ。Goで書かれたTerraformは、クラウド環境全体のインフラをデプロイ、破棄、管理するシンプルで柔軟な方法を提供します。

1,320万以上のインストール数を誇るDatabricks providerを使えば、既存のTerraformインフラとシームレスに統合することができます。使い始めるために、Databricksは使用可能な一連のサンプルモジュールを公開しています。

以下が含まれます：

顧客管理キー、VPC、PrivateLink、IPアクセスリストによる複数のAWS Databricksワークスペースのデプロイ - Code
ハブ＆スポークファイアウォールによるAWS Databricksのプロビジョニング - Code
Unity Catalogを使ったDatabricksのデプロイ - Code： Part 1, Part 2

Databricksによって作成された例の完全なリストはこちらをご覧ください。here

Terraformのコード構造のベストプラクティスについてよく質問を受けます。ほとんどの場合、Terraformのベストプラクティスはあなたが他のリソースに使っているものと一致するでしょう。シンプルなmain.tfファイルから始めて、様々な環境に論理的に分離し、最後に各環境で使われる様々な既製のモジュールを組み込み始めることができます。

Picture: The interaction of resources from the Databricks and AWS Terraform Providers — Picture: DatabricksとAWS Terraform Providersのリソースの相互作用

上の画像では、Databricksが管理するVPCでワークスペースを作成する際に、DatabricksとAWSの両プロバイダにある様々なリソースの相互作用を見ることができます。

AWSプロバイダを使用して、IAMロール、IAMポリシー、S3バケット、S3バケットポリシーを作成します。
Databricksプロバイダを使って、IAMロール、IAMポリシー、S3バケットポリシーのデータソースを呼び出す。
これらのリソースが作成されたら、DatabricksプロバイダでバケットとIAMロールをワークスペースのストレージとクレデンシャル構成としてログに記録する。

これは、2つのプロバイダーがどのように相互作用し、これらの相互作用が新しいAWSとDatabricksリソースの追加によってどのように成長しうるかの簡単な例である。

最後に、Terraformしたい既存のワークスペースのために、DatabricksプロバイダはTerraformコードを生成するために使用できるExperimental Exporterを持っています。

Databricks Terraform Experimental Exporter：

Databricks Terraform Experimental Exporterは、Databricksワークスペースの様々なコンポーネントをTerraformに抽出するための貴重なツールです。このツールの特徴は、ワークスペース用のTerraformコードを構造化するための洞察を提供し、そのまま使用したり最小限の修正を加えることを可能にすることです。エクスポートされた成果物は、他の Databricks 環境でオブジェクトや設定を素早くセットアップするために利用できます。

これらのワークスペースは、テストやステージングを目的とした下層環境として利用することもできますし、異なるリージョンに新しいワークスペースを作成するために利用することもできます。

エクスポーターの機能を実演するために、GitHub Actions workflow YAML ファイルの例を用意した。このワークフローは、experimental exporter を使ってワークスペースから特定のオブジェクトを抽出し、ワークフローが実行されるたびに指定した GitHub repository内の新しいブランチにこれらの成果物を自動的にプッシュします。このワークフローは、ソースリポジトリへのプッシュをトリガーしたり、GitHub Actions の cronjob 機能を使って特定の間隔で実行するようスケジュールしたりと、さらにカスタマイズすることができます。

指定された GitHub リポジトリでは、ブランチごとにエクスポートが区別されるため、既存または新規の Databricks ワークスペースにインポートしたい特定のブランチを選択することができます。これにより、エクスポートされた成果物から必要な設定やオブジェクトを簡単に選択し、ワークスペースのセットアップに組み込むことができます。新しいワークスペースをセットアップする場合でも、既存のワークスペースを更新する場合でも、この機能を使用すると、必要なエクスポートを含む特定のブランチを活用できるため、プロセスが簡素化され、Databricks へのインポートがスムーズかつ効率的になります。

これはDatabricks Terraform Experimental Exporterを利用した一例です。その他ご不明な点がございましたら、Databricksの担当者までお問い合わせください。

まとめ: Terraformに慣れている、既存のパイプラインで既に使用している、デプロイプロセスをより堅牢にしたい、マルチクラウドを管理している、などの場合にTerraformはデプロイに最適です。

AWS CloudFormation:

2011年に初めて発表されたAWS CloudFormationは、AWSリソースを料理のレシピのように管理する方法です。

DatabricksとAWSは協力して、CloudFormationを活用したAWS Quick Startを公開しました。この open source codeでは、ネイティブ関数を使用してAWSリソースを作成し、Lambda関数がDatabricksのアカウントとワークスペースのエンドポイントに様々なAPIコールを実行します。

CloudFormationを使用しているお客様には、クイックスタートのオープンソースコードをベースラインとして使用し、チーム固有の要件に応じてカスタマイズすることをお勧めします。

まとめ： DevOpsの経験があまりないチームにとって、CloudFormationはGUIベースでDatabricksのワークスペースをパラメータを指定して素早く立ち上げることができる優れた選択肢です。

Best Practices:

このブログのまとめとして、使用しているツールに関係なく、IaCを使用するためのベストプラクティスについて。

繰り返し、繰り返し：「完璧は善の敵になるな」という古いことわざがある。コンセプトの実証から本番へのデプロイとコードの改良のプロセスには時間がかかるが、それはまったく問題ない！これは、最初のワークスペースをコンソールからデプロイする場合にも当てはまります。
モノリスではなくモジュール： IaCの道を進むにつれ、様々なリソースを個々のモジュールに分割することをお勧めします。例えば、同じクラスタ構成を3つの異なる環境で、完全なパリティで使用することがわかっている場合、このモジュールを作成し、それぞれの新しい環境に呼び出します。同一のリソースを複数作成し、維持するのは負担になります。
より高い環境でのIaC使用量のスケール： IaCは、開発環境、QA環境、本番環境で常に一様に使用されているわけではありません。共有クラスターの作成など、あらゆる場所で使用される共通のモジュールがあるかもしれませんが、開発ユーザーには手動でジョブを作成させ、本番環境では完全に自動化されているかもしれません。一般的な傾向としては、開発環境ではユーザーが自由に作業できるようにし、本番環境に移行したらIaCツールを使ってパッケージ化し、QAや本番環境のような上位環境にプッシュする。これにより、標準化のレベルを維持しつつ、ユーザーにプラットフォームを自由に探索させることができる。
適切なプロバイダー認証： Databricks on AWSのデプロイメントにIaCを採用する場合、アカウントとワークスペースの認証には常にサービスプリンシパルを使用する必要があります。これにより、ハードコードされたユーザー認証情報を回避し、環境ごとにサービスプリンシパルを管理することができます。
集中バージョン管理：前述したように、IaCの統合は反復プロセスです。これはコードのメンテナンスと一元管理にも当てはまります。最初はローカル・マシンからコードを実行するかもしれませんが、開発を続けるうちに、このコードをGitHub、GitLab、BitBucketなどの中央リポジトリに移すことが重要になります。これらのリポジトリとバックエンドのTerraform設定により、チーム全体でDatabricksワークスペースを更新することができます。

結論として、クラウドのデプロイを成功させるには自動化が不可欠であり、AWS上のDatabricksも例外ではない。このブログポストで取り上げた3つのエンドポイントを活用し、自動化のベストプラクティスを実装することで、スムーズで効率的なデプロイプロセスを実現することができます。もしあなたがAWS上にDatabricksをデプロイしようとしているクラウドエンジニアだとしたら、これらのヒントをあなたのデプロイ戦略に組み込み、この強力なプラットフォームが提供するメリットを活用することをお勧めします。