ある企業が、マイクロサービスアーキテクチャで Amazon ECS を使っている。特定のサービスへのリクエストが急増した際に、そのサービスの ECS タスク数を自動的に増加させたい。増加トリガーとして、SQS キュー内のメッセージ数(待機中のメッセージ数)を使用したい。最も適切な設定はどれか。
- A. ECS サービスの Application Auto Scaling にターゲット追跡スケーリングポリシーを設定する。カスタムメトリクス(SQS の ApproximateNumberOfMessagesVisible / ECS タスク数)をターゲット値に設定して、タスクあたりのキュー待機メッセージ数が目標値を超えたらスケールアウトする。
- B. SQS から ECS タスクへの直接のイベントトリガーを設定する。
- C. CloudWatch アラームを ECS タスク数の CloudWatch メトリクスで設定してスケールアウトを行う。
- D. Lambda 関数で毎分 SQS のメッセージ数をチェックし、しきい値を超えたら ECS タスクを手動で追加する。
解答と解説を見る
正解: A
ECS サービスの Application Auto Scaling でカスタムメトリクスを使ったターゲット追跡スケーリングを設定することで、SQS キューのメッセージ数に応じた自動スケーリングが実現できる。「SQS の ApproximateNumberOfMessagesVisible ÷ ECS の RunningTaskCount」をカスタムメトリクスとして定義し、ターゲット値(例: タスクあたり 10 メッセージ)を設定することで、メッセージが増えると比例してタスクが増加する。選択肢CのCloudWatch アラームをECSタスク数のメトリクスで設定する方法は、ECS タスク数が増減しても SQS メッセージ数との関係が動的に調整されないため、変動するワークロードへの精密な対応が難しい。選択肢DのLambda による手動追加はポーリング間隔(毎分)があり、リアルタイムなスケーリングができない。運用コストも高い。選択肢BのSQS から ECS への直接イベントトリガーは存在しない機能であり、技術的に誤った選択肢。
📚 関連サービスの解説: Amazon ECS ・ Amazon SQS