コスト最適化のベストプラクティス

これらのベストプラクティスは、ワークロードにリソースを合わせ、Databricks での費用を制御するのに役立ちます。これらは次のセクションのアーキテクチャ原則によって整理されています。

1. 最適なリソースを選択する

パフォーマンスが最適化されたデータ形式を使用する

Databricks Data + AI プラットフォームを最大限に活用するには、ストレージフレームワークとして Delta Lake を使用する必要があります。よりシンプルで信頼性の高い ETL パイプラインの構築を支援し、Parquet、ORC、JSON を使用する場合と比較してワークロードを大幅に高速化できる多くのパフォーマンス強化機能が備わっています。Databricksにおける最適化の推奨事項を参照してください。ワークロードがジョブコンピュートでも実行されている場合、これはコンピュートリソースの稼働時間の短縮に直結し、コスト削減につながります。

ジョブ コンピュートの活用

ジョブは、 Databricksインスタンス上で非対話型コードを実行する方法です。 たとえば、抽出、変換、ロード (ETL) ワークロードを対話形式で、またはスケジュールに従って実行できます。 もちろん、ノートブック UI でジョブをインタラクティブに実行することもできます。 ただし、ジョブ コンピュートでは、非対話型ワークロードのコストは、汎用コンピュートよりも大幅に低くなります。 Jobs コンピュート と 汎用 コンピュート を比較するには、価格概要を参照してください。

一部のジョブには、各ジョブを新しいコンピュート インスタンスで実行できるため、ワークロードが相互に分離されるという利点もあります。 ただし、マルチタスク ジョブでは、すべてのタスクに対してコンピュート リソースを再利用することもできるため、コンピュートの起動時間はジョブごとに 1 回だけ発生します。 「ジョブのコンピュートの設定」を参照してください。

SQLウェアハウスをSQLワークロードに使用する

対話型 SQL ワークロードの場合、 Databricks SQL ウェアハウス は最もコスト効率の高いエンジンです。 価格の概要をご覧ください。すべてのSQLウェアハウスにはデフォルトでPhotonが付属しており、既存のSQLおよびデータフレーム API呼び出しを高速化し、ワークロードあたりの全体的なコストを削減します。

さらに、サーバレス SQLウェアハウスは、多数のクエリを迅速かつコスト効率よく処理する Databricks SQL サーバレスの機能を強化する一連の機能であるインテリジェントワークロード管理 (IWM) をサポートしています。

ワークロードに最新のランタイムを使用する

Databricks プラットフォームには、データ エンジニアリング タスク (Databricks Runtime) または機械学習タスク (Databricks Runtime for Machine Learning) に最適化されたさまざまなランタイムが用意されています。ランタイムは、タスクに最適なライブラリの選択肢を提供し、提供されるすべてのライブラリが最新であり、最適に連携するように構築されています。 Databricks ランタイムは定期的にリリースされ、メジャー リリース間でパフォーマンスが向上します。 これらのパフォーマンスの向上は、多くの場合、コンピュート リソースのより効率的な使用によるコスト削減につながります。

適切なワークロードにのみGPUを使用する

GPU を搭載した仮想マシンは、ディープラーニングの計算を劇的に高速化できますが、CPU のみのマシンよりも大幅に高価です。 GPU インスタンスは、GPU アクセラレーションライブラリを持つワークロードにのみ使用してください。

ほとんどのワークロードは GPU アクセラレーション ライブラリを使用しないため、GPU 対応インスタンスのメリットは得られません。 ワークスペース管理者は、不要な使用を防ぐために GPU マシンとコンピュートリソースを制限できます。 ブログ記事GPU は本当に高価ですか? Databricks クラスターでの推論用 GPU のベンチマークを参照してください。

ワークロードにサーバレス サービスを使用する

BI の使用例

BI ワークロードは通常、データをバーストして消費し、複数の並列クエリを生成します。 たとえば、BIツールを使用している人は、ダッシュボードを更新したり、クエリを書いたりして、プラットフォームとそれ以上のやり取りをせずに結果を分析することができます。 このシナリオでは、データ プラットフォームは次のことを行います。

• アイドル状態のコンピュート リソースを終了して、コストを節約します。
• ユーザーが BI ツールを使用して新しいデータまたは更新されたデータを要求したときに、コンピュート リソースをすばやく提供します。

非サーバレス Databricks SQL ウェアハウスの起動時間は分であるため、多くのユーザーは高いコストを受け入れ、アイドル期間中に終了しない傾向があります。 一方、 サーバレス SQLウェアハウス は数秒で起動およびスケールアップするため、即時の可用性とアイドル終了の両方を実現できます。 これにより、優れたユーザーエクスペリエンスと全体的なコスト削減が実現します。

さらに、サーバレス ウェアハウス SQLウェアハウスは、非サーバレス ウェアハウスよりも早くスケールダウンするため、コストが削減されます。

MLモデルとAIモデルのサービング

ほとんどのモデルは、Web アプリケーションまたはクライアント アプリケーションに統合するための REST API として機能します。モデルサービング サービスは、時間の経過と共にさまざまな要求を受け取り、モデルサービング プラットフォームは常に十分なリソースを提供する必要がありますが、実際に必要な数 (アップスケーリングとダウンスケーリング) のみを提供する必要があります。

モデルサービングはサーバーレス コンピュートを使用し、モデルを展開するための高可用性と低遅延のサービスを提供します。 このサービスは、需要の変化に応じて自動的にスケールアップまたはスケールダウンするため、インフラコストを削減しながらレイテンシー性能を最適化します。

適切なインスタンスタイプを使用してください

最新世代のクラウドインスタンスタイプを使用すると、最高のパフォーマンスと最新の機能が提供されるため、ほとんどの場合、パフォーマンス上のメリットが得られます。

たとえば、Graviton2 ベースの Amazon EC2 インスタンスは、同等の Amazon EC2 インスタンスよりも大幅に優れたコストパフォーマンスを提供できます。

ワークロードに基づいて、最適なパフォーマンス/価格比を得るために適切なインスタンスファミリーを選択することも重要です。 いくつかの簡単な経験則は次のとおりです。

• ML、負荷の高いシャッフル、スピルのワークロードに最適化されたメモリ
• 構造化ストリーミング ワークロードとメンテナンス ジョブ (最適化や vacuumなど)に最適化されたコンピュート
• キャッシングの恩恵を受けるワークロード(アドホック解析や対話型データ分析など)に最適化されたストレージ
• 特定のMLおよびDLワークロード向けに最適化されたGPU
• 特定の要件がない場合の汎用

最も効率的なコンピュートサイズを選ぶ

Databricks では、ワーカーノードごとに 1 つのエグゼキューターを実行します。そのため、エグゼキューターとワーカーという用語は、Databricks アーキテクチャのコンテキストでは同じ意味で使用されます。 クラスターサイズはワーカー数の観点からよく考慮されますが、他にも考慮すべき重要な要素があります。

• エグゼキューターコア(コンピュート)の合計数: すべてのエグゼキューターのコアの合計数。 これにより、コンピュート・インスタンスの最大並列処理が決まります。
• 総エグゼキューターメモリ容量: すべてのエグゼキューターのRAMの合計容量。これにより、ディスクにスピルする前にメモリに格納できるデータの量が決まります。
• エグゼキューターローカルストレージ: ローカルディスクストレージのタイプと容量。ローカルディスクは、主にシャッフルおよびキャッシュ中にデータがスピルした場合に使用されます。

その他の考慮事項には、ワーカーインスタンスのタイプとサイズが含まれ、これらも前述の要因に影響します。 コンピュートのサイズを設定するときは、次の点を考慮してください。

• ワークロードのデータ消費量
• ワークロードの計算の複雑さはどの程度ですか?
• データの読み取り先
• 外部ストレージでのデータのパーティション方法
• 必要な並列処理量

詳細と例については、 コンピュートのサイズに関する考慮事項を参照してください。

導入時の適切なサイズのコンピュート リソース

導入時にコンピュートのサイジング基準とポリシーを確立し、コスト効率の高いリソースの割り当てを確保します。

さまざまなワークロードタイプに対応したクラシックなコンピュートのサイジング

• 開発/テスト : シングルノードまたはオートスケールを備えた小規模なクラシック コンピュート (2 ～ 4 ワーカー)。
• バッチETL : メモリ最適化インスタンスとオートスケールが有効になっているミディアム クラシック コンピュート (8-16 ワーカー)。
• ストリーミング : 可変スループット用のオートスケールを備えた小規模から中規模のクラシック コンピュート (4-8 ワーカー)。
• 機械学習 ：モデルとデータ量に基づいてサイズが決定されるGPUインスタンス。

SQLウェアハウスのサイジング : 並列ユーザー数とクエリの複雑さに基づいてSQLウェアハウスのサイズを設定します。 小規模または中規模のウェアハウスから始めて、オートスケールを有効にします。 即時起動と自動スケーリングにはサーバレスSQLウェアハウスを使用します。

コスト管理のためのクラシック コンピュート ポリシー : サイジング基準を強制し、高価なインスタンス タイプを制限し、オートスケールを要求し、最大ワーカー数を設定するためのクラシック コンピュート ポリシーを作成します。 標準化されたコンピュート構成のために、T シャツのサイズ ポリシー (つまり、Small、Medium、または Large) を定義します。

コンピュートのサイジング テーブル、 SQLウェアハウスの構成、および従来のコンピュート ポリシーの詳細な例については、 「デザイン クラスターのサイジング戦略」を参照してください。

パフォーマンスが最適化されたクエリエンジンを評価する

Photonは、Databricks SQLデータフレームAPIワークロードを高速化し、 呼び出し (データ取り込み、ETL 、ストリーミング、データサイエンス、対話型クエリ) を高速化する、高パフォーマンスの ネイティブ ベクトル化クエリ エンジンです。Photon は Apache Spark APIと互換性があるため、コードの変更やロックインは不要で、電源を入れるのと同じくらい簡単に開始できます。

観察された高速化は大幅なコスト削減につながる可能性があり、定期的に実行されるジョブは、Photonで高速であるだけでなく、安価であるかどうかを評価する必要があります。

2. リソースを動的に割り当てる

オートスケーリングのコンピュートを使用する

オートスケールでは、Databricksはジョブの特性に応じてワーカーをアカウントに動的に再割り当てします。パイプラインの特定の部分は他の部分よりも計算量が多い場合があり、Databricks はジョブのそれらのフェーズで追加のワーカーを自動的に追加します (不要になったら削除します)。オートスケールは、静的なサイズのコンピュートインスタンスと比較して、全体的なコストを削減できます。

構造化ストリーミングワークロードのクラスターサイズをスケールダウンする場合、コンピュートの自動スケーリングには制限があります。Databricksは、ストリーミングワークロードにはLakeFlow Pipelinesと強化されたオートスケールを使用することを推奨しています。

自動終了を使う

Databricks には、アイドル状態のリソースを減らし、コンピュート リソースをデプロイできるタイミングを制御することで、コストを制御するのに役立ついくつかの機能が用意されています。

• すべてのインタラクティブ コンピュート リソースの自動終了を構成します。 指定したアイドル時間が経過すると、コンピュート リソースはシャットダウンします。 自動終了を参照してください。
• コンピュートが営業時間中のみ必要なユースケースでは、コンピュート リソースを自動終了で構成でき、スケジュールされたプロセスで、ユーザーがデスクトップに戻る前の朝にコンピュート (および必要に応じてプレウォーム データ) を再起動できます。 CACHE SELECTを参照してください。
• コンピュートの起動時間が長すぎる場合は、クラスター プールの使用を検討してください ( 「プールのベスト プラクティス」を参照してください)。 Databricks プールは、アイドル状態ですぐに使用できるインスタンスのセットです。アイドル状態のインスタンスを使用してクラスターノードを作成すると、クラスターの開始時間と自動スケーリング時間が短縮されます。 プールにアイドル状態のインスタンスがない場合、プールは、クラスターの要求に対応するために、インスタンス プロバイダーから新しいインスタンスを割り当てることで拡張されます。

Databricks は、インスタンスがプールでアイドル状態の間、 Databricks ユニット (DBU) を請求しないため、コストが削減されます。 インスタンスプロバイダーの請求は適用されます。

コンピュート ポリシーを使用してコストを管理する

コンピュート ポリシーは、コンピュート リソースに対して多くのコスト固有の制限を適用できます。 オペレーショナル エクセレンス - コンピュート ポリシーの使用を参照してください。例えば：

• クラスターのオートスケールを、ワーカー ノードの最小数を設定して有効にします。
• 適切な値 (1 時間など) で クラスター自動終了 を有効にして、アイドル時間の支払いを回避します。
• コスト効率の高い VM インスタンスのみを選択できるようにします。クラスター構成のベスト プラクティスに従います。「クラシック コンピュート構成のベストプラクティス」を参照してください。
• スポットインスタンス戦略を適用します。

3. コストの監視と管理

Databricks のコスト管理は、パフォーマンスを維持しながらクラウドの支出を最適化するための重要な側面です。このプロセスは、次の 3 つの主要な領域に分けることができます。

• 設定
• モニタリング
• 管理

次のベスト プラクティスは、これら 3 つの領域をカバーしています。

コストアトリビューションのタグ付けを設定する

一般的なコストを監視し、 Databricks 使用量を組織のビジネスユニットやチームに正確に帰属させるために (たとえば、組織内のチャージバックの場合)、 ワークスペース、クラスター、 SQLウェアハウス、プールにタグを付けることができます。

セットアップフェーズでは、組織は効果的なタグ付けプラクティスを実装する必要があります。これには、組織全体でタグの命名規則を作成することが含まれます。特定のユーザーグループに使用状況を帰属させる一般的なタグと、ロール、製品、サービスなどに基づいて非常に具体的な知見を提供するより詳細なタグの両方を使用することが重要です。

Databricks の使用開始からタグ付けを開始します。Databricksによって設定されたデフォルト タグに加えて、少なくとも、カスタム タグ _Business Units_ と _Projects_ を設定し、特定の組織に入力します。開発コスト、品質保証コスト、本番運用コストを区別する必要がある場合は、タグ Environment をワークスペースとコンピュート リソースに追加することを検討してください。

タグは、コスト分析のために使用状況ログと クラウド プロバイダー リソース の両方に伝達されます。合計コストには、 Databricks ユニット (DBU) に加えて、仮想マシン、ディスク、および関連するネットワークのコストが含まれます。サーバレス サービスの場合、 DBU コストにはすでに仮想マシンのコストが含まれていることに注意してください。

タグの追加は将来の使用にのみ影響するため、より詳細なタグ付け構造から始めることをお勧めします。タグが時間の経過とともに実用化され、コストの理解とアトリビューションに影響を与えないことが示された場合は、タグを無視することは常に可能です。ただし、欠落しているタグを過去のイベントに追加することはできません。

予算とアラートを設定して、アカウントの支出のモニタリングを有効にする

予算を設定すると、アカウント全体の使用状況を監視できます。財務目標を設定する方法を提供しており、アカウント全体の支出を追跡すること、または特定のチーム、プロジェクト、ワークスペースの支出を追跡するためにフィルターを適用することができます。アカウントがサーバレス コンピュートを使用している場合は、必ず使用量ポリシーを使用してアカウントのサーバレス使用量を按分してください。利用ポリシーでのサーバレス使用の属性を参照してください。

予期しない支出を避けるために、毎月の予算に達したときに Eメール通知を設定する ことをお勧めします。

コストを監視して、支出を期待に合わせる

コスト可視化ダッシュボードは支出パターンの把握に役立ち、使用ポリシーは、サーバレス コンピュートの使用状況を特定のユーザー、グループ、またはプロジェクトに帰属させるのに役立ち、より正確なコスト配分を可能にします。支出を把握するために、Databricks はコストを追跡・分析するためのさまざまなツールと機能を提供しています。

• アカウントコンソールで使用状況を監視する : Databricks は、アカウントコンソールで コスト管理 AI/BI ダッシュボード を提供しており、アカウント管理者はアカウント内の任意の Unity Catalog 対応ワークスペースにインポートできます。これにより、アカウントの使用状況または単一のワークスペースの使用状況を監視できます。

• 予算を使用してアカウントの使用を監視する: 予算を使用すると 、アカウント全体の使用状況を監視できます。
  利用ポリシーは、ポリシーに割り当てられたユーザーが使用するサーバレス コンピュート アクティビティにタグを適用することで、サーバレスの使用状況を割り当てるために使用できます。

• **OpenSharing エグレスコストの監視および管理**：他のデータ共有プラットフォームとは異なり、OpenSharing はデータのレプリケーションを必要としません。このモデルには多くの利点がありますが、クラウドまたはリージョン間でデータを共有する場合、クラウドベンダーがデータエグレス料金を請求する可能性があることを意味します。エグレス料金を監視および管理するには、OpenSharing エグレス コストの監視と管理 (プロバイダー向け) を参照してください。

• システムテーブルを使用してコストを監視する : システムテーブル system.billing.usage を使用すると、 コストを監視できます。 ワークスペースとコンピュート リソースに適用されたカスタム タグは、このシステム テーブルに反映されます。 サーバレス コンピュート、ジョブ コスト、モデルサービング コストのコストを監視することができます。

• Download 課金利用 for local analysis : アカウント REST API を使用して、指定したアカウントと日付範囲の課金利用ログを CSV 形式でダウンロードできます。

組織のニーズに合わせて使用量を調整するためのコスト管理

コスト管理は、技術的な実装にとどまらず、より広範な組織戦略を含めます。

• ハウスキーピングジョブを開発してスケジュールし、タグを(段階的に)適用またはクリーンアップします。ジョブは、単一のリソースの問題によって中断されないように回復力を備えている必要があります。すべての変更は監査ログに書き込む必要があります。
• 定期的なコスト監査を実施して、すべてのアクティブなリソース、それらの支出、および組織のニーズとの整合性を確認します。月次コスト レポートを共有すると、消費量の増加と異常を追跡し、すべてのチームでプロアクティブなコスト管理が促進されます。
• オートスケールや自動終了などの戦略を通じてリソースの割り当てを最適化し、ワークロード要件に基づいてリソースを動的に割り当てます。この章のその他のベストプラクティスを参照してください。
• リソース使用のコストへの影響についてチームを教育し、コスト最適化のベストプラクティスについてトレーニングします。
• コンピュート ポリシーをツールとして使用して、特定のユーザーが作成およびアクセスできるコンピュート リソースの種類とサイズを制御します。

全体として、コストの最適化は継続的なプロセスと見なす必要があり、スケーリング、新しいプロジェクト、または予期しないコストの急増が発生した場合に備えて、戦略を定期的に見直す必要があります。Databricks のネイティブ コスト管理機能とサードパーティ ツールの両方を使用して、包括的な制御と最適化を実現します。

4。費用対効果の高いワークロードを設計します

常時オンとトリガーによるストリーミングのバランス

従来、ストリーミングについて考えるとき、「リアルタイム」、「24/7」、「常時接続」などの用語が頭に浮かびます。 データ取り込みがリアルタイムで発生する場合、基になるコンピュート リソースは 24/7 で実行する必要があり、1 日のうち 1 時間ごとにコストが発生します。

ただし、イベントの連続ストリームに依存するすべてのユースケースで、それらのイベントをすぐにアナリティクス データ セットに追加する必要があるわけではありません。 ユースケースのビジネス要件で、数時間ごとまたは毎日最新のデータのみが必要な場合は、1 日に数回実行するだけでその要件を満たすことができ、ワークロード コストが大幅に削減されます。Databricks では、低待機時間要件がない増分ワークロードに対して、 AvailableNowトリガーで構造化ストリーミングを使用することをお勧めします。AvailableNow : 増分バッチ処理を参照してください。

オンデマンドインスタンスと容量超過インスタンスのバランス

スポットインスタンス は、低価格で利用できる余剰の仮想マシンリソースクラウド上で利用します。 コストを節約するために、 Databricks はスポットインスタンスを使用したクラスターの作成をサポートしています。 最初のインスタンス (Spark ドライバー) は、常にオンデマンド仮想マシンにすることをお勧めします。 スポットインスタンスは、1 つ以上のスポットインスタンスがクラウドプロバイダーによって削除されたために、より長くかかることが許容されるワークロードに適しています。

また、Fleet インスタンスタイプの使用も検討してください。 クラスターでこれらのフリートインスタンスタイプのいずれかを使用する場合、 Databricks は、クラスターで使用するのに最適な料金と可用性を持つ一致する AWS 物理インスタンスタイプを選択します。