Managed Service for Apache Spark（旧Dataproc）

解決する課題

• 既存の Spark / Hadoop / Hive / Presto などの OSS 資産を、自前でクラスタを構築・運用せずに動かしたい
• オンプレの Hadoop クラスタをそのままクラウドへ移行（リフト＆シフト）したい
• 必要なときだけクラスタを立ち上げ、ジョブが終わったら捨てることでコストを抑えたい
• データをクラスタのローカルディスクに固定せず、ストレージと計算を分離して柔軟にスケールしたい

主要概念と用語

• クラスタ (Cluster): マスターノードとワーカーノードからなる処理基盤。Compute Engine の VM で構成され、HDFS や YARN などの Hadoop エコシステムが導入される
• マスター / ワーカーノード: ジョブの調整・スケジューリングを担うマスターと、実際の計算を担うワーカー。ワーカーはプライマリとセカンダリ（プリエンプティブル可）に分かれる
• ジョブ (Job): クラスタに投入する処理単位。Spark、PySpark、Hive、Pig、Presto などをサポートする
• イメージバージョン: クラスタに導入される OSS コンポーネントのバージョンセット。Spark や Hadoop のバージョン組み合わせを規定する
• エフェメラルクラスタ (使い捨てクラスタ): ジョブ実行のためだけに起動し、完了後に削除する短命なクラスタ。コスト最適化の基本パターン
• サーバーレスデプロイ: 旧 Google Cloud Serverless for Apache Spark。クラスタを事前に作らず、Spark バッチやインタラクティブセッションを実行する形態
• 初期化アクション: クラスタ起動時に各ノードで実行されるスクリプト。追加ライブラリの導入や設定に使う
• オートスケーリングポリシー: ワーカー数を負荷に応じて増減させる設定。主にセカンダリワーカーを対象とする

仕様・制限・クォータ

• 2026年4月3日に Dataproc と Google Cloud Serverless for Apache Spark が Managed Service for Apache Spark に統合改称された。機能は削除されず、Dataproc API、クライアント、gcloud dataproc、IAM 名は継続する
• クラスタは Compute Engine VM 上に構築されるため、CPU・メモリ・ディスクのクォータは Compute Engine のものを消費する
• クラスタ作成は通常数十秒から数分で完了し、EMR と同様にオンデマンドで起動できる。これにより使い捨て運用が現実的になる
• ワーカーにはプリエンプティブル VM / Spot VM を混在させられ、大幅なコスト削減が可能。ただし途中で停止される前提のため、永続データを置かない
• HDFS をローカルに持つこともできるが、推奨はデータを Cloud Storage に置きクラスタを使い捨てにする構成。Cloud Storage コネクタが HDFS 互換アクセスを提供する
• サーバーレスデプロイはクラスタのサイズ指定が不要で、ワークロードに応じてリソースが割り当てられる。料金やクォータの具体値はリージョンや時期で変動するため、最新の公式情報を確認する

内部の仕組み

横にスクロール

Managed Service for Apache Spark のクラスタデプロイは、内部的に Compute Engine の VM を起動して Hadoop / Spark クラスタを構成します。マスターノードが YARN リソースマネージャーやジョブ調整を担い、ワーカーノードが YARN ノードマネージャーとして実際のタスクを実行します。クラスタ作成時にイメージバージョンに従って OSS コンポーネントが導入され、初期化アクションで追加のカスタマイズが行われます。

ストレージは大きく二通りあります。クラスタ内の HDFS（ワーカーのローカルディスク）と、外部の Cloud Storage です。クラウドネイティブな使い方では、入力・出力データを Cloud Storage に置き、Cloud Storage コネクタを通じて Spark や Hadoop から HDFS と同じインターフェースでアクセスします。こうすると計算とストレージが分離され、クラスタを削除してもデータが残るため、エフェメラルクラスタが成立します。

サーバーレスデプロイでは、ユーザーがクラスタを意識せずに Spark バッチやセッションを投入すると、サービス側が必要なリソースをプロビジョニングして実行し、完了後に解放します。これは AWS でいう EMR Serverless に近い実行モデルです。

設計パターン / ベストプラクティス

• ジョブごとにエフェメラルクラスタを作って捨てるのが基本。常時起動の大きなクラスタは避ける
• 入出力データは Cloud Storage に置き、計算とストレージを分離する。クラスタ削除でデータを失わない
• セカンダリワーカーに Spot / プリエンプティブル VM を使い、オートスケーリングポリシーで負荷に追従させる
• 単純な Spark バッチであれば、クラスタ管理を省ける サーバーレスデプロイを第一候補にする
• ワークフローはマネージドの ワークフローテンプレート や Cloud Composer（Airflow）で自動化し、クラスタ作成からジョブ実行・削除までを一括化する
• 大規模な ETL や SQL 分析でクラスタ運用自体が不要なら、Dataflow（Beam）や BigQuery への置き換えも検討する

運用・監視

• Cloud Monitoring と Cloud Logging にメトリクスとログが連携され、YARN のリソース使用状況やジョブの状態を監視できる
• クラスタには コンポーネントゲートウェイを通じて Spark UI や YARN UI などの Web インターフェースに安全にアクセスできる
• ジョブのログとドライバ出力は Cloud Logging / Cloud Storage に保存され、失敗時の調査に使う
• オートスケーリングが効いているか、Spot VM の停止でジョブが過度にリトライしていないかを確認する
• 長期運用クラスタでは HDFS の使用量やディスク逼迫に注意し、可能ならストレージを Cloud Storage に逃がす

コスト

Dataproc 自体の課金は、クラスタを構成する Compute Engine VM の利用時間に対する vCPU 単位の管理料金が中心で、これに基盤となる Compute Engine やディスク、Cloud Storage の料金が加わります。具体的な単価はリージョンや時期で変動するため、ここでは考え方を整理します。

セキュリティ

• クラスタやジョブの権限は IAM で最小権限に分離し、Dataproc 用とデータアクセス用のロールを使い分ける（AWS の IAM ロール相当）
• クラスタのワーカーには専用のサービスアカウントを割り当て、認証情報のハードコードを避ける
• ネットワークは VPC / サブネット内に閉じ、外部公開を避ける。UI アクセスはコンポーネントゲートウェイ経由にする
• 保存データは Google 管理鍵で既定暗号化され、要件に応じて CMEK（顧客管理鍵, Cloud KMS） を適用できる。データ流出対策に VPC Service Controls を併用する
• Hadoop の認証を強化する Kerberos を有効化したセキュアクラスタも構成できる

Well-Architected の観点

• パフォーマンス効率: ワークロードに応じたマシンタイプ選択とオートスケーリングで、過不足のないリソース割り当てを行う。クラスタの起動が速いため、ジョブ規模に合わせて専用クラスタを使い分けられる
• コスト最適化: エフェメラルクラスタ、Spot / プリエンプティブルワーカー、ストレージ分離、そして必要に応じたサーバーレス採用で、アイドル時間と固定費を最小化する
• これら二つが Managed Service for Apache Spark の主眼で、運用負荷の軽減はマネージドであること自体が寄与する

試験で問われるポイント

関連サービス・比較

新規のパイプライン開発では、Beam ベースの Dataflow や、SQL 中心の分析なら BigQuery が代替候補になります。Dataproc は「既存 OSS をそのまま動かす」点に強みがあります。

ハンズオン / CLI例

# 1) 使い捨てを前提にした小さなクラスタを作成（セカンダリワーカーは Spot）
gcloud dataproc clusters create demo-cluster \
  --region=asia-northeast1 \
  --master-machine-type=n2-standard-2 \
  --num-workers=2 \
  --num-secondary-workers=2 \
  --secondary-worker-type=spot

# 2) Spark ジョブを投入（入出力は Cloud Storage を指定）
gcloud dataproc jobs submit spark \
  --cluster=demo-cluster \
  --region=asia-northeast1 \
  --class=org.apache.spark.examples.SparkPi \
  --jars=file:///usr/lib/spark/examples/jars/spark-examples.jar \
  -- 1000

# 3) ジョブが終わったらクラスタを削除（コスト最小化の要）
gcloud dataproc clusters delete demo-cluster --region=asia-northeast1

# 4) クラスタを作らずにSparkバッチをサーバーレス実行
gcloud dataproc batches submit spark \
  --region=asia-northeast1 \
  --jars=file:///usr/lib/spark/examples/jars/spark-examples.jar \
  --class=org.apache.spark.examples.SparkPi \
  -- 1000