大規模 EC サイトを運営する企業が以下のリアルタイムデータパイプラインを稼働させています。 【現在の構成】 ・顧客の行動ログ（ページビュー、クリック、購入イベント）を API Gateway で受信し、Kinesis Data Streams（10 シャード）に書き込む ・AWS Lambda（バッチサイズ 100、タイムアウト 15 分）がストリームを消費し、JSON 形式で Amazon S3 に書き込む（プレフィックス：logs/year=YYYY/month=MM/day=DD/） ・データアナリストが Amazon Athena でアドホッククエリを実行し、売上・行動分析レポートを作成している 【現在の問題点】 ・ブラックフライデー等のトラフィックスパイク時に Lambda が頻繁にタイムアウトし、データの重複書き込みまたは欠損が発生する ・Athena のクエリコストが月 $65,000 に達しており、その大半が複数ヶ月分のデータをフルスキャンするクエリに起因する ・データのエンドツーエンドレイテンシ（Kinesis 受信から S3 格納完了まで）が平均 12 秒で、SLA（サービスレベル合意）の 5 秒を超過している 【制約と追加要件】 ・アプリケーションチームによる Kinesis Data Streams への書き込みロジックは変更不可 ・アナリストのクエリパターン：全クエリの 80% が「過去 7 日間のデータを product_category 列と region 列でフィルタリング」するパターン ・Athena クエリコストを少なくとも 60% 削減することが必須要件 これらすべての問題を最も効果的に解決するアーキテクチャ変更はどれですか？
Kinesis Data Streams の下流に Amazon Data Firehose（旧称 Kinesis Data Firehose）を標準コンシューマーとして接続し、Lambda を廃止する。Firehose でダイナミックパーティショニングを有効化し、jq の式で product_category と region をパーティションキーとして抽出する（出力プレフィックス例：data/category=!{partitionKeyFromQuery:product_category}/region=!{partitionKeyFromQuery:region}/year=.../month=.../day=.../）。AWS Glue データカタログと連携した Apache Parquet 形式への自動変換も有効化する。Athena はパーティションプルーニングとカラム型フォーマットの組み合わせにより大幅にスキャン量が削減される。 Amazon Data Firehose（選択肢B・正解）はフルマネージドサービスのためLambdaのタイムアウト・重複書き込み問題が解消されます。ただしダイナミックパーティショニング有効時はzero bufferingが利用不可でバッファ間隔は60秒以上となるため、エンドツーエンドレイテンシ5秒のSLAは本構成では達成できません。3つの問題のうち最多を効果的に解決する選択肢です。ダイナミックパーティショニングによりproduct_categoryとregionでデータが分割されるため、全クエリの80%で不要なパーティションをスキップでき、Parquetのカラム型ストレージと組み合わせることでAthenaのスキャンデータ量が大幅に削減され60%以上のコスト削減が可能です。 選択肢Aは理由。Lambdaメモリ増加・予約済み同時実行数設定はLambdaの根本的なスケーラビリティ問題（タイムアウト・重複書き込み）を解決しません。Glueクローラーとワークグループのスキャン上限設定はコスト可視化には有効ですが、スキャンデータ量の根本的削減にはならず60%削減要件を達成できません。 選択肢Cは理由。シャード数50への拡張 + 1時間ごとのGlue ETL はシャード増加コストが高く、1時間ごとのETL変換前はJSONデータへのスキャンが残るためAthenaコスト60%削減を安定して達成できません。また根本的なLambdaタイムアウト問題も解消されません。 選択肢Dは理由。Firehose + EMR Serverless 30分ごと変換はEMR Serverlessの起動コストと30分の変換ラグが発生します。Firehoseで直接Parquet変換できる選択肢Bと比べ構成が過剰で追加コストも大きくなります。