Q87 — AWS SAA-C03 第16章

第 87/100 問 | ← 第16章

Q1287. ある企業は、Amazon Elastic Container Service（Amazon ECS）クラスター上でコンテンツ管理システムを実行しています。このシステムでは、訪問者が製品に関するフィードバックを提供するために、ドキュメントおよび製品の写真をAmazon S3バケットにアップロードできます。同社は、アップロードされたドキュメントを処理してテキストおよび画像のセンチメント分析を実行するAWS上のワークフローを保有しており、この処理ワークフローでは複数のAWSサービスが呼び出されます。企業は、この処理ワークフローを自動化するソリューションを必要としています。また、失敗したアップロードも確実に処理できる必要があります。これらの要件を満たすとともに、**最小限の工数**で実現できるソリューションはどれですか？

• A. S3イベント通知を使用して、イベントをAmazon Simple Notification Service（Amazon SNS）トピックに発行します。Amazon ECSクラスター上でWebアプリケーションをデプロイし、そのSNSトピックをサブスクライブしてイベントを受信・監視し、処理ワークフローをオーケストレーションします。
• B. S3イベント通知を使用して、イベントをAmazon Simple Queue Service（Amazon SQS）キューに発行します。ロングポーリングを設定します。処理ワークフローをオーケストレーションするスクリプトを実行するAmazon EC2インスタンスをデプロイします。
• C. S3イベント通知を使用して、イベントをAmazon Simple Queue Service（Amazon SQS）キューに発行します。キュー内のメッセージ数に基づいてスケールするECSクラスターを作成します。このクラスターが処理ワークフローをオーケストレーションするように設定します。
• D. S3イベント通知を使用してAmazon EventBridgeルールを起動します。このルールを設定して、処理ワークフローをオーケストレーションするAWS Step Functionsワークフローを開始させます。 ✓

正解: D. S3イベント通知を使用してAmazon EventBridgeルールを起動します。このルールを設定して、処理ワークフローをオーケストレーションするAWS Step Functionsワークフローを開始させます。

解説

正しいソリューションは、S3アップロードをトリガーとした処理ワークフローの自動化、失敗したアップロードの確実な処理、そして最小限の運用工数を同時に満たす必要があります。各選択肢を検討します。 正解：D。S3イベント通知を使用してAmazon EventBridgeルールを起動し、そのルールを設定してAWS Step Functionsワークフローを開始させ、処理ワークフローをオーケストレーションします。 なぜDが最適か： ・完全サーバーレスかつ自動化されたワークフロー：S3イベント通知がEventBridgeルールをトリガーし、それがStep Functionsワークフローを起動します。Step Functionsは、センチメント分析のために複数のAWSサービスを呼び出すような複雑なオーケストレーション、エラー処理、再試行、成功／失敗通知をネイティブでサポートします。EC2やECSベースのソリューションと異なり、手動によるスケーリングやインフラ管理は不要です。 ・組み込みのエラー処理と再試行機能：Step Functionsは、失敗したステップに対する自動再試行、回復不能な障害向けのデッドレターキュー（DLQ）、およびワークフロー失敗時のビジュアルデバッグを提供します。S3イベント通知＋EventBridge＋Step Functionsの組み合わせにより、メッセージの喪失が防がれます（適切なエラー処理がないSQSベースのソリューションとは異なります）。 ・最小限の運用負荷：EC2インスタンスやECSクラスター、カスタムスクリプトの管理（A/B/C）は不要です。Step Functionsは完全マネージドサービスであり、保守工数を大幅に削減します。 他の選択肢が不適切な理由： A：SNS単体ではメッセージ処理の保証がなく（手動でのアックノレッジメント処理が必要）、ECS上で動作するWebアプリケーション側で再試行・エラー処理・スケーリングを実装する必要があります（Step Functionsと比較して工数が多く、エラーも発生しやすい）。また、Step Functionsのようなワークフローの可視化やデバッグ機能もありません。 B：EC2インスタンスにはパッチ適用、スケーリング、モニタリングといった手動管理が必要です。スクリプト側で再試行、DLQ、障害処理をすべて実装する必要があり（工数・リスクともに高くなります）、Step Functionsのようなビジュアルなワークフロー管理もできません。 C：ECSのスケーリングはクラスター管理、タスク定義、Auto Scalingポリシーなど、過剰な複雑さを追加します。なお、再試行やエラー処理のためのカスタムロジックは依然として必要であり（Step Functionsとは異なり）、断続的なワークロードに対してはサーバーレスなStep Functionsよりもコストも高くなります。 要件別比較： 要件｜選択肢D｜他の選択肢 ---｜---｜--- コード量を最小限に抑えつつワークフローを自動化｜Step Functionsがオーケストレーションを担当｜A/B/Cはカスタムロジックが必要 失敗したアップロードの処理（再試行・DLQ）｜Step Functionsが組み込みで対応｜A/B/Cは手動実装が必要 サーバーレス（インフラ管理不要）｜EventBridge＋Step Functions｜A：ECS、B：EC2、C：ECS 最小限の運用工数｜完全マネージド｜A/B/Cはスケーリング・パッチ適用・モニタリングが必要 結論：選択肢Dのみが以下のすべてを満たします： ・S3 → EventBridge → Step Functionsによる完全自動化ワークフロー ・再試行・DLQ・デバッグ機能による障害への堅牢な対応 ・インフラ管理不要のサーバーレス設計 最終的な正解：D