コンピュート構成リファレンス

注：

この記事の構成は、単純な形式のコンピュート UI を使用していることを前提としています。 簡易フォームの更新の概要については、「 簡易フォームを使用してコンピュートを管理する」を参照してください。

この記事では、新しい all-purpose リソースまたはジョブ コンピュート リソースを作成するときに使用できる構成設定について説明します。 ほとんどのユーザーは、割り当てられたポリシーを使用してコンピュート リソースを作成するため、構成可能な設定が制限されます。 UI に特定の設定が表示されない場合は、選択したポリシーでその設定を構成できないためです。

シンプルなコンピュートフォーム

この記事で説明する構成と管理ツールは、all-purpose とジョブ コンピュートの両方に適用されます。 ジョブ コンピュートの構成に関する考慮事項の詳細については、「 ジョブのコンピュートを構成する」を参照してください。

新しい汎用コンピュートリソースを作成する

新しい汎用コンピュートリソースを作成するには、次の手順を実行します。

  1. ワークスペースのサイドバーで、[コンピュート] をクリックします。

  2. [コンピュートを作成] ボタンをクリックします。

  3. コンピュートリソースを構成します。

  4. 作成をクリックします。

新しいコンピュートリソースは自動的にスピンアップを開始し、すぐに使用できるようになります。

コンピュート ポリシー

ポリシーは、ユーザーがコンピュートリソースを作成するときに利用できる設定オプションを制限するために使用される一連のルールです。ユーザーが無制限でクラスター作成を許可する権限を持っていない場合、そのユーザーは付与されたポリシーを使用してコンピュートリソースを作成することしかできません。

ポリシーに従ってコンピュートリソースを作成するには、[ポリシー] ドロップダウンメニューから目的のポリシーを選択します。

デフォルトでは、すべてのユーザーがパーソナルコンピュートポリシーにアクセスでき、単一マシンのコンピュートリソースを作成できます。パーソナルコンピュートまたはその他のポリシーへのアクセスが必要な場合は、ワークスペース管理者にお問い合わせください。

パフォーマンス設定

次の設定は、シンプルフォームのコンピュートUIの [パフォーマンス ]セクションに表示されます。

Databricks Runtime のバージョン

Databricks Runtimeは、コンピュートで実行されるコアコンポーネントのセットです。Databricks Runtime Versionドロップダウンメニューを使用してランタイムを選択します。特定のDatabricks Runtimeバージョンの詳細については、Databricks Runtimeリリースノートのバージョンと互換性を参照してください。すべてのバージョンにApache Sparkが含まれています。Databricksでは、次のことを推奨しています。

  • 汎用コンピュートの場合は、コードとプリロードされたパッケージ間の最新の互換性を確保するために、最新の最適化と、最新バージョンを使用してください。

  • 運用ワークロードを実行しているジョブコンピュートの場合は、Databricks Runtimeの長期サポート（LTS）バージョンの使用を検討してください。LTSバージョンを使用すれば、互換性の問題が発生せず、アップグレードする前にワークロードを徹底的にテストできます。

  • データサイエンスと機械学習のユースケースでは、Databricks Runtime MLバージョンを検討してください。

Photonアクセラレーションを使用する

Databricks Runtime 9.1 LTS以降を実行しているコンピュートでは、Photonはデフォルトで有効になっています。

Photonアクセラレーションを有効または無効にするには、[Photonアクセラレータを使用] チェックボックスを選択します。Photonの詳細については、「 Photonとは」を参照してください。

ワーカーノードタイプ

コンピュート リソースは、1 つのドライバー ノードと 0 個以上のワーカー ノードで構成されます。 ドライバーノードとワーカーノードに別々のクラウドプロバイダーインスタンスタイプを選択できますが、デフォルトでは、ドライバーノードはワーカーノードと同じインスタンスタイプを使用します。 ドライバー ノードの設定は、[ 高度なパフォーマンス ] セクションの下にあります。

インスタンスタイプのファミリーが異なれば、メモリ集約型またはコンピュート集約型のワークロードなど、さまざまなユースケースに適合します。 ワーカーノードまたはドライバーノードとして使用するプールを選択することもできます。

重要

ドライバータイプとしてスポットインスタンスを含むプールは使用しないでください。 オンデマンド ドライバーの種類を選択して、ドライバーが再利用されないようにします。 「プールへの接続」を参照してください。

マルチノードのコンピュートでは、コンピュートリソースが正しく機能するために必要な Spark エグゼキューターやその他のサービスをワーカーノードは実行します。Spark を使用してワークロードを分散すると、すべての分散処理がワーカーノードで行われます。Databricks では、ワーカーノードごとに 1 つのエグゼキューターを実行します。そのため、エグゼキューターとワーカーという用語は、Databricks アーキテクチャのコンテキストでは同じ意味で使用されます。

ヒント

Spark ジョブを実行するには、少なくとも 1 つのワーカーノードが必要です。コンピュートリソースのワーカーがゼロの場合、ドライバーノードで Spark 以外のコマンドは実行できますが、Spark コマンドは失敗します。

ワーカーノードのIPアドレス

Databricks は、それぞれ 2 つのプライベート IP アドレスを持つワーカーノードを起動します。ノードのプライマリプライベート IP アドレスは、Databricks の内部トラフィックをホストします。セカンダリプライベート IP アドレスは、クラスター内通信のために Spark コンテナーで使用されます。このモデルにより、Databricks では同じワークスペース内の複数のコンピュートリソース間の分離が可能となります。

GPUインスタンスタイプ

ディープラーニングに関連するタスクなど、高いパフォーマンスを必要とする計算量が多いタスクの場合、Databricks はグラフィックス処理装置（GPU）で高速化されたコンピュートリソースをサポートします。詳細については、「GPU対応コンピュート」を参照してください。

Databricksは、Amazon EC2 P2インスタンスを使用したコンピュートのスピンアップをサポートしなくなりました。

AWS Gravitonインスタンスタイプ

Databricks は AWS Graviton のインスタンスをサポートしています。AWS Graviton インスタンスは、Arm64 命令セットアーキテクチャに基づいて構築された AWS 設計の Graviton プロセッサを使用しています。AWS によると、これらのプロセッサを搭載したインスタンスタイプは、Amazon EC2 のどのインスタンスタイプのなかで最も優れた価格性能比を提供します。Graviton インスタンスタイプを使用するには、 ワーカータイプ、 ドライバータイプ、またはその両方で使用可能な AWS Graviton インスタンスタイプのいずれかを選択します。

Databricksは、以下のAWS Graviton対応のコンピュートをサポートします：

  • Photon以外の場合Databricks Runtime 9.1 LTS以上、Photonの場合、Databricks Runtime 10.2 (EoS) 以上。

  • Databricks Runtime 15.4 LTS for Machine Learning で、Databricks Runtime for Machine Learning の場合。

  • すべてのAWSリージョン。ただし、すべてのインスタンスタイプがすべてのリージョンで利用できるわけではないことに注意してください。リージョンでは利用できないインスタンスタイプをワークスペースに選択すると、コンピュート作成が失敗します。

  • AWS Graviton2およびGraviton3プロセッサ対応。

注：

Delta Live Tablesは、Graviton対応コンピュートではサポートされていません。

ARM64 ISA の制限事項

  • 浮動小数点の精度の変更：加算、減算、乗算、除算などの一般的な演算では精度は変更されません。sinやcosなどの単一の三角形関数の場合、Intelインスタンスとの精度の差の上限は1.11e-16です。

  • サードパーティのサポート：ISAの変更は、サードパーティのツールやライブラリのサポートに何らかの影響を与える可能性があります。

  • 混合インスタンスコンピュート：Databricksでは、AWS Gravitonインスタンスタイプと非AWS Gravitonインスタンスタイプの混在はサポートされていません。各タイプには異なるDatabricks Runtimeが必要であるためです。

Gravitonの制限

次の機能はAWS Gravitonインスタンスタイプをサポートしていません。

  • Python UDF（Python UDFはDatabricks Runtime 15.2以降で使用できます）

  • Databricks Container Services

  • Delta Live Tables

  • Databricks SQL

  • AWS GovCloud上のDatabricks

  • WebターミナルからGitフォルダ内のファイルを含むワークスペースファイルへのアクセス

AWSフリートインスタンスタイプ

注：

ワークスペースが2023年5月より前に作成された場合は、フリートインスタンスタイプにアクセスできるようにIAMロールの権限を更新する必要がある場合があります。詳細については、フリートインスタンスタイプの有効化を参照してください。

フリートインスタンスタイプは、同じサイズの利用可能な最適なインスタンスタイプに自動的に解決される可変インスタンスタイプです。

たとえば、フリートインスタンスタイプ m-fleet.xlarge を選択した場合、ノードは、その時点でスポット容量と価格が最も優れた汎用インスタンスタイプの .xlarge に割り当てられます。コンピュートリソースが解決されるインスタンスタイプは、常に選択したフリートインスタンスタイプと同じメモリとコア数を持ちます。

フリートインスタンスタイプは、AWS のスポットプレイスメントスコア API を使用して、コンピュートリソースに最適で最も成功する可能性が高いアベイラビリティゾーンを起動時に選択します。

フリートの制限

  • スポットインスタンスの入札率を API または JSON を使用して更新しても、ワーカーノードタイプがフリートインスタンスタイプに設定されている場合は効果がありません。 これは、スポット価格の参照ポイントとして使用するオンデマンドインスタンスが 1 つも存在しないためです。

  • フリートインスタンスは GPU インスタンスをサポートしていません。

  • ごく一部の古いワークスペースでは、まだフリートインスタンスタイプをサポートしていません。ワークスペースがこのような場合は、フリートインスタンスタイプを使用してコンピュートまたはインスタンスプールを作成しようとしたときに、このことを示すエラーが表示されます。私たちは、残りのワークスペースにサポートを提供できるよう取り組んでいます。

シングルノードコンピュート

「単一ノード」チェック・ボックスを使用すると、単一ノード・コンピュート・リソースを作成できます。

シングルノードコンピュートは、少量のデータまたはシングルノードの機械学習ライブラリなどの非分散ワークロードを使用するジョブを対象としています。マルチノードコンピュートは、作業負荷が分散された大規模なジョブに使用する必要があります。

シングルノードのプロパティ

シングルノードのコンピュートリソースには次のプロパティが含まれます。

  • Sparkをローカルで実行します。

  • ドライバーはマスターとワーカーの両方の役割を果たし、ワーカーノードはありません。

  • コンピュートリソースの論理コアごとに 1 つのエグゼキュータースレッドを生成し、ドライバー用に 1 コアを引いたものです。

  • すべてのstderr、 stdout、およびlog4jログ出力をドライバーログに保存します。

  • マルチノードのコンピュートリソースに変換することはできません。

単一ノードまたは複数ノードの選択

シングルノードとマルチノードのコンピュートのどちらを使用するかは、ユースケースに応じて決定してください。

  • 大規模なデータ処理では、シングルノードのコンピュートリソースのリソースが枯渇してしまいます。このようなワークロードの場合、Databricks ではマルチノードのコンピュートの使用を推奨しています。

  • シングルノードのコンピュートは共有できるように設計されていません。リソースの競合を回避するために、コンピュートを共有する必要がある場合は、Databricks ではマルチノードのコンピュートリソースを使用することを推奨しています。

  • マルチノードのコンピュートリソースを 0 ワーカーにスケーリングすることはできません。代わりにシングルノードのコンピュートを使用してください。

  • 単一ノードコンピュートはプロセス分離と互換性がありません。

  • GPUスケジューリングは単一ノードコンピュートでは有効になっていません。

  • 単一ノードコンピュートの場合、SparkはUDT列を含むParquetファイルを読み取ることができません。次のエラーメッセージが表示されます。

    The Spark driver has stopped unexpectedly and is restarting. Your notebook will be automatically reattached.

    この問題を回避するには、ネイティブのParquetリーダーを無効にします。

    spark.conf.set("spark.databricks.io.parquet.nativeReader.enabled", False)

Enable オートスケール

「オートスケールを有効にする」をチェックすると、コンピュートリソースのワーカーの最小値と最大値を指定できます。その後で、ジョブの実行に必要な適切な数のワーカーを Databricks は選択します。

コンピュートリソースがオートスケールするワーカーの最小数と最大数を設定するには、ワーカータイプドロップダウンの横にあるMinフィールドとMaxフィールドを使用します。

オートスケールを有効にしない場合は、[ワーカータイプ] ドロップダウンの横にある [ワーカー] フィールドに固定数のワーカーを入力する必要があります。

注：

コンピュートリソースが実行中の場合、コンピュートの詳細ページに割り当てられたワーカーの数が表示されます。割り当てられたワーカーの数をワーカーの設定と比較し、必要に応じて調整を行うことができます。

オートスケールのメリット

オートスケールを使用すると、Databricksはジョブの特性を考慮してワーカーを動的にアカウントに再割り当てします。パイプラインの特定の部分は他の部分よりも計算負荷が高い場合があり、Databricksはジョブのこれらのフェーズ中にワーカーを自動的に追加（さらに、ワーカーが不要になったときにワーカーを削除）します。

オートスケーリングを使用すると、ワークロードに合わせてコンピュートをプロビジョニングする必要がないため、使用率を簡単に上げられます。これは、要件が時間の経過と共に変化するワークロード（1日の間にデータセットを探索するなど）の場合に特に当てはまりますが、プロビジョニング要件が不明な1回限りの短いワークロードの場合に当てはまります。オートスケーリングには次の2つの利点があります。

  • ワークロードは、固定サイズのプロビジョニング不足のコンピュートリソースと比較して高速に実行できます。

  • オートスケールを使うことで、静的にサイズ調整されたコンピュートリソースと比較して全体的なコストを削減できます。

コンピュートリソースの固定サイズとワークロードに応じて、オートスケールでは、これらの利点の一方または両方が同時に実現されます。コンピュートのサイズは、クラウドプロバイダーがインスタンスを終了するときに選択されたワーカーの最小数を下回る可能性があります。この場合、Databricks は、ワーカーの最小数を維持するために、インスタンスの再プロビジョニングを継続的に再試行します。

注：

オートスケールはspark-submitジョブでは使用できません。

注：

コンピュートのオートスケーリングは、構造化ストリーミングワークロードのクラスターサイズのスケールダウンに対して制限があります。Databricksでは、ストリーミングワークロードの強化オートスケーリングでDelta Live Tablesを使用することを推奨しています。「強化オートスケールを使用してDelta Live Tablesパイプラインのクラスター使用率を最適化する」を参照してください。

オートスケールの動作

プレミアムプラン以上のワークスペースでは、最適化された自動スケーリングが使用されます。スタンダードプランのワークスペースでは、標準の自動スケーリングが使用されます。

最適化されたオートスケールには、次の特性があります。

  • 2つのステップで最小から最大にスケールアップします。

  • コンピュートリソースがアイドル状態になくても、シャッフルファイルの状態を調べることでスケールダウンできます。

  • 現在のノードの割合に基づいてスケールダウンします。

  • ジョブコンピュートでは、コンピュートリソースが過去 40 秒間に十分に活用されていない場合はスケールダウンします。

  • All-Purpose コンピュートは、過去 150 秒間にコンピュートリソースが十分に活用されていない場合にスケールダウンします。

  • spark.databricks.aggressiveWindowDownS Spark 構成プロパティは、コンピュートがダウンスケーリングの決定を行う頻度を秒単位で指定します。値を大きくすると、コンピュートのスケールダウンが遅くなります。最大値は600です。

標準プランのワークスペースでは標準のオートスケールが使用されます。標準のオートスケールには次の特性があります。

  • まず8ノードを追加します。その後、指数関数的にスケールアップし、最大値に達するまでに必要なステップ数を踏みます。

  • ノードの90%が10分間ビジー状態でなく、コンピュートも30秒以上アイドル状態である場合にスケールダウンします。

  • 1 ノードから指数関数的にスケールダウンします。

プールのついたオートスケール

コンピュートリソースをプールに接続する場合は、次の点を考慮してください。

  • リクエストされたコンピュートサイズが、プール内のアイドル状態のインスタンスの最小数以下であることを確認してください。大きい場合、コンピュートの起動時間は、プールを使用しないコンピュートと同じになります。

  • コンピュートの最大サイズがプールの最大容量以下であることを確認してください。大きい場合、コンピュートの作成は失敗します。

オートスケールの例

静的コンピュートリソースをオートスケールするように再構成すると、Databricks はすぐにコンピュートリソースのサイズを最小値と最大値の範囲内で変更し、オートスケールを開始します。例として、次の表は、5～10 ノードの間でオートスケールするようにコンピュートリソースを再構成した場合に、特定の初期サイズのコンピュートリソースに何が起こるかを示しています。

初期サイズ

再構成後のサイズ

6

6

12

10

3

5

パフォーマンスの詳細設定

次の設定は、単純な形式のコンピュートUIの[ 高度なパフォーマンス ]セクションの下に表示されます。

スポットインスタンス

スポットインスタンスを使用するかどうかを指定するには、[Advanced performance] (アドバンストパフォーマンス) の [Use spot instance] (スポットインスタンスを使用) チェックボックスをオンにします。 スポット価格AWSを参照してください。

azure:

#### <a id="spot-instances"></a> Spot instances

To save cost, you can choose to use [spot instances, also known as Azure Spot VMs](https://learn.microsoft.com/azure/virtual-machines/spot-vms) by checking the **Spot instances** checkbox.

![Configure spot](/_static/images/clusters/spot-azure.png)

The first instance will always be on-demand (the driver node is always on-demand) and subsequent instances will be spot instances.

If instances are evicted due to unavailability, <Databricks> will attempt to acquire new spot instances to replace the evicted instances. If spot instances can't be acquired, on-demand instances are deployed to replace the evicted instances. This on-demand failback is only supported for spot instances that have been fully acquired and are running. Spot instances that fail during setup are not automatically replaced.

Additionally, when new nodes are added to existing compute resources, <Databricks> attempts to acquire spot instances for those nodes.

自動終了

コンピュートの自動終了は、 Advanced performance セクションで設定できます。 コンピュートの作成時に、コンピュート リソースを終了する非アクティブ期間を分単位で指定します。

現在の時刻とコンピュートリソースで最後のコマンドが実行された時刻の差が指定された非アクティブ期間を超える場合、Databricks はそのコンピュートを自動的に終了します。コンピュートの終了の詳細についてのリソースは、「コンピュートの終了」を参照してください。

ドライバーの種類

[高度なパフォーマンス] セクションでドライバーの種類を選択できます。ドライバー ノードは、コンピュート リソースに接続されているすべてのノートブックの状態情報を保持します。 ドライバー ノードは、SparkContext も保持し、コンピュート リソース上のノートブックまたはライブラリから実行するすべてのコマンドを解釈し、Apache Spark Sparkエグゼキューターと調整する マスターを実行します。

ドライバーノードタイプのデフォルト値は、ワーカーノードタイプと同じです。Sparkワーカーから大量のデータをcollect()により収集してノートブックで分析する場合は、より多くのメモリを備えたより大きなドライバーノードの種類を選択できます。

ヒント

ドライバーノードは、アタッチされているノートブックのすべての状態情報を保持するため、未使用のノートブックは必ずドライバーノードからデタッチしてください。

タグ

タグを使用すると、組織内のさまざまなグループで使用されるコンピュート リソースのコストを簡単に監視できます。 コンピュートを作成するときにキーと値のペアとしてタグを指定すると、 Databricks これらのタグを VM やディスク ボリュームなどのクラウド リソースに適用し、 DBU 使用状況レポートにも適用します。

プールから起動されたコンピュートの場合、カスタムタグはDBU使用状況レポートにのみ適用され、クラウドリソースには伝わりません。

プールとコンピュートのタグタイプがどのように連携するかについての詳細は、タグを使用した属性の使用を参照してください

コンピュートリソースにタグを追加する方法は次のとおりです。

  1. [タグ] セクションで、各カスタムタグのキーと値のペアを追加します。

  2. [追加] をクリックします。

詳細設定

次の設定は、シンプル フォーム コンピュート UI の [詳細設定 ] セクションの下に表示されます。

アクセスモード

アクセス モードは、コンピュート リソースを使用できるユーザーと、コンピュート リソースを使用してアクセスできるデータを決定するセキュリティ機能です。 Databricks内のすべてのコンピュート リソースにはアクセス モードがあります。アクセスモードの設定は、シンプルフォームのコンピュートUIの [詳細設定 ]セクションにあります。

アクセスモードの選択は Auto by Default で、選択した Databricks Runtimeに基づいてアクセスモードが自動的に選択されます。 機械学習ランタイムと Databricks ランタイムが 14.3 より低い デフォルトから Dedicated に、それ以外の場合は Standard が使用されます。

Databricks では、すべてのワークロードに標準アクセス モードを使用することをお勧めします。 専用アクセスモードは、必要な機能が標準アクセスモードでサポートされていない場合にのみ使用してください。

アクセスモード

ユーザーに表示

UCサポート

対応言語

注

専用 (以前のシングルユーザー)

いつも

あり

Python、SQL、Scala、R

1 人のユーザーまたはグループに割り当てて使用できます。

スタンダード(旧共有)

いつも

あり

Python、 SQL、 Scala ( Databricks Runtime 13.3 LTS 以降を使用した Unity Catalog 対応コンピュート)

ユーザー間でデータを分離することにより、複数のユーザーが使用できます。

これらの各アクセス モードの機能サポートの詳細については、「 Unity Catalogのコンピュート アクセス モードの制限」を参照してください。

注：

Databricks Runtime 13.3 LTS以降では、initスクリプトとライブラリはすべてのアクセスモードでサポートされています。要件とサポートのレベルは異なります。 「initスクリプトはどこでインストールできますか?」を参照してください。 および コンピュートスコープのライブラリ。

インスタンスプロファイル

注：

DatabricksUnity Catalogに接続するにはS3 インスタンスプロファイルの代わりに外部ロケーションを使用することをお勧めします。Unity Catalog は、アカウント内の複数のワークスペースにわたるデータアクセスを一元的に管理および監査するための場所を提供することで、データのセキュリティとガバナンスを簡素化します。 「Unity Catalog を使用してクラウド オブジェクト ストレージとサービスに接続する」を参照してください。

AWSキーを使用せずにAWSリソースに安全にアクセスするには、インスタンスプロファイルを使用してDatabricksコンピュートを起動できます。インスタンスプロファイルを作成および設定する方法については、「チュートリアル：インスタンスプロファイルを使用したS3アクセスの設定」を参照してください。インスタンスプロファイルを作成したら、[インスタンスプロファイル]ドロップダウンリストで選択します。

コンピュートリソースを起動したら、次のコマンドを使用して S3 バケットにアクセスできることを確認してください。コマンドが成功すると、そのコンピュートリソースは S3 バケットにアクセスできるようになります。

 dbutils.fs.ls("s3a://<s3-bucket-name>/")

警告

コンピュートリソースがインスタンスプロファイルと共に起動すると、このコンピュートリソースへのアタッチ権限を持つユーザーであれば誰でも、このロールによって制御されるベースのリソースにアクセスすることができます。不要なアクセスから保護するために、コンピュート権限を使用してコンピュートリソースへに対する権限を制限してください。

可用性ゾーン

アベイラビリティーゾーンの設定を見つけるには、「 Advanced 」セクションを開き、「 Instances」 タブをクリックします。 この設定では、コンピュート リソースで使用するアベイラビリティーゾーン (AZ) を指定できます。 デフォルトでは、この設定は auto に設定されており、ワークスペースサブネットで使用可能な IP に基づいて AZ が自動的に選択されます。 自動 AZ は、AWS が容量不足エラーを返した場合、他のアベイラビリティーゾーンで再試行します。

注：

Auto-AZ はコンピュート起動時にのみ動作します。コンピュートリソースが起動した後、コンピュートリソースが終了または再起動されるまで、すべてのノードは元のアベイラビリティーゾーンに残ります。

コンピュートリソースに特定の AZ を選択する方法は、主に特定のアベイラビリティゾーンのリザーブドインスタンスを組織が購入している場合に便利です。AWS アベイラビリティゾーンの詳細についてお読みください。

オートスケール ローカル ストレージを有効にする

「オートスケール・ローカル・ストレージを有効にする」を構成し、「詳細」セクションを開き、「インスタンス」タブをクリックします。

コンピュート作成時に固定数のEBSボリュームを割り当てたくない場合は、オートスケールローカルストレージを使用します。Databricksではローカルストレージをオートスケールするため、使用コンピュートのSparkワーカーで利用可能なディスクの空き容量が監視されます。ディスクでのワーカーの実行速度が過度に低くなり始めると、Databricksでは容量不足に陥る前に、新しいEBSボリュームがワーカーに自動的にアタッチされます。EBSボリュームは、インスタンスごとに合計5 TBのディスク容量（インスタンスのローカルストレージを含む）を上限としてアタッチされます。

インスタンスにアタッチされたEBSボリュームは、インスタンスがAWSに返却されたときにのみデタッチされます。つまり、EBSボリュームは、実行中のコンピュートの一部である限り、インスタンスから切り離されることはありません。EBSの使用量をスケールダウンするために、Databricksは、オートスケールコンピュートまたは自動ターミネーションで構成されたコンピュートでこの機能を使用することを推奨します。

注：

Databricks は Amazon EBS GP3 ボリュームを使用して、インスタンスのローカルストレージを拡張します。 これらのボリュームの デフォルトの AWS 容量制限 は 50 TiB です。 この制限に達しないようにするには、管理者は使用要件に基づいてこの制限の引き上げをリクエストする必要があります。

EBS ボリューム

このセクションでは、ワーカーノードのデフォルトのEBSボリューム設定、シャッフルボリュームの追加方法、およびDatabricksがEBSボリュームを自動的に割り当てるようにコンピュートを構成する方法について説明します。

EBS ボリュームを設定するには、コンピュートをオートスケールローカルストレージで有効にしないでください。 コンピュート構成の「詳細」の下にある「インスタンス」タブをクリックし、「EBS ボリュームタイプ」ドロップダウンリストでオプションを選択します。

デフォルトのEBSボリューム

Databricksは、次のようにすべてのワーカーノードに対してEBSボリュームをプロビジョニングします。

  • ホストオペレーティングシステムとDatabricks内部サービスによって使用される、30 GBの暗号化されたEBSインスタンスルートボリューム。

  • Sparkワーカーが使用する150 GBの暗号化されたEBSコンテナルートボリューム。これは、Sparkサービスとログをホストします。

  • （HIPAAのみ）Databricks内部サービスのログを保存する75 GBの暗号化されたEBSワーカーログボリューム。

EBSシャッフルボリュームの追加

シャッフルボリュームを追加するには、[EBSボリュームタイプ] ドロップダウンリストで [汎用SSDボリューム] を選択します。

デフォルトでは、Sparkシャッフルの出力内容はインスタンスのローカルディスクに送信されます。インスタンスがローカルディスクを持たないタイプである場合や、Sparkシャッフルのストレージ容量を増やしたい場合は、追加のEBSボリュームを指定できます。この措置は、大きなシャッフル出力を生成するSparkジョブの実行において、ディスク容量不足エラーが発生する事態を回避したい場合に、特に有効です。

Databricksは、オンデマンドインスタンスとスポットインスタンスの両方でこれらのEBSボリュームを暗号化します。AWS EBSボリュームの詳細についてお読みください。

必要に応じて、Databricks EBSボリュームを顧客マネージドキーで暗号化する

オプションとして、カスタマが管理するキーでコンピュートEBSボリュームを暗号化することができます。

暗号化用のカスタマーマネージドキーを参照してください。

AWS EBSの制限

AWS EBSの上限が、デプロイされたすべてのコンピュートですべてのワーカーのランタイム要件を満たすのに十分であることを確認してください。デフォルトのEBS制限とその変更方法については、「Amazon Elastic Block Store（EBS）の制限」を参照してください。

AWS EBS SSDボリュームタイプ

AWS EBS SSDボリュームタイプとしてgp2またはgp3を選択します。この操作について詳しくは、「SSDストレージの管理」を参照してください。Databricksでは、gp2よりもコスト削減できるgp3への切り替えを推奨しています。

注：

デフォルトでは、Databricks構成はgp3ボリュームのIOPSとスループットIOPSを、同じボリュームサイズのgp2ボリュームの最大パフォーマンスと一致するように設定されます。

gp2およびgp3の技術情報については、「Amazon EBSボリュームタイプ」を参照してください。

ローカルディスクの暗号化

プレビュー

この機能はパブリックプレビュー段階です。

コンピュートを実行するために使用するインスタンスタイプによっては、ディスクがローカルに接続されている場合があります。Databricks は、これらのローカルに接続されたディスクにシャッフルデータまたは一時データを保存する場合があります。コンピュートリソースのローカルディスクに一時的に保存されているシャッフルデータを含め、保存中のすべてのデータをすべてのストレージタイプで確実に暗号化するには、ローカルディスク暗号化を有効にします。

重要

ローカルボリュームとの間で暗号化されたデータを読み書きするとパフォーマンスに影響を与え、ワークロードの実行が遅くなる可能性があります。

ローカルディスクの暗号化が有効な場合、Databricksは各コンピュートノードに固有の暗号化キーをローカルに生成し、ローカルディスクに保存されたすべてのデータを暗号化するために使用します。キーのスコープは各コンピュートノードに対してローカルであり、コンピュートノード自体と共に破棄されます。鍵の有効期間中、鍵は暗号化と復号化のためにメモリに存在し、ディスクに暗号化されて保存されます。

ローカルディスクの暗号化を有効にするには、クラスターAPIを使用する必要があります。コンピュートの作成または編集中に、enable_local_disk_encryptionをtrueに設定します。

Spark の構成

Sparkジョブを微調整するために、カスタムSpark構成プロパティを指定できます。

  1. コンピュートの設定ページで、[ 詳細設定 ] トグルをクリックします。

  2. [Spark] タブをクリックします。

    Spark構成

    Spark構成では、1行に1つのキーと値のペアとして設定プロパティを入力します。

クラスターAPIを使用してコンピュートを構成する場合は、クラスター作成APIまたはクラスター更新APIのspark_confフィールドでSparkプロパティを設定します。

ワークスペース管理者はコンピュートポリシーを使用してコンピュートにSpark構成を適用することができます。

シークレットからSpark構成プロパティを取得する

Databricksでは、パスワードなどの機密情報をプレーンテキストではなくシークレットに格納することをお勧めします。Spark構成でシークレットを参照するには、次の構文を使用します。

spark.<property-name> {{secrets/<scope-name>/<secret-name>}}

たとえば、passwordというSpark構成プロパティをsecrets/acme_app/passwordに保存されているシークレットの値に設定するには、次のようにします。

spark.password {{secrets/acme-app/password}}

詳細については、「 シークレットの管理」を参照してください。

環境変数

コンピュートリソース上で実行されるinitスクリプトからアクセスできるカスタム環境変数を設定します。Databricks には、initスクリプトで使用できる定義済みの環境変数 も用意されています。これらの定義済み環境変数を上書きすることはできません。

  1. コンピュートの設定ページで、[ 詳細設定 ] トグルをクリックします。

  2. [Spark] タブをクリックします。

  3. [環境変数] フィールドで環境変数を設定します。

    環境変数フィールド

クラスターAPIの作成またはクラスターAPIの更新のspark_env_varsフィールドを使用して環境変数を設定することもできます。

コンピュート log delivery

コンピュートを作成するときに、Spark ドライバーノード、ワーカーノード、イベントのログを配信する場所を指定できます。ログは 5 分ごとに配信され、選択した宛先に 1 時間ごとにアーカイブされます。コンピュートリソースが終了した時点で、コンピュートリソースが終了するまでの間に生成されたすべてのログを配信することを Databricks は保証します。

ログの保存先はコンピュートリソースのcluster_idによって異なります。指定された宛先がdbfs:/cluster-log-deliveryの場合、 0630-191345-leap375のコンピュートログはdbfs:/cluster-log-delivery/0630-191345-leap375に配信されます。

ログの配信場所を設定するには、以下の手順に従ってください。

  1. [コンピュート] ページで、[ 詳細設定 ] トグルをクリックします。

  2. [ロギング] タブをクリックします。

  3. 宛先タイプを選択します。

  4. コンピュートログのパスを入力します。

S3バケットの宛先

S3 の宛先を選択した場合は、バケットにアクセスできるインスタンスプロファイルを使用してコンピュートリソースを設定する必要があります。このインスタンスプロファイルには、 PutObject権限とPutObjectAcl権限の両方が必要です。便宜上、インスタンスプロファイルの例が含まれています。インスタンスプロファイルの設定方法については「インスタンスプロファイルを使用して S3 アクセスを設定する」を参照してください。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::<my-s3-bucket>"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:PutObjectAcl",
        "s3:GetObject",
        "s3:DeleteObject"
      ],
      "Resource": [
        "arn:aws:s3:::<my-s3-bucket>/*"
      ]
    }
  ]
}

注：

この機能は、REST APIでも使用できます。クラスターAPIを参照してください。