2020年6月13日 星期六

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

沒有留言:

張貼留言