跳到主要內容

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

標籤：

留言

張貼留言

這個網誌中的熱門文章

Access private API gateway from another account

最近在做一個 PoC 驗證說怎麼在現有的架構下，把一些 public API 移到 VPC 裡面，只讓特定網路的人可以存取。 當然最直覺的想法就是，建一個新的 VPC ，加上 execute-api VPC endpoint 然後這個 VPC 再跟特定網路做 Peering，建一個 Private API Gateway 在新的 VPC 裡面。 這樣新的 VPC 可以透過 VPC endpoint 去存取 API Gateway，然後再加一個 ALB ，裡面的 target group 指向 VPC endpoint 的 IP和 443 port，ALB 設定好 Domain Listener，API Gateway 也加上相同的 Custom Domain Name，這樣子 ALB 就可以當成特定網路 access 的 entry point，一但 Peering 完成後，從特定網路來的 request 就可以經由 ALB -> API GW 跨 VPC 存取原本環境的 backend resource。 但我一直在想，Peering 是必要的嗎? 沒想到隔天就看到這個教學  How can I access an API Gateway private REST API in another account using an interface VPC endpoint?  裡面的做法突破了原本我直覺上的盲點! 就是即使是 Internal API Gateway 似乎只要設定好了 resource policy 就可以允許其他 account 的 VPC endpoint 跨帳號存取! 所以例子裡面的 private API Gateway 是建立在 B 帳號裡面，A 帳號的 VPC 只是啟用了 VPC endpoint，一但 B 帳號的 private API Gateway 在 resource policy 設定好允許 A 帳號的 VPC endpoint 存取，即使兩個帳號之間沒有 peering 也是可以互通的! 雖然說這樣子要帶 hostname header or api-gw-id 但是 原本架構上的 ALB 也是為了 VPC endpoint 可以知道要 forward request 給哪個 API Gateway ...
張貼留言
閱讀完整內容

全球鷹/響尾蛇 D300 行車記錄器

全球鷹 Global Eagle /響尾蛇 D300 行車記錄器 前後雙鏡頭，透過電瓶的壓升壓降來開啟/關閉行車記錄器主機 wifi 是 mmcx 接頭，去淘寶買一條 20 元 預設 wifi 密碼是 12345678 透過 TimaCam 可以 wifi 連線主機，用來看即時鏡頭畫面還可以 但是要下載一個片段 216MB 非常慢，讓我看到噪音管和吐白煙的想檢舉也覺得麻煩... 主機拆下後，即使透過 USB 供電也無法開機， 要操作主機只能發動機車在車子旁邊操作， 主機沒接線的裝態也不能直接拿來看錄影檔。 從 2018.3 月安裝到現在，發生過一次熄火吃完飯(約20分鐘)，竟然沒關機還在錄影。還好只是 20 分鐘，不然電瓶的電不知道會不會被吃完。 現在都很提心吊膽，熄火後都會等他壓降關機後(約 1 分鐘)才會離開。 早知道還是裝一般開電門供電，關電門關機的機種。 wifi 看檔和安裝容易都只是噱頭，買了才知道難用。
張貼留言
閱讀完整內容

Publish lambda layer to regions from s3 bucket?

boto3 有個  publish_layer_version  API，你可以使用 S3 bucket + key or zipfile 來發布 lambda layer. 使用 zipfile 的話就是從命令執行端上傳，所以假設你的 lambda packet 是 20MB 然後你要發佈到 16 個 AWS region 的話，就看你命令執行端的網路上傳速度了。 使用 S3 bucket 來放要發佈的 zipfile 檔似乎比較合理，因為這樣子檔案的複製就是在 AWS 的網路內發生。 But... 很機車的是，如果你的 zipfile 是放在 us-west-1 的 S3 bucket 那麼你就只能發佈到 us-west-1 .... 當你要發佈到其他 region 會出現 error botocore.errorfactory.InvalidParameterValueException: An error occurred (InvalidParameterValueException) when calling the PublishLayerVersion operation: Error occurred while GetObject. S3 Error Code: PermanentRedirect. S3 Error Message: The bucket is in this region: us-east-1. Please use this region to retry the request S3 bucket name 是 global unique 但其實 bucket 位置是有 region 的... 目前還沒有看到什麼比較好的方式來發佈 lambda layer 到全部的 region.... replicate 所有的 zipfile 到所有的 region, 然後每個都有自己的 bucket name 似乎蠻蠢的?....
張貼留言
閱讀完整內容