我是GMO Connect的永田。
在某個案件中,對於性能的要求異常嚴格,經過多次嘗試終於達成了,所以我總結了一些技術要點。
一開始,我樂觀地認為ECS的縮放策略可以達到一定效果,但實際上當我構建環境並測試時,發現無法在數分鐘內達到ELB目標的ServiceIn😇
簡單查看一下目標追蹤策略中的Scale Out內容,分配大約如下。
No | 實施內容 | 大約時間 | 備註 |
---|---|---|---|
1 | 收集CloudWatch指標 | 2分鐘〜3分鐘? | 參考數據至1分鐘間隔的Metrics大約需要這麼長時間 |
2 | 依據指標觸發Alarm(desiredCount增加) | 3分鐘 | 在目標追蹤下固定為3分鐘(Alarm的設置無法自行調整),若為步進縮放則至少1分鐘 |
3 | Alarm觸發後,至ELB的target INIT | 20秒〜30秒 | ECS任務啟動後到ELB INIT需要時間 |
4 | 從ELB target INIT至ServiceIn | 30秒〜60秒 | 即使將ELB健康檢查最小化(5秒x2次),仍然需要時間 |
No3和No4的過程在AWS服務中是黑盒子,即使將容器Image尺寸縮小、健康檢查等所有可想到的參數都設為最小,這些時間也不會再縮短。
因此,我們需要自行實作No1和No2所需的大約5分鐘觸發時間(desiredCount增加),以提高速度(=自定義實作fast scaler),這便是本文的重點。
「fast scaler」的概念並不是獨創的,而是透過AWS樣本取得的,本次的實作基本思想相同。
改動的內容如下:
以下是用序列圖表示的內容。(僅記載要點)
在導入上述fast scaler後,我們大約能以以下速度完成Scale Out。No1和No2大幅改善,最終能在大約1分半鐘內實現ELB target Service In!
No | 實施內容 | 大約時間 | 備註 |
---|---|---|---|
1 | 收集指標 | 1秒 | 每秒呼叫ECS的自定義端點 |
2 | 依據指標觸發Alarm(desiredCount Up) | 5秒 | 根據指標AVG所需的datapoint數量 |
3 | Alarm觸發後,至ELB的target INIT | 20秒〜30秒 | ECS任務啟動後到ELB INIT仍需時間 |
4 | 從ELB target INIT至ServiceIn | 30秒〜60秒 | 即使將ELB健康檢查最小化(5秒x2次),仍需要時間 |
不過,No3和No4這部分無法避免,因此在Service In至多1分半的時間內,針對ECS任務選擇了充裕的硬體規格與台數以應對突發流量。
至此為止我們討論了Scale Out的部分,但由於Scale In可以「慢慢來」,因此將目標追蹤策略的CPU使用率設為範圍。
我們公司廣泛提供基於AWS的服務開發及技術支援,如有需要,隨時歡迎聯繫我們。
聯繫方式: https://gmo-connect.jp/contactus/