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

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

1.適切なリソースを選択します

Delta Lakeを使用する

Delta Lake には、ワークロードを大幅に高速化できる多くのパフォーマンスの向上があります (Parquet、ORC、JSON を使用する場合と比較して)。 Databricksの最適化に関する推奨事項を参照してください。ワークロードがジョブクラスターでも実行される場合、クラスターの実行時間が短くなり、コストが削減されます。

ジョブクラスターを使用する

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

その他の利点は、すべてのジョブまたはワークフローが新しいクラスターで実行され、ワークロードが互いに分離されることです。

注

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

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

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

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

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

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

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

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

2. リソースを動的に割り当てたり、割り当てを解除したりする

自動スケーリングコンピュートの活用

オートスケールを使用すると、ワークロードはジョブを完了するために必要な適切な量のコンピュートを使用できます。

注

コンピュートの自動スケーリングには、構造化ストリーミングワークロードのクラスターサイズをスケールダウンする制限があります。 Databricks 、ストリーミングワークロードに拡張オートスケールを備えたDelta Live Tablesを使用することをお勧めします。「拡張オートスケールDelta Live Tables Pipeline のクラスター使用率を最適化する」を参照してください。

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

バッチワークロードに対してオートスケールを有効にします。
オートスケール for SQLウェアハウスを有効にします。
拡張オートスケール Delta Live Tables を使用します。

自動終了を使用する

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

すべてのインタラクティブクラスターの自動終了を構成します。指定されたアイドル時間が経過すると、クラスターはシャットダウンします。「自動終了」を参照してください。
クラスターが営業時間中にのみ必要なユースケースでは、クラスターを自動終了で構成し、スケジュールされたプロセスで、ユーザーがデスクトップに戻る前に午前中にクラスターを再起動できます (必要に応じてデータを予熱する可能性があります)。キャッシュ選択を参照してください。
クラスターの完全な開始より大幅に短い開始時間を許容できる場合は、クラスタープールの使用を検討してください。「プールのベストプラクティス」を参照してください。 Databricks プールは、アイドル状態ですぐに使用できるインスタンスのセットを維持することで、クラスターの起動と自動スケーリングの時間を短縮します。クラスターがプールに接続されると、プールのアイドル状態のインスタンスを使用してクラスターノードが作成されます。プールにアイドル状態のインスタンスがない場合、クラスターの要求に対応するために、インスタンスプロバイダーから新しいインスタンスを割り当てることによってプールが拡張されます。クラスターがインスタンスを解放すると、インスタンスはプールに戻り、別のクラスターが自由に使用できるようになります。プールに接続されているクラスターのみが、そのプールのアイドル状態のインスタンスを使用できます。

Databricks は、インスタンスがプール内でアイドル状態の間は DBU を課金しないため、コスト削減につながります。インスタンスプロバイダーの課金が適用されます。

クラスターポリシーを使用してコストを管理する

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

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

3.コストの監視と管理

コストの監視

アカウントコンソールには課金利用が表示されます。アカウントコンソールを使用して課金利用を表示するを参照してください。アカウント APIを使用してログをダウンロードすることもできます。

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

ワークロードのPhotonを評価する

Photon は、データ取り込み、ETL、ストリーミング、データサイエンス、インタラクティブクエリーなど、非常に高速なクエリーパフォーマンスを低コストで直接データレイク上で直接提供します。 PhotonはApache Spark APIsと互換性があるため、コードの変更やロックインなしで、電源を入れるのと同じくらい簡単に開始できます。 Apache Sparkと比較して、PhotonはTPC-DS 1TBベンチマークで測定されたように、さらに2倍の高速化を提供します。顧客は、最新のDBRバージョンと比較して、ワークロードに基づいて平均3倍から8倍のスピードアップを確認しています。

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

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

BI ワークロードは通常、バーストでデータを使用し、複数の並列クエリーを生成します。たとえば、BI ツールを使用しているユーザーは、プラットフォームとそれ以上対話することなく、ダッシュボードを更新したり、クエリーを記述したり、単にクエリー結果を分析したりできます。この例では、次の 2 つの要件を示します。

アイドル期間中にクラスターを終了して、コストを節約します。
コンピュートのリソースを (スタートアップとスケールアップの両方で) 迅速に利用できるようにして、ユーザーが BI ツールを使用して新しいデータや更新されたデータを要求したときにクエリを満足させます。

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

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

4.支出の分析と帰属

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

コストを監視し、Databricks の使用状況を組織の部署とチームに正確に帰属させるには (チャージバックなど)、クラスターとプールにタグを付けることができます。これらのタグは、詳細な DBU 使用状況レポートと、コスト分析のためにクラウドプロバイダーの VM と BLOB ストレージインスタンスに伝達されます。

チームとユースケースのワークスペースとクラスターを設定するときは、コスト管理とアトリビューションが既に念頭に置いていることを確認します。これにより、タグ付けが合理化され、コスト属性の精度が向上します。

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

「タグを使用して使用状況を監視する」を参照してください。

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

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

伝統的に、人々がストリーミングについて考えるとき、「リアルタイム」、「24/7」、「常時オン」などの用語が思い浮かびます。データ取り込みが「リアルタイム」で行われる場合、基になるクラスターは24時間週7日稼働する必要があり、1日1時間ごとに消費コストが発生します。

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

最も効率的なクラスターサイズを選択する

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

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

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

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

詳細と例については、「クラスターのサイジングに関する考慮事項」を参照してください。