TL

Cloud Service

Dataproc

Spark や Hadoop などの OSS データ処理基盤をマネージドで実行する GCP のクラスタサービス。AWS の EMR に相当。

中級パフォーマンス効率コスト最適化
最終更新: 2026-06-14公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.Spark / Hadoop をクラスタ管理の手間なくマネージドで実行できる。
  • 2.起動が速く、ジョブ単位の使い捨てクラスタとストレージ分離が定石。
  • 3.AWS の EMR 相当。サーバーレス版なら個別クラスタ管理も不要。

解決する課題

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

主要概念と用語

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

仕様・制限・クォータ

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

内部の仕組み

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

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

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

ストレージ分離が肝

Dataproc を「常時起動の HDFS クラスタ」として使うと、EMR でいうローカル HDFS 固定運用と同じ落とし穴にはまります。データは Cloud Storage に置き、クラスタはジョブのたびに作って捨てる。これだけでコストと運用性が大きく改善します。

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

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

運用・監視

  • Cloud MonitoringCloud 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 の料金が加わります。具体的な単価はリージョンや時期で変動するため、ここでは考え方を整理します。

コスト要素課金の考え方削減のヒント
Dataproc 管理料金クラスタの vCPU 数と稼働時間に比例使い捨てクラスタで稼働時間を最小化
ワーカー VMCompute Engine の VM 利用時間セカンダリワーカーに Spot / プリエンプティブルを利用
ストレージHDFS はディスク料金、外部は Cloud Storage 料金データは Cloud Storage に置きクラスタは捨てる
Serverless 実行ワークロードの消費リソースに対する従量課金クラスタ常時起動が不要なバッチに採用

セキュリティ

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

Dataproc クラスタを外部 IP 付きで安易に立てると、Hadoop / Spark の各種 UI やポートがインターネットから到達可能になるリスクがあります。内部 IP のみのクラスタとコンポーネントゲートウェイを使い、UI への直接公開は避けてください。

Well-Architected の観点

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

試験で問われるポイント

頻出
  • Dataproc は Spark / Hadoop をマネージドで動かすサービスで、AWS の EMR に相当する。OSS 資産の移行やリフト&シフトが典型シナリオ
  • 既存の Spark / Hadoop ジョブをクラウドで動かしたい」なら Dataproc。「Apache Beam で新規のストリーム / バッチ処理を書く」なら Dataflow を選ぶ、という切り分けが問われる
  • コスト最適化の定石はエフェメラルクラスタ+ Cloud Storage によるストレージ分離+ Spot / プリエンプティブルワーカー
  • クラスタ管理自体を不要にしたいバッチには Dataproc Serverless を選ぶ
  • データは HDFS にロックせず Cloud Storage に置くのが推奨。これによりクラスタを安全に削除できる

関連サービス・比較

観点GCP(Dataproc)AWS(EMR)
位置づけSpark / Hadoop のマネージド実行Spark / Hadoop のマネージド実行
基盤Compute Engine VM 上のクラスタEC2 上のクラスタ
推奨ストレージCloud Storage(コネクタ経由)Amazon S3(EMRFS 経由)
割安な計算Spot / プリエンプティブル VMSpot インスタンス
サーバーレスDataproc ServerlessEMR Serverless
権限付与サービスアカウント + IAMIAM ロール

新規のパイプライン開発では、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 バッチを Serverless で実行
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

Google Cloud Service

Dataprocを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

分析

比較で見る軸

クラウド: Google Cloud / カテゴリ: 分析 / 難易度: intermediate

導入後に効く点

起動が速く、ジョブ単位の使い捨てクラスタとストレージ分離が定石。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Google Cloud
カテゴリ
分析
難易度
intermediate
関連資格
設計柱
performance / cost

判断チェックリスト

  • 自社の用途が「分析 / performance」に近いか確認する。
  • 強みである「Spark / Hadoop をクラスタ管理の手間なくマネージドで実行できる。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

分析performancecost