一件の評価実行時間が長い時にオートスケールで、プロセスが終わらなくなる

[EndoNrak]

症状

• 試行回数が10回とか多く設定したとき、かつキューの中身がなくなった時に評価が途中で終わってしまう

原因

• 一つの評価の試行回数が多い時は評価にかかる時間が長くなる（評価時間×試行回数）
• キューから最後のメッセージが取得された瞬間、SQSのメトリクスである’ ApproximateNumberOfMessagesVisible’がゼロになる
• このメトリクスがゼロになった時、アラームがOK状態になって、ECSサービスがスケールインされてしまう（メトリクスがゼロになってから数分後）
• 評価時間が長い評価だと、評価終了前にスケールインしてしまい評価自体は正常に始まるものの、終わるのを待たずにプロセスがスケールインされ、評価が終わらない

追記

• スケールインした時はNotVisibleが0.2、Visibleが0.8になっていた
• Visibleの方の閾値を1にしていたことでスケールインがトリガされてしまった
• 今回はNotVisibleとVisibleの和を条件にしているため結果的には正しく動作できるように修正

[EndoNrak]

解消方法 オートスケーリング用のアラーム内容を適正化する

現状

• ApproximateNumberOfMessagesVisible（sqsに取得可能な状態で入っているキューの数）が1以上ならalarm、0ならOK
• ApproximateNumberOfMessagesNotVisible（処理中のキューの数）は考慮していない

変更案

• ApproximateNumberOfMessagesVisibleとApproximateNumberOfMessagesNotVisibleがともにゼロの時はOK、それ以外はalarm

[EndoNrak]

実現手段案

1. ApproximateNumberOfMessagesVisibleとApproximateNumberOfMessagesNotVisibleの和が1以上ならalarm、0ならOKであるので数式に基づくカスタムアラームを作る（https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Create-alarm-on-metric-math-expression.html）
2. ApproximateNumberOfMessagesVisibleとApproximateNumberOfMessagesNotVisibleをそれぞれ監視し、1以上である場合にalarm状態になるアラームをそれぞれ作成。それら二つの複合アラームを作る（https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html）

[EndoNrak]

アラームの数が一つで済むので、1を採用する

[EndoNrak]

スケーリングする幅が0と1だからこれでOKだが、より複雑なときには対応できていない気がする スケールインするときにタスクの中身が終わるのを待てるようにするのが理想かも