AWS Autos Scaling Group termination policy

今天遇到了一個有趣的問題，是有個 build job 說他的 build node 會被隨機 terminate 掉。

大致去看了一下 Auto Scaling Group 的設定，當 idle node > 1 的時候， ASG 就會開始 scale in ，當有 build queue 不為空的時候，就 step scaling out
研究一下他的做法是在 jenkins cronjob 每分鐘去 query jenkins api 回報 build queue 和目前狀態是 idle or offline 的 build node number 去 CloudWatch metrics

然後 CloudWatch metrics 再去觸發 ASG 的 scale in or out

這時候我想到的問題是，那當 scale in 被觸發時，是哪台 instance 要被 terminate?
當初的設計很聰明，他利用了 lifecycle hook，用意是說當 build node 被選上要被 terminate 時，會進入 Terminate Wait 的狀態，直到 ASG 收到 complete-lifecycle-action 的指令時，才會真的 terminate 掉。

但這個 lifecycle hook 是有預設 timeout 時間 3600 sec !!  也就是說一但 instance 進入 Terminate Wait 即使你沒有用 cron job 去 complete-lifecycle-action 過了一小時 waiting 時間它還是會被關掉....

原本我以為 ASG 應該會挑 CPU 閒置的機器下手吧？後來再去翻一下文件發現， default termination policy 的策略依序是盡量讓機器分散在不同 AZ >  Allocation Policy > Oldest Launch Template or Config 最後是開機時間最接近整數小時的機器。

其他可以選的 termination policy 也都不是根據 instance usage 來判定。

原本因為不想花太多時間，只是暫時先把 timeout 時間設長，讓他有機會即使不幸被選上，還是可以把 build 跑完。

但再翻一下文件，或許可以把 busy build node 透過 cron job 送 record-lifecycle-action-heartbeat 或者是怕 timeout 太長，就等 build 跑完，再補送 complete-lifecycle-action 就好了...


Ref:

https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html

https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-termination.html