サーバーレスのコスト管理がさらにスマートに

Databricksでは、サーバーレスコンバートの利用が過去1年間で3倍以上に急増し、現在では何千ものお客様が、ミッションクリティカルなノートブック、ジョブ、パイプラインをサーバーレス上で実行しています。導入が進むにつれて、「サーバーレスのコストをより詳細に可視化し、予算内に収めるにはどうすればよいか」という、すべてのプラットフォームチームが最初に尋ねる疑問の声がますます大きくなっています。

サーバーレスSQLおよびModel Servingを実行しているDatabricksのお客様は、クラスタの設定を一切変更することなく、ですでに支出の紐付け、アクセスのガバナンス、および消費量の監視を行っています。私たちは現在、その同じ機能をノートブック、ジョブ、パイプラインのサーバーレスコンバートにも導入しています。プラットフォームチームがすでに期待している通りの方法で、サーバーレスのコスト管理が機能するように取り組んでいます。

サーバーレスがコスト管理を上位レイヤーに移行

従来のコンバートでは、コスト管理はインフラストラクチャ内で行われていました。ユーザーがプロビジョニングできる範囲を制限するために、ノード数、インスタンスタイプ、自動スケーリングの範囲、クラスタポリシーなどのマシンを制限することで支出に上限を設けていました。インフラストラクチャをご自身で管理する必要があったため、これらの制御が必要でした。

サーバーレスでは、それらの設定があえて削除されています。インフラストラクチャのプロビジョニング、スケーリング、および適切なサイズ調整は、現在ではプラットフォーム側の負担となり、Databricksが処理します。これが価値の大きな部分を占めています。しかし、コスト管理はどこかで行う必要があるため、より上位のレイヤーに移行します。マシンに紐づくのではなく、人やワークロードに紐づきます。誰がサーバーレスの実行を許可されているか、ワークロードがどれだけ急速に支出することを許可されているか、そしてコストがどこに帰属するかが、今重要となる問題です。

プラットフォームチームは、自らのニーズを次の3つの方法で説明しています。

• 野放図な支出: クラスタのサイズや自動スケーリングの上限がないため、単一の制限のないノートブックの実行により、1日で何千ドルも費やす可能性があります。
• 不適切な権限: 誰が実行できるかを制御する権利がないため、プロビジョニングすべきではないユーザーを含め、デフォルトですべてのユーザーがサーバーレスを利用できます。
• 説明責任の欠如: チームは、従来のコンバートで行っていたタグの強制がない限り、サーバーレスを採用しないでしょう。

従来のコンバートでは、コストを紐付けるタグ、アクセスを制御する権限、および支出に上限を設けるクラスタサイズ制限という3つのツールでこれらに対応していました。サーバーレスには、これらと同じ3つが必要です。そのうちの2つは現在存在し、3つ目はまもなく登場します。

サーバーレスコスト管理の3つの目的

1. コストの紐付け: サーバーレスDBUがどのチーム、プロジェクト、またはユーザーに属しているかを把握します。
2. アクセスの制御: そもそも誰がサーバーレスを実行できるか、そして何に対して実行できるかを決定します。
3. 支出の制限: 事後ではなく事前に、ワークロードまたはチームがどれだけ/どれほど速く支出できるかに上限を設けます。

これらについて順に詳しく見ていきます。

コストの紐付け

紐付けはタグから始まります。従来のコンバートではクラスタにタグ付けしていましたが、サーバーレスではコンバートにタグ付けし、そのコンバートが実行するすべてのDBUはそのタグを請求まで引き継ぎます。

• Serverless Compute Tags: サーバーレスコンバートオブジェクトに一度タグ付けすると、その上で実行されるワークロードは、維持すべき個別のポリシーオブジェクトなしで、適切なチーム、プロジェクト、またはコストセンターに紐付けられます。
• システムテーブル: すべてのサーバーレスDBUはsystem.billing.usageに格納され、ユーザー別、製品別、タグ別に分類されます。リーダーシップに適した「チーム別コスト」ビューは単一のクエリであり、アカウントコンソールのコストダッシュボードには、SQLを一切記述することなくそれが表示されます。

同じテーブルは、誰かのアクセス権を変更する前に必要となる監査の疑問に答えてくれます。「現在、実際にサーバーレスを実行しているのは誰か、そしてどれくらい支出しているか？」これは消費量順にランク付けされたもう一つのクエリであり、完全な例はシステムテーブルのドキュメントに記載されています。

可用性: 紐付け用のサーバーレスコンバートタグは、現在ベータ版でご利用いただけます。

オブザーバビリティはすでに利用可能であり、お客様はAWS、Azure、およびGoogle Cloud上のシステムテーブルを使用してサーバーレスコストをすでに監視できます。

支出の変動の監視: 予算、アラート、ダッシュボード

コストを紐付けるのと同じシステムテーブルを使用して、コストを追跡することもできます。アカウントコンソールの予算は、サーバーレスの支出が閾値を超えたときにメールアラートを発生させ、コスト管理ダッシュボードでは、製品、ワークスペース、およびタグごとに消費量を追跡できます。昨日のサーバーレス支出に対するSQLアラートにより、数時間以内にループが閉じられます。

ただし、監視はリアクティブです。問題を防ぐのではなく、コストがかかった翌朝にその日を報告します。そのギャップが存在する理由が、次の2つの目的が存在する理由です。

可用性: 監視は現在一般提供されています。AWS、Azure、およびGoogle Cloudで予算と支出アラートを設定します。

アクセスの制御

最初 プロアクティブな制御は、そもそも誰がサーバーレスを実行できるかを決定することです。その付与は権利（エンタイトルメント）です。既存の権利が、誰がクラスタを作成できるか、またはSQLウェアハウスに接続できるかを制御するのと同様に、どのユーザーまたはグループがサーバーレスにアクセスできるかを定義します。Serverless Compute Access Controlsが一般提供されるようになりました。これにより、すべてのワークロードに組み込まれたポリシーではなく、コンバートオブジェクトに対するアクセス許可というモデルでサーバーレスをガバナンスできます。

サーバーレスコンバートオブジェクトは、サーバーレスのアクセス許可の境界です。すべてのワークスペースにはデフォルトで2つ用意されています。

• Default Serverless Interactive Compute: ノートブックとDatabricks Connect。
• Default Serverless Automated Compute: ジョブとSpark Declarative Pipelines。

これらのオブジェクトに対するアクセス許可は、ウェアハウスですでに馴染みのある2つです: Can UseとCan Manage。誰がSQLウェアハウスにアタッチできるかを判断できるのであれば、誰がサーバーレスを実行できるかも判断できます。

このモデルはデフォルトで安全です。すべてのユーザーがCan Useから開始するため、管理者が操作するまで、機能をオンにしても何も変わりません。管理者が実際に操作する場合、フローは予想通りのものになります。コンバートページを開き、[Serverless]タブに移動し、デフォルトのコンバートオブジェクトを開き、「All Users」を削除し、特定のグループを追加します。そのグループ外のユーザーには、ノートブックのコンバート選択でサーバーレスがグレーアウトされて表示されるようになり、すでに実行されていたものは一切中断されません。

可用性: 現在一般提供されています。AWS、Azure、およびGoogle Cloudのドキュメントをご覧ください。

支出制限の設定

アクセス制御はワークロードを実行するかどうかを決定するものであり、実行後にどれだけ支出できるかを決定するものではありません。そのギャップを埋めるのが3つ目のタスクであるレート制限であり、先ほど確認したのと同じコンバートオブジェクトに適用されます。

• 自動化されたワークロードのレート制限: Tシャツサイズ（S、M、L、XL）として表現されるコンバートごとの制限により、実行できるかどうかだけでなく、ジョブやパイプラインがどれだけ、またはどれほど速く支出できるかに上限を設けます。管理者はカスタムコンバートオブジェクトを作成し、チームごとに共有することで、各チームに独自の制限を与えることができます。これは、サーバーレスに移植された従来のクラスタポリシーパターンです。
• インタラクティブ向けの共有予算（近日公開）: 多くの「Medium」セッションが累積するため、セッションごとの上限だけではチームの予算を保護できません。私たちの方向性は、その下にあるガードレールとしてのセッションごとの最大値とともに、グループ全体の共有制限を設定することです。

同時にアトリビューションも向上します。serverless_compute_id 内の新しい system.billing.usage により、コンピュートオブジェクトごとのコストが算出されるため、「チームごとのコスト」と同様に「コンピュートオブジェクトごとのコスト」を簡単に把握できるようになります。

DBSQLのサイズ（S、M、Lなど）をご存知の方への補足として、ノートブックやジョブの場合、サイズは固定のクラスターサイズではなく、自動スケーリングの上限となります。Mediumのみが必要なジョブに対してXLを選択した場合でも、Mediumが割り当てられます。

提供状況: レート制限がベータ版でご利用いただけるようになりました。Databricksのプレビュー設定からレート制限を有効にしてください。ドキュメントについては、AWS、Azure、Google Cloud をご覧ください。

全体像

3つのジョブを組み合わせます：

• コストの配分: サーバーレスコンピュート上のネイティブタグと、システムテーブル内の serverless_compute_id。予算やダッシュボードで使用できます。
• アクセス制御: サーバーレスコンピュートオブジェクトに対する権限設定。
• コスト制限: レート制限。グループ全体で共有され、ワークロードごとに制限されます。

今すぐ始めましょう

サーバーレスのコスト制御の導入を今すぐ始めることができます。手順は以下の通りです：

1. タグの適用を有効化: 他の何よりも先にアトリビューションが機能するように、サーバーレスコンピュートにタグ付けを行います。
2. モニタリングの設定: system.billing.usage 上にコストダッシュボードを追加し、サーバーレスの利用料金に対する予算アラートを設定します。
3. 現在サーバーレスを実行しているユーザーの監査: アクセス権を変更する前に影響範囲を把握できるようにします。
4. アクセスポリシーの決定: インラクティブなサーバーレスの実行を許可するユーザーと、自動化された処理を実行するユーザーを決定します。
5. サーバーレスコンピュートアクセス制御の有効化: 選択したグループに対して、高速でフルマネージドなコンピュートを有効にします。

サーバーレスコンピュートアクセス制御は現在一般提供（GA）されています。アトリビューションとモニタリングについてさらに詳しく知るには、システムテーブル（AWS | Azure| GCP）およびサーバーレスのタグ付け（AWS | Azure | GCP）のドキュメントから始めるのが最適です。

詳細情報:

• AWS でのサーバーレスコンピュートの管理 | Azure | GCP
• サーバーレスコンピュートへの接続 | AWS上の Databricks
• サーバーレスコンピュートへの接続 - Azure Databricks
• Databricks のコスト管理ツール - Azure Databricks
• ペタバイト規模のサーバーレスコンピュート：最新のリリース、ロードマップ、移行
• インフラストラクチャを減らし、インパクトを拡大：Nationwideによるサーバーレス移行

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事