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

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

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 では、ストリーミング ワークロードの自動スケーリングが強化されたLakeflow 宣言型パイプラインを使用することをお勧めします。

自動終了を使用する

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

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

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

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

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

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

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

Databricks のコスト管理は、パフォーマンスを維持しながらクラウド支出を最適化する上で重要な側面です。 このプロセスは、次の 3 つの重要な領域に分けることができます。

• 設定
• モニタリング
• 管理

次のベスト プラクティスでは、これら 3 つの領域について説明します。

コスト配分用のタグの設定を行う

一般的なコストを監視し、Databricks の使用状況を組織のビジネス ユニットとチーム (組織内のチャージバックなど) に正確に属性付けするには 、ワークスペース、クラスター、SQL ウェアハウス、プールにタグを付けることができます。

セットアップ フェーズでは、組織は効果的なタグ付けプラクティスを実装する必要があります。 これには、組織全体でタグの名前付け規則を作成する必要があります。 特定のユーザー グループに使用を属性付けする一般的なタグと、ロール、製品、サービスなどに基づいて、高度に具体的な分析情報を提供するより詳細なタグの両方を使用することが重要です。

Databricks の使用の最初からタグ付けを開始します。 Databricks によって設定された既定のタグに加えて、少なくとも、カスタム タグ _Business Units_と_Projects_を設定し、特定の組織用に設定します。 開発、品質保証、運用コストを区別する必要がある場合は、タグ Environment をワークスペースとコンピューティング リソースに追加することを検討してください。

タグは、コスト分析のために使用状況ログと クラウド プロバイダー リソース の両方に伝達されます。 合計コストには、 Databricks Units (DBU) に 加えて、仮想マシン、ディスク、および関連するネットワーク コストが含まれます。 サーバーレス サービスの場合、DBU コストには仮想マシンのコストが既に含まれていることに注意してください。

タグの追加は将来の使用にのみ影響するため、より詳細なタグ付け構造から始める方が良いです。 時間の経過に伴う実際の使用がコストの理解と属性に影響を与えないことを示している場合は、タグを無視することは常に可能です。 ただし、不足しているタグを過去のイベントに追加することはできません。

アカウント支出の監視を有効にするために予算とアラートを設定する

予算を 使用すると、アカウント全体の使用状況を監視できます。 財務目標を設定し、アカウント全体の支出を追跡したり、フィルターを適用して特定のチーム、プロジェクト、ワークスペースの支出を追跡したりできます。 アカウントでサーバーレス コンピューティングを使用する場合は、予算ポリシーを使用してアカウントのサーバーレス使用量を属性付けしてください。 サーバーレス使用を予算ポリシーにより属性付けることを参照してください。

予期しない支出を回避するために、毎月の予算に達したときに 電子メール通知を設定 することをお勧めします。

支出を期待に合わせてコストを監視する

コスト監視ダッシュボードは支出パターンを視覚化するのに役立ち、予算ポリシーはサーバーレスコンピューティングの使用状況を特定のユーザー、グループ、またはプロジェクトに属性付けし、より正確なコスト割り当てを可能にします。 支出を把握するために、Databricks には、コストを追跡および分析するためのさまざまなツールと機能が用意されています。

• アカウント コンソールで使用状況を監視する: Databricks では、アカウント コンソールに コスト管理 AI/BI ダッシュボード が用意されています。このダッシュボードは、アカウント管理者が自分のアカウント内の Unity カタログ対応ワークスペースにインポートできます。 これにより、アカウントの使用状況または 1 つのワークスペースの使用状況を監視できます。

• 予算を使用してアカウントの支出を監視する: 予算 を使用すると、アカウント全体の使用状況を監視できます。
  予算ポリシーを使用すると、ポリシーに割り当てられたユーザーによって発生するサーバーレス コンピューティング アクティビティにタグを適用することで、サーバー レスの使用状況を属性 付けできます。

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

• システム テーブルを使用してコストを監視する: system.billing.usageによってコストを監視できます。 ワークスペースとコンピューティング リソースに適用されるカスタム タグは、このシステム テーブルに反映されます。 サーバーレス コンピューティング、ジョブ コスト、モデル サービスコストのコストを監視できます。

• Azure Cost Manager を使用してコストを監視する: コスト分析 は、Azure のコストを分析するためのツールです。 このツールでは、Azure Databricks リソースのタグを使用して詳細な分析を行うことができます。

組織のニーズに合わせてコストを管理する

コスト管理は技術的な実装を超えて、より広範な組織戦略を含めます。

• タグを増分的に適用またはクリーンアップするためのハウスキーピングジョブを開発してスケジュールします。 ジョブは、単一のリソースの問題によって中断されないように耐える必要があります。 すべての変更を監査ログに書き込む必要があります。
• 定期的なコスト監査を実施して、すべてのアクティブなリソース、支出、組織のニーズとの整合性を確認します。 毎月のコスト レポートを共有することで、消費量の増加と異常を追跡し、すべてのチームでプロアクティブなコスト管理を促進できます。
• ワークロードの要件に基づいてリソースを動的に割り当てる自動スケールや自動終了などの戦略を使用して、リソースの割り当てを最適化します。この章の他のベスト プラクティスを参照してください。
• リソース使用量のコストへの影響についてチームを教育し、コスト最適化のベスト プラクティスに関するトレーニングを行います。
• コンピューティング ポリシーをツールとして使用して、特定のユーザーが作成してアクセスできるコンピューティング リソースの種類とサイズを制御します。

全体的に、コスト最適化は進行中のプロセスと見なす必要があり、スケーリング、新しいプロジェクト、または予期しないコストの急増が発生した場合は、戦略を定期的に見直す必要があります。 Databricks のネイティブ コスト管理機能とサードパーティ製ツールの両方を使用して、包括的な制御と最適化を行います。

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

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

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

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

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

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