SAA弾力性に優れたアーキテクチャの設計
動画変換サービスが SQS キューからジョブを取得し、EC2 インスタンス（Auto Scaling グループ）で処理している。
ジョブ量は日中に急増し深夜はほぼゼロになる不規則なパターンを示す。
現在は EC2 の CPU 使用率によるターゲット追跡スケーリングを使用しているが、キューに大量のジョブが積み上がってもインスタンスがすぐにスケールアウトされないことがある。
キューの状況を最も正確に反映したスケーリング設定に変更するにはどれが最適か？
ACloudWatch の SQS メトリクス「ApproximateNumberOfMessagesVisible（可視メッセージ数）」のみに基づくステップスケーリングポリシーに変更する
ApproximateNumberOfMessagesVisibleだけでスケーリングを判断するとインスタンス数が考慮されないため、稼働インスタンスが多くても少なくても同じしきい値で動作し、過剰または過少なスケーリングが発生しやすくなります。
B「SQS キュー内メッセージ数 ÷ Auto Scaling グループの稼働インスタンス数」をカスタム CloudWatch メトリクスとして発行し、ターゲット追跡スケーリングに使用する
✓ 正解
インスタンスあたりの処理待ちメッセージ数（バックログ数）をターゲット値とすることで、処理能力とキュー深さが均衡するようインスタンス数を自動調整できます。AWSが推奨するSQSベースのスケーリングベストプラクティスに沿った最も正確な手法です。
CEC2 のメモリ使用率をカスタムメトリクスとして発行し、ターゲット追跡スケーリングに変更する
EC2のメモリ使用率はSQSキューへのメッセージ蓄積状況を直接反映しません。キューに大量のジョブが積み上がってもインスタンスがアイドル状態であればスケールアウトがトリガーされず、現在の問題解決につながりません。
DAuto Scaling の予測スケーリングを有効化し、過去の CPU 使用率パターンに基づいて事前にスケールアウトする
過去のCPU使用率パターンを機械学習で分析して事前にスケールアウトしますが、突発的で不規則なジョブ急増への即時対応が難しく、またCPU使用率ベースのためキュー深さを直接反映しません。
解説
「インスタンスあたりのバックログ数（ApproximateNumberOfMessagesVisible ÷ InService インスタンス数）」をターゲット値に設定することで、キュー深さとインスタンス数が比例し適切なスケーリングが実現できます。
ApproximateNumberOfMessagesVisibleのみに基づくステップスケーリングポリシーは、インスタンス数を考慮しないため過剰・過少スケーリングになりやすいです。
EC2のメモリ使用率をカスタムメトリクスとして使用する方法は、メモリや CPU はキューの積み上がりを直接反映しません。
Auto Scaling の予測スケーリングは過去パターン依存で突発的なジョブ急増には対応しにくいです。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSAAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →