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

[アーティクル]
11/21/2024

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

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

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

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

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

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

ポリシー

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

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

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

単一ノードまたはマルチノードコンピューティング

ポリシーに応じて、単一ノード コンピューティングリソースまたはマルチノード コンピューティングリソースの作成を選択できます。

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

単一ノードのプロパティ

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

Spark をローカルで実行します。
ドライバーは、ワーカーノードを持たないマスターとワーカーの両方として機能します。
コンピューティングリソースの論理コアごとに、ドライバーの 1 コアを差し引いた 1 つの Executor スレッドを生成します。
すべての stderr、stdout、および log4j ログ出力をドライバーログに保存します。
マルチノードコンピューティングリソースに変換することはできません。

単一またはマルチノードクラスターを選択する

単一およびマルチノードコンピューティングのどちらかを決定する場合は、ユースケースを考慮してください。

大規模なデータ処理では、単一ノードコンピューティングリソースのリソースを使い果たします。これらのワークロードについては、Databricks でマルチノードコンピューティングを使用することをお勧めします。
単一ノードコンピューティングは、共有するようには設計されていません。リソースの競合を避けるため、コンピューティングを共有する必要がある場合には Databricks でマルチノードコンピューティングリソースを使用することをお勧めします。
マルチノードコンピューティングリソースは、0 個の worker にはスケーリングできません。代わりに単一ノードコンピューティングを使用してください。
単一ノードコンピューティングはプロセス分離との互換性がありません。
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)
```

アクセスモード

アクセスモードは、誰がコンピューティングリソースを使用できるかと、その人物がコンピューティングリソースを使用してアクセスできるデータを決定するセキュリティ機能です。 Azure Databricks 内のすべてのコンピューティングリソースはアクセスモードを持っています。

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

アクセスモード	ユーザーに表示	UC のサポート	サポートされている言語	メモ
1 人のユーザー	Always (常に)	はい	Python、SQL、Scala、R	単一のユーザーのみに割り当てて、使用できるようにします。一部のワークスペースでは、割り当てられたアクセスモードと呼ばれます。
共有済み	常に (Premium プランが必要)	はい	Python (Databricks Runtime 11.3 LTS 以降)、SQL、Scala (Databricks Runtime 13.3 LTS 以降を使用する Unity Catalog 対応コンピューティング上)	複数のユーザーが、ユーザー間でデータを分離して使用できます。
No Isolation (分離なし) 共有	管理者は、管理設定ページでユーザー分離を適用して、このアクセスモードを非表示にできます。	いいえ	Python、SQL、Scala、R	分離なし共有コンピューティングには、関連するアカウントレベルの設定があります。
Custom	非表示 (すべての新しいコンピューティングの場合)	いいえ	Python、SQL、Scala、R	このオプションは、アクセスモードが指定されていない既存のコンピューティングリソースがある場合にのみ表示されます。

アクセスモードをシングルユーザーまたは共有に設定することで、Unity Catalog の要件を満たすように既存のコンピューティングリソースをアップグレードすることができます。 Unity Catalog が有効なワークスペース内のこれらの各アクセスモードでサポートされる機能の詳細については、「Unity Catalog のコンピューティングアクセスモードの制限事項」を参照してください。

Note

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

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 台以上のワーカーノードで構成されます。ドライバーノードとワーカーノードに対して別々のクラウドプロバイダーインスタンスの種類を選択することもできますが、既定では、ドライバーノードではワーカーノードと同じインスタンスの種類が使用されます。インスタンスの種類の異なるファミリは、メモリ集中型やコンピューティング集中型のワークロードなど、異なるユースケースに適合します。

ワーカーまたはドライバーノードとして使用するプールを選択することもできます。 worker の種類としてスポットインスタンスを含むプールのみを使用します。ドライバーが再要求されないようにするには、別のオンデマンドドライバーの種類を選択します。「プールに接続する」を参照してください。

作業者タイプ

マルチノードコンピューティングでは、コンピューティングリソースが適切に機能するために必要な 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 は同じワークスペース内の複数のコンピューティングリソース間で分離を提供できます。

ドライバーの種類

ドライバーノードでは、コンピューティングリソースに接続されているすべてのノートブックの状態情報が保持されます。また、ドライバーノードでは SparkContext が保持され、コンピューティングリソース上のノートブックやライブラリから実行されるコマンドが解釈され、Spark Executor との調整を行う Apache Spark マスターが実行されます。

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

ヒント

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

GPU インスタンスの種類

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

Azure Confidential Computing VM

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

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

スポットインスタンス

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

スポットを構成する

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

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

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

自動スケールの有効化

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

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

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

Note

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

自動スケーリングの利点

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

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

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

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

注意

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

注意

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

自動スケールの動作

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

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

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

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

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

ローカルディスク暗号化

重要

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

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

重要

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

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

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

自動終了

コンピューティングに対して自動終了を設定できます。コンピューティングの作成時に、コンピューティングリソースを終了するまでの非アクティブな期間を分単位で指定してください。

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

Spark の構成

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

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

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

Clusters 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}}

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

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

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

Note

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

環境変数

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

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

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

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

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

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

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

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

Note

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

次の方法で共有

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

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

ポリシー