Dataproc Serverless バッチ ワークロードのモニタリングとトラブルシューティング

このドキュメントでは、Spark UI を使用して Dataproc Serverless for Spark のバッチ ワークロードをモニタリングしてトラブルシューティングする方法について説明します。

Spark UI

Spark UI は、Spark バッチ ワークロード用に Dataproc Serverless から Apache Spark の実行の詳細を収集します。Spark UI 機能はデフォルトで有効になっています。この機能は料金が発生しません。

Spark UI 機能によって収集されたデータは 90 日間保持されます。このウェブ インターフェースを使用すると、永続履歴サーバーを作成せずに Spark ワークロードをモニタリングしてデバッグできます。

注: Spark UI は、Dataproc Serverless インタラクティブ セッションの実行の詳細も収集して表示します。詳細については、Dataproc Serverless インタラクティブ セッションのモニタリングとトラブルシューティングをご覧ください。

必要な Identity and Access Management の権限とロール

バッチ ワークロードで Spark UI 機能を使用するには、次の権限が必要です。

• データ収集の権限: dataproc.batches.sparkApplicationWrite。この権限は、バッチ ワークロードを実行するサービス アカウントに付与する必要があります。この権限は Dataproc Worker ロールに含まれています。このロールは、Dataproc Serverless がデフォルトで使用する Compute Engine のデフォルトのサービス アカウントに自動的に付与されます（Dataproc Serverless サービス アカウントをご覧ください）。ただし、バッチ ワークロードにカスタム サービス アカウントを指定する場合は、そのサービス アカウントに dataproc.batches.sparkApplicationWrite 権限を追加する必要があります（通常は、サービス アカウントに Dataproc Worker ロールを付与します）。

• Spark UI アクセス権限: dataproc.batches.sparkApplicationRead。Google Cloud コンソールの Spark UI にアクセスするには、この権限をユーザーに付与する必要があります。この権限は、Dataproc Viewer　ロール、Dataproc Editor ロールと Dataproc Administrator ロールに含まれています。Google Cloud コンソールで Spark UI を開くには、これらのロールのいずれか、またはこの権限を含むカスタムロールが必要です。

Spark UI を開く

Spark UI ページは、Spark バッチ ワークロード用の Google Cloud コンソールで使用できます。

1. [Dataproc Serverless インタラクティブ セッション] ページに移動します。

   Dataproc バッチに移動

2. バッチ ID をクリックして、バッチの詳細ページを開きます。

3. 上部のメニューで [View Spark UI] をクリックします。

次の場合に、[Spark UI を表示] ボタンが無効になります。

• 必要な権限が付与されていない場合
• [バッチの詳細] ページで [Spark UI を有効にする] チェックボックスをオフにしている場合
• バッチ ワークロードを送信するときに spark.dataproc.appContext.enabled プロパティを false に設定した場合

制限事項

Spark UI は、次の Dataproc Serverless ワークロードをサポートしていません。

• CMEK（顧客管理の暗号鍵）
• Assured Workloads

永続的履歴サーバー

Spark 向け Dataproc Serverless は、ワークロードの実行に必要なコンピューティング リソースを作成し、それらのリソースでワークロードを実行し、ワークロードが終了するとリソースを削除します。ワークロードの指標とイベントは、ワークロードの完了後に保持されません。ただし、永続的履歴サーバー（PHS）を使用すると、ワークロード アプリケーションの履歴（イベントログ）を Cloud Storage に保持できます。

バッチ ワークロードで PHS を使用する手順は次のとおりです。

1. Dataproc 永続的履歴サーバー（PHS）を作成します。

   注: Google Cloud コンソールの [Spark UI] ページでは、Spark ワークロードの実行の詳細が収集されて表示されます。これにより、PHS クラスタを作成しなくてもワークロードをモニタリングしてデバッグできます。

2. ワークロードを送信するときに PHS を指定します。

3. コンポーネント ゲートウェイを使用して PHS に接続し、アプリケーションの詳細、スケジューラ ステージ、タスクレベルの詳細、環境とエグゼキュータの情報を表示します。

Spark 向け Dataproc サーバーレスのログ

Spark 向け Dataproc サーバーレスでは、ロギングがデフォルトで有効になっており、ワークロードが完了した後にワークロード ログが保持されます。Spark 向け Dataproc サーバーレスは、Cloud Logging でワークロード ログを収集します。Dataproc Serverless for Spark のログには、ログ エクスプローラの Cloud Dataproc Batch リソースでアクセスできます。

Dataproc Serverless for Spark のログをクエリする

Google Cloud コンソールのログ エクスプローラには、バッチ ワークロード ログを調べるクエリを作成するためのクエリペインがあります。バッチ ワークロード ログを調べるクエリを作成する手順は次のとおりです。

1. [ログ エクスプローラ] に移動

2. 現在のプロジェクトが選択されています。[プロジェクトのスコープを絞り込む] をクリックして、別のプロジェクトを選択できます。

3. バッチログクエリを定義します。

   • フィルタ メニューを使用して、バッチ ワークロードをフィルタします。

     1. [すべてのリソース] で、[Cloud Dataproc Batch] リソースを選択します。

        

        1. [リソースの選択] パネルで、バッチの [ロケーション]、[バッチ ID] の順に選択します。これらのバッチ パラメータは、Google Cloud コンソールの Dataproc の [バッチ] ページに表示されます。

           

        2. [適用] をクリックします。

        3. [ログ名を選択] で、[ログ名を検索] ボックスに「dataproc.googleapis.com」と入力して、クエリするログタイプを制限します。表示されたログファイル名を 1 つ以上選択します。

           

   • クエリエディタを使用して、VM 固有のログをフィルタします。

     1. 次の例に示すように、リソースタイプと VM リソース名を指定します。

        resource.type="cloud_dataproc_batch"
        labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCH_UUID-VM_SUFFIX"
        

        注:
        • BATCH_UUID: バッチ UUID は、Google Cloud コンソールの [バッチ] ページでバッチ ID をクリックすると表示される [バッチの詳細] ページに表示されます。

          

        バッチログには、VM リソース名のバッチ UUID も一覧表示されます。バッチ driver.log の例を次に示します。

        

4. [クエリを実行] をクリックします。

Dataproc Serverless for Spark のログタイプとサンプルクエリ

次のリストに、さまざまな Dataproc サーバーレス ログタイプと、各ログタイプのログ エクスプローラのクエリの例を示します。

1. dataproc.googleapis.com/output: このログファイルには、バッチ ワークロードの出力内容が含まれています。Dataproc Serverless for Spark は、バッチ出力を output Namespace にストリーミングし、ファイル名を JOB_ID.driver.log に設定します。

   出力ログのログ エクスプローラ クエリの例:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Foutput"
   

2. dataproc.googleapis.com/spark: spark Namespace は、Dataproc クラスタのマスター VM とワーカー VM で実行されているデーモンとエグゼキュータの Spark ログを集約します。各ログエントリには、ログソースを識別する master、worker、または executor コンポーネントラベルが含まれています。

   • executor: ユーザーコード エグゼキュータからのログ。通常、これらは分散ログです。
   • master: Spark スタンドアロン リソース マネージャー マスターのログ。Dataproc on Compute Engine YARN ResourceManager ログに似ています。
   • worker: Spark スタンドアロン リソース マネージャー ワーカーのログ。Dataproc on Compute Engine YARN NodeManager ログに似ています。

   spark Namespace 内のすべてのログに対するログ エクスプローラのクエリの例:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fspark"
   

   spark Namespace の Spark スタンドアロン コンポーネント ログのサンプル ログ エクスプローラ クエリ:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fspark"
   jsonPayload.component="COMPONENT"
   

3. dataproc.googleapis.com/startup: startup Namespace には、バッチ（クラスタ）の起動ログが含まれます。初期化スクリプトのログが含まれます。コンポーネントはラベルで識別されます。次に例を示します。

   startup-script[855]: ... activate-component-spark[3050]: ... enable spark-worker
   

   指定した VM の起動ログのログ エクスプローラ クエリの例:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fstartup"
   labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCH_UUID-VM_SUFFIX"
   

4. dataproc.googleapis.com/agent: agent Namespace は、Dataproc エージェント ログを集約します。各ログエントリには、ログソースを識別するファイル名ラベルが含まれています。

   指定したワーカー VM によって生成されたエージェントログのログ エクスプローラ クエリの例:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fagent"
   labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCHUUID-wWORKER#"
   

5. dataproc.googleapis.com/autoscaler: autoscaler Namespace は、Dataproc Serverless for Spark のオートスケーラー ログを集約します。

   指定したワーカー VM によって生成されたエージェントログのログ エクスプローラ クエリの例:

   resource.type="cloud_dataproc_batch"
   resource.labels.location="REGION"
   resource.labels.batch_id="BATCH_ID"
   logName="projects/PROJECT_ID/logs/dataproc.googleapis.com%2Fautoscaler"
   labels."dataproc.googleapis.com/resource_name"="gdpic-srvls-batch-BATCHUUID-wWORKER#"
   

詳細については、Dataproc ログをご覧ください。

Dataproc サーバーレスの監査ログ

Dataproc Serverless の監査ログについては、Dataproc 監査ロギングをご覧ください。

ワークロード指標

Spark 向け Dataproc サーバーレスのデフォルトでは、Spark 指標収集プロパティを使用して無効にしない限り、利用可能な Spark 指標の収集が有効になります。または、1 つ以上の Spark 指標のコレクションをオーバーライドできます。

ワークロード指標は、Metrics Explorer または Google Cloud コンソールの [バッチの詳細] ページで確認できます。

バッチ指標

Dataproc batch リソース指標は、バッチ エグゼキュータの数など、バッチ リソースに関する分析情報を提供します。バッチ指標には dataproc.googleapis.com/batch という接頭辞が付いています。

Spark 指標

利用可能な Spark 指標には、Spark ドライバとエグゼキュータの指標、システム指標が含まれます。利用可能な Spark 指標には custom.googleapis.com/ という接頭辞が付いています。

指標アラートを設定する

Dataproc 指標アラートを作成して、ワークロードの問題に関する通知を受け取ることができます。

グラフを作成

ワークロード指標を可視化するグラフを作成するには、Google Cloud コンソールの Metrics Explorer を使用します。たとえば、disk:bytes_used を表示するグラフを作成し、batch_id でフィルタリングできます。

Cloud Monitoring

Monitoring では、ワークロードのメタデータと指標を使用して、Spark 向け Dataproc サーバーレス ワークロードの健全性とパフォーマンスに関する分析情報を提供します。ワークロード指標には、Spark 指標、バッチ指標、オペレーション指標が含まれます。

Google Cloud コンソールの Cloud Monitoring を使用して、指標の探索、グラフの追加、ダッシュボードの作成、アラートの作成を行うことができます。

ダッシュボードの作成

複数のプロジェクトとさまざまな Google Cloud プロダクトの指標を使用してワークロードをモニタリングするダッシュボードを作成できます。詳細については、カスタム ダッシュボードの作成と管理をご覧ください。

高度なトラブルシューティング（プレビュー）

このセクションでは、Google Cloud コンソールで利用可能な高度なトラブルシューティング機能（プレビュー）について説明します。これらの機能には、Gemini in BigQuery サービスの一部である Dataproc Serverless の Gemini 支援のトラブルシューティングが含まれます。

プレビュー

この機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 pre-GA の機能は「現状有姿」で利用できますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

このリリースへのアクセスについては、アクセス リクエスト ページをご覧ください。

プレビュー機能にアクセスする

高度なトラブルシューティング機能のプレビュー リリースに登録するには、Gemini in BigQuery の Pre-GA 登録フォームに必要事項を記入してお送りください。フォームが承認されると、フォームにリストされているプロジェクトはプレビュー機能にアクセスできるようになります。

注: このプレビュー リリースに関するフィードバックを送信するには、Dataproc プレビュー: フィードバック フォームを使用します。

プレビュー版の料金

プレビューへの参加に追加料金はかかりません。以下のプレビュー機能は、一般提供（GA）された時点で料金が発生します。

• Dataproc Serverless の Gemini 支援のトラブルシューティング
• バッチ指標のハイライト
• ジョブのログ

GA の料金に関する事前通知は、プレビューの登録フォームに入力したメールアドレスに送信されます。

特徴の要件

• 登録: この機能は登録する必要があります。

• 権限: dataproc.batches.analyze 権限が必要です。

  • 事前定義された roles/dataproc.admin、roles/dataproc.editor、または roles/dataproc.viewer のロールを持っている場合は、必要な権限があります。これ以上の対応は必要ありません。

  • カスタムロールを使用して Dataproc サービスにアクセスする場合は、カスタムロールに dataproc.batches.analyze 権限が必要です。次のコマンドに示すように、gcloud CLI を使用して権限を追加できます。このコマンドは、プロジェクト レベルで権限を追加します。

  gcloud iam roles update CUSTOM_ROLE_ID --project=PROJECT_ID \
  --add-permissions="dataproc.batches.analyze"
  

  gcloud iam roles describe コマンドを使用して付与された権限を表示した場合、dataproc.batches.analyze 権限は一覧表示されません。

• Dataproc Serverless の Gemini 支援のトラブルシューティングを有効にする: Google Cloud コンソール、gcloud CLI、Dataproc API を使用して、定期的な各 Spark バッチ ワークロードを送信する場合は、Dataproc Serverless の Gemini 支援のトラブルシューティングを有効にします。定期的なバッチ ワークロードに対してこの機能を有効にすると、Dataproc はワークロード ログのコピーを 30 日間保存し、保存されたログデータを使用してワークロードに Gemini 支援のトラブルシューティングを行います。Spark ワークロードのログの内容については、Spark 向け Dataproc Serverless のログをご覧ください。

Console

次の手順を実行して、繰り返しの Spark バッチ ワークロードで Gemini 支援のトラブルシューティングを有効にします。

1. Google Cloud コンソールで、Dataproc バッチ ページに移動します。

   Dataproc バッチに移動

2. バッチ ワークロードを作成するには、[作成] をクリックします。

3. [コンテナ] セクションで、コホート名を入力します。これは、バッチを一連の反復的なワークロードの 1 つとして識別します。Gemini 支援の分析は、このコホート名で送信された 2 回目以降のワークロードに適用されます。たとえば、毎日 TPC-H クエリを実行するスケジュール設定されたワークロードのコホート名として TPCH-Query1 を指定します。

4. 必要に応じて [バッチを作成] ページの他のセクションに入力し、[送信] をクリックします。詳細については、バッチ ワークロードを送信するをご覧ください。

gcloud

次の gcloud CLI gcloud dataproc batches submit コマンドをターミナル ウィンドウでローカルに実行するか、Cloud Shell で実行して、繰り返しの Spark バッチ ワークロードで Gemini による支援のトラブルシューティングを有効にします。

gcloud dataproc batches submit COMMAND \
    --region=REGION \
    --cohort=COHORT \
    other arguments ...

以下を置き換えます。

• COMMAND: Spark ワークロード タイプ（Spark、PySpark、Spark-Sql、Spark-R など）。
• REGION： ワークロードが実行される リージョンを指定します。
• COHORT: コホート名。バッチが一連の繰り返しワークロードの 1 つとして識別されます。Gemini 支援の分析は、このコホート名で送信された 2 回目以降のワークロードに適用されます。たとえば、毎日 TPC-H クエリを実行するスケジュール設定されたワークロードのコホート名として TPCH Query 1 を指定します。

API

batches.create リクエストに RuntimeConfig.cohort 名を含めて、繰り返しの Spark バッチ ワークロードで Gemini 支援のトラブルシューティングを有効にします。Gemini 支援の分析は、このコホート名で送信された 2 回目以降のワークロードに適用されます。たとえば、毎日 TPC-H クエリを実行するスケジュール設定されたワークロードのコホート名として TPCH-Query1 を指定します。

例:

...
runtimeConfig:
  cohort: TPCH-Query1
...

Dataproc Serverless の Gemini 支援のトラブルシューティング

Google Cloud コンソールの [バッチの詳細] と [バッチ] リストページでは、次の Gemini 支援のトラブルシューティング プレビュー機能を使用できます。

• [調査] タブ: [バッチの詳細] ページの [調査] タブには、[Health Overview（プレビュー）] セクションがあり、次の Geomini 支援のトラブルシューティング パネルがあります。

  • 自動調整の対象 1 つ以上のワークロードで自動チューニングを有効にしている場合、このパネルには、実行中のワークロード、完了したワークロード、失敗したワークロードに適用された最新の自動チューニングの変更が表示されます。

  

  • 「今何が起きているのでしょうか？」そして、「それに対して何ができますか？」「Gemini に相談」をクリックして、失敗したワークロードの修正や、成功しているが遅いワークロードの改善に役立つ推奨事項をリクエストします。

  

  [Gemini に相談] をクリックすると、Gemini for Google Cloud はワークロード ログ、Spark 指標、Spark イベントからエラー、異常、またはハイライトを生成します。Gemini for Google Cloud では、失敗したワークロードを修正したり、成功しているが遅いワークロードのパフォーマンスを向上したりするために実行できる推奨手順のリストを表示することもできます。

  

• Gemini 支援のトラブルシューティングの列: プレビュー リリースの一部として、Google Cloud コンソールの Dataproc の [バッチ] リストページに、What was Autotuned、What is happening now?、What can I do about it? の列が追加されています。

  

  「Gemini に相談」ボタンは、完了したバッチが Failed、Cancelled、または Succeeded 状態にある場合にのみ表示されます。[Gemini に相談] をクリックすると、Gemini for Google Cloud はワークロード ログ、Spark 指標、Spark イベントからエラー、異常、またはハイライトを生成します。Gemini for Google Cloud では、失敗したワークロードを修正したり、成功しているが遅いワークロードのパフォーマンスを向上したりするために実行できる推奨手順のリストを表示することもできます。

バッチ指標のハイライト

プレビュー リリースの一環として、Google Cloud コンソールの [バッチの詳細] ページには、重要なバッチ ワークロード指標の値を表示するグラフが含まれています。バッチが完了すると、指標グラフに値が入力されます。

指標の表

次の表は、Google Cloud コンソールの [バッチの詳細] ページに表示される Spark ワークロードの指標の一覧と、指標の値からワークロードのステータスとパフォーマンスに関する分析情報を得る方法について説明します。

指標	確認できるポイント
エグゼキュータ レベルの指標
JVM GC 時間と実行時間の比率	この指標は、エグゼキュータごとの JVM GC（ガベージ コレクション）時間と実行時間の比率を示します。比率が高い場合は、特定のエグゼキュータで実行されているタスク内のメモリリークや、非効率的なデータ構造が原因で、オブジェクトの頻繁な変更につながる可能性があります。
ディスク バイト数（スピンアウト）	この指標は、さまざまなエグゼキュータに流出したディスク バイトの合計数を示します。エグゼキュータのディスク バイト数が多すぎる場合は、データスキューが発生している可能性があります。指標が時間とともに増加する場合は、メモリ不足またはメモリリークが発生しているステージがあることを示している可能性があります。
読み取りと書き込みのバイト数	この指標は、エグゼキュータごとの書き込みバイトと読み取りバイトを示します。読み取りまたは書き込みのバイト数が大きく異なる場合は、レプリケートされた結合が特定のエグゼキュータでデータ増幅につながっているシナリオを示している可能性があります。
読み取りと書き込みのレコード	この指標は、エグゼキュータごとの読み取りと書き込みのレコードを示します。読み取られたレコードの数が多く、書き込まれたレコード数が少ない場合は、特定のエグゼキュータの処理ロジックのボトルネックを示している可能性があります。これにより、待機中にレコードが読み取られます。読み取りと書き込みで常に遅延が発生しているエグゼキュータは、これらのノードでのリソース競合またはエグゼキュータ固有のコード非効率を示している可能性があります。
シャッフル書き込み時間と実行時間の比率	この指標は、全体の実行時間に対して、エグゼキュータがシャッフル実行時間に費やした時間を示します。一部のエグゼキュータでこの値が高い場合は、データスキューまたはデータのシリアル化が非効率的であることを示している可能性があります。シャッフル書き込み時間が長いステージは、Spark UI で特定できます。完了に平均時間よりも時間がかかっているステージ内の外れ値のタスクを探します。シャッフル書き込み時間が長いエグゼキュータでディスク I/O アクティビティも高くなっているかを確認します。より効率的なシリアル化と追加のパーティショニング ステップが役立つ場合があります。レコードの読み取りと比較してレコードの書き込みが非常に多い場合、非効率的な結合や不適切な変換が原因で意図しないデータの重複が発生している可能性があります。
アプリケーション レベルの指標
ステージの移行	この指標は、失敗したステージ、待機中のステージ、実行中のステージのステージ数を示します。失敗したステージや待機中のステージが多数ある場合は、データスキューが発生している可能性があります。Spark UI の [ステージ] タブを使用して、データ パーティションを確認し、ステージの失敗の原因をデバッグします。
バッチ Spark エグゼキュータ	この指標は、必要なエグゼキュータ数と実行中のエグゼキュータ数を示します。必要なエグゼキュータと実行中のエグゼキュータの間に大きな差がある場合は、自動スケーリングの問題を示している可能性があります。
VM レベルの指標
使用されたメモリ	この指標は、使用中の VM メモリの割合を示します。マスターの割合が高い場合は、ドライバがメモリ不足に陥っていることを示している可能性があります。他の VM ノードでは、割合が高い場合、エグゼキュータがメモリ不足であることを示している可能性があります。これにより、ディスクの流出が高まり、ワークロード実行時間が遅くなる可能性があります。Spark UI を使用してエグゼキュータを分析し、GC 時間が長いかどうか、タスクの失敗が多いかどうかを確認します。また、大規模なデータセットのキャッシュと変数の不要なブロードキャストについて、Spark コードをデバッグします。

ジョブのログ

プレビュー リリースの一環として、Google Cloud コンソールの [バッチの詳細] ページにジョブ（バッチ ワークロード）ログが一覧表示されます。ログには、ワークロードの出力と Spark ログからフィルタされた警告とエラーが含まれます。ログの [重大度] を選択し、[フィルタ] を追加して、[ログ エクスプローラで表示] アイコンをクリックして選択したログ エクスプローラのバッチログを開くことができます。

例: Google Cloud コンソールの [バッチの詳細] ページの重大度セレクタで Errors を選択すると、ログ エクスプローラが開きます。