Cloud Service
Dataproc
Spark や Hadoop などの OSS データ処理基盤をマネージドで実行する GCP のクラスタサービス。AWS の EMR に相当。
- 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 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 の料金が加わります。具体的な単価はリージョンや時期で変動するため、ここでは考え方を整理します。
| コスト要素 | 課金の考え方 | 削減のヒント |
|---|---|---|
| Dataproc 管理料金 | クラスタの vCPU 数と稼働時間に比例 | 使い捨てクラスタで稼働時間を最小化 |
| ワーカー VM | Compute 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 / プリエンプティブル VM | Spot インスタンス |
| サーバーレス | Dataproc Serverless | EMR Serverless |
| 権限付与 | サービスアカウント + IAM | IAM ロール |
新規のパイプライン開発では、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、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。