次の方法で共有

クラスターの管理

  • [アーティクル]

この記事では、表示、編集、開始、終了、削除、アクセス制御、パフォーマンスとログの監視を含む、Azure Databricks クラスターの管理方法について説明します。

クラスターの表示

ワークスペースにクラスターを表示するには、サイドバーの compute iconコンピューティング クリックします。

左側には、2 つの列 (クラスターがピン留めされているかどうかを示す列とクラスターの状態を示す列) があります。 状態にカーソルを合わせると、詳細情報が表示されます。

クラスターのピン留め

クラスターは、終了してから 30 日後に完全に削除されます。 終了後 30 日以上経過した後も汎用クラスターの構成を維持するには、管理者はクラスターをピン留めすることができます。 最大 100 個のクラスターをピン留めできます。

管理者は、ピン留めアイコンをクリックして、クラスターの一覧またはクラスターの詳細ページからクラスターをピン留めできます。

Clusters API エンドポイントを呼び出して、プログラムでクラスターをピン留めすることもできます。

クラスター構成の JSON ファイルとしての表示

場合によっては、クラスター構成を JSON として表示すると役立つことがあります。 これは、Clusters API を使用して同様のクラスターを作成する場合に特に便利です。 既存のクラスターを表示する場合は、[構成] タブにアクセスし、タブの右上にある [JSON] をクリックします。JSON をコピーして API 呼び出しに貼り付けます。 JSON ビューは読み取り専用です。

クラスターの編集

クラスターの詳細 UI からクラスター構成を編集できます。 Clusters API エンドポイントを呼び出して、プログラムでクラスターを編集することもできます。

注意

  • クラスターにアタッチされたノートブックとジョブは、編集後もアタッチされたままになります。
  • クラスターにインストールされているライブラリは、編集後もインストールされたままになります。
  • 実行中のクラスターの何らかの属性を編集した場合は (クラスターのサイズとアクセス許可を除く)、そのクラスターを再起動する必要があります。 これにより、現在そのクラスターを使用しているユーザーを中断させる可能性があります。
  • 編集できるのは、実行中または終了済みのクラスターだけです。 ただし、クラスターの詳細ページでは、これらの状態にないクラスターの "アクセス許可" を更新できます。

クラスターの複製

既存のクラスターを複製するには、Kebab menu kebab メニュー (3 つのドット メニューとも呼ばれます) から [複製] を選択します。

[複製] を選択すると、クラスター構成が事前に設定されたクラスター作成 UI が開きます。 複製には次の属性が含まれません。

  • クラスターのアクセス許可
  • インストールされているライブラリ
  • アタッチされているノートブック

クラスターへのアクセス制御

管理者設定ページ内のクラスター アクセス制御で、ワークスペース管理者は、きめ細かいクラスター アクセスを他のユーザーに付与できます。 クラスター アクセス制御には、次の 2 種類があります。

  • クラスター作成アクセス許可: ワークスペース管理者は、クラスターの作成を許可するユーザーを選択できます。
  • クラスター レベルのアクセス許可: クラスターの [Can Manage] (管理可能) アクセス許可を持つユーザーは、他のユーザーがそのクラスターへのアタッチ、そのクラスターの再起動、サイズ変更、管理を行うことができるかどうかを構成できます。

クラスターのアクセス許可を編集するには、そのクラスターの Kebab menu kebab メニューで [アクセス許可の編集] を選択します。

クラスター アクセス制御とクラスター レベルのアクセス許可の詳細については、「クラスター アクセス制御」を参照してください。

クラスターを終了する

クラスター リソースを保存するために、クラスターを終了できます。 終了したクラスターの構成は、後で再利用 (またはジョブの場合は自動開始) できるように格納されます。 手動でクラスターを終了することも、指定した非アクティブ期間の後に自動的に終了するようクラスターを構成することもできます。 終了したクラスターの数が 150 を超えると、最も古いクラスターが削除されます。

クラスターがピン留めされていない限り、終了してから 30 日後に、自動的に完全に削除されます。

終了したクラスターは、クラスター名の左側に灰色の円が付加されてクラスター リストに表示されます。

注意

"新しいジョブ クラスター" でジョブを実行すると (通常、これが推奨されます)、クラスターは終了し、ジョブの完了時に再起動することはできません。 一方、終了された "既存の汎用クラスター" で実行するジョブをスケジュールすると、そのクラスターは自動開始されます。

重要

試用版プレミアム ワークスペースを使用している場合、次のときに、実行中のすべてのクラスターが終了します。

  • ワークスペースをフル プレミアムにアップグレードする場合。
  • ワークスペースがアップグレードされず、評価版が期限切れになった場合。

手動終了

クラスターの一覧 (クラスターの行の四角形をクリック) またはクラスターの詳細ページ ([終了] をクリック) からクラスターを手動で終了できます。

自動終了

クラスターに対して自動終了を設定することもできます。 クラスターの作成時に、クラスターを終了するまでの非アクティブな期間を分単位で指定できます。

現在の時刻とクラスターで実行された最後のコマンドの差が、指定された非アクティブ期間を超えると、Azure Databricks はそのクラスターを自動的に終了します。

クラスター上のすべてのコマンド (Spark ジョブ、構造化ストリーミング、JDBC 呼び出しなど) の実行が完了すると、クラスターは非アクティブと見なされます。

警告

  • クラスターでは、DStreams を使用した結果のアクティビティは報告されません。 つまり、DStreams の実行中に自動終了を設定しているクラスターが終了する可能性があります。 DStreams を実行するクラスターの自動終了をオフにするか、構造化ストリーミングの使用を検討してください。
  • 自動終了機能は、ユーザー定義のローカル プロセスではなく、Spark ジョブのみを監視します。 したがって、すべての Spark ジョブが完了すると、ローカル プロセスが実行されている場合でも、クラスターが終了する可能性があります。
  • アイドル状態のクラスターでは、終了する前の非アクティブ期間中に、DBU とクラウド インスタンスの料金が継続的に蓄積されます。

自動終了の構成

クラスターの作成 UI で自動終了を構成できます。 チェック ボックスがオンになっていることを確認し、[非アクティブな分数の ___ 分後に終了する] 設定に分数を入力します。

[自動終了] チェックボックスをオフにするか、非アクティブ期間に 0 を指定することで、自動終了を解除できます。

注意

自動終了は、最新の Spark バージョンで最適にサポートされています。 以前のバージョンの Spark では、クラスター アクティビティのレポートが不正確になる可能性のある制限が確認されていました。 たとえば、JDBC、R、またはストリーミング コマンドを実行しているクラスターで、予定よりも早くクラスターを終了してしまう、古いアクティビティ時間を報告する可能性がありました。 バグの修正や自動終了の機能強化が反映されるように、最新の Spark バージョンにアップグレードしてください。

予期しない終了

手動終了や自動終了の設定の結果としてではなく、予期せずにクラスターが終了することがあります。

終了の理由と修復手順の一覧については、ナレッジ ベースを参照してください。

クラスターを削除する

クラスターを削除すると、クラスターが終了し、その構成も削除されます。 クラスターを削除するには、クラスターの Kebab menu メニューで [削除] を選択します。

警告

この操作を元に戻すことはできません。

ピン留めされたクラスターを削除するには、まず管理者によってピン留めが解除される必要があります。

Clusters API エンドポイントを呼び出して、プログラムでクラスターを削除することもできます。

クラスターを再起動する

以前に終了したクラスターは、クラスターの一覧、クラスターの詳細ページ、またはノートブックから再起動できます。 Clusters API エンドポイントを呼び出して、プログラムでクラスターを開始することもできます。

Azure Databricks では、一意のクラスター ID を使用してクラスターを識別します。 終了したクラスターを開始すると、Databricks は同じ ID でクラスターを再作成し、すべてのライブラリを自動的にインストールして、ノートブックを再アタッチします。

注意

試用版ワークスペースを使用していて、試用期間が終了した場合は、クラスターを開始することはできません。

クラスターを再起動して最新のイメージで更新する

クラスターを再起動すると、コンピューティング リソース コンテナーと VM ホストの最新のイメージが取得されます。 ストリーミング データの処理などで使われる実行時間の長いクラスターの場合、定期的な再起動をスケジュールすることが重要です。

すべてのコンピューティング リソースを定期的に再起動し、最新のイメージ バージョンでイメージを最新の状態に保つことは、ユーザーの責任です。

重要

アカウントまたはワークスペースのコンプライアンス セキュリティ プロファイルを有効にすると、実行時間の長いクラスターは 25 日後に自動的に再起動されます。 Databricks では、ワークスペース管理者がスケジュールされたメンテナンス期間中にクラスターを手動で再起動することをお勧めします。 これにより、自動再起動によってスケジュールされたジョブが中断されるリスクが軽減されます。

ノートブックの例: 長期間実行しているクラスターを検索する

ワークスペース管理者は、各クラスターが実行されている期間を特定するスクリプトを実行し、指定されている日数より古い場合は必要に応じて再起動できます。 このスクリプトは、Azure Databricks でノートブックとして提供されています。

スクリプトの最初の行では、構成パラメーターを定義します。

  • min_age_output: クラスターが実行できる最大日数。 既定値は 1 です。
  • perform_restart: True の場合、スクリプトは経過時間が min_age_output で指定された日数を超えるクラスターを再起動します。 既定値は False で、実行時間の長いクラスターの識別だけを行い、再起動しません。
  • secret_configuration: REPLACE_WITH_SCOPE と REPLACE_WITH_KEY は、シークレット スコープとキー名に置き換えます。 シークレットの設定について詳しくは、ノートブックをご覧ください。

警告

perform_restart を True に設定すると、スクリプトは対象となるクラスターを自動的に再起動するので、アクティブなジョブが失敗したり、開いているノートブックがリセットされたりする可能性があります。 ワークスペースのビジネス クリティカルなジョブが中断するリスクを軽減するため、予定メンテナンス期間を計画し、ワークスペースのユーザーに必ずお知らせください。

実行時間の長いクラスター ノートブックを特定し、必要に応じて再起動する

ノートブックを入手

ジョブと JDBC/ODBC クエリのクラスターの自動開始

終了済みクラスターに割り当てられたジョブが実行されるようにスケジュールされている場合、または JDBC/ODBC インターフェイスから終了したクラスターに接続する場合、クラスターは自動的に再起動されます。 「ジョブの作成」と JDBC 接続に関するページを参照してください。

クラスターの自動開始を使用すると、スケジュールされたジョブのクラスターを再起動するように手動で介入しなくても、クラスターを自動的に終了するように構成できます。 さらに、終了したクラスターで実行するジョブをスケジュールすることで、クラスターの初期化をスケジュールすることもできます。

クラスターを自動的に再起動する前に、クラスターとジョブのアクセス制御のアクセス許可がチェックされます。

注意

クラスターが Azure Databricks プラットフォーム バージョン 2.70 以前で作成された場合、自動開始は利用できません。終了したクラスターで実行するようにスケジュールされたジョブは失敗します。

Apache Spark UI でのクラスター情報の表示

[クラスターの詳細] ページの [Spark UI] タブを選択して、Spark ジョブに関する詳細情報を表示できます。

終了したクラスターを再起動した場合、Spark UI には、終了したクラスターの履歴情報ではなく、再起動したクラスターの情報が表示されます。

クラスター ログの表示

Azure Databricks では、次の 3 種類のクラスター関連アクティビティのログ記録が表示されます。

  • クラスターのイベント ログ。作成、終了、構成の編集などのクラスター ライフサイクル イベントをキャプチャします。
  • Apache Spark ドライバーとワーカー ログ。デバッグに使用できます。
  • クラスター init スクリプト ログ。init スクリプトのデバッグに役立ちます。

このセクションでは、クラスター イベント ログとドライバーおよびワーカー ログについて説明します。 init スクリプトのログの詳細については、「init スクリプト ログ」を参照してください。

クラスター イベント ログ

クラスター イベント ログには、ユーザー操作によって手動でトリガーされるか、Azure Databricks によって自動的にトリガーされる、重要なクラスター ライフサイクル イベントが表示されます。 このようなイベントは、クラスター全体とクラスター内で実行されているジョブの動作に影響します。

サポートされているイベントの種類については、Clusters API データ構造体に関するページを参照してください。

イベントは 60 日間保存されます。これは、Azure Databricks の他のデータ保持期間と同程度です。

クラスター イベント ログの表示

クラスターのイベント ログを表示するには、クラスターの詳細ページで [イベント ログ] タブを選択します。

イベントの詳細については、ログでその行をクリックし、[JSON] タブをクリックして詳細を確認してください。

クラスター ドライバーとワーカー ログ

ノートブック、ジョブ、ライブラリから print ステートメントおよび log ステートメントを実行することによって、Spark ドライバー ログにアクセスできます。 これらのログ ファイルには、[クラスターの詳細] ページの [ドライバー ログ] タブからアクセスできます。 ログ ファイルをダウンロードするには、その名前をクリックします。

これらのログには、次の 3 つの出力があります。

  • 標準出力
  • 標準エラー
  • Log4j ログ

Spark ワーカー ログを表示するには、[Spark UI] タブを使用します。クラスターのログ配信場所を構成することもできます。 指定した場所には、ワーカー ログとクラスター ログの両方が配信されます。

パフォーマンスの監視

Azure Databricks クラスターのパフォーマンスを監視できるようにするため、Azure Databricks ではクラスターの詳細ページからメトリックにアクセスできます。 Databricks Runtime 12.2 以下の場合、Azure Databricks は Ganglia メトリックへのアクセスを提供します。 Databricks Runtime 13.0 以降の場合、クラスター メトリックは Azure Databricks によって提供されます。

さらに、Azure の監視プラットフォームである Azure Monitor の Log Analytics ワークスペースにメトリックを送信するように Azure Databricks クラスターを構成することもできます。

また、クラスター ノードに Datadog エージェントをインストールして、Datadog メトリックを Datadog アカウントに送信することもできます。

クラスターのメトリック

クラスター メトリックは、Databricks Runtime 13.0 以降の既定の監視ツールです。 クラスター メトリック UI にアクセスするには、クラスターの詳細ページの [メトリック] タブに移動します。

日付の選択フィルターを使用して時間の範囲を選択することで、履歴メトリックを表示できます。 メトリックは 1 分ごとに収集されます。 [最新の情報に更新] ボタンをクリックして、最新のメトリックを取得することもできます。 詳細については、「ライブおよび履歴クラスター メトリックの表示」を参照してください。

Ganglia メトリック

注意

Ganglia メトリックは、Databricks Runtime 12.2 以下でのみ使用できます。

Ganglia UI にアクセスするには、クラスターの詳細ページの [メトリック] タブに移動します。 CPU メトリックは、すべての Databricks ランタイムの Ganglia UI で使用できます。 GPU メトリックは、GPU 対応クラスターで使用できます。

ライブ メトリックを表示するには、[GANGLIA UI] リンクをクリックします。

履歴のメトリックを表示するには、スナップショット ファイルをクリックします。 スナップショットには、選択した時刻より前の時間の集計されたメトリックが含まれます。

注意

Ganglia は Docker コンテナーではサポートされていません。 クラスターで Docker コンテナー を使用する場合、Ganglia メトリックは使用できません。

Ganglia メトリック収集を構成する

既定では、Azure Databricks によって 15 分ごとに Ganglia メトリックが収集されます。 収集期間を構成するには、init スクリプトを使用するか、Create new cluster API のspark_env_vars フィールドで、DATABRICKS_GANGLIA_SNAPSHOT_PERIOD_MINUTES 環境変数を設定します。

Azure Monitor

Azure の監視プラットフォームである Azure Monitor の Log Analytics ワークスペースにメトリックを送信するように Azure Databricks クラスターを構成することもできます。 詳細な手順については、「Azure Databricks の監視」を参照してください。

注意

独自の仮想ネットワークに Azure Databricks ワークスペースをデプロイし、Azure Databricks で必要とされないすべての送信トラフィックを拒否するようにネットワーク セキュリティ グループ (NSG) を構成している場合は、"AzureMonitor" サービス タグに対して追加の送信規則を構成する必要があります。

ノートブックの例: Datadog のメトリック

Datadog metrics

クラスター ノードに Datadog エージェントをインストールして、Datadog メトリックを Datadog アカウントに送信できます。 次のノートブックには、クラスター スコープの init スクリプトを使用してクラスターに Datadog エージェントをインストールする方法が示されています。

すべてのクラスターに Datadog エージェントをインストールするには、クラスター ポリシーを使用するクラスター スコープの init スクリプトを管理します。

Datadog エージェントの init スクリプト ノートブックのインストール

ノートブックを入手

スポット インスタンスの使用停止

スポット インスタンスはコストを削減できるため、オンデマンド インスタンスではなくスポット インスタンスを使用してクラスターを作成する方法は、ジョブを実行する一般的な方法です。 ただし、スポット インスタンスは、クラウド プロバイダーのスケジュール メカニズムによってプリエンプトされる場合があります。 スポット インスタンスのプリエンプションによって、次のような実行中のジョブに関する問題が発生する可能性があります。

  • シャッフル フェッチ エラー
  • シャッフル データ損失
  • RDD データ損失
  • ジョブの失敗

これらの問題に対処するために、使用停止を有効にすることができます。 使用停止では、スポット インスタンスを使用停止にする前に、クラウド プロバイダーが通常送信する通知を利用します。 実行プログラムを含むスポット インスタンスがプリエンプション通知を受け取ると、使用停止プロセスはシャッフルと RDD データを正常な実行プログラムに移行しようとします。 最終的なプリエンプションの前の期間は、クラウド プロバイダーに応じて、通常 30 秒から 2 分になります。

Databricks では、使用停止も有効になっている場合に、データ移行を有効にすることを推奨します。 通常、シャッフル フェッチ エラー、シャッフル データ損失、RDD データ損失などのエラーの可能性は、より多くのデータが移行されるにつれて低下します。 データの移行により、再計算やコストの削減にもつながります。

注意

使用停止はベスト エフォートであり、最終プリエンプションの前にすべてのデータを移行できることを保証するものではありません。 使用停止では、実行中のタスクが実行プログラムからシャッフル データをフェッチしている場合、シャッフル フェッチ エラーを防ぐことを保証できません。

使用停止が有効になっていると、スポット インスタンスのプリエンプションによって発生したタスク エラーは、失敗した試行の合計数に追加されません。 失敗の原因はタスクの外部にあり、ジョブの失敗にはならないため、プリエンプションによって発生したタスク エラーは、失敗した場合としてカウントされません。

使用停止を有効にする

クラスターで使用停止を有効にするには、クラスター構成 UI の [詳細オプション] の [Spark] タブに次のプロパティを入力します。 これらのプロパティの詳細については、「Spark の構成」を参照してください。

  • アプリケーションの使用停止を有効にするには、[Spark 構成] フィールドに次のプロパティを入力します。

    spark.decommission.enabled true

  • 使用停止中にシャッフル データ移行を有効にするには、[Spark 構成] フィールドに次のプロパティを入力します。

    spark.storage.decommission.enabled true
spark.storage.decommission.shuffleBlocks.enabled true

  • 使用停止中に RDD キャッシュ データ移行を有効にするには、[Spark 構成] フィールドに次のプロパティを入力します。

    spark.storage.decommission.enabled true
spark.storage.decommission.rddBlocks.enabled true

    注意

    RDD StorageLevel レプリケーションが 1 より大きい値に設定されている場合、Databricks では、RDD によってデータが失われないようにするため、RDD データ移行を有効にすることは推奨されません。

  • ワーカーの使用停止を有効にするには、[環境変数] フィールドに次のプロパティを入力します。

    SPARK_WORKER_OPTS="-Dspark.decommission.enabled=true"

使用停止の状態と失われた理由を UI で表示する

UI からワーカーの使用停止状態にアクセスするには、[Spark クラスター UI - マスター] タブに移動します。

使用停止が完了すると、クラスターの詳細ページの [Spark UI > Executor] タブで Executor の失われた理由を確認できます。