次の方法で共有

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

  • [アーティクル]

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

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

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

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

ジョブ コンピューティングを使用する

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

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

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

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

また、サーバーレス SQL ウェアハウスは、インテリジェント ワークロード管理 (IWM) をサポートしています。これは、Databricks SQL Serverless での大量のクエリを迅速かつコスト効率よく処理する能力を高める、一連の機能です。

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

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

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

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

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

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

BI ユース ケース

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

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

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

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

ML と AI のモデル提供

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

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

適切なインスタンスの種類を使用する

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

ワークロードに基づいて、最適なパフォーマンス/価格比を得るために適切なインスタンス ファミリを選択することも重要です。 次のような一般的な経験則があります。

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

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

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

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

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

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

詳細と例については、「コンピューティングのサイズ設定に関する考慮事項」で確認できます。

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

Photon は、SQL ワークロードと DataFrame API 呼び出し (データ インジェスト、ETL、ストリーミング、データ サイエンス、対話型クエリ) を高速化する、高性能な Databricks ネイティブのベクター化クエリ エンジンです。 Photon は Apache Spark API と互換性があるため、コードを変更することなく、ロックインされることなく、電源を入れるだけで簡単に使い始めることができます。

確認されている高速化の実績でも、大幅なコスト削減を達成できる可能性がり、定期的に実行されるジョブは、Photon によって速度が上がるかだけでなく、コストも安くなるか評価する必要があります。

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

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

自動スケーリングを使用すると、Databricks では、ジョブの特性を考慮してワーカーが動的に再び割り当てられます。 パイプラインのある部分は、他の部分よりも計算負荷が高く、Databricks はジョブのこれらのフェーズ中に自動的にワーカーを追加します (不要になるとそれらを削除します)。 自動スケーリングでは、静的にサイズ設定されたコンピューティング インスタンスと比較して、全体的にコストを削減できます。

コンピューティングの自動スケールには、構造化ストリーミング ワークロードのクラスター サイズをスケールダウンする際に制限があります。 Databricks では、ストリーミング ワークロードに 自動スケール で Delta Live Tables を使用することをお勧めします。

自動終了を使用する

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

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

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

コンピューティング ポリシーを使用してコストを制御する

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

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

コストを監視する

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

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

チャージバックの目的で、コストを全体的に監視し、Azure Databricks の使用量を組織の部署やチームに正確に帰属させるために、クラスター、SQL ウェアハウス、プールにタグを付けることができます。 これらのタグは、コスト分析のために、詳細な Databricks ユニット (DBU)、およびクラウド プロバイダー VM と Blob Storage の使用量に伝達されます。

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

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

Azure Databricks リソースのタグは、Azure portal のコスト分析ツールで使用できます

監視機能を実装してコストを追跡およびチャージバックする

複雑な技術エコシステムを扱う場合、未知の要素を事前に理解することが、プラットフォームの安定性を維持し、コストを管理するうえで重要となります。 可観測性は、生成されたデータに基づいてシステムを分析および最適化する手段を提供します。 これは、既知の問題を追跡するのではなく、新しいパターンを識別することに重点を置くため、監視とは異なります。

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

「Blog: Intelligently Balance Cost Optimization & Reliability on Databricks」を参照してください

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

月間コスト レポートを生成して、消費量の増加と異常を追跡します。 クラスターのタグ付けを使用して、ユース ケースやチームごとのレポートを、ワークロードを所有するチームと共有します。 これにより、コストが高くなり過ぎた場合の動揺を回避し、チームがワークロードを積極的に調整できます。

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

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

4.費用対効果に優れたワークロードを設計する

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

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

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

オンデマンド インスタンスと容量余剰インスタンスのバランスを取る

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