Q57 — AWS SAA-C03 第17章

第 57/89 問 | ← 第17章

Q1357. ある企業は、複数のモバイルアプリおよびWebアプリケーションからユーザーがアクセスするECサイトアプリケーションを運用しています。この企業には、モバイルアプリおよびWebアプリケーションからのリクエストをAPI経由で受信するソリューションが必要です。1日のうちでトラフィック量は大きく変動し、セール期間中には急激なトラフィックスパイクが発生します。このソリューションは疎結合（ローズリーコープルド）である必要があり、また、いかなるリクエストも失われてはなりません。これらの要件を満たすソリューションはどれですか？

正解: B. Amazon API GatewayのREST APIを設定し、Amazon SQSキューへの統合を構成します。デッドレターキュー（DLQ）を設定します。SQSキューからメッセージをポーリングしてリクエストを処理するAWS Lambda関数を作成します。

解説

正解はBです。「Amazon API GatewayのREST APIを設定し、Amazon SQSキューへの統合を構成します。デッドレターキュー（DLQ）を設定します。SQSキューからメッセージをポーリングしてリクエストを処理するAWS Lambda関数を作成します。」 解説： この企業には、可変かつ急激なトラフィック（特にセール時のスパイク）にも耐え、リクエストを一切失わず、かつ疎結合なアーキテクチャを実現するスケーラブルで堅牢なソリューションが求められます。 主な要件： ・疎結合アーキテクチャ：APIフロントエンドとバックエンド処理を分離すること。 ・リクエストの喪失防止：高負荷時でもリクエストが確実に永続化・処理されること。 ・スケーラビリティ：トラフィックスパイクを効率的に処理できること。 ・APIベースのアクセス：モバイル／WebアプリからAPI経由でリクエストを受け付けること。 なぜ選択肢Bが最適か： ・Amazon API Gateway REST API：モバイルおよびWebアプリ向けに、安全かつスケーラブルなAPIエンドポイントを提供します。 ・Amazon SQSとの統合： 　– APIフロントエンドとバックエンド処理を完全に分離（疎結合）します。 　– リクエストをキュー内に永続的に保存するため、高負荷時でもリクエストが失われません。 　– トラフィックスパイク時にリクエストをバッファリングし、後続の処理可能タイミングまで待機させることができます。 　– デッドレターキュー（DLQ）により、処理に失敗したリクエストを再処理やデバッグ用に確実にキャプチャできます。 ・SQSをポーリングするAWS Lambda関数： 　– メッセージの到着に応じて自動的にスケールし、過剰な手動スケーリング（例：EC2ベース）を不要にします。 他の選択肢が不適切な理由： A．ALB＋Elastic Beanstalk： 　– 緊密結合（ALBがElastic Beanstalkに直接ルーティング）。トラフィックスパイク時にElastic Beanstalkが応答しきれず、リクエストが失われる可能性があります。 　– キュー機能がなく、スパイクへの耐性が低く、スケーラビリティもSQSベースより劣ります。 C．ALB＋Lambda（ALBターゲット）： 　– ALBはHTTPレスポンスを期待しますが、Lambdaの同時実行数制限に達するとリクエストがドロップされるリスクがあります。 　– スパイク時のスケール速度が遅く、キューによるバッファリングがないため、リクエスト喪失のリスクがあります。 　– SQSのような信頼性の高い耐障害性を備えていません。 D．API Gateway HTTP API＋SNS＋Lambda： 　– SNSはキューではなくパブサブ（配信型）サービスであり、正確な1回限りの処理保証がなく、重複または欠落が発生する可能性があります。 　– SQSのような組み込みの再試行メカニズムやDLQ機能がなく、リクエスト喪失防止という観点で信頼性が低いです。 比較表： | 選択肢 | アーキテクチャ | 疎結合？ | リクエスト喪失防止？ | スケーラビリティ | 主な用途 | |--------|--------------|---------|---------------------|----------------|-----------| | A | ALB → Elastic Beanstalk | ×（キューなし） | 中程度 | 中程度 | 伝統的なWebアプリ | | B | API Gateway → SQS → Lambda | ○（SQSで永続化） | 高 | 高 | 可変トラフィック・喪失ゼロ要件 | | C | ALB → Lambda | △（キューなし） | 中程度 | 中程度 | 単純なAPIバックエンド | | D | API Gateway → SNS → Lambda | ○（ただし重複／欠落リスクあり） | 中程度 | 高 | イベント駆動型パブサブ | 結論： 選択肢Bが最適なソリューションである理由： ・SQSにより、トラフィックスパイク時でもリクエストが確実に永続化され、一切失われません。 ・Lambdaはキュー内のメッセージに応じて自動スケールし、処理能力を柔軟に確保します。 ・DLQにより、処理失敗時のリカバリと監視が容易になり、信頼性が向上します。 ・全体として疎結合な設計により、耐障害性とスケーラビリティが両立します。 選択肢A、C、Dはいずれも適切なキューイング機構を欠いており、あるいは過度に緊密結合なため、推奨されません。