AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
マーケティングプロモーションが成功すると、EC2 インスタンスの数が 2 台から 20 台に増加しました。この間、アプリケーション自体は正常に動作し続けました。しかし、リクエスト率の上昇によってサードパーティーのシステムが過負荷になり、リクエストが失敗する結果となりました。
負荷がかかってもプロセス全体が正しく機能するように、アフィリエイトシステムを呼び出すコードを AWS Lambda 関数へ移動することを計画しています。さらに追加の対応として、効果的なのは次のうちどれですか？
- 注文データを Amazon Simple Queue Service (Amazon SQS) キューに配置するようにアプリケーションを変更し、キューから Lambda 関数を呼び出す。
- AWS Lambda 関数のタイムアウトを延長する。
- AWS Lambda 関数の予約済み同時実行数を減らす。
- AWS Lambda 関数のメモリを増やす。
A. 注文データを Amazon Simple Queue Service (Amazon SQS) キューに配置するようにアプリケーションを変更し、キューから Lambda 関数を呼び出す。
Amazon SQS を挟むと、注文データはまずキューに永続化され、Lambda がキューから取り出せる分だけ処理する形になる。これによりインスタンスが 20 台に増えても、外部システムへの呼び出しはキューの消化ペースに平準化される。
外部システムがエラーを返した場合もメッセージはキューに残り可視性タイムアウト後に再試行されるため、注文データが失われない（必要ならデッドレターキューへ退避できる）。
「スケールする側」と「スケールできない側」の間にバッファを置くという疎結合の定石であり、負荷時もプロセス全体が正しく機能するという要件を満たす唯一の選択肢。
B. AWS Lambda 関数のタイムアウトを延長する。
タイムアウトの延長は、Lambda 関数が 1 回の実行で応答を待てる時間を伸ばすだけである。
問題の原因は外部システムに届くリクエストのレートが高すぎることであり、待ち時間を伸ばしても呼び出し回数は 1 件も減らない。
むしろ過負荷の相手を長く待ち続けることで実行時間の課金が増え、失敗した注文の再試行やデータ保全の仕組みも得られない。
C. AWS Lambda 関数の予約済み同時実行数を減らす。
予約済み同時実行数を減らせば外部システムへの同時リクエストは確かに抑えられる。しかしキューが無い状態では、アプリケーションからの呼び出しは同期的に行われるため、上限を超えた分はスロットリング（429）で拒否され、その注文データはどこにも残らない。
結果として「過負荷でリクエストが失敗する」問題が「Lambda の同時実行制限でリクエストが失敗する」問題に置き換わるだけで、手数料の対象となる注文が失われる。
同時実行数の制限は、選択肢 A のようにSQS でデータを保全したうえで併用してこそ有効な手段である。
D. AWS Lambda 関数のメモリを増やす。
メモリの増量は Lambda に割り当てられる CPU・帯域を増やし、関数の処理を速くする方向に働く。
本問のボトルネックは Lambda 側の処理能力ではなくサードパーティー側の受け入れ能力であるため、効果が無いどころか、速く呼び出せる分だけ外部システムへの負荷を悪化させかねない。
コストも増えるだけで、リクエスト失敗の根本原因には一切触れていない。
構成図
ALB ─▶ EC2（Auto Scaling: 2台→20台）
│ 注文データ
▼
Amazon SQS（バッファ＋再試行）
│ ポーリングで起動
▼
AWS Lambda ──平準化されたリクエスト──▶ サードパーティー追跡システム
速い側と遅い側の間にはキューを挟む。Lambda の設定（時間・メモリ・同時実行数）をいじっても、外部の限界は変わらない。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| EC2 が 2 台から 20 台にスケールし、外部システムが過負荷になった | 呼び出し元だけがスケールし、受け側はスケールしない。両者の間にバッファ（キュー）を置いて流量を平準化する →選択肢（A）が正解 |
| 失敗したリクエストは売上手数料に直結する（注文データを失えない） | キューに永続化＋再試行できるのは SQS のみ。同期呼び出しを絞るだけの案はデータを失う →選択肢（C）を消す |
| 「負荷がかかってもプロセス全体が正しく機能する」ことが要件 | Lambda のタイムアウト延長は呼び出し回数を減らさないため、過負荷は解消しない →選択肢（B）を消す |
| ボトルネックはサードパーティー側の受け入れ能力 | メモリ増量は Lambda を速くするだけで、相手側の限界は変わらない（むしろ負荷を強める） →選択肢（D）を消す |
ひっかけポイント
- 選択肢 C（予約済み同時実行数を減らす）はスロットリングの定番手法なので魅力的に見える。しかしキューが無ければ、絞られたリクエストは再試行されずに消える。SQS と組み合わせて初めて成立する手段である
- 「Lambda に移す」と書かれているため Lambda のパラメータ調整（B・D）に目が行くが、Lambda の設定は自分側の実行環境を変えるだけで、外部システムの限界には無関係
- 「注文が正常に処理されると即座にポストする」という記述が、同期呼び出しのままでよいという思い込みを誘う。売上手数料の追跡は非同期でよい処理であり、疎結合化が正しい
- メモリ増量（D）は「性能改善＝良いこと」と錯覚しやすいが、過負荷の相手により速くリクエストを投げることになり逆効果
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「SQS を導入したうえで、外部 API のレート制限（例 10 TPS）を厳守したい」 | Lambda の予約済み同時実行数（またはイベントソースマッピングの最大同時実行数）で流量を制限するのが正解に浮上する。 |
| 「何度再試行しても失敗するメッセージを隔離して調査したい」 | デッドレターキュー（DLQ）の設定が正解軸に。 |
| 「注文イベントを複数のシステムに同時配信したい」 | Amazon SNS（ファンアウト）＋ SQS の組み合わせが正解軸に。 |
| 「注文の処理順序を厳密に保証したい」 | SQS FIFO キュー（メッセージグループ ID）が正解軸に。 |
| 「外部システムが停止しても、数日分のデータを保持して後で流したい」 | SQS のメッセージ保持期間（最大 14 日）や Kinesis Data Streams によるバッファリングが問われる。 |
マーケティングプロモーションが成功すると、EC2 インスタンスの数が 2 台から 20 台に増加しました。この間、アプリケーション自体は正常に動作し続けました。しかし、リクエスト率の上昇によってサードパーティーのシステムが過負荷になり、リクエストが失敗する結果となりました。
負荷がかかってもプロセス全体が正しく機能するように、アフィリエイトシステムを呼び出すコードを AWS Lambda 関数へ移動することを計画しています。さらに追加の対応として、効果的なのは次のうちどれですか？
- 注文データを Amazon Simple Queue Service (Amazon SQS) キューに配置するようにアプリケーションを変更し、キューから Lambda 関数を呼び出す。
- AWS Lambda 関数のタイムアウトを延長する。
- AWS Lambda 関数の予約済み同時実行数を減らす。
- AWS Lambda 関数のメモリを増やす。