以下のセクションで説明する情報とツールを使用して、Spark バッチ ワークロード用の Dataproc サーバーレスのモニタリングとトラブルシューティングを行うことができます。
永続的履歴サーバー
Dataproc Serverless for Spark は、ワークロードの実行に必要なコンピューティング リソースを作成し、それらのリソースでワークロードを実行し、ワークロードが終了するとリソースを削除します。ワークロード指標とイベントは、ワークロードの完了後に保持されません。ただし、永続履歴サーバー（PHS）を使用すると、ワークロード アプリケーション履歴（イベントログ）を Cloud Storage に保持できます。
バッチ ワークロードで PHS を使用するには、次の手順を行います。
ワークロードを送信するときに PHS を指定します。
コンポーネント ゲートウェイを使用して PHS に接続し、アプリケーションの詳細、スケジューラ ステージ、タスクレベルの詳細、環境とエグゼキュータの情報を表示します。
Spark 向け Dataproc サーバーレスのログ
Spark 向け Dataproc サーバーレスでは、ロギングがデフォルトで有効になっており、ワークロードが完了した後にワークロード ログが保持されます。Spark 向け Dataproc サーバーレスは、Cloud Logging でワークロード ログを収集します。ログ エクスプローラの Cloud Dataproc Batch リソースのワークロード spark、agent、output、container のログにアクセスできます。
Spark 向け Dataproc サーバーレスのバッチの例:
詳細については、Dataproc のログをご覧ください。
ワークロード指標
Spark 向け Dataproc サーバーレスのデフォルトでは、Spark 指標収集プロパティを使用して無効にしない限り、利用可能な Spark 指標の収集が有効になります。または、1 つ以上の Spark 指標のコレクションをオーバーライドできます。
ワークロードの指標は、Google Cloud コンソールの Metrics Explorer または [バッチの詳細] ページで確認できます。
バッチ指標
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 の Geomini 支援のトラブルシューティングが含まれます。
プレビュー機能にアクセスする
高度なトラブルシューティング機能のプレビュー リリースに登録するには、BigQuery の Geomini プレビュー フォームに必要事項を記入してお送りください。フォームが承認されると、フォームにリストされているプロジェクトはプレビュー機能にアクセスできるようになります。
プレビュー料金
プレビューへの参加に追加料金はかかりません。以下のプレビュー機能は、一般提供（GA）された時点で料金が発生します。
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"
Dataproc Serverless の Gemini 支援のトラブルシューティングを有効にする: Google Cloud コンソール、gcloud CLI、Dataproc API を使用して、定期的な各 Spark バッチ ワークロードを送信する場合は、Dataproc Serverless の Gemini 支援のトラブルシューティングを有効にします。定期的なバッチ ワークロードに対してこの機能を有効にすると、Dataproc はワークロード ログのコピーを 30 日間保存し、保存されたログデータを使用してワークロードに Gemini 支援のトラブルシューティングを行います。Spark ワークロードのログの内容については、Spark 向け Dataproc Serverless のログをご覧ください。
コンソール
繰り返し実行する Spark バッチ ワークロードごとに Gemini 支援のトラブルシューティングを有効にするには、次の手順を実行します。
Google Cloud コンソールで、Dataproc バッチ ページに移動します。
バッチ ワークロードを作成するには、[作成] をクリックします。
[コンテナ] セクションで、[コホート] の名前を入力します。これにより、バッチが一連の繰り返しワークロードの 1 つとして識別されます。Gemini 支援の分析は、このコホート名で送信される 2 番目以降のワークロードに適用されます。たとえば、毎日 TPC-H クエリを実行するスケジュール済みワークロードのコホート名として
TPCH-Query1を指定します。必要に応じて [バッチ作成] ページの他のセクションに入力し、[送信] をクリックします。詳細については、バッチ ワークロードを送信するをご覧ください。
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
RuntimeConfig.cohort 名を batches.create リクエストに含めると、定期的な Spark バッチ ワークロードごとに Gemini 支援のトラブルシューティングが可能になります。Gemini 支援の分析は、このコホート名で送信される 2 番目以降のワークロードに適用されます。たとえば、毎日 TPC-H クエリを実行するスケジュール設定されたワークロードのコホート名として TPCH-Query1 を指定します。
例:
...
runtimeConfig:
cohort: TPCH-Query1
...
Dataproc Serverless の Gemini 支援のトラブルシューティング
Google Cloud コンソールの [バッチの詳細] と [バッチ] リストページでは、次の Gemini 支援のトラブルシューティング プレビュー機能を使用できます。
[調査] タブ: [バッチの詳細] ページの [調査] タブには、[Health Overview（プレビュー）] セクションがあり、次の Geomini 支援のトラブルシューティング パネルがあります。
- 自動調整の対象 1 つ以上のワークロードで自動チューニングを有効にしている場合、このパネルには、実行中、完了したワークロード、失敗したワークロードに適用された最新の自動チューニングの変更が表示されます。
- 現在の状況と対処方法 [Gemini に質問する] をクリックして、失敗したワークロードの修正や、成功しているが遅いワークロードの改善に役立つ推奨事項をリクエストします。
![[Gemini に質問する] ボタン](https://cloud.google.com/static/dataproc-serverless/docs/images/ask-gemini-button.png?hl=ja)
[Gemini に質問する] をクリックすると、Gemini はワークロード ログ、Spark 指標、Spark イベントからエラー、異常、またはハイライトを生成します。また、Gemini には、失敗したワークロードの修正や、成功しているが遅いワークロードのパフォーマンスを向上させるための推奨手順のリストも表示されます。
Gemini 支援のトラブルシューティング列: プレビュー リリースの一部として、Google Cloud コンソールの Dataproc の [バッチ] リストページには、
What was Autotuned、What is happening now?列とWhat can I do about it?列で構成されます。
[Gemini に質問する] ボタンは、完了したバッチが
Failed、Cancelled、またはSucceeded状態にある場合にのみ表示されます。[Gemini に質問する] をクリックすると、Gemini はワークロード ログ、Spark 指標、Spark イベントからエラー、異常、またはハイライトを生成します。また、Gemini には、失敗したワークロードの修正や、成功しているが遅いワークロードのパフォーマンスを向上させるための推奨手順のリストも表示されます。
バッチ指標のハイライト
プレビュー リリースの一部として、Google Cloud コンソールの [バッチの詳細] ページには、重要なバッチ ワークロードの指標値を表示するグラフが含まれています。バッチが完了すると、指標グラフに値が入力されます。
次の表では、Google Cloud コンソールの [バッチの詳細] ページに表示される Spark ワークロードの指標と、指標値を使用してワークロードのステータスとパフォーマンスに関する分析情報を得る方法について説明します。
| 指標 | 確認できるポイント |
|---|---|
| エグゼキュータ レベルの指標 | |
| ランタイムに対する JVM GC 時間の比率 | この指標は、エグゼキュータごとのランタイムに対する JVM GC（ガベージ コレクション）時間の比率を示します。比率が高い場合は、特定のエグゼキュータで実行されているタスク内のメモリリークや非効率的なデータ構造を示している可能性があり、高いオブジェクト チャーンにつながる可能性があります。 |
| ディスクのバイト数 | この指標は、さまざまなエグゼキュータにオーバーフローしたディスクバイト数の合計を示します。エグゼキュータでディスクのオーバーフロー量が高いことが示されている場合は、データスキューを示している可能性があります。時間の経過とともに指標が増加する場合は、メモリ圧縮またはメモリリークの段階があることを示しています。 |
| 読み取りと書き込みのバイト数 | この指標は、エグゼキュータあたりの書き込みバイト数と読み取りバイト数を示します。読み取り / 書き込みバイト数の大きな差異は、複製された結合によって特定のエグゼキュータでデータが増幅されるシナリオを示している可能性があります。 |
| 読み取りと書き込みのレコード | この指標は、エグゼキュータごとに読み書きされたレコードを示します。書き込まれたレコード数が少ない状態でレコードが読み取られると、特定のエグゼキュータの処理ロジックのボトルネックが発生している可能性があります。これにより、待機中にレコードが読み取られることがあります。エグゼキュータで読み取りと書き込みが一貫して遅れる場合は、それらのノードでのリソース競合や、エグゼキュータ固有のコードが非効率的であることを示している可能性があります。 |
| 実行時間に対するシャッフル書き込み時間の比率 | この指標は、全体的なランタイムと比較した、エグゼキュータがシャッフルのランタイムに費やした時間を示します。一部のエグゼキュータでこの値が高い場合は、データスキューまたはデータのシリアル化が非効率である可能性があります。 Spark UI で、シャッフルの書き込み時間が長いステージを特定できます。それらのステージ内で、完了まで平均時間を超えてかかっている外れ値のタスクを探します。シャッフルの書き込み時間が高いエグゼキュータでも、ディスク I/O アクティビティが多いかどうかを確認します。効率的なシリアル化と追加のパーティショニング手順が役立つことがあります。レコードの読み取りと比較してレコードの書き込み量が非常に大きい場合は、非効率的な結合や誤った変換が原因で、意図しないデータの重複が発生している可能性があります。 |
| アプリケーション レベルの指標 | |
| ステージの進行 | この指標は、失敗したステージ、待機ステージ、実行中のステージの数を示します。失敗したステージまたは待機ステージが多い場合は、データスキューが発生する可能性があります。Spark UI の [Stages] タブを使用して、データ パーティションを確認し、ステージエラーの理由をデバッグします。 |
| バッチ Spark エグゼキュータ | この指標は、必要な可能性があるエグゼキュータの数と、実行中のエグゼキュータの数を示します。必要なエグゼキュータと実行中のエグゼキュータに大きな差がある場合は、自動スケーリングに問題がある可能性があります。 |
| VM レベルの指標 | |
| 使用されたメモリ | この指標は、使用中の VM メモリの割合を示します。マスターの割合が高い場合は、ドライバがメモリ不足であることを示している可能性があります。他の VM ノードの場合、割合が高い場合はエグゼキュータがメモリ不足になっていることを示している可能性があります。これにより、ディスクの漏えいを避け、ワークロードのランタイムが遅くなる可能性があります。Spark UI を使用してエグゼキュータを分析し、GC 時間とタスクの失敗が高いかどうかを確認します。また、大規模なデータセット キャッシュ保存や変数の不要なブロードキャストのために Spark コードをデバッグします。 |
ジョブのログ
プレビュー リリースの一環として、Google Cloud コンソールの [バッチの詳細] ページには、ジョブ（バッチ ワークロード）ログが一覧表示されます。このログには、ワークロード出力と Spark ログからフィルタリングされた警告とエラーが含まれます。ログの [重大度] を選択し、[フィルタ] を追加して、[ログ エクスプローラで表示] アイコンをクリックして選択したログ エクスプローラのバッチログを開くことができます。
例: Google Cloud コンソールの [バッチの詳細] ページの重大度セレクタから Errors を選択すると、ログ エクスプローラが開きます。
Spark UI（プレビュー）
Spark UI のプレビュー機能にプロジェクトを登録している場合は、Dataproc PHS（永続履歴サーバー）クラスタを追加します。Spark UI は、バッチ ワークロードから Spark の実行の詳細を収集します。詳細については、Spark UI プレビュー リリースの一部として、登録済みのお客様に配布されるユーザーガイドをご覧ください。