はじめに

Azure Databricksのドキュメント（Microsoft Learn）で、本章がまだ日本語訳されていなかったため、DeepLで翻訳しました。

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

この記事では、コスト最適化の原則を支えるベストプラクティスを、原則別にご紹介します。

1. 正しいリソースの選択

Delta Lakeの使用

Delta Lake には、（Parquet、ORC、および JSON を使用する場合と比較して）ワークロードを大幅に高速化できる多くのパフォーマンス向上が付属しています。Azure Databricksの最適化の推奨を参照してください。ワークロードがジョブクラスターでも実行される場合、これはクラスターの実行時間の短縮とコストの削減に直接つながります。

ジョブクラスターの使用

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

さらに、すべてのジョブまたはワークフローが新しいクラスタ上で実行されるため、ワークロードが互いに分離されるという利点もあります。

注意

マルチタスクワークフローでは、すべてのタスクでコンピュートリソースを再利用できるため、クラスタの起動時間はワークフローごとに1回しか発生しません。ジョブで「Azure Databricks コンピートを使用する」を参照してください。

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

インタラクティブなSQLワークロードには、Databricks SQL warehouseが最もコスト効率の高いエンジンです。価格の概要を参照してください。

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

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

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

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

GPUアクセラレーション・ライブラリを使用しないほとんどのワークロードは、GPU対応インスタンスの恩恵を受けません。ワークスペース管理者は、不必要な使用を防ぐためにGPUマシンとクラスタを制限することができます。ブログポスト「GPUは本当に高価か？Databricks クラスターでの推論用 GPU のベンチマーク" を参照してください。

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

スポットインスタンスは、安価に利用できるクラウド仮想マシンの余剰リソースを使用します。コストを節約するために、Azure Databricksはスポットインスタンスを使用したクラスタの作成をサポートしています。最初のインスタンス（Sparkドライバ）は常にオンデマンド仮想マシンにすることを推奨します。スポットインスタンスは、1つまたは複数のスポットインスタンスがクラウドプロバイダーによって退去させられたため、時間がかかることが許容されるワークロードに最適な選択です。

2. リソースの動的な割り当てと割り当て解除

オートスケーリング・コンピートの活用

自動スケーリングにより、ワークロードはジョブの完了に必要な適切な量のコンピートを使用できます。

注意

コンピュートオートスケーリングでは、構造化ストリーミングワークロードのクラスタサイズの縮小に限界があります。Databricksは、ストリーミングワークロードにEnhanced Autoscalingを備えたDelta Live Tablesを使用することを推奨します。「拡張オートスケーリングとは」を参照してください。

「信頼性 - オートスケーリングの設計」を参照してください：

バッチワークロードの自動スケーリングを有効にしてください。
SQL ウェアハウスの自動スケーリングを有効にしてください。
Delta Live Tables Enhanced Autoscaling を使用します。

自動ターミネーションの使用

Azure Databricks には、アイドル状態のリソースを削減し、コンピュートリソースのデプロイ可能なタイミングを制御することで、コスト管理を支援する機能が多数用意されています。

すべての対話型クラスタに対して自動終了を設定します。指定したアイドル時間が経過すると、クラスタはシャットダウンします。自動終了を参照してください。
クラスタが業務時間中にのみ必要なユースケースについては、クラスタを自動終了で構成し、スケジュールされたプロセスによって、ユーザーがデスクトップに戻る前の朝にクラスタを再起動（必要に応じてデータをプリウォーム）することができます。CACHE SELECTを参照してください。
クラスタのフル起動よりも大幅に短い起動時間が許容される場合は、クラスタプールの使用を検討してください。ベストプラクティス：プール」を参照してください。Azure Databricksプールは、アイドルですぐに使用できるインスタンスのセットを維持することで、クラスタの開始時間と自動スケーリング時間を短縮します。クラスタがプールにアタッチされると、プールのアイドルインスタンスを使用してクラスタノードが作成されます。プールにアイドル・インスタンスがない場合、プールはクラスタの要求に対応するためにインスタンス・プロバイダから新しいインスタンスを割り当てて拡張します。クラスタがインスタンスを解放すると、そのインスタンスはプールに戻り、別のクラスタが自由に使用できるようになります。プールに接続されているクラスタだけが、そのプールのアイドルインスタンスを使用できます。
Azure Databricksは、インスタンスがプール内でアイドル状態である間はDBUに課金しないため、コスト削減につながります。インスタンスプロバイダによる課金は適用されます。

クラスタポリシーを使用してコストを制御

クラスタポリシーは、クラスタに対して多くのコスト固有の制限を強制できます。オペレーショナル・エクセレンス - クラスタ・ポリシーの使用」を参照してください。たとえば

ワーカーノードの最小数を設定してクラスタの自動スケーリングを有効にします。

妥当な値（たとえば1時間）でクラスタの自動終了を有効にして、アイドル時間に対する支払いを回避します。
コスト効率の高いVMインスタンスのみを選択できるようにします。クラスタ構成のベストプラクティスに従ってください（ベストプラクティス：クラスタ構成参照）。
スポット・インスタンス戦略を適用します。

3. コストの監視と管理

コストの監視

Azure Cost Managerを使用して、Azure Databricksのコストを分析します。クラスタとワークスペースのタグも Azure Cost Manager に配信されます。コストの帰属については、クラスタにタグを付けるを参照してください。

ベストプラクティスとして、フルコスト（VM、ストレージ、ネットワークインフラストラクチャを含む）を監視する必要があります。これは、クラウドプロバイダのコスト管理ツールや、サードパーティのツールを追加することで実現できます。

お客様のワークロードに適したPhotonの評価

Photonは、データ取り込みからETL、ストリーミング、データサイエンス、対話型クエリまで、データレイク上で非常に高速なクエリパフォーマンスを低コストで提供します。PhotonはApache Spark APIと互換性があるため、コードを変更することなく、ロックインされることなく、電源を入れるだけで簡単に使い始めることができます。Apache Sparkと比較して、PhotonはTPC-DS 1TBベンチマークのメジャー値でさらに2倍のスピードアップを実現します。お客様は、最新のDBRバージョンと比較して、ワークロードに応じて平均3倍から8倍のスピードアップを確認しています。

コストの観点からは、PhotonワークロードはSparkワークロードよりも1時間あたり約2倍から3倍のDBUを使用します。観測された高速化を考慮すると、これは大幅なコスト削減につながる可能性があり、定期的に実行されるジョブは、Photonを使用することで高速化されるだけでなく、コストも削減されるかどうかを評価する必要があります。

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

BIワークロードは通常、データをバースト的に使用し、複数の同時クエリを生成します。例えば、BIツールを使用している人は、ダッシュボードを更新したり、クエリを作成したり、あるいはプラットフォームとそれ以上やり取りすることなくクエリ結果を分析したりします。この例では、次の2つの要件を示します：

アイドル期間中にクラスタを終了してコストを削減すること。

ユーザーが BI ツールで新しいデータまたは更新されたデータを要求したときに、ユーザーのクエリを満たすために（スタートアップとスケールアップの両方で）コンピュートリソースを迅速に利用できるようにすること。

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

さらに、サーバーレスSQLウェアハウスは非サーバーレスウェアハウスよりも早期にスケールダウンするため、結果的にコストを削減できます。

4. 支出の分析と帰属

コスト帰属のためのクラスタへのタグ付け

コストを監視し、Azure Databricksの使用量を組織のビジネスユニットやチームに正確に帰属させるために（たとえば、チャージバックのために）、クラスタとプールにタグを付けることができます。これらのタグは、詳細なDBU使用状況レポート、およびコスト分析のためのクラウドプロバイダのVMとブロブストレージインスタンスに伝搬されます。

チームやユースケース用にワークスペースやクラスタをセットアップする際に、コスト管理と帰属がすでに考慮されていることを確認します。これにより、タグ付けが効率化され、コスト帰属の精度が向上します。

全体的なコストについては、DBU仮想マシン、ディスク、関連するネットワーク・コストを考慮する必要があります。サーバーレス SQL ウェアハウスの場合、DBU コストにはすでに仮想マシンとディスクのコストが含まれているため、これはよりシンプルです。

クラスタ、プール、ワークスペースのタグを使用した使用状況の監視を参照してください。

定期的なコストレポートの共有

毎月コストレポートを作成し、使用量の増加や異常を追跡します。クラスタタグを使用して、これらのレポートをユースケースまたはチームに分けて、それぞれのワークロードを所有するチームと共有します。これにより、驚きを回避し、コストが高くなりすぎた場合に、チームがワークロードを積極的に適応させることができます。

5. ワークロードを最適化し、スケーラブルなコストを目指します。

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

従来、ストリーミングというと、「リアルタイム」「24時間365日」「常時オン」といった言葉が思い浮かびます。データの取り込みが「リアルタイム」で行われる場合、基礎となるクラスタは24時間365日稼働する必要があり、1日1時間ごとに消費コストが発生します。

しかし、継続的なイベントのストリームに基づくすべてのユースケースで、これらのイベントをアナリティクスのデータセットに即座に追加する必要があるわけではありません。ユースケースのビジネス要件が、数時間ごとまたは毎日新鮮なデータを必要とするだけであれば、この要件は1日に数回実行するだけで達成でき、ワークロードの大幅なコスト削減につながります。Databricks では、低レイテンシを必要としないインクリメンタルワークロードには、トリガ AvailableNow を使用した Structured Streaming の使用を推奨しています。インクリメンタルバッチ処理の構成を参照してください。

最も効率的なクラスタサイズの選択

Azure Databricks は、ワーカーノードごとに 1 つのエクゼキュータを実行します。したがって、Azure Databricksアーキテクチャの文脈では、ExecutorとWorkerという用語は互換的に使用されます。クラスタサイズをワーカーの数で考えることが多いですが、他にも考慮すべき重要な要素があります：

総エグゼキュータコア数（コンピュート）：全エグゼキュータのコア数の合計。これはクラスタの最大並列度を決定します。
総エクゼキュータメモリ：全エクゼキュータのRAMの総量。ディスクにデータを流出させる前に、どれだけのデータをメモリに保存できるかを決定します。
エクゼキュータ・ローカル・ストレージ：ローカル・ディスク・ストレージの種類と量。ローカルディスクは主に、シャッフルやキャッシュ中にこぼれた場合に使用されます。
その他の考慮事項としては、ワーカーインスタンスのタイプとサイズがあり、これらは前述の要因にも影響します。クラスタのサイジングを行う際には、以下の点を考慮してください：

ワークロードが消費するデータ量は？
ワークロードの計算の複雑さは？
どこからデータを読み出しますか？
外部ストレージでのデータのパーティショニングは？
必要な並列度は？

詳細と例は、クラスタサイジングの考慮事項でご覧いただけます。