クラウドデータウェアハウスのコストに対する予算とアラートの設定

すべての分析チームがこのような経験をしたことがあるはずです。月末の請求書が届き、単一の SQL ウェアハウスが予算を大幅に超過していることに気づきます。コンピュートが一晩中実行されたままになっていたのかもしれませんし、四半期レビュー中に80人の Tableau ユーザーに対応するためにアドホックなウェアハウスが自動スケーリングされたのかもしれません。コストの発生は現実ですが、さらに深刻なのは、手遅れになるまで誰もそのことに気づかなかったというフラストレーションです。

プロアクティブなコスト管理はこのモデルを覆します。事後になってから請求書を細かく分析する代わりに、1ドルも消費される前にガードレールを設定します。予算はウェアハウス、チーム、または BI ワークロードに関連付けられます。選択したしきい値でトリガーされるアラートや、使用状況のトレンドをリアルタイムで可視化するダッシュボードは、すべて  Databricks Data & AI Platform。オンプレミスシステムや他のクラウドデータウェアハウスからの移行の途中であれば、今こそそのガバナンスを導入すべきタイミングです。

リアクティブなコスト管理が失敗する理由

データウェアハウスのワークロードには、特有のコスト課題があります。SQL ウェアハウスは、需要が予測不可能で一時的に急増する（バースト性の高い）、インタラクティブで人間主導のワークロード（BI ダッシュボード、アドホック分析、組み込み分析）を処理します。役員全員が参加する1回の全社会議で200のダッシュボードが同時に更新されるだけで、コストは数分で急増します。ほとんどの組織は、同じ方法で FinOps の取り組みを開始します。誰かが先月の使用状況の CSV をダウンロードし、ピボットテーブルを開いて、原因を探し始めます。このアプローチが破綻する理由は4つあります。

• 誰が消費しているのかが見えない。使用量はプラットフォーム全体で集計され、それを引き起こしたチームやクエリごとには集計されないため、誰もその数値に責任を持つことができません。
• 誰も予算を所有していない。ウェアハウスやチームに紐づいた支出目標がないため、2 TB のテーブルに対して SELECT * を実行しているアナリストはコストを意識することがありません。プラットフォームチームが静かにそれを吸収することになります。
• 発覚が遅すぎる。先月の Excel レポートで予算超過が明らかになったときには、すでに2回の請求サイクルが経過しており、その原因となった決定は追跡できなくなっています。
• 手動でのレビューはスケールしない。5つのウェアハウスであれば、毎月のピボットテーブルによるレビューで対応できるかもしれません。しかし、数十規模にスケールし、Tableau、Power BI、Looker を使用する数百人のアナリストをサポートするようになると、管理は不可能になります。

プロアクティブなコスト管理（アトリビューション、予算、アラート、ダッシュボード、最適化）は、これら5つすべてに対処します。

サーバーレスから始める：最初のコスト決定

予算を設定する前に、適切なウェアハウスタイプを選択しましょう。 SQL Serverless ウェアハウスは、ほとんどのワークロードにおいて Databricks が推奨するオプションです。数秒で起動し、クエリが終了した瞬間にスケールダウンします。また、インテリジェントなワークロード管理機能がコンピュートを自動的に割り当てるため、アイドル状態の待機時間ではなく、実際のクエリ実行に対してのみ料金を支払うことになります。

レガシーなクラウドデータウェアハウスから移行する場合、これは大きな転換となります。ほとんどのレガシーなプラットフォームは、常時起動のコンピュートに対して課金するか、手動でのスケーリング決定を必要とします。サーバーレスは、この種のコストに関するミスを完全に排除します。

Lumen Technologiesはこれを身をもって実感しました。2つの不可欠な通信システムをオンプレミスのデータウェアハウスから SQL Serverless に移行したことで、コンピュートコストが30〜40%削減され、クエリ速度が90%向上しました。現在、システムは10分ごとに約 7 GB を処理するために自動的にスケールし、サーバーレスによって、バースト性の高いリアルタイムワークロードにありがちな「常時起動コスト」が排除されています。

プロアクティブなコスト管理の5つの柱

このフレームワークは5つの柱で構成されています。最初の4つは支出を可視化するもので、5つ目は実際に支出を削減するものです。

• コストアトリビューション。すべてにタグを付け、誰がどのウェアハウスでいくら消費したかを把握できるようにします。
• 予算。アカウント、ワークスペース、またはチームレベルで月間の支出目標を定義します。
• アラート。支出がしきい値に近づくか、それを超えた瞬間に通知を受け取ります。
• ダッシュボード。ウェアハウスのトレンドを可視化し、コストを最優先の運用メトリクスにします。
• 最適化。 そもそも作業にかかるコストを削減します。

第1の柱：2つのレベルでのコストアトリビューション

アトリビューション（帰属）を特定できないものは管理できません。ウェアハウスにおいては、ウェアハウス自体と個々のクエリという2つのレベルを意味します。一方はどのウェアハウスがコストを消費したかを示し、もう一方はそのウェアハウス内で誰が消費したかを示します。

レベル1：ウェアハウスのタグ付け

SQL ウェアハウスは、system.billing.usage に伝播する key:value ペアとしてのカスタムタグをサポートしており、消費されたすべての DBU をチーム、プロジェクト、またはコストセンターに関連付けます。タグ付けは、すべてのウェアハウスタイプ（Classic、Pro、Serverless）で同じように機能し、すべてウェアハウスレベルでタグ付けされるため、1つのパターンを覚えればどこにでも適用できます。

UI の SQL Warehouses > 該当のウェアハウス > Edit > Tags でタグを設定するか、REST API を使用してウェアハウスを作成します。

REST API によるタグ付け

少なくとも3つのディメンションを適用します。チーム（所有者）、コストセンター（支払者）、ユースケース（BI サービング、アドホック、スケジュールされた更新）です。

現在、ウェアハウスのタグを強制するネイティブなポリシーはないため、誰でもタグのないウェアハウスを作成できます。代わりに、プロビジョニングプロセスに強制力を組み込んでください。Terraform、Declarative Automation Bundles、または定義内にタグを含めた REST API を使用してウェアハウスを作成し、UI での作成は例外として扱います。この記事の後半で紹介するアトリビューションギャップのクエリを使用すれば、見落とされたものをキャッチできます。

レベル2：クエリのタグ付け

ウェアハウスのタグは、先月ウェアハウスに4,000ドルかかったことを教えてくれます。しかし、その60%が15分ごとに更新される単一の Power BI ダッシュボードによるものであることは教えてくれません。ウェアハウスは共有されるため、このギャップは重要です。1つの BI ウェアハウスが、数十のダッシュボード、いくつかの dbt モデル、そして一連のアドホッククエリを処理しています。

クエリタグ（パブリックプレビュー）は、個々の SQL ステートメントにビジネスコンテキストを付加することで、このギャップを埋めます。

タグは、executed_by や statement_id と並んで、system.query.history（パブリックプレビュー）の query_tags 列に格納されるため、ウェアハウスごとではなく、ダッシュボード、モデル、またはコストセンターごとに支出をグループ化できます。一部のツールではこれらが自動的に設定されます。例えば、dbt-databricks 1.11.0 以降では、モデルクエリに dbt モデル名が自動的にタグ付けされ、Power BI は ADBC ドライバーを介してワークスペースとデータセットの識別子を渡します。

2つの注意点があります。クエリタグはSQLウェアハウスのクエリにのみ適用されること、そしてこれらは課金データではなくクエリ履歴に保存されるため、クエリごとのコストを把握するにはこれら2つをご自身で結合する必要があることです。

SQLを記述する前に、Governance Hub（ベータ版）の「コスト（Cost）」ページを確認してください。これは、支出、コスト要因、予算、タグ付けのカバー率をアカウントレベルで表示するもので、使用量のうちどれだけが追跡可能であるかを最も素早く確認できる方法です。アカウント管理者は、アカウントコンソールの「プレビュー（Previews）」ページからこれを有効にできます。

ピラー2：アカウントコンソールでの予算設定

予算の作成

アカウントコンソールで、Usage（使用量）> Budgets（予算）に移動し、Add budget（予算の追加）をクリックして、以下を設定します。

• Name（名前）：わかりやすい名前（例：「Analytics SQL Warehouses, Monthly」）
• Amount（金額）：USDでの月間目標額
• Scope（スコープ）：ワークスペースやタグでフィルタリング（例：Team:Analytics）
• Email notifications（メール通知）：支出が予算額に達したときに通知を受け取る受信者

予算設定の例

重要なパターンは、階層化された予算です。説明責任を果たすためのチームレベルの予算に加えて、漏れを防ぐセーフティネットとしてのアカウント全体の予算を設定します。

予算は監視メカニズムであり、ハードリミット（強制制限）ではないことに注意してください。使用を停止したり課金を防いだりするものではないため、請求額が予算を超えることもあります。目的は、状況を把握して迅速に対応することであり、更新の途中で本番環境のダッシュボードを破損させるような強制シャットダウンではありません。

GetYourGuideはこれを直接検証しました。すべてのLookerワークロードをSQL Serverlessに統合したところ、チームはClassicクラスターの方が安価になると予想していたにもかかわらず、BIサービングコストが約20%削減され、クエリが35%高速化しました。ウェアハウスタイプの選択は、一度決めたら終わりではなく、再検証する価値のある予算上の意思決定です。

バーンレートの読み取り

いずれかの予算をクリックすると、現在の支出と目標の比較、残りの予算、および日ごとのバーンレートの視覚化チャートが表示されます。データウェアハウジングにおいて、このチャートは特に多くのことを示してくれます。

• 直線的な日次バーン：BIサービングコストが安定していることを意味します。
• 月曜・金曜にスパイクが発生する鋸歯状（のこぎり刃状）：平日を中心にアドホックな探索が集中していることを示します。
• 月半ばの急激なステップアップ：コストレビューを行わずに新しいダッシュボードがデプロイされたことを意味します。
• 緩やかな上昇傾向：自然な導入拡大が予算の想定を上回っていることを意味します。

ピラー3：アラート、コストガバナンスの神経系

予算は現在の状況を教えてくれます。アラートは行動すべきタイミングを教えてくれます。

予算のメールアラート

予算を作成する際、支出が予算額を超えたときに通知を受け取るメール受信者を追加します。コードは一切不要です。

しきい値に基づくアラートを設定するには、`system.billing.usage`を直接クエリするDatabricks SQL Alertsを作成します。最も重要なパターンは以下のとおりです。

日次のSQLウェアハウス支出がしきい値を超えたときにアラートを送信する

ペース調整アラート：月末の予測支出が予算を超える場合

これは、チームが最も価値を実感できるパターンです。予算を超過した後にアラートを出すのではなく、月末の支出を予測し、その予測が予算を超える前（まだ対応する時間があるうち）にアラートをトリガーします。

これを4時間ごとにスケジュールし、Slackまたはメールにルーティングします。これにより、予算が超過する数日前に、チームが対応（ウェアハウスの適切なサイズへの変更、高コストなクエリの最適化、バッチ処理の延期など）を行う猶予が生まれます。

マテリアライズドビューの更新による隠れたコストを検出する

マテリアライズドビューの更新コストは、ウェアハウスの使用量ではなくサーバーレスパイプラインの使用量として課金されるため、チームが最も見落としがちなコストです。1日に2回しか更新されないソースに対して15分ごとに更新するように設定されたビューは、何のメリットもないまま差分コストを消費します。更新スケジュールを基になるデータが実際に変更される頻度に合わせてから、パイプラインの支出を直接監視してください。

ピラー4：ダッシュボードと継続的な監視

アラートは特定の時点におけるトリガーです。ダッシュボードは継続的なコンテキストを提供します。Databricksは、アカウント管理者がUnity Catalogが有効な任意のワークスペースにインポートできる、事前構築済みの使用状況ダッシュボードを提供しています。これらには、支出トレンド、Top-N分析、タグフィルタリング、ウェアハウスごとのドリルダウンが含まれます。カスタムモニタリングには、特に次の2つのクエリが役立ちます：

チームごとのSQLウェアハウスコスト

割り当てのないSQL使用状況（アトリビューションギャップ）

タグ付けされていないSQL使用状況はアトリビューションギャップであり、どのチームにも追跡できないウェアハウス支出です。これをゼロにしましょう。

Raiffeisen Bank Internationalは、Databricksのシステムテーブル上に直接、ウェアハウスごと、ユーザーごと、ワークロードごとの可視性を備えた独自のコスト監視・予測プラットフォームを構築しました。その成果は技術的なものだけでなく、文化的なものでもありました。ワークロードが3〜4倍高速化されただけでなく、さらに重要なことに、チームが自らの支出を可視化し、その説明責任を持つようになると、強制されることなく行動が変化したのです。

柱5：最適化（実際に請求額を変化させる柱）

最初の4つの柱は、支出を可視化することに関するものでした。この柱は支出を削減することに関するものであり、多くのチームが見落としがちな部分です。コストとパフォーマンスを同時に改善する2つの変更から始めましょう。

Unity Catalog管理テーブルの予測最適化を有効にします。Databricksは、各テーブルが実際にどのようにクエリされているかに基づいて、OPTIMIZE、VACUUM、およびANALYZEを自動的に実行します。また、CLUSTER BY AUTOにより、クエリパターンの変化に合わせてクラスタリングキーを調整します。スキャンされるデータ量が減ることで、クエリが高速化し、DBU消費も削減されます。メンテナンススケジュールを管理する必要もありません。これは2024年11月11日以降に作成されたアカウントではデフォルトで有効になっており、それ以前のアカウントにも2026年にかけて順次適用されます。

前述した起動時およびアイドル時の経済的メリットを得るために、デフォルトでサーバーレスウェアハウスを使用します。ほとんどのチームにとって、これが継続的な労力をかけずに最大の節約効果を得る方法です。

そこから、いくつかの設定をチューニングする価値があります：

• 自動停止時間を短縮します。ProおよびClassicは停止までに45分間のアイドル時間が必要ですが、サーバーレスはデフォルトで10分です。UIから5分に、またはAPIを介して1分に短縮できます。最後のダッシュボードが閉じた後、BIウェアハウスがアイドル状態になっている時間はすべて無駄になります。
• ステートメントのタイムアウトを設定します（ベータ版 — プレビューを有効にし、APIを介してウェアハウスごとに設定します）。1つの暴走クエリによって週末のコンピュートリソースが浪費されるべきではありません。BIウェアハウスでは短く設定し、ETLでは長めに設定します。
• デフォルトのウェアハウス（管理設定 > コンピュート）を指定して、10行のデータをすばやく確認するだけでETLサイズのクラスターが起動しないようにします。また、過剰なプロビジョニングを避け、SmallまたはMediumから開始します。
• 目的を持ってスケールアップまたはスケールアウトを行います。スケールアップ（より大きなサイズ、現在は5X-Large（パブリックプレビュー）まで対応）は単一の重いクエリを高速化し、スケールアウト（最大クラスター数の増加）はより多くの同時実行ユーザーに対応します。誤った方法を選択することは、よくある、そしてコストのかかる間違いです。

データレイヤーも重要です。 OPTIMIZE、 VACUUM、そして liquid clusteringは、それぞれクエリに必要なコンピュートリソースを削減し、その効果は1日あたり数千件のBIクエリ全体で累積されます。

根本的には、ほとんどのコスト問題はクエリの問題です。結合キーの欠落や、列数の多いテーブルに対する SELECT * の実行は、ウェアハウスをどのようにチューニングしても同じコストがかかります。そして、どのクエリやダッシュボードを修正すべきかを教えてくれるのが、柱1のアトリビューションです。

主なまとめ

1. 初日からサーバーレスとアトリビューションをプラットフォームに組み込む。即時の起動、自動スケーリング、アイドル時間のコストゼロを実現するために、デフォルトでSQL Serverlessウェアハウスを使用します。また、最初からカスタムタグを強制します。割り当てのない使用状況は可視化されず、可視化されない使用状況は常に増加するためです。

2. 複数のレベルでプロアクティブに予算を設定し、アラートを通知する。説明責任を果たすためのチームごとの予算と、異常を検知するためのアカウント全体の予算を組み合わせます。また、単なるしきい値だけでなく、消費ペースに基づいてアラートを設定することで、予算超過が発生した後ではなく、対処する時間があるうちに超過の兆候を把握できます。

3. 支出を可視化し、それを文化にする。 最も持続可能な節約は、制限からではなく透明性から生まれます。そのため、チームが作業する場所にコストダッシュボードを配置します。RBIが実証したように、チームが自らの支出を可視化できるようになると、強制されることなく行動が変化します。

はじめに

• 最初の予算を作成する（アカウントコンソール内） 
• SQLウェアハウスとクエリにタグを付けて使用状況を割り当てる
• システムテーブルでコストを監視する、system.billing.usageをクエリしてウェアハウス固有のインサイトを取得する
• SQLウェアハウスのサイジングとスケーリングの動作、IWMとサーバーレスの経済的メリットを理解する
• コスト最適化のベストプラクティス、ウェアハウスのサイジング、Photon、および Delta Lake の最適化
• カオスからコントロールへ：Databricksによるコスト成熟への道のり、FinOps成熟のためのcrawl-walk-runフレームワーク

クラウドデータウェアハウスのコストを管理する準備はできましたか？Databricksの無料トライアルアカウントを設定し、最初のSQL Serverlessウェアハウスを作成して、アカウントコンソールで電子メールアラート付きの予算を設定しましょう。5分で完了し、費用はかかりません。

コストの可観測性について詳しく知るには、課金システムテーブルのドキュメントを参照し、事前構築済みの使用状況ダッシュボードをインポートして、初日から支出の監視を開始してください。

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