LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

AWS Glue/EMRのETLコスト最適化とは

AWS Glue/EMRのデータ処理・ETLコスト最適化とは、AWSが提供するマネージドデータ統合サービス（Glue）とビッグデータ処理基盤（EMR）における課金構造を理解し、ジョブ設計・クラスタ設定・実行タイミングを見直すことで、処理品質を維持しながら費用を削減する取り組みを指します。

AWS GlueはDPU（Data Processing Unit）単位で課金されます。1 DPUは4 vCPUと16 GBのメモリに相当し、標準のETLジョブは0.44 USD/DPU時間で秒単位に計算されます^*1。Amazon EMRは、EC2インスタンス料金にEMR追加料金が上乗せされる仕組みです^*2。

どちらのサービスも、設計の妥当性よりも「とりあえず動く設定」のまま運用を続けると、使われていないコンピュートリソースに料金が発生し続けます。データ量が増えるほどこの差は広がるため、適切なタイミングで設定を見直すことが費用管理の前提となります。

GlueのDPU過剰・EMRの常時稼働 — コスト増加の2大原因

Glue/EMRのコストが想定より高くなる背景には、サービス固有の課金構造への理解不足と、設計時の「余裕見込み」が積み重なるパターンがあります。

AWS GlueのDPU過剰プロビジョニング

AWS GlueのETLジョブは、デフォルトで複数のDPUが割り当てられます。DPUが多いほどジョブは速く完了しますが、データ量や処理の複雑さに対して過剰なDPU設定を維持し続けると、余剰分のコンピュートリソースへ料金が発生します。

ワーカータイプにはG.025X（0.25 DPU / 2 vCPU / 4 GB）・G.1X（1 DPU / 4 vCPU / 16 GB）・G.2X（2 DPU / 8 vCPU / 32 GB）の3種類があります^*3。小規模のストリーミングジョブにG.2Xを使用している場合、G.025Xへの変更だけで大幅な費用削減が見込めます。

また、パーティション化されていないS3データを全件読み込むジョブは、処理対象を絞るだけでDPUの消費量を減らせます。フィルタ条件をデータ読込前に適用する「述語プッシュダウン（Predicate Pushdown）」は、Glueが標準的にサポートする最適化手法の一つです。

Amazon EMRの常時稼働クラスタ

EMRは、クラスタを起動したままにしておくと処理が終わった後もEC2インスタンス料金とEMR追加料金が発生し続けます。バッチ処理が終了した後もクラスタが稼働している「常時稼働クラスタ」は、コスト増加の典型的なパターンです。

夜間バッチや月次集計など、処理頻度が低いジョブで常時稼働クラスタを維持することは、稼働時間のうちの多くをアイドル状態で過ごすことを意味します。クラスタの用途とジョブの頻度を整理し、適切な運用形態を選択することが費用管理の基本となります。

Glue固有のコスト削減手法：FLEX・G.025X・Auto Scaling・述語プッシュダウン

AWS Glueには、コスト削減に直結する複数の機能が用意されています。それぞれの特性を理解した上で、ジョブの性質に合わせて組み合わせることが大切です。

FLEX実行クラス：非緊急ジョブを0.29 USD/DPU時間で実行

FLEX実行クラスは、処理完了を急がないジョブ向けの低単価オプションです。標準の0.44 USD/DPU時間に対し、FLEX実行クラスは0.29 USD/DPU時間で実行できます^*1。夜間バッチや翌日締め処理のように、数時間の遅延が許容されるジョブに適しています。

AWSの実行キューに空きキャパシティが生じたタイミングで動作する仕組みのため、開始時刻の保証はありません。リアルタイム性や締め時間が厳密なジョブには向かず、ジョブの優先度とFLEXの適用可否を個別に判断する必要があります。

G.025Xワーカー：低ボリュームストリーミング向けの小型DPU

G.025Xは0.25 DPU（2 vCPU / 4 GB メモリ）の小型ワーカータイプです^*3。AWS Glue バージョン3.0以降のストリーミングジョブで利用できます。データ量が少ないストリーミングジョブをG.1XやG.2Xで動かしている場合、G.025Xへの切り替えでDPU消費を4分の1まで減らせます。

ただし、G.025Xはストリーミングジョブ専用であり、通常のバッチETLジョブには利用できません。対応バージョンと用途の要件を確認した上で採用を検討してください。

Auto Scaling：Glue 3.0以降で有効なDPU動的調整

AWS Glue 3.0以降では、Auto Scalingによってジョブ実行中にDPU数を動的に増減させることができます。処理データの増減に応じてコンピュートリソースが自動調整されるため、固定DPU設定で発生する余剰コストを抑えられます。

Auto Scalingを有効にする際は、DPU数の下限と上限の設定に注意が必要です。上限値を設定しないと、データ量の急増時にDPUが意図せず大量に割り当てられ、コストが増えることがあります。設定変更後は実際の処理ログを確認しながら調整することが実務上の標準的な進め方です。

述語プッシュダウンとパーティション設計

S3に保存したデータを「年月日」などのキーでパーティション分割しておくと、Glueジョブが必要な期間のデータだけを読み込めます。これによりスキャン対象のデータ量が減り、DPUの消費時間を短縮できます。

既存のデータレイクでパーティション設計が不十分な場合は、データの再配置が必要になるため、改修範囲と優先度の見極めが重要です。ジョブ実行ログで入力データ量と実行時間を確認し、ボトルネックとなっているジョブから着手するのが効率的です。

EMR固有のコスト削減手法：Spot活用・インスタンスフリート・トランジェントクラスタ

Amazon EMRのコスト削減は、EC2のインスタンスタイプ選択とクラスタの運用形態の見直しが中心になります。いずれも設定の変更だけで対応できますが、稼働中のジョブへの影響を事前に確認することが不可欠です。

Spotインスタンスの活用：大規模バッチジョブでの費用削減

Amazon EC2のSpotインスタンスはAWSの余剰キャパシティを活用した購入オプションで、オンデマンド料金より低単価で利用できます^*2。EMRのタスクノード（処理専用ノード）にSpotを割り当てることで、バッチジョブの計算コストを抑えられます。

Spotインスタンスは需給状況によってAWSから強制回収されることがあります。EMRではSpotが回収された際にジョブが自動的に残りのノードで継続される仕組みがありますが、大規模ジョブで多くのタスクノードがSpotで構成されている場合、回収タイミングによってジョブが失敗するリスクがあります。マスターノードとコアノードはオンデマンドまたはリザーブドに、タスクノードのみSpotにするのが一般的な構成です。

インスタンスフリートで柔軟なキャパシティ確保

インスタンスフリート（Instance Fleet）は、複数のインスタンスタイプとSpot/オンデマンドを組み合わせてEMRクラスタを構成する機能です。単一のインスタンスタイプに依存しないため、特定のインスタンスのSpot単価が上昇したり、在庫が不足したりした場合でも、代替インスタンスタイプからキャパシティを確保できます。

インスタンスフリートを使う際はターゲットキャパシティ（必要なvCPU数またはインスタンス数）を設定します。どのインスタンスタイプが選ばれるかはAWSの判断に委ねられるため、インスタンスサイズの違いによる処理性能の変動も考慮した設計が必要です。

トランジェントクラスタ：処理後即時終了で無駄なコストをゼロにする

トランジェントクラスタとは、ジョブの実行が完了したら自動的にクラスタを終了する運用形態です。常時稼働クラスタと異なり、処理時間分のみEC2料金とEMR追加料金が発生します。バッチジョブが1日1回または週1回程度の頻度であれば、トランジェントクラスタに切り替えることでアイドル時間のコストを大幅に削減できます。

注意点は、クラスタの起動と終了に数分から十数分かかるため、処理レイテンシが増えることです。またHDFSに保存したデータはクラスタ終了時に消えるため、処理結果はS3に出力する設計が前提となります。既存ジョブのデータフローがHDFS依存になっていないか事前に確認してください。

内製対外注の比較：必要スキルと実装リスクを整理する

Glue/EMRのコスト最適化を内製で進めるか外注するかは、社内のAWS・Sparkスキルとジョブの本番影響範囲によって判断が異なります。

内製で進める場合、AWS GlueおよびEMRのチューニングには、Sparkの実行モデルへの理解と実機でのプロファイリング経験が必要です。設定変更後の検証を省略すると、本番ジョブの停止や処理遅延につながります。

外注する場合は、社内エンジニアがジョブ一覧や現在の設定値・コスト明細を整理した上でパートナーに渡せるかどうかが、作業の効率と精度を左右します。発注前の社内整理が最適化効果を引き出す前提条件です。

外注先の選定基準：Glue/EMR実績・チューニング対応力・コスト可視化能力

Glue/EMRのコスト最適化を外注する際、パートナーの選定では技術的な実績と費用管理への対応力を軸に評価することが大切です。

AWS Glue/EMRの実機チューニング実績

Glue/EMRのコスト最適化は、ドキュメントを読むだけでは実践が難しい作業です。実際の本番環境でジョブプロファイリングを行い、DPU設定やSpot比率を調整した経験がパートナーにあるかを確認してください。提案書内に具体的な改善事例（ジョブの種類・実施内容・結果の定性的記述）があるかどうかが、実務経験の判断材料になります。

FLEXやAuto Scalingの設計知識

FLEX実行クラスはすべてのジョブに適用できるわけではなく、どのジョブに適用するかを判断するにはジョブの処理目的と許容遅延の把握が必要です。Auto ScalingのDPU上限設定も、処理ピーク時のコスト爆発を防ぐための重要なパラメータです。これらをジョブ単位で設計できるパートナーかどうかを確認しましょう。

コスト改善の可視化と報告体制

最適化作業の効果を測るには、改修前後のコスト比較が必要です。AWS Cost Explorerやコストタグを活用してジョブ単位のコスト変化を定量的に示す報告書を提出できるパートナーかどうかを確認してください。単に設定変更を行うだけでなく、費用削減の根拠を共有できる体制があることが、継続的な最適化につながります。

社内ナレッジ移転への姿勢

外注後も社内エンジニアがジョブの設定変更や追加チューニングを行えるよう、作業内容の説明と設定変更ドキュメントの納品をパートナーに依頼することをお勧めします。ブラックボックス化した運用は、担当者交代時のリスクになります。

Glue/EMRの最適化に必要な知識は、AWS Certified Data Analytics（現: AWS Certified Data Engineer）レベルの専門性を含みます。社内でこのスキルを持つ担当者がいない場合は、適切なパートナーへの委託が現実的な選択肢になります。

まとめ：ETLコスト最適化を成功させる3つの判断軸

本稿ではAWS GlueとEMRのデータ処理・ETLコスト最適化について整理しました。要点を3つに集約すると次のとおりです。第一に、コスト増加の根本原因はDPUの過剰設定とEMRの常時稼働クラスタにあり、まずジョブ単位のコスト分析から着手することが重要です。第二に、FLEX実行クラス・G.025Xワーカー・EMR Spot・トランジェントクラスタなど、AWSが提供する公式の最適化機能を組み合わせることで費用を段階的に削減できます。第三に、内製対応にはSpark・AWSコスト管理の専門スキルと実機検証が必要で、外注を活用する場合はGlue/EMRの実機チューニング実績とコスト可視化能力を持つパートナーを選ぶことが成果の分岐点となります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Amazon Web Services「AWS Glue 料金」（2024年、AWS公式ページ）
2. *2　出典：Amazon Web Services「Amazon EMR の料金」（2024年、AWS公式ページ）
3. *3　出典：Amazon Web Services「AWS Glue ジョブプロパティの設定（ワーカータイプ仕様）」（AWS公式ドキュメント）

Tweet