Q19 — AWS SAA-C03 第10章

第 19/100 問 | ← 第10章

Q619. ある企業には、サードパーティベンダーからほぼリアルタイムでデータを受信できる REST ベースのインターフェイスを持つアプリケーションがあります。受信したデータは、アプリケーションによって処理され、さらに分析するためのストレージに保存されます。このアプリケーションは Amazon EC2 インスタンス上で実行されています。サードパーティベンダーは、アプリケーションへデータを送信する際に多数の 503 Service Unavailable エラーを受信しています。データ量が急増すると、コンピューティング能力が最大限に達し、アプリケーションがすべてのリクエストを処理できなくなっています。よりスケーラブルなソリューションを提供するために、ソリューションアーキテクトが推奨すべき設計はどれですか？

正解: A. Amazon Kinesis Data Streams を使用してデータを取り込み、AWS Lambda 関数でデータを処理します。

解説

データ量の急増時に 503 Service Unavailable エラーが発生し、スケーラビリティに課題があるアプリケーションに対して、よりスケーラブルなソリューションを提供するには、以下の設計が推奨されます： A. Amazon Kinesis Data Streams を使用してデータを取り込み、AWS Lambda 関数でデータを処理します。 Kinesis Data Streams は、高ボリュームのデータ取り込みを耐久性高くスケーラブルに処理できるストリーミングサービスです。アプリケーションを Kinesis Data Streams 経由でデータを受信するように構成することで、EC2 インスタンスのコンピューティング上限に達することなく、データ量のピークにも対応できます。また、AWS Lambda 関数を用いて Kinesis Data Streams からのデータをサーバーレスで処理すれば、着信データ量に応じて自動的にスケール可能であり、ほぼリアルタイムでの処理が可能です。処理済みデータは、その後、分析のために保存できます。 B は最適な選択肢ではありません： API Gateway を既存アプリケーションの上位に配置し、クォータ制限付きの使用プランを設定しても、スケーラビリティやデータ量の急増への対応という根本的な課題を解決しません。これは API の利用制御・管理には有効ですが、着信データの処理能力向上には寄与しません。 C も最適な選択肢ではありません： Amazon SNS をデータ取り込みに使用し、EC2 インスタンスを Application Load Balancer の背後に配置した Auto Scaling グループで実行する方法は、データ量の増加に対応するための直接的なスケーリングソリューションとはなりません。SNS はメッセージ配信サービスであり、ほぼリアルタイムのデータ受信・処理というユースケースには最も適した選択肢ではありません。 D も最適な選択肢ではありません： アプリケーションをコンテナ化し、EC2 ランチタイプの Amazon ECS と Auto Scaling グループでデプロイすることはスケーラビリティを向上させますが、AWS Lambda などのサーバーレス関数で十分に処理可能な場合、コンテナ化は不要な複雑さを導入する可能性があります。また、問題文にはコンテナ化に関する要件は一切記載されていません。 したがって、本シナリオにおいて最も適切なスケーラブルな設計は、Amazon Kinesis Data Streams を用いたデータ取り込みと AWS Lambda 関数による処理（選択肢 A）です。