Q68 — AWS SAA-C03 第16章
第 68/100 問 | ← 第16章
Q1268. ある企業が、自社ウェブサイトからのクリックストリームデータを処理するサーバーレスアプリケーションを構築しています。クリックストリームデータは、アプリケーションのWebサーバーからAmazon Kinesis Data Streamsに送信されます。同社は、このクリックストリームデータをAmazon Aurora Multi-AZデータベースに格納された顧客プロファイルデータと結合(ジョイン)してエンリッチ(拡張)したいと考えています。また、エンリッチされたデータをAmazon Redshiftで分析することを希望しており、ソリューションには高い可用性(High Availability)が求められます。これらの要件を満たすソリューションはどれですか?
- A. AWS Lambda関数を使用してクリックストリームデータを処理・エンリッチし、同一のLambda関数でエンリッチされたデータをAmazon S3に書き込みます。その後、Amazon Redshift Spectrumを用いてAmazon S3内のエンリッチ済みデータをクエリします。 ✓
- B. Amazon EC2 Spot Instanceを使用してデータストリームをポーリングし、クリックストリームデータをエンリッチします。EC2インスタンスを設定してCOPYコマンドを実行し、エンリッチされた結果をAmazon Redshiftに送信します。
- C. Amazon Elastic Container Service(Amazon ECS)タスクをAWS Fargate Spot容量で使用してデータストリームをポーリングし、クリックストリームデータをエンリッチします。さらに、Amazon EC2インスタンスを設定してCOPYコマンドを実行し、エンリッチされた結果をAmazon Redshiftに送信します。
- D. Amazon Data Firehoseを使用して、Kinesis Data StreamsからクリックストリームデータをAmazon S3にロードします。AWS Glueクローラーを用いてスキーマを推定し、AWS Glue Data Catalogを更新します。その後、Amazon AthenaでAmazon S3内の生データをクエリします。
正解: A. AWS Lambda関数を使用してクリックストリームデータを処理・エンリッチし、同一のLambda関数でエンリッチされたデータをAmazon S3に書き込みます。その後、Amazon Redshift Spectrumを用いてAmazon S3内のエンリッチ済みデータをクエリします。
解説
Kinesis Data Streamsからのクリックストリームデータを処理・エンリッチし、Auroraの顧客プロファイルデータと結合した上で、Amazon Redshiftで分析するという要件を、高い可用性(HA)とサーバーレス性を両立して満たす最も適切なソリューションは以下の通りです。 正解:A。AWS Lambda関数を用いてクリックストリームデータを処理・エンリッチし、同一のLambda関数でエンリッチ済みデータをAmazon S3に書き込み、Amazon Redshift SpectrumでS3内のデータを直接クエリする。 なぜ選択肢Aが最適か: ・サーバーレスかつ高可用性:AWS Lambdaは、複数のAZにまたがって自動的に実行されるため、本質的に高可用性であり、Kinesisのスループットに応じて自動スケーリングされます。EC2 SpotやFargate Spotのような中断リスクのあるリソースや、サーバー管理のオーバーヘッドが不要です。 ・効率的なデータエンリッチ:LambdaはKinesis Data Streamsをポーリングし、RDS Proxyを経由してAurora Multi-AZから顧客プロファイルデータを取得・結合できます。エンリッチされたデータは、耐久性・スケーラビリティ・コスト効率に優れたAmazon S3に保存されます。 ・Redshiftによるシームレスな分析:Redshift Spectrumを使えば、データをRedshiftクラスター内にロードせずにS3上のデータを直接クエリでき、ストレージコストを削減できます。必要に応じて、COPYコマンドでS3からRedshiftへデータをロードすることも可能です。 ・コスト効率:Lambda、S3、Redshift Spectrumは課金単位が「使用量」であるため、アイドル時の無駄なコストが発生しません。常時稼働するEC2/ECSインスタンスは不要です。 他の選択肢が不適切な理由: B:EC2 Spot Instanceは突然終了される可能性があり、データ損失や複雑な再試行ロジックが必要になるため、高可用性を保証できません。また、スケーリング、フェイルオーバー、Aurora接続の管理など、運用負荷が大きく、常に稼働させる場合のコストもLambdaより高くなります。 C:Fargate SpotもSpotリソースのため、中断リスクがあり、チェックポイントや再起動ロジックの実装が必要です。さらに、ECS+EC2というハイブリッド構成は複雑さを増し、EC2側のCOPYステップにも手動管理が伴います。 D:Data FirehoseはAuroraとの結合(ジョイン)機能を持たないため、エンリッチ処理が不可能です。また、要件では「Amazon Redshiftで分析」と明記されているのに対し、Athenaは代替手段ではなく、Redshift Spectrumを活用した選択肢Aの方が要件に合致します。さらに、Athenaは生データを対象とするため、エンリッチ済みのコンテキストを含む分析には不向きです。 高可用性観点での比較: ・データ処理:選択肢A(Lambda:マルチAZ) vs 選択肢B/C(Spot:中断リスクあり) ・データ保存:すべてS3(マルチAZ)およびRedshift(マルチAZ) ・クエリ層:選択肢A(Redshift Spectrum:サーバーレス) vs 他(Redshiftの稼働状態依存) 結論:選択肢Aは、完全なサーバーレス設計と高可用性(Lambda+S3+Redshift Spectrum)、KinesisとAuroraの結合による効率的なエンリッチ、課金単位が使用量であるコスト効率の良さ、およびRedshiftによる分析要件(SpectrumまたはCOPYによるロード)をすべて満たす唯一の選択肢です。 最終回答:A