コンピューティング構成リファレンス

2025-05-09

注

この記事の組織では、単純なフォームコンピューティング UI を使用していることを前提としています。単純なフォームの更新の概要については、「単純なフォームを使用してコンピューティングを管理する」を参照してください。

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

単純なコンピューティングフォーム

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

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

次のように、新しい汎用コンピューティングリソースを作成します。

ワークスペースのサイドバーで [コンピューティング] をクリックします。
[コンピューティングの作成] ボタンをクリックします。
コンピューティングリソースを構成します。
Create をクリックしてください。

新しいコンピューティングリソースが自動的に起動し、すぐに使用できるようになります。

コンピューティングポリシー

ポリシーは、ユーザーがコンピューティングリソースを作成するときに使用できる構成オプションを制限するために使用される一連のルールです。ユーザーが 無制限のクラスター作成 エンタイトルメントを持っていない場合、付与されたポリシーを使用してのみコンピューティングリソースを作成できます。

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

既定では、すべてのユーザーが個人用コンピューティング ポリシーにアクセスできるため、単一コンピューターのコンピューティングリソースを簡単に作成できます。パーソナルコンピューティングまたは追加のポリシーにアクセスする必要がある場合は、ワークスペース管理者に連絡してください。

パフォーマンス設定

単純なフォームコンピューティング UI の [パフォーマンス ] セクションに、次の設定が表示されます。

Databricks Runtime のバージョン
Photon アクセラレーションを使用する
ワーカーノードの種類
単一ノードコンピューティング
自動スケールを有効にする
高度なパフォーマンス設定

Databricks Runtime のバージョン

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

汎用コンピューティングの場合は、最新バージョンを使用して、最新の最適化と、コードと事前に読み込まれたパッケージ間の最新の互換性が確保されます。
運用ワークロードを実行するジョブコンピューティングの場合は、長期サポート (LTS) バージョンの Databricks Runtime を使用することを検討してください。 LTS バージョンを使用すると、互換性の問題が発生しないようにし、アップグレードする前にワークロードを十分にテストできます。
データサイエンスおよび機械学習に関するユースケースは、Databricks Runtime ML バージョンを検討してください。

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

Photon は、既定で Databricks Runtime 9.1 LTS 以上を実行しているコンピューティングで有効です。

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

ワーカーノードの種類

コンピューティングリソースは、1 台のドライバーノードと 0 台以上のワーカーノードで構成されます。ドライバーノードとワーカーノードに対して別々のクラウドプロバイダーインスタンスの種類を選択することもできますが、既定では、ドライバーノードではワーカーノードと同じインスタンスの種類が使用されます。ドライバーノードの設定は、[ 高度なパフォーマンス ] セクションの下にあります。

インスタンスの種類の異なるファミリは、メモリ集中型やコンピューティング集中型のワークロードなど、異なるユースケースに適合します。ワーカーまたはドライバーノードとして使用するプールを選択することもできます。

重要

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

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

ヒント

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

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

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

GPU インスタンスの種類

ディープラーニングに関連するものなど、ハイパフォーマンスが要求される、計算が困難なタスクの場合、Azure Databricks ではグラフィックス処理装置 (GPU) によって高速化されたコンピューティングリソースがサポートされます。詳細については、GPU 対応コンピューティングに関するページを参照してください。

Azure Confidential Computing VM

Azure コンフィデンシャルコンピューティング VM の種類は、クラウドオペレーターからのデータを含め、使用中のデータへの不正アクセスを防ぎます。この VM の種類は、規制の厳しい業界や地域だけでなく、クラウド上に機密データを持つ企業にも役立ちます。 Azure のコンフィデンシャルコンピューティングの詳細については、 Azure コンフィデンシャルコンピューティングに関するページを参照してください。

Azure Confidential Computing VM を使用してワークロードを実行するには、ワーカーノードとドライバーノードのドロップダウンで、DC または EC シリーズの VM の種類の中から選択します。詳しくは、 Azure Confidential VM オプションをご覧ください。

単一ノードコンピューティング

[ 単一ノード ] チェックボックスを使用すると、単一ノードのコンピューティングリソースを作成できます。

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

単一ノードのプロパティ

単一ノードコンピューティングリソースには、次のプロパティがあります。

Spark をローカルで実行します。
ドライバーは、ワーカーノードを持たないマスターとワーカーの両方として機能します。
コンピューティングリソースの論理コアごとに、ドライバーの 1 コアを差し引いた 1 つの Executor スレッドを生成します。
すべての 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)
```

自動スケールの有効化

[自動スケールを有効にする] がオンになっている場合は、コンピューティングリソースのワーカーの最小数と最大数を指定できます。その後、Databricks でジョブの実行に必要な適切なワーカー数が選択されます。

コンピューティングリソースが自動スケールするワーカーの最小数と最大数を設定するには、[ワーカーの種類] ドロップダウンの横にある [最小] フィールドと [最大] フィールドを使用します。

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

注

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

自動スケーリングの利点

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

自動スケールを使用すると、ワークロードに合わせてコンピューティングをプロビジョニングする必要がないため、高い使用率を実現しやすくなります。これは特に、(1 日の流れの中でデータセットの探索を行うなど、) 時間の経過とともに要件が変化するワークロードに適用されますが、プロビジョニング要件が不明な 1 回限りの短いワークロードにも適用できます。したがって、自動スケーリングには次の 2 つの利点があります。

プロビジョニング数が不足している一定サイズのコンピューティングリソースと比較して、より高速にワークロードを実行できます。
自動スケーリングでは、静的にサイズ設定されたコンピューティングリソースと比較して、全体的にコストを削減できます。

コンピューティングリソースとワークロードの一定サイズに応じて、自動スケーリングを使用すると、これらの利点の一方または両方を同時に得ることができます。コンピューティングサイズは、クラウドプロバイダーがインスタンスを終了するときに選択されたワーカーの最小数を下回る場合があります。この場合は、最小数のワーカーを維持するために、Azure Databricks によって連続的にインスタンスの再プロビジョニングが再試行されます。

注

自動スケーリングは、spark-submit ジョブには使用できません。

注

コンピューティングの自動スケールには、構造化ストリーミングワークロードのクラスターサイズのスケールダウンに制限があります。 Databricks では、ストリーミングワークロードの自動スケーリングが強化された Lakeflow 宣言型パイプラインを使用することをお勧めします。自動スケーリングを使用した Lakeflow 宣言パイプラインのクラスター使用率の最適化に関するページを参照してください。

自動スケールの動作

Premium プランのワークスペースでは、最適化された自動スケールが使用されます。 Standard 価格プランのワークスペースでは、標準の自動スケーリングを使用します。

最適化された自動スケーリングには、次のような特徴があります。

2 ステップで最小から最大にスケールアップします。
シャッフルファイルの状態を確認することで、コンピューティングリソースがアイドル状態でなくてもスケールダウンできます。
現在のノードの割合に基づいてスケールダウンします。
ジョブコンピューティングでは、コンピューティングリソースの使用率が低い状態が 40 秒間続くとスケールダウンします。
汎用コンピューティングでは、コンピューティングリソースの使用率が低い状態が 150 秒間続くとスケールダウンします。
spark.databricks.aggressiveWindowDownS Spark 構成プロパティは、コンピューティングでスケールダウンの決定が行われる頻度を秒単位で指定します。この値を大きくすると、コンピューティングでのスケールダウンが遅くなります。最大値は 600 です。

標準の自動スケーリングは、Standard プランワークスペースで使用されます。標準の自動スケーリングには、次のような特徴があります。

8 台のノードの追加で開始されます。その後、最大に達するために必要なだけのステップを実行して、指数関数的にスケールアップします。
ノードの 90% が 10 分間ビジー状態ではなく、コンピューティングが 30 秒以上アイドル状態になっている場合にスケールダウンします。
1 台のノードから開始して、指数関数的にスケールダウンします。

プールを使用した自動スケーリング

コンピューティングリソースをプールにアタッチする場合は、次の点を考慮してください。

要求されたコンピューティングサイズが、プール内のアイドル状態のインスタンスの最小数以下になるようにします。より大きい場合、コンピューティングの起動時間は、プールを使用しないコンピューティングと同じになります。

最大コンピューティングサイズが、プールの最大容量以下になるようにします。それより大きい場合、コンピューティングの作成は失敗します。

自動スケーリングの例

静的コンピューティングリソースを自動スケーリングに再構成すると、Azure Databricks では、即座に最小と最大境界内にコンピューティングリソースのサイズを変更してから、自動スケーリングを開始します。例として、次の表では、5 から 10 台のノードの間で自動スケーリングするようにコンピューティングリソースを再構成した場合に、特定の初期サイズを持つコンピューティングリソースがどうなるかを示しています。

初期サイズ	再構成後のサイズ
6	6
12	10
3	5

高度なパフォーマンス設定

次の設定は、単純なフォームコンピューティング UI の [Advanced performance]\(パフォーマンスの詳細設定 \) セクションの下に表示されます。

スポットインスタンス
自動終了
ドライバーの種類

スポットインスタンス

コストを節約するには、[スポットインスタンス] チェックボックスをオンにして、スポットインスタンス (Azure スポット VM とも呼ばれる) を使用することを選択できます。

スポットを構成する

最初のインスタンスは常にオンデマンド (ドライバーノードは常にオンデマンド) であり、後続のインスタンスはスポットインスタンスになります。

使用できないためにインスタンスが削除された場合、Azure Databricks は、削除されたインスタンスを置き換えるために新しいスポットインスタンスの取得を試みます。スポットインスタンスを取得できない場合は、削除されたインスタンスを置き換えるためにオンデマンドインスタンスがデプロイされます。このオンデマンドフェールバックは、完全に取得されて実行されているスポットインスタンスでのみサポートされます。セットアップ中に失敗するスポットインスタンスは自動的に置き換えされません。

さらに、新しいノードが既存のコンピューティングリソースに追加されると、Azure Databricks はそれらのノード用のスポットインスタンスの取得を試みます。

自動終了

コンピューティングの自動終了は、[ 高度なパフォーマンス ] セクションで設定できます。コンピューティングの作成時に、コンピューティングリソースを終了するまでの非アクティブな期間を分単位で指定してください。

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

ドライバーの種類

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

ドライバーノードの種類の既定値は、ワーカーノードの種類と同じです。 Spark ワーカーから多くのデータを collect() し、それらをノートブックで分析することを計画している場合は、より多くのメモリを備えたより大規模なドライバーノードの種類を選択できます。

ヒント

ドライバーノードには、接続されているノートブックのすべての状態情報が保持されるため、使用されていないノートブックはドライバーノードから切断するようにしてください。

詳細設定

単純なフォームコンピューティング UI の [詳細設定 ] セクションに、次の設定が表示されます。

アクセスモード
ローカルストレージの自動スケールを有効にする
ローカルディスクの暗号化
Spark の構成
コンピューティングへの SSH アクセス
環境変数
コンピューティングログ配信

アクセスモード

アクセスモードは、誰がコンピューティングリソースを使用できるかと、その人物がコンピューティングリソースを使用してアクセスできるデータを決定するセキュリティ機能です。 Azure Databricks 内のすべてのコンピューティングリソースはアクセスモードを持っています。アクセスモードの設定は、単純なフォームコンピューティング UI の [詳細設定 ] セクションにあります。

アクセスモードの選択は既定では自動です。つまり、選択した Databricks ランタイムに基づいてアクセスモードが自動的に選択されます。機械学習ランタイムと 14.3 未満の Databricks ランタイムは既定で Dedicated で、それ以外の場合は Standard が使用されます。

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

アクセスモード	ユーザーに表示	UC のサポート	サポートされている言語	メモ
専用（以前は単独ユーザー）	Always (常に)	はい	Python、SQL、Scala、R	1 人のユーザーまたはグループに割り当て、使用できます。
Standard (以前の共有)	Always (常に)	はい	Python、SQL、Scala (Databricks Runtime 13.3 LTS 以降を使用した Unity カタログ対応コンピューティング)	複数のユーザーが、ユーザー間でデータを分離して使用できます。

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

注

Databricks Runtime 13.3 LTS 以上では、init スクリプトとライブラリはすべてのアクセスモードでサポートされています。要件とサポートレベルは異なります。 init スクリプトをインストールできる場所とコンピューティングスコープのライブラリを参照してください。

ローカルストレージの自動スケールを有効にする

多くの場合、特定のジョブに必要となるディスク領域を見積もることは困難です。作成時にコンピューティングに接続するマネージドディスクのギガバイト数を見積もらずに済むように、Azure Databricks では、すべての Azure Databricks コンピューティングでローカルストレージの自動スケーリングが自動的に有効になります。

ローカルストレージの自動スケーリングにより、Azure Databricks はコンピューティングの Spark ワーカーで使用可能な空きディスク領域の量を監視します。ワーカーでディスク領域の量が少なくなり始めると、ディスク領域が枯渇する前に、Databricks によって自動的に新しいマネージドディスクがワーカーに接続されます。ディスクは、仮想マシンごとに最大 5 TB の合計ディスク領域 (仮想マシンの初期ローカルストレージを含む) に接続されます。

仮想マシンにアタッチされたマネージドディスクは、仮想マシンが Azure に返された場合にのみデタッチされます。つまり、マネージドディスクは、実行中のコンピューティングの一部である限り、仮想マシンから切断されません。マネージドディスクの使用量をスケールダウンする場合、Azure Databricks では、自動スケールコンピューティングまたは自動終了を使用して構成されたコンピューティングでこの機能を使用することが推奨されています。

ローカルディスク暗号化

重要

この機能はパブリックプレビュー段階にあります。

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

重要

ローカルボリュームとの間の暗号化されたデータの読み取りと書き込みによるパフォーマンスへの影響により、ワークロードの実行速度が低下する可能性があります。

ローカルディスク暗号化が有効になっている場合、Azure Databricks によって各コンピューティングノードに固有の暗号化キーがローカルで生成されます。これは、ローカルディスクのすべての格納データを暗号化するために使用されます。このキーのスコープは各コンピューティングノードに対してローカルであり、コンピューティングノード自体と共に破棄されます。有効期間中、キーは暗号化と暗号化解除のためにメモリ内に存在し、ディスク上に暗号化されて格納されます。

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

Spark の構成

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

[コンピューティング構成] ページで、[ 詳細設定 ] トグルをクリックします。
[Spark] タブをクリックします。

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

Clusters API を使用してコンピューティングを構成する場合は、spark_confまたはクラスター API の更新のフィールドに 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}}

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

コンピューティングへの SSH アクセス

セキュリティ上の理由から、Azure Databricks では、SSH ポートは既定で閉じられています。 Spark クラスターへの SSH アクセスを有効にする場合は、「ドライバーノードへの SSH 接続」を参照してください。

注

SSH は、ワークスペースが独自の Azure 仮想ネットワークにデプロイされている場合にのみ有効にできます。

環境変数

コンピューティングリソースで実行されている init スクリプトからアクセスできる環境変数を構成します。 Databricks には、init スクリプトで使用できる定義済みの環境変数も用意されています。これらの定義済みの環境変数をオーバーライドすることはできません。

[コンピューティング構成] ページで、[ 詳細設定 ] トグルをクリックします。
[Spark] タブをクリックします。
[環境変数] フィールドに 環境変数 を設定します。

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

コンピューティングログの配信

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

ログの配信場所を構成するには、次のようにします。

コンピューティングページで、[ 詳細設定 ] トグルをクリックします。
[ログ] タブをクリックします。
送信先の種類を選択します。
ログパスを入力します。

Databricks は、ログを格納するために、選択したログパスにコンピューティングのcluster_id名のサブフォルダーを作成します。

たとえば、指定したログパスが /Volumes/catalog/schema/volume場合、 06308418893214 のログは /Volumes/catalog/schema/volume/06308418893214に配信されます。

注

ボリュームへのログの配信はパブリックプレビュー段階であり、 Standard アクセスモードまたは専用アクセスモードがユーザーに割り当てられている Unity カタログ対応コンピューティングでのみサポートされます。この機能は、 専用アクセスモード がグループに割り当てられているコンピューティングではサポートされていません。パスとしてボリュームを選択する場合は、ボリュームに対する READ VOLUME と WRITE VOLUME のアクセス許可があることを確認します。ボリュームに関する特権を参照してください。

注

この機能は、REST API でも使用できます。 Clusters API に関するページを参照してください。

次の方法で共有