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

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

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

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

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

ジョブコンピュートを使用する

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

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

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

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

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

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

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

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

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

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

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

BI ユースケース

BIワークロードは通常、データをバーストで消費し、複数の並列クエリを生成します。たとえば、BI ツールを使用するユーザーは、ダッシュボードを更新したり、クエリを作成したりして、プラットフォームとのさらなるやり取りを行わずに結果を分析するだけです。このシナリオでは、データプラットフォームは次のことを行います。

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

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

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

MLとAIモデルサービング

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

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

適切なインスタンスタイプを使用する

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

たとえば、Graviton2 ベースの Amazon EC2 インスタンスは、同等の Amazon EC2 インスタンスよりも大幅に優れた価格性能を実現できます。

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

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

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

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

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

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

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

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

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

Photonは、Databricks SQLDataFrameAPIワークロードと呼び出し (データ取り込み、ETL 、ストリーミング、データサイエンス、インタラクティブクエリ用) を高速化する、高性能なネイティブのベクトル化クエリエンジンです。Photon Apache Spark APIsと互換性があるため、コードの変更やロックインなしで、電源を入れるだけで簡単に使い始めることができます。

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

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

自動スケーリングコンピュートを使用する

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

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

自動終了を使用する

Databricksアイドルリソースを削減し、コンピュートリソースをデプロイできるタイミングを制御することでコストを管理するのに役立ついくつかの機能を提供します。

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

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

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

コンピュートポリシーは、コンピュートリソースに対して多くのコスト固有の制限を適用できます。「Operational Excellence - コンピュートポリシーの使用」を参照してください。例えば：

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

3.コストの監視と管理

コストの監視

アカウントコンソールでは、課金利用を表示することができます。Databricks アカウントオーナーまたはアカウント管理者として、アカウントコンソールを使用して課金利用ログをダウンロードすることもできます。このデータにプログラムでアクセスするには、アカウント API を使用してログをダウンロードすることもできます。また、ファイル形式の課金利用ログ CSVをAWSS3 ストレージバケットに毎日配信するように設定することもできます。

コスト属性のタグクラスター

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

チームやユースケースのワークスペースとクラスターを設定するときは、コスト管理と帰属が考慮されるようにします。これにより、タグ付けが合理化され、コスト帰属の精度が向上します。

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

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

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

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

ブログを参照: Databricks でコスト最適化と信頼性をインテリジェントにバランスさせる

4. コスト効率の高いワークロードを設計する

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

従来、ストリーミングについて考えるとき、「リアルタイム」、「24時間年中無休」、「常時オン」などの用語が思い浮かびます。データ取り込みがリアルタイムで行われる場合、基盤となるコンピュートリソースは 24 時間 365 日実行する必要があり、1 日中 1 時間ごとにコストが発生します。

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

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

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

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