Q54 — AWS SAA-C03 第2章

第 54/65 問 | ← 第2章

Q119. ある企業が、分散型アプリケーションをAWSに移行しようとしています。このアプリケーションは可変のワークロードを処理します。従来のプラットフォームでは、ジョブを複数のコンピュートノード間で調整する役割を担うプライマリサーバーが存在します。企業は、耐障害性とスケーラビリティを最大限に高める現代的なソリューションでアプリケーションを刷新したいと考えています。要件を満たすために、ソリューションアーキテクトはどのようなアーキテクチャを設計すべきでしょうか？

正解: B. ジョブの送信先としてAmazon Simple Queue Service (Amazon SQS) キューを設定します。コンピュートノードは、Auto Scalingグループで管理されるAmazon EC2インスタンスで実装します。EC2 Auto Scalingを、キューのサイズに基づいて構成します。

解説

正解はBです。分散アプリケーションの現代化において、ジョブのコーディネーションと実行を分離し、非同期かつ疎結合なアーキテクチャを採用することが推奨されます。Amazon SQSは、ジョブを一時的に保存・バッファリングするための信頼性の高いメッセージキューサービスであり、プライマリサーバー（例：ステートレスなAPIエンドポイントやLambda関数など）がジョブをSQSに送信し、コンピュートノードがプル方式で処理することで、スケーラビリティと耐障害性が向上します。コンピュートノードをAuto Scalingグループで管理し、SQSキューの長さ（例：ApproximateNumberOfMessagesVisibleメトリクス）に基づいてスケーリングを自動化すれば、ワークロードの変動にリアルタイムで対応でき、コスト効率も最適化されます。一方、選択肢Aの「スケジュールベース」は予測可能なワークロードにしか有効ではなく、可変ワークロードには不向きです。選択肢CとDは、プライマリサーバー自体をAuto Scaling対象とし、またCloudTrailやEventBridgeをジョブ送信先としている点で根本的な誤りがあります（CloudTrailは監査ログ収集サービスであり、ジョブキューではない；EventBridgeはイベントルーティングサービスであり、永続的なジョブバッファとして不適切）。さらに、プライマリサーバーの負荷やコンピュートノードのCPU使用率などに依存したスケーリングは、キューに溜まった未処理ジョブの実態を反映しないため、遅延やスループット低下を招く可能性があります。