AWS(35) — ASG + ALB，packer 實作 Golden ami (驗證與除錯)

主要是看用 Golden AMI 的擴展速度，因為若是擴太慢，那是擋不了流量高峰的，所以多快擴展就是很重要的一環

• 計算 userdata 建立所花費的時間

故意選了比較久的編譯方式看要建立多久，開 EC2 試建的結果如下，這是含下載 nginx 並編譯的過程

# 計時功能
time sudo ./userdata.sh

執行時間是 2 分多

• 確認服務

先看 terraform 部署後的服務有沒有跑，建立時間大約是 2 分多，其實大部分時間都在跑 userdata.sh

啟動到完成大約花了 2 分鐘

然後就看各服務的狀態，算是認識 UI 介面

這是 ALB，連接 3 個 AZ

後端有起了 3 個 EC2，符合預設起 3 台的設定

這是 target group，監控後端服務的正常度

下方是 health check，這裡路徑是故意去戳 health.html 看能不能回覆

ASG 的部分可以看是怎麼 scale 的，這裡可以看到是 CPU utilization 到 50% 才 scale

• AMI + userdata 擴展狀況

我用了 hey 來模擬高併發流量，但發現 CPU 完全上不去，畢竟只裝了 nginx 跟超級簡單的 html，也不會有啥事

只好換方法，進到 EC2 裡用 stress 來把 CPU usage 提起來

對雙核 CPU 下指令來操 CPU

我只對 2 台機器下 stress，所以平圴 CPU 是 66% 左右

開了一台，時間是 01:39:32

target group 顯示到 13:43 才擴展完畢，有點太慢了

擴展了 1 台

首先是擴展花了 3–4 分鐘，這太久了；另外是 default monitor 所以 5 分鐘看一次，最久可能會 8–9 分鐘才擴展完(監控 + 擴展)

但用戶不可能等到 8 分鐘，所以最佳方法是縮短 monitor interval，然後把 ami 換成安裝不需要跑那麼久的，也就是 Golden AMI

• Golden AMI 擴展狀況

在看 Golden AMI 前先看 monitor interval，看起來是有每分鐘的數據的

有精確到分鐘級

然後就看 scale out 的結果

開了兩台，時間是 04:27:21

target group 顯示在 27–28 分就擴展完畢了

在 28 分可以看到有 5 台的 metrics

通常 EC2 開機是 10 多秒，然後機器用了 golden ami 就可以把軟體安裝簡化到幾秒的程度

然後順便看一下 scale out，scale out 會謹慎一點，大概至少要 15 分鐘，除非有額外設定

等了 3 分鐘才 scale out

但 EC2 開機還是要個 10 秒，所以 ASG 擴展最快大概也是 30–60 秒吧，只能說若是跟流量相關的，可能還是要用 overprovision 的方式

個人是覺得除非有特殊原由，否則還是傾向跑在容器裡，容器 scale out 的時間比起 ASG 來的快太多了

除非是跟網路、底層效能相關的話，可能才會選 VM 吧

參考資料：

1. Google Gemini
2. GitHub 程式碼