AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. Amazon EMR で固定台数のクラスターを常時稼働させ、必要に応じて手動でノード数を調整する

Amazon EMR は Spark を動かせる実行基盤だが、この選択肢は固定台数のクラスターを常時稼働させ、ノード数は手動調整という構成になっている。
日次処理しか走らないのにクラスターを 24 時間動かし続けるのは無駄が大きく、「コストを抑えたい」という要件に反する。
また処理量が日々変動する本問では、手動調整では追従できない（EMR を使うなら Managed Scaling や一時クラスター、EMR Serverless が前提になる）。

正解

B. AWS Glue の Spark ETL ジョブを使用し、ワーカータイプと最大ワーカー数を指定したうえで Auto Scaling を有効にする

AWS Glue は Apache Spark をベースにしたサーバーレスの ETL サービスで、クラスターの構築・パッチ適用・停止といった管理が一切不要。
ワーカータイプ（G.1X / G.2X など）と最大ワーカー数を指定して Auto Scaling を有効にすると、ジョブ実行中の負荷に応じてワーカー数が自動で増減し、処理量が多い日は並列度を上げ、少ない日はワーカーを使い切らずに済む。
課金はジョブが動いた分（DPU 時間）だけで、フォーマットが倉庫ごとに異なるファイルのクレンジング・統合も Glue のデータカタログや DynamicFrame と組み合わせて扱いやすい。要件をすべて満たす最適解。

C. AWS Step Functions と AWS Lambda を組み合わせ、ファイルを分割しながら順次処理する

Step Functions と Lambda でファイルを分割して順次処理する構成は、本問が前提としている Spark ベースの分散変換処理にならない。
分割ロジック・状態管理・リトライ設計を自前で組み立てる必要があり、実装と保守の負担が大きい。
さらに Lambda の最大実行時間（15 分）とメモリの制約が残るため、大容量ファイルの結合や集計を伴う処理には向かない。

D. AWS Lambda 関数(Python)でファイルを直接読み込み、変換処理を実行する

AWS Lambda 関数で S3 のファイルを直接読み込んで変換する方式は、最大 15 分の実行時間、限られたメモリと一時ディスクという制約を受ける。
日によってファイル量が大きく変動する本問では、量が増えた日にタイムアウトやメモリ不足で失敗しやすい。
Lambda が適するのは小さなファイルの軽量な変換やイベント駆動の前処理であって、Spark 規模の一括変換ではない。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
Spark ベースの変換処理でクレンジング・統合したい	Spark を動かせるのは EMR か Glue。Lambda には Spark の分散実行基盤がない →選択肢（C・D）を消す
日によってファイル量が大きく変動し、処理能力を自動調整したい	Glue の Auto Scaling（バージョン 3.0 以降）なら、最大ワーカー数の範囲で実行中に自動増減する。手動調整は追従できない →選択肢（A）を消す
コストを抑えたい（処理は日次のみ）	ジョブ実行時間だけ課金される Glue が有利。常時稼働クラスターはアイドル時間もそのまま課金される →選択肢（B）が正解
フォーマットが倉庫ごとに異なるファイルを統合する	Glue のデータカタログ／クローラーと DynamicFrame でスキーマ差異を扱いやすい。運用工数の面でも有利 →選択肢（B）が正解
1 ファイルあたりの処理が長時間・大容量になり得る	Lambda は最大 15 分・メモリ上限があり、量が増えた日に失敗する。分割して回避しても複雑さが残る →選択肢（C・D）を消す

ひっかけポイント

• 選択肢 A は「EMR＝Spark」で正しそうに見えるが、固定台数を常時稼働＋手動調整という構成が要件（自動調整・コスト抑制）を外している。サービス名ではなく構成まで読むのが本問の勘所
• Step Functions を挟むと高度な設計に見えるが、Lambda の 15 分制限は消えない。オーケストレーションは実行時間の制約を解決しない
• 「ファイルを分割しながら順次処理」は逐次処理であり、日次で量が跳ねたときにトータル時間が伸びる。Spark の並列処理の代替にならない
• Glue の Auto Scaling はバージョン 3.0 以降で、指定する NumberOfWorkers は「最大ワーカー数」として働く。標準 DPU ではなく G 系／R 系のワーカータイプが対象である点も押さえる

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「Hive や HBase など Hadoop エコシステムを含めて自前で細かくチューニングしたい」	Amazon EMR（Managed Scaling ／ スポットインスタンス併用）が正解軸に。
「Spark ジョブを動かしたいが、Glue の制約を避けつつサーバーレスで実行したい」	EMR Serverless が正解に浮上する。
「処理対象は数 MB の小さな JSON を 1 件ずつ、到着と同時に変換したい」	S3 イベント通知＋AWS Lambda が正解に。Glue はオーバースペックになる。
「コードを書かずに GUI でデータ品質チェックやクレンジングを行いたい」	AWS Glue DataBrew（および Glue Data Quality）が正解軸に。

関連サービスの解説

Amazon EMR
Amazon Simple Storage Service (Amazon S3)
AWS Glue
AWS Lambda

リファレンス

この問題を解くために必要な知識を扱う公式ドキュメントです。

知識項目	公式ドキュメント
AWS Glue ジョブの Auto Scaling（最大ワーカー数の範囲で自動増減）	AWS Glue 向けの自動スケーリングの使用