メインコンテンツまでスキップ

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

この記事では、 コスト最適化 の原則をサポートするベスト プラクティスを原則別に整理して説明します。

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

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

Databricks Data Intelligence Platform を最大限に活用するには、ストレージフレームワークとして Delta Lake を使用する必要があります。 よりシンプルで信頼性の高い ETL パイプラインの構築に役立ち、Parquet、ORC、JSON を使用する場合と比較してワークロードを大幅に高速化できる多くのパフォーマンス強化が付属しています。 Databricks の最適化に関する推奨事項を参照してください。ワークロードがジョブ コンピュートでも実行されている場合、これはコンピュート リソースのアップタイムの短縮に直結し、コストが削減されます。

Use ジョブ コンピュート​

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ML and AI モデルサービング

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

Mosaic AI Model Serving はサーバレス コンピュートを使用し、モデルをデプロイするための高可用性と低遅延のサービスを提供します。このサービスは、需要の変化に合わせて自動的にスケールアップまたはスケールダウンし、インフラストラクチャのコストを削減しながら、レイテンシのパフォーマンスを最適化します。

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

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

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

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

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

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

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

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

  • ワークロードのデータ消費量
  • ワークロードのコンピューティングの複雑さの度合い
  • データの読み取り先
  • 外部ストレージでのデータのパーティション方法
  • 必要な並列処理量

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

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

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

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

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

Auto Scaling コンピュートを使用する​

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

コンピュート Auto-Scaling には、構造化ストリーミング ワークロードのクラスタリング サイズをスケールダウンする場合に制限があります。 Databricks では、ストリーミングワークロードに 拡張オートスケール の DLT を使用することをお勧めします。

自動終了を使う​

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

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

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

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

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

3. コストの監視と管理​

コストの監視​

アカウントコンソールでは、課金利用状況を確認できます。 使用状況ダッシュボードを参照してください。アカウント APIを使用してログをダウンロードすることもできます。

コストアトリビューションのタグクラスター​

一般的なコストを監視し、チャージバックの目的で Databricks 使用量を組織のビジネスユニットとチームに正確に帰属させるために、 クラスター、 SQLウェアハウス、プールにタグを付けることができます。 これらのタグは、コスト分析のために、 Databricks ユニット (DBU) とクラウド プロバイダーの VM と BLOB ストレージの使用状況に詳細に反映されます。

ワークスペースを設定し、チームとユースケースのクラスターを行う際には、コスト管理とアトリビューションが考慮されていることを確認してください。 これにより、タグ付けが効率化され、コストアトリビューションの精度が向上します。

総コストには、DBU 仮想マシン、ディスク、および関連するネットワーク コストが含まれます。 サーバレスSQLウェアハウスの場合、DBU コストには仮想マシンとディスクのコストがすでに含まれています。

コストを追跡してチャージバックするためのオブザーバビリティを実装してください​

複雑な技術エコシステムを扱う場合、未知の要素を積極的に理解することが、プラットフォームの安定性を維持し、コストを抑制するための鍵となります。 可観測性は、システムが生成するデータに基づいてシステムを分析および最適化する方法を提供します。 これは、既知の問題の追跡ではなく、新しいパターンの特定に重点を置いたモニタリングとは異なります。

Databricksは、システム Databricksカタログで見つかった顧客アカウントの運用データの ホスト分析ストアである システム テーブル を使用して、優れた可観測性機能を提供します。これらは、アカウント全体の履歴オブザーバビリティを提供し、プラットフォームのテレメトリに関するユーザーフレンドリーな表形式の情報が含まれています。

ブログ: Databricks でコスト最適化と信頼性をインテリジェントにバランスさせるをご覧ください。

コスト レポートを定期的に共有​

毎月のコストレポートを生成して、消費量の増加と異常を追跡します。 これらのレポートをユースケース別またはチームごとに、 クラスタータグを使用してワークロードを所有するチームと共有します。 これにより、予期せぬことがなくなり、コストが高くなりすぎた場合にチームがワークロードを事前に調整できるようになります。

Delta Sharing のエグレス コストを監視および管理する​

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

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

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

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

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

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

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

に最終更新