次の方法で共有

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

  • [アーティクル]

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

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

Delta Lake を使用する

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

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

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

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

Note

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

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

対話型 SQL ワークロードの場合、Databricks SQL ウェアハウスは最もコスト効率の高いエンジンです。 「価格の概要」を参照してください。

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

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. 動的にリソースの割り当ておよび割り当て解除を行う

自動スケーリング コンピューティングを活用する

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

Note

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

「信頼性 - 自動スケーリングの設計」で以下について確認してください。

  • バッチ ワークロード用の自動スケーリングの有効化。
  • SQL ウェアハウス用の自動スケーリングの有効化。
  • Delta Live Tables 拡張自動スケーリングの使用。

自動終了を使用する

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

  • すべての対話型クラスターの自動終了を構成します。 指定したアイドル時間が経過すると、クラスターがシャットダウンします。 「自動終了」を参照してください。
  • クラスターが営業時間内にのみ必要なユース ケースの場合、クラスターを自動終了付きで構成し、スケジュールされたプロセスで、朝ユーザーが自分のデスクトップに戻ってくる前に、クラスターを再起動 (そして場合によっては必要に応じてデータをプリウォーム) することができます。 「CACHE SELECT」を参照してください。
  • 完全なクラスターの起動よりもかなり短い起動時間の方が好ましい場合は、クラスター プールの使用を検討してください。 「プールのベスト プラクティス 」を参照してください。 Azure Databricks プールは、アイドル状態ですぐに使用できるインスタンスのセットを維持することで、クラスターの開始と自動スケールの時間を短縮します。 クラスターがプールにアタッチされている場合、クラスター ノードはプールのアイドル状態のインスタンスを使用して作成されます。 プールにアイドル状態のインスタンスがない場合、クラスターの要求に対応するために、インスタンス プロバイダーから新しいインスタンスを割り当てることによってプールが拡張されます。 クラスターがインスタンスを解放すると、そのインスタンスはプールに戻り、別のクラスターが使用できるようになります。 プールに接続されているクラスターのみが、そのプールにあるアイドル状態のインスタンスを使用できます。

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

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

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

3. コストを監視して制御する

コストを監視する

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

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

ワークロードに対して Photon を評価する

Photon は、データ レイク上で直接、低コストで極めて高速なクエリ パフォーマンス (データ インジェスト、ETL、ストリーミング、データ サイエンスから対話型クエリまで) を提供します。 Photon は Apache Spark API と互換性があるため、開始方法はそれをオンにするだけという簡単なものです。コードの変更やロックインは存在しません。 TPC-DS 1TB ベンチマークによる測定では、Photon は Apache Spark との比較で、さらに 2 倍の高速化を記録しています。 お客様においては、各自のワークロード上で、最新の DBR バージョンとの比較で、平均 3 倍から 8 倍の高速化が確認されています。

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

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

通常、BI ワークロードは急激にデータを使用し、複数の同時クエリを生成します。 たとえば、BI ツールを使用している誰かが、プラットフォームとさらに対話することなく、ダッシュボードの更新、クエリの記述、または単にクエリ結果の分析を行う可能性があります。 この例は、次の 2 つの要件が存在することを示しています。

  • コストを節約するために、アイドル時間中にクラスターを終了する。
  • ユーザーが BI ツールを使用して新しいまたは更新されたデータを要求する際に、ユーザー クエリに答えるためのコンピューティング リソースを迅速に (起動とスケールアップの両方の目的で) 使用できるようにする。

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

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

4. 支出を分析して属性を付ける

コストの帰属用にクラスターにタグを付ける

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

チームやユース ケースのためにワークスペースとクラスターを設定する際には、コストの制御と帰属が既に念頭に置かれていることを確認します。 これにより、タグ付けが合理化され、コストの帰属の正確性が向上します。

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

「タグを使用した使用状況の監視」をご覧ください。

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

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

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

Always-On とトリガー ストリーミングのバランスを取る

従来、人々がストリーミングについて考える際には、“リアルタイム”、“24 時間 365 日”、“常時オン” などの用語を思い浮かべます。 データ インジェストが “リアルタイム” で発生する場合、根底にあるクラスターは 24 時間 365 日実行する必要があり、1 日のどの時間でも使用コストが発生します。

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

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

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

  • Executor の合計コア数 (コンピューティング): すべての Executor におけるコアの合計数。 これにより、クラスターの最大並列度が決まります。
  • Executor の合計メモリ: すべての Executor における RAM の総量。 ディスクに書き込む前にメモリに保存できるデータ量を決定します。
  • Executor のローカル ストレージ: ローカル ディスク ストレージの種類と量。 ローカル ディスクは、シャッフルやキャッシュ中にスピルが発生した場合に主に使用されます。

その他の考慮事項には、上記の要因に影響するワーカー インスタンスの種類とサイズが含まれます。 クラスターのサイズを設定する場合は、次の点を考慮します。

  • ワークロードで消費されるデータ量。
  • ワークロードのコンピューティングの複雑さ。
  • データの読み取り元。
  • 外部ストレージでのデータのパーティションの方法。
  • どの程度の並列処理が必要であるか。

詳細と例については、「クラスターのサイズ設定に関する考慮事項」で確認できます。