Q63 — AWS SAA-C03 第17章
第 63/89 問 | ← 第17章
Q1363. ある企業が、顧客向けに金融データにアクセスできるAPIを提供するソリューションを構築しています。このAPIのバックエンドは、各リクエストごとに税金計算を実行する必要があります。同社では、毎年最後の3か月間にデータへのアクセス需要が大幅に増加すると予想しています。ソリューションアーキテクトは、通常時の需要と年末のピーク需要の両方に対応できるスケーラブルなソリューションを設計する必要があります。これらの要件を満たすソリューションはどれですか?
- A. サードパーティ製ソフトウェアを実行するAmazon EC2インスタンス上でAPIをホストし、そのEC2インスタンスで税金計算を実行するように設定します。
- B. Amazon API GatewayのREST APIをデプロイします。税金計算を実行するAWS Lambda関数を作成し、そのLambda関数をREST APIと統合します。 ✓
- C. 2台のAmazon EC2インスタンスの前にApplication Load Balancer(ALB)を配置します。EC2インスタンスを税金計算を実行するように設定します。
- D. Amazon API GatewayのREST APIをデプロイします。税金計算を実行するAmazon EC2インスタンスを設定し、そのEC2インスタンスをREST APIと統合します。
正解: B. Amazon API GatewayのREST APIをデプロイします。税金計算を実行するAWS Lambda関数を作成し、そのLambda関数をREST APIと統合します。
解説
正解はBです。Amazon API GatewayのREST APIをデプロイし、税金計算を実行するAWS Lambda関数を作成して、そのLambda関数をREST APIと統合します。 解説: この企業には、以下の要件を満たすスケーラブルでコスト効率が高く、運用負荷の低いソリューションが必要です: ・通常時の需要(安定したトラフィック)への対応 ・年末のピーク需要(年間最後の3か月間における高トラフィック)への対応 なぜ選択肢Bが最適なのか: ・AWS Lambdaによる税金計算 → 需要に応じて自動的にスケール(サーバーのプロビジョニングや管理不要) → リクエスト単位の課金(可変ワークロードに最適:過剰な容量確保による無駄なコストを回避) → ステートレス実行(各APIリクエストが独立しているため、税金計算のようなトランザクション処理に最適) ・Amazon API Gateway → APIトラフィックの管理(レート制限、認証、キャッシュなど) → Lambdaとのシームレスな統合(ロードバランシングなどの手動設定不要) → REST APIの標準的なサポート(金融データアクセスに一般的) → ピーク需要への効率的な対応:Lambdaは高トラフィック時(例:年末の集中アクセス)に自動スケールし、EC2ベースのソリューションのように事前にインスタンスを「ウォームアップ」する必要がありません。 他の選択肢が不適切な理由: A:単一EC2インスタンスでのAPIホスティング → 単一障害点:インスタンス障害時にAPIが完全に停止 → 手動スケーリング必須:ピーク需要に備えて余分な容量を事前に確保する必要があり、非効率かつ高コスト → 運用オーバーヘッド大:パッチ適用、バックアップ、モニタリングなどすべて自社管理 C:ALB+2台のEC2インスタンス → スケーラビリティ制限:2台ではピーク需要に到底対応できず、手動で追加スケーリングが必要 → コスト効率低:低トラフィック期でもアイドル状態のインスタンスに対して課金が発生 → 依然として運用管理が必要:OS更新、監視、セキュリティ対応など D:API Gateway+EC2(Lambdaではなく) → EC2は自動スケールしない:手動でスケールアップ/ダウンする必要があり、ダウンタイムリスクまたは過剰プロビジョニングのリスクあり → 運用オーバーヘッド大:サーバー管理を自社で行う必要があるため、サーバーレスの利点を活かせない 比較表: | 選択肢 | スケーラビリティ | コスト効率 | 運用オーバーヘッド | 最適なユースケース | |--------|----------------|------------|---------------------|-------------------| | B(Auto-scaling Lambda) | 自動スケール | リクエスト単位課金(最小限) | 最小限 | 可変ワークロード(ピーク需要対応) | | A(単一インスタンス) | 固定 | 固定コスト(常時課金) | 高 | レガシーアプリ(本ケースでは非推奨) | | C(手動スケーリング) | 手動(限定的) | 過剰プロビジョニング発生 | 中程度 | 予測可能な中程度トラフィック | | D(手動EC2スケーリング) | 手動 | 固定コスト(常時課金) | 高 | EC2依存アプリ(税金計算APIには不適) | 結論: 選択肢Bが最もスケーラブルで、コスト効率が高く、運用負荷の少ないソリューションです。理由は以下の通りです: ・Lambdaが自動スケール → 手動介入なしでピーク需要に対応可能 ・API Gatewayがトラフィックを管理 → ロードバランサやカスタムスケーリングロジックの不要 ・サーバー管理不要 → 運用の複雑さを大幅に削減 選択肢A、C、Dはいずれもスケーリングの課題や不要な運用管理を伴うため、避けるべきです。 最終的な正解:B