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

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

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

Delta Lake を使用する

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

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

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

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

注

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

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

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

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

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 を課金しないため、コスト削減につながります。 インスタンスプロバイダーの課金が適用されます。

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

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

3.コスト の監視と管理

コスト の監視

アカウント コンソールでは課金利用状況を表示できます。 Databricksアカウント所有者またはアカウント管理者は、アカウント コンソールを使用して課金利用ログをダウンロードすることもできます。 プログラムでこのデータにアクセスするには、アカウント API を使用してログをダウンロードすることもできます。 または、 課金利用ログインCSVファイル形式をAWS S3ストレージ バケットに毎日配信するように設定することもできます。

ベスト プラクティスとして、全コスト (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の合計容量。これにより、ディスクにスピルする前にメモリに格納できるデータの量が決まります。

  • エグゼキューターローカルストレージ: ローカルディスクストレージのタイプと容量。ローカルディスクは、主にシャッフルおよびキャッシュ中にデータがスピルした場合に使用されます。

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

  • ワークロードのデータ消費量

  • ワークロードのコンピューティングの複雑さの度合い

  • データの読み取り先

  • 外部ストレージでのデータのパーティション方法

  • 必要な並列処理量

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