Contents
1. コスト削減の KPI と測定フレームワーク
1‑1 KPI の基本構成（導入）
費用削減は 「ジョブ実行時間」・「インスタンス稼働率」・「月間総コスト」 の３指標で管理すると、改善のインパクトが定量的に把握しやすくなります。以下では各 KPI の測定方法と現実的な目標例を示します。
| KPI | 主な測定手段 | 推奨目標（目安） |
|---|---|---|
| ジョブ実行時間 | Spark UI の Duration、または CloudWatch Logs に出力された spark.driver.totalTime |
前回比 10 % 短縮 |
| インスタンス稼働率（CPU/メモリ利用率） | CloudWatch の CPUUtilization / MemoryUtilization 平均値 |
70 %以上の平均利用率 |
| 月間総コスト | AWS Cost Explorer、GCP Billing Export、Azure Cost Management でタグ別集計 | 前月比 15 % 削減 |
ポイント：KPI は「測定可能」かつ「ビジネスに直結」していることが重要です。Cost Explorer のカスタムレポートや GCP の BigQuery Billing Export でタグ（例：
Project=SparkJob）を付与すれば、サービス別・ジョブ別の費用を簡単に抽出できます。
2. インスタンスタイプとスケーリング戦略
2‑1 インスタンス選定の指針（導入）
Spark のパフォーマンスは CPU コア数 と メモリ容量 のバランスに大きく依存します。汎用型、コンピュート最適化、メモリ最適化といったインスタンスタイプをワークロード特性に合わせて選択しましょう。
| インスタンスタイプ | 主な特徴 | 典型的なユースケース |
|---|---|---|
| m5.xlarge (AWS) / n2-standard-4 (GCP) / D8s v3 (Azure) | 汎用（CPU : メモリ ≈ 1 : 4） | 中規模 ETL、バッチジョブ |
| r6g.large (AWS) / n2-highmem-2 (GCP) / E4as v5 (Azure) | メモリ最適化（CPU : メモリ ≈ 1 : 8） | 大規模シャッフル、機械学習前処理 |
| c6i.xlarge (AWS) / n2-highcpu-4 (GCP) / F8s v2 (Azure) | コンピュート最適化（CPU : メモリ ≈ 1 : 2） | CPU 集中型アルゴリズム（例：集計、統計解析） |
注意：上記は 2024 年 6 月時点の一般的なスペックです。実際に選定する際は 各リージョンの価格表 と インスタンスの在庫状況 を必ず確認してください。
2‑2 スポット／プレエンプティブインスタンス活用（導入）
余剰キャパシティを利用できるスポット（AWS）、プリエンプティブ（GCP）、低優先度（Azure）VM は、オンデマンド価格より 約 50‑80 % 削減できるケースが多いですが、回収リスクは常に存在します。
実装のベストプラクティス
- 入札上限はオンデマンド価格の 70 % 前後 に設定（リージョンによって変動）。
- フェイルオーバー自動化：Spot が回収されたら同一インスタンスタイプのオンデマンドへ即時切替える Auto Scaling ポリシーを作成。
- 混合構成：コアノードはオンデマンド、ワーカーノードはスポットとするハイブリッド構成で安定性とコスト削減の両立を図る。
ポイント：AWS の Spot Fleet、GCP の Instance Group、Azure の Scale Set では「インスタンスプール」機能が提供されており、回収時に自動的に代替ノードが起動します。設定例は公式ドキュメント（2024‑06 更新）を参照してください。
2‑3 Auto Scaling と時間帯スケジューリング（導入）
スパイク時だけリソースを増やす CPU/メモリベースの Auto Scaling と、夜間・週末にクラスタ全体を停止する スケジュール起停 を組み合わせると、アイドルコストを大幅に削減できます。
代表的なポリシー例
| ポリシー種別 | 条件（CloudWatch アラーム） | アクション |
|---|---|---|
| CPU 高負荷 | CPUUtilization > 70 % が 5 分連続 |
ワーカー数 +2 |
| キュー長増加 | Spark のステージキューが 10 超 | ワーカー数 +1 |
| 時間帯停止 | 平日 02:00‑06:00（ローカル時間） | クラスタ全体 Terminate |
実装ヒント：AWS では EC2 Auto Scaling、GCP は Instance Group Autoscaler、Azure は Virtual Machine Scale Set が対応しています。スケジュール起停は各ベンダーの「Scheduled Actions」または「Cron Job」機能で実現可能です。
3. Spark 設定パラメータのチューニング
3‑1 Executor の数とリソース割り当て（導入）
executor は Spark ジョブの実行単位です。過不足が直接 ジョブ時間 と コスト に影響します。以下は公式推奨をベースにした ガイドライン で、数式だけに依存しない柔軟な調整方法です。
| 推奨項目 | 設定方針 |
|---|---|
| Executor 数 | ノードあたりの vCPU を 4‑5 コア 程度の executor.cores に分割し、残りは OS とシステムデーモン用に確保。例：8 vCPU のインスタンスなら executor.cores = 4 → 最大 2 個 の executor が安全です。 |
| Executor メモリ | インスタンスメモリの 60‑70 % を spark.executor.memory に割り当て、残りは OS と Spark driver 用に確保（例：32 GB → 20 GB 程度）。 |
| Dynamic Allocation | spark.dynamicAllocation.enabled=true を有効化し、minExecutors, maxExecutors をワークロードの最小/最大規模に合わせて設定。 |
根拠：Spark の公式ドキュメント（2024‑06）では「1 executor は 5‑6 GB メモリ + 1 CPU が一般的」だとされていますが、実際はジョブ特性や GC 設定に応じて調整してください。
設定例（Spark Submit）
|
1 2 3 4 5 6 7 8 |
spark-submit \ --conf spark.executor.cores=4 \ --conf spark.executor.memory=20g \ --conf spark.dynamicAllocation.enabled=true \ --conf spark.dynamicAllocation.minExecutors=2 \ --conf spark.dynamicAllocation.maxExecutors=30 \ ... |
3‑2 Shuffle パーティション数の決め方（導入）
shuffle.partitions はデータが再分散される際のタスク数を制御し、過剰・不足どちらもコストに影響します。128 MB/パーティション を目安とした経験則は有用ですが、実測データで微調整することが推奨されます。
| データ規模 | 推奨 shuffle.partitions 計算式 |
実務上のチューニングポイント |
|---|---|---|
| 100 GB | (100 GB ÷ 0.128 GB) ≈ 780 | ジョブ実行後に StageInfo のタスク時間を確認し、過剰なら 0.5 倍へ |
| 2 TB | (2048 GB ÷ 0.128 GB) ≈ 16,000 | 大規模ジョブは Dynamic Allocation と組み合わせてスケールアウトさせる |
注意：S3 のオブジェクト数が多いと
GETリクエスト料が増えるため、極端に小さなパーティションは避けましょう。
4. データフォーマット・圧縮とキャッシュ戦略
4‑1 列指向フォーマットの活用（導入）
Spark の I/O コストは 「読み込むデータ量」 に比例します。CSV や JSON といった行指向形式は全カラムをスキャンするため、Parquet / ORC へ変換し、かつ snappy または zstd 圧縮を併用すると、ストレージ使用量と転送コストが大幅に削減できます。
実装例（Scala）
|
1 2 3 4 5 |
df.write .mode("overwrite") .option("compression", "zstd") // ZSTD (level=3 推奨) .parquet("s3://my-bucket/processed/") |
- 効果イメージ：500 GB の CSV → Parquet+ZSTD で約 150 GB に圧縮（≈ 70 % 削減）
- パフォーマンス：同クエリの実行時間が 20‑30 % 短縮
4‑2 キャッシュとチェックポイントの費用感（導入）
persist / cache はメモリ上にデータを保持し、再計算コストを削減します。一方、checkpoint は S3（または GCS/Azure Blob）への永続化が必要になるため、書き込み頻度とデータサイズに応じた 費用増 を意識する必要があります。
| 操作 | 推奨シナリオ | 主なコスト要因 |
|---|---|---|
cache / persist |
同一 DataFrame の反復利用が 3 回以上、かつメモリ余裕がある場合 | メモリ料金のみ（インスタンスに含む） |
checkpoint |
ジョブ失敗時のリカバリが必須、データサイズ < 10 GB | S3 PUT/GET リクエストと保存容量（数十円程度/月） |
ポイント：キャッシュは「使うかどうか」をタスク単位で評価し、不要なデータは
unpersist()してメモリ解放しましょう。チェックポイントは 失敗頻度が低いバッチ では省略可能です。
5. リアルタイムコストモニタリングとベンダー比較
5‑1 Cost Explorer と CloudWatch の連携（導入）
クラウド費用の変動は リアルタイムで把握 しないと、最適化施策が遅れます。以下の手順で「ジョブ単位」のコスト可視化を構築できます。
- タグ付与：全 Spark クラスタ／ジョブに
Project=SparkJobタグを設定。 - Cost Explorer カスタムレポート：
- フィルタで上記タグ → 集計粒度は「Hourly」
- 表示項目は「サービス別」「インスタンスタイプ別」
- CloudWatch アラーム：
RunningHoursが予想を超えたら SNS へ通知し、Auto Scaling ポリシーでスケールダウン。
|
1 2 3 4 5 6 7 8 9 10 11 |
aws cloudwatch put-metric-alarm \ --alarm-name "EMR-High-Running-Hours" \ --metric-name RunningHours \ --namespace AWS/ElasticMapReduce \ --statistic Sum \ --period 300 \ --threshold 1000 \ --comparison-operator GreaterThanThreshold \ --evaluation-periods 2 \ --alarm-actions arn:aws:sns:... |
結果：異常が検知された瞬間に自動でインスタンス数を削減でき、月額コストの増加を 5 % 未満 に抑制できます。
5‑2 主要クラウドベンダーの Spark サービス比較（導入）
AWS EMR・GCP Dataproc・Azure Synapse の３サービスはそれぞれ料金体系と機能に差があります。以下は 2024 年 6 月時点 の公開価格を元にした概算です（リージョンや割引（Savings Plans / Committed Use）未考慮）。
| 項目 | AWS EMR (オンデマンド) | GCP Dataproc (オンデマンド) | Azure Synapse (Apache Spark pool) |
|---|---|---|---|
| 課金対象 | EC2 インスタンス + EMR クラスタ管理料 ($0.10/ノード・時) |
Compute Engine インスタンス + Dataproc 管理料 ($0.01/CPU‑hour) |
vCore 時間 ($0.12/vCore‑hour) |
| 従量課金モデル | EMR Serverless (実行秒 × vCPU/GB) | Preemptible インスタンスで最大 80 % 削減可能 | スパークプールは自動スケーリングでアイドル時間は無課金 |
| 最大同時ジョブ数 | 1,000+ (EMR Serverless) | 500+ (Dataproc Jobs API) | 300+ (Spark pool) |
| 主な制限 | クラスタサイズ上限 10,000 インスタンス、Spot 回収リスク | Preemptible は 24 時間で自動終了、再起動が必要 | プールの最小 vCore 数は 3、スケールアウトは数分遅延 |
| 料金例（8 vCPU・30 GB） | 約 $0.20/時 (オンデマンド) |
約 $0.18/時 (標準) / $0.04/時 (Preemptible) |
約 $0.24/時 (標準) |
| 割引オプション | Savings Plans、Reserved Instances | Committed Use Discounts、Sustained Use Discount | Reserved Capacity、Hybrid Benefit |
結論：
- 短時間・不規則バッチ → EMR Serverless や GCP Preemptible がコスト最適。
- 長期安定稼働が必要な ETL → オンデマンド+Spot のハイブリッド（AWS/GCP）や Azure Synapse Spark pool が有利。
6. 実践チェックリスト
| 項目 | 完了チェック |
|---|---|
| KPI を定義し、Cost Explorer/BigQuery Billing Export にタグ付与したか | ☐ |
| インスタンスタイプをワークロードに合わせて最適化したか（CPU・メモリ比） | ☐ |
| Spot／Preemptible の導入とフェイルオーバー自動化が設定済みか | ☐ |
| Auto Scaling ポリシー (CPU、キュー長、時間帯) が有効か | ☐ |
| Executor / Shuffle 設定をベンチマークで検証したか | ☐ |
| データは Parquet/ORC + Snappy/ZSTD に変換済みか | ☐ |
| キャッシュとチェックポイントの利用基準を策定したか | ☐ |
| CloudWatch / Azure Monitor のコストアラートが設定されているか | ☐ |
| ベンダー間比較表で自社に最適なサービスを選定したか | ☐ |
7. まとめ
- KPI を数値化 し、Cost Explorer や Billing Export と連携させることで「費用が見える」状態を作ります。
- インスタンスタイプはワークロード特性に合わせて選定し、Spot／Preemptible のハイブリッド構成で 50‑80 % 削減を狙います（実際の削減率はリージョン・需要によります）。
- Auto Scaling と時間帯スケジューリング を併用すればアイドルコストが最小化できます。
- Spark の executor、shuffle、キャッシュ設定は公式ガイドラインと実測ベンチマークを組み合わせて調整し、過不足のないリソース配分を実現します。
- 列指向フォーマット＋高圧縮 がストレージ・I/O コスト削減の最も効果的な手段です。
- リアルタイムモニタリングとベンダー比較 によって、ジョブ特性に合ったサービス（EMR Serverless / Dataproc Preemptible / Synapse Spark pool）を選択し、長期的なコスト最適化基盤を構築します。
最終アクション：本ガイドのチェックリストを元に現在の環境を評価し、優先度が高い項目から段階的に実装してください。継続的に KPI をモニタリングすれば、費用とパフォーマンスのバランスを保ちながらスケールアウト/インが可能になります。
本記事の数値・表は 2024 年 6 月時点の公開情報に基づく概算です。リージョン別価格、Savings Plans / Committed Use Discount の適用、有料サポートプランなどを考慮した正確な見積もりは、各ベンダーの料金計算ツールをご利用ください。