SAA高性能なアーキテクチャの設計複数選択
あるオンライン小売企業が注文処理システムを Amazon SQS キューと Amazon ECS Fargate（コンシューマータスク）で構成しています。フラッシュセール時に SQS の ApproximateNumberOfMessagesVisible が 50,000 件に達し、処理が追いつかなくなります。タスク 1 件あたりの処理可能メッセージ数は一定であるため、キューのバックログをタスク数で割った値（1 タスクあたりのバックログ）に比例してスケールしたいと考えています。このスケーリングを実装するために必要な組み合わせはどれですか？（2 つ選択）
ASQS の未処理メッセージ数を ECS 実行中タスク数で割った値を CloudWatch カスタムメトリクスとして定期的に発行する
✓ 正解
バックログメトリクス（メッセージ数÷タスク数）を CloudWatch カスタムメトリクスとして発行することで、タスク数の変化に応じた動的なスケーリング指標となる。このメトリクスは SQS 標準では提供されないため Lambda 等で計算して発行する必要がある。
BApplication Auto Scaling でターゲット追跡スケーリングポリシーを作成し、上記カスタムメトリクスをターゲット指標に設定する
✓ 正解
Application Auto Scaling のターゲット追跡ポリシーにカスタムメトリクスを指定することで、バックログ比率が目標値を超えたときに ECS タスクを自動的に増減できる。選択肢 A のカスタムメトリクス発行と組み合わせて完全なスケーリングを実現する。
CSQS の ApproximateNumberOfMessagesVisible をターゲット追跡スケーリングのメトリクスに直接使用して ECS サービスを拡張する
未処理メッセージ数の生の値をターゲット追跡に使用すると、タスクがスケールアウトしても処理が進むまでメトリクスが減少せず、スケーリングが適切に機能しない。タスク数で割ったバックログメトリクスを使用する必要がある。
DSQS キューの可視性タイムアウトを延長して処理中メッセージが再キューイングされないようにしスケーリングを安定させる
可視性タイムアウトの延長は処理中のメッセージが他のコンシューマーに再配信されるのを防ぐ設定であり、スケーリングの応答速度や精度には影響しない。スケーリング設計とは独立した設定である。
ESQS のロングポーリング設定（ReceiveMessageWaitTimeSeconds）を最大値の 20 秒に設定して、コンシューマーが効率的にメッセージを受信し処理スループットを向上させる
ロングポーリングは空振りポーリングのコストを削減しレイテンシを改善するが、バックログ増加に応じて ECS タスク数をスケールさせる仕組みとは無関係であり、キューバックログの解消策にならない。
解説
SQS キューベースの ECS スケーリングでは、バックログメトリクス（ApproximateNumberOfMessages ÷ 実行中タスク数）を使用する。このメトリクスは SQS が標準で提供しないため、Lambda や EventBridge Scheduled Rules で定期的に計算して CloudWatch カスタムメトリクスとして発行する必要がある。次に Application Auto Scaling のターゲット追跡スケーリングポリシーを作成し、このカスタムメトリクスをターゲット値（例: タスクあたり 100 件）で維持するよう設定する。タスク数が増えるとメトリクスが低下し、スケールイン/アウトが正確にトリガーされる。
選択肢C の ApproximateNumberOfMessagesVisible をそのままターゲット追跡メトリクスに使用すると、スケールアウトしてもメッセージ数が即座に減少しないためメトリクスが減らず、過剰なスケールアウトが続く可能性がある。
選択肢D の SQS 可視性タイムアウトの延長は処理中メッセージの再キューイングを防ぐための設定であり、スケーリングの速度や精度には直接影響しない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →