【AWS SAA】文系卒でもわかる！S3のデータを賢く使うためのAWS Glue入門（データ分析基盤の第一歩）
あなたは、急成長中のD2Cアパレルブランドに入社したばかりの新人データアナリストです。ある日、CTOから次のような相談を受けました。
「Web広告の費用対効果を最大化するため、広告のクリックログデータを分析して、どの広告が売上に繋がっているかをリアルタイムに近い形で把握したい。現状、広告代理店から毎時、数ギガバイトにもなる巨大なCSV形式のログデータが送られてきて、S3に保存しているだけなんだ。このままではデータが大きすぎて、分析チームがクエリを実行するたびに時間がかかりすぎ、コストもかさんでいる。この状況をなんとかしてほしい。」
CTOからの具体的な依頼は以下の通りです。
「S3に保存されたCSVログデータを、分析に適した高速な形式（Parquet）に自動で変換する仕組みを構築し、分析クエリの速度を50%改善、運用コストを30%削減してほしい。」
技術的制約/要件:
広告代理店から毎時提供される、ファイルサイズが1GBを超えるCSVファイルがS3バケットにアップロードされる。
ファイルがアップロードされたことをきっかけ（トリガー）に、自動で処理を開始すること。
サーバーのプロビジョニングやOSのパッチ当てといった、インフラ管理の手間（運用オーバーヘッド）は極力ゼロにしたい。
設問:
この要件を満たすために最もコスト効率が良く、運用オーバーヘッドの少ないアプローチを1つ選択してください。
A. S3へのファイルアップロードをトリガーにAWS Lambda関数を起動する。Lambda関数内でCSVファイルをダウンロードし、ライブラリを使ってParquet形式に変換後、別のS3バケットにアップロードする。
B. S3へのファイルアップロードをトリガーにAWS Lambda関数を起動する。Lambda関数からAmazon EMRクラスタ上で動作するApache Sparkジョブを呼び出し、CSVからParquetへの変換処理を実行させる。
C. 毎日深夜にCloudWatch EventsでAWS Lambda関数を定期実行する。Lambda関数からAmazon Athenaを呼び出し、S3上のCSVファイルに対してクエリを実行してParquet形式で結果を別のS3バケットに保存する。
D. S3へのファイルアップロードをトリガーにAWS Lambda関数を起動する。そのLambda関数がAWS GlueのETLジョブを開始し、CSVファイルをParquet形式に変換して別のS3バケットに保存する。
【この問題のポイント】
このタイプの課題、悩みますよね。「S3にファイルが置かれたら何かする」という仕組みはよくありますが、**「その “何か” をどのサービスに任せるのが最適か？」**を見極めるのが合格へのカギです。
特に、Lambdaの手軽さと、それが故の限界を正しく理解しているか。そして、**AWS Glueという「データ加工のプロフェッショナル」**の存在を知っているかが問われています。一見、Lambdaだけで何でもできそうに思えるのが、この問題の落とし穴です。
【結論】このシナリオの「鉄板構成」はこれだ！
結論から言うと、このシナリオの最適解、つまり「鉄板構成」は選択肢Dの 「S3イベントでLambdaを起動し、LambdaがAWS Glue ETLジョブを呼び出す」 構成です。
なぜこれが最適解なのでしょうか？理由はシンプルで、CTOの出した要件に最もスマートに応えられるからです。
サーバー管理が不要 (サーバーレス): S3、Lambda、GlueはすべてAWSが裏側を管理してくれるマネージドサービスです。あなたがサーバーの心配をする必要は一切ありません。
大規模データに強い: 1GBを超えるような巨大ファイルの変換は、汎用的なLambdaには荷が重い仕事です。一方、AWS Glueは大量のデータを効率的に処理（ETL）するために生まれた専門サービスなので、まさに適任です。
イベント駆動で自動化: S3にファイルが置かれた瞬間に、一連の処理が自動で動き出すため、手作業は発生しません。
まさに「餅は餅屋」。それぞれのサービスが最も得意なことだけを担当させる、美しく効率的なアーキテクチャなのです。
【要点整理】登場サービスはこれだけ覚えよう
この問題を解くために必要な登場人物は4人だけです。彼らのキャラクターを掴んでしまいましょう！
【ひっかけ問題対策】よくある間違い選択肢の見抜き方
SAA試験では、正解を選ぶのと同じくらい「なぜ他が間違いなのか」を理解することが重要です。よくある「ひっかけパターン」をここでマスターしてしまいましょう。
ひっかけパターン1：「何でも屋のLambda」の罠（選択肢A）
解説: Lambdaは非常に便利ですが、万能ではありません。実行時間は最大15分、メモリや一時ディスク容量にも制限があります。1GBもの巨大ファイルをダウンロードし、変換し、再度アップロードする、という一連の処理は、タイムアウトしたりメモリ不足に陥るリスクが非常に高いです。
見抜き方: 問題文に「大容量ファイル」「数GBのデータ」「長時間のバッチ処理」といったキーワードが出てきたら、「Lambda単独で処理するのは危険かも？」と疑いましょう。Lambdaはあくまで「軽い処理」や「他のサービスへの橋渡し役」と考えるのが基本です。
ひっかけパターン2：「オーバースペック＆運用負荷」の罠（選択肢B）
解説: Amazon EMR（Apache Spark）は、超大規模なデータ処理における強力な選択肢です。しかし、これは自分でサーバー群（クラスタ）を管理する必要があります。「サーバーレスで運用負荷を最小限に」という今回の要件とは真逆のアプローチです。
見抜き方: 問題文の要件に「運用オーバーヘッドを最小化」「サーバーレスで構成」「マネージドサービスを優先」といった言葉があれば、EC2やEMRのようにインフラ管理が必要なサービスは、不正解の可能性が高いと判断できます。
ひっかけパターン3：「サービスの役割誤認」の罠（選択肢C）
解説: Amazon Athenaは、S3にあるデータを直接SQLで「問い合わせ（クエリ）」するためのサービスです。一方、AWS Glueはデータを「変換・加工（ETL）」するためのサービス。目的が根本的に違います。また、この選択肢は「毎日深夜に定期実行」となっており、「ファイルがアップロードされたことをトリガーに」という要件も満たせていません。
見抜き方: 「データを変換したいのか」、それとも「データを**分析（クエリ）**したいのか」を明確に区別しましょう。動詞に注目するのがポイントです。変換ならGlue、分析ならAthena、と覚えてください。
【合格への最短ルート】この問題から盗むべき「思考の型」
最後に、この一問から学べる、他の問題にも応用できる「思考の型」を伝授します。これを身につければ、正解へのスピードが格段に上がります。
思考のショートカット
トリガーは何か？ → 問題文の「ファイルがアップロードされたことをきっかけに」から、**「S3イベント通知」**が起点だと瞬時に判断する。
何の処理をするか？ → 「CSVをParquetに変換」から、これは**「ETL処理」**だと見抜く。
データ規模と制約は？ → 「1GBを超える」「運用オーバーヘッドは極力ゼロ」から、**「大規模データ」を「サーバーレス」**で扱う必要があると理解する。
最適なサービスは？ → 上記の3要素（S3イベント、大規模ETL、サーバーレス）をすべて満たす黄金の組み合わせは… **「S3 → Lambda → Glue」**しかない！と結論づける。
絶対に覚えるべき暗記リスト
サーバーレスETL = AWS Glue: このキーワードの組み合わせは絶対です。「サーバーレスで大規模なデータ変換」と来たら、99% Glueが答えの候補になります。
Lambdaは「司令塔」: Lambda自身が重い処理をするのではなく、S3からの通知を受けてGlueやStep Functionsといった専門サービスを呼び出す「司令塔」や「橋渡し役」として使うのが、美しいアーキテクチャの基本です。
Parquetは分析の味方: データ分析のシナリオで「クエリを高速化」「コストを削減」という要件が出てきたら、Parquet形式への変換が有効な手段であることを思い出してください。
この思考の型をマスターして、ぜひ合格を勝ち取ってください！応援しています！
