DEA / ドメイン1 データの取り込みと変換

データ処理のコスト最適化

データ処理の費用は、「どれだけの計算資源を、どれだけの時間使うか」と「どれだけのデータを読み、置き、動かすか」で決まります。DEA では、同じ結果を安く得る方法として、計算の買い方 (Flex、スポット、)、読む量の削減 (パーティション、列指向、圧縮)、費用の監視 (、) が問われます。

Point
  • スポットインスタンスは、EC2 の空き容量を大きな割引で使う買い方です。AWS の都合で中断されることがあります。
  • Flex は AWS Glue の実行クラスで、空いている資源を使って安く実行します。開始が遅れることがあります。
  • 和訳

概要

概要の図 データ処理の費用 計算資源 × 時間 読むデータの量 保管と転送 Glue Flex・オートスケーリングEMR スポット・一時的なクラスターサーバーレスで待機をなくす パーティション・列指向・圧縮増分の処理 ライフサイクル・階層化同じリージョン・VPC エンドポイント
費用を決める要素例
計算 の 時間、 の の時間、 の GB 秒、 の 時間
スキャン量 と のスキャンしたバイト数
保管 の、Redshift のマネージドストレージ
リクエストと転送S3 の PUT/GET の回数、間や 間の転送、 ゲートウェイのデータ処理

主要技術

①計算資源の買い方 ⚠️ 頻出

サービス安くする方法条件
Flex 実行クラス急がないジョブ。G.1X/G.2X、Glue 3.0 以降
AWS Glueオートスケーリング、適切なワーカーの種類と数段階で処理量が変わる
AWS Glueジョブのタイムアウトを適切に設定異常に長い実行の費用を防ぐ
タスクノードをスポット、インスタンスフリート中断されてもデータを失わない構成
Amazon EMR一時的なクラスター、自動終了、マネージドスケーリング待機時間をなくす
Amazon EMRGraviton のインスタンス、常時動く部分
メモリ (と ) の最適な設定、Arm (Graviton) のアーキテクチャ実行時間とメモリの積が最小になる設定を測る
Serverless の最大 や使用量の上限、プロビジョンドの一時停止、リザーブドノード利用の時間帯が偏る / 常時使う

⚠️ 頻出: 「時間に余裕のある夜間の Glue ジョブのコストを下げたい」は Flex、「EMR のコストを下げたいが中断でデータを失いたくない」はタスクノードのスポットです。

②サーバーレスとプロビジョニングの費用の考え方

負荷の形有利な選択
散発的、1日に数回、予測できない (、 Serverless、 Serverless、、)。使わない時間の費用がない
常に高い負荷が一定に続く (EMR on のリザーブド、Redshift のプロビジョンドのリザーブドノード)。単価を下げられる

詳しい比較は「サーバーレスとプロビジョニングのトレードオフ」の章で扱います。

③読む量を減らす ⚠️ 頻出

や はスキャンしたデータ量で課金され、 や も読む量が多いほど時間がかかります。

手段効果
パーティション (日付など)WHERE 句の条件に合うフォルダだけを読む
列指向の形式 (/)必要な列だけを読む
圧縮読むバイト数そのものを減らす
増分の処理 (ブックマーク、)毎回全量を処理しない
Glue で読む前にパーティションを絞る
SELECT * を避ける必要な列だけを指定する
結果の再利用Athena のクエリ結果の再利用で、同じクエリを再実行しない

Athena のワークグループでは、1クエリあたりのスキャン量の上限 (データ使用量の制御) を設定し、想定外に大きなクエリを止められます。

④保管と転送の費用

手段内容
のライフサイクル古い raw データを低頻度アクセスやのクラスへ移す、不要になれば削除する
S3 Intelligent-Tieringアクセスの頻度が読めないデータを自動で安い階層へ
未完了のマルチパートアップロードの削除ライフサイクルルールで残骸を消す
の結合S3 のリクエストの回数と、処理のオーバーヘッドを減らす
同じで処理リージョン間の転送料金を避ける
S3 のゲートウェイ からの S3 へのアクセスで、 ゲートウェイのデータ処理料金を避ける

⑤AWS Budgets と Cost Explorer による監視 ⚠️ 頻出

サービス役割使いどころ
予算 (費用や使用量) を決め、実績や予測が閾値を超えたら通知する。アクションで ポリシーの適用などもできる「月の費用が予算の 80% を超えたら知らせる」
過去の費用と使用量をサービス、タグ、アカウントで分けてグラフで分析し、予測する「どのパイプラインの費用が増えたか」を調べる
コスト配分タグリソースのタグ (例: pipeline=sales) で費用を分けるチームやパイプラインごとの費用を見る
Cost Anomaly Detectionで、いつもと違う費用の増加を検知して通知する設定ミスによる急な費用の増加に気づく
⑤AWS Budgets と Cost Explorer による監視 ⚠️ 頻出の図 閾値を超えた 異常な増加 コスト配分タグpipeline=sales Cost Explorerタグ別に分析 AWS Budgets月の予算 SNS・メールで通知 Cost Anomaly Detection

⚠️ 頻出: 「費用が予算を超えそうになったら通知」は AWS Budgets、「費用の増減の内訳を分析」は Cost Explorer です。タグで分けるには、タグをコスト配分タグとして有効にしておきます。

試験対策

①判断マトリクス

問題文のキーワード選ぶ手段
急がない ジョブを安くFlex 実行クラス
Glue のワーカーが段階によって余るオートスケーリング
を安く、データは失わないタスクノードをスポット、インスタンスフリート
EMR が処理のない時間も動いている一時的なクラスター、自動終了、EMR Serverless
散発的な処理の待機時間の費用をなくす
のスキャン量が多く高いパーティション、、圧縮
想定外に大きな Athena のクエリを止めるワークグループのデータ使用量の制御
の費用と速さの最適点メモリの設定を測って調整、Arm
ゲートウェイの料金が へのアクセスで高いS3 のゲートウェイ
予算超過の前に通知
どのパイプラインの費用が増えたか + コスト配分タグ
急な費用の増加を自動で検知Cost Anomaly Detection

②よくある誤答

  • 期限の厳しいジョブに Flex やスポットを使うこと。開始の遅れや中断で SLA を守れません。
  • のコアノードやプライマリノードをスポットにして費用を下げること。
  • で予算超過の通知を設定しようとすること。通知は です。
  • 計算の費用だけを見て、スキャン量や転送の費用を見落とすこと。

参考文献

  1. ※1出題比率: AWS 公式の試験ガイドに記載された、採点対象の設問のうちその分野が占める割合です。

検索

キーワードを入力してください