AWS 自動擴縮政策與容量排程

工程挑戰

多項服務同時使用 CloudWatch 擴縮政策、容量排程，以及 Blue/Green Auto Scaling Group。主要挑戰是釐清這些控制如何互相影響：排程設定的最小與最大容量可能限制擴縮政策；固定容量的群組無法水平擴縮；而歷史 synth 紀錄也不一定符合目前的原始碼快照或 AWS 實際設定。

架構與設計

• 使用 CPU 階梯式擴縮增加容量，並以獨立的低使用率警示保守地一次移除一個執行個體。
• 可選擇啟用 Network In／Out 政策；當每個執行個體的流量超過實測目標時向外擴縮。網路政策不負責縮減容量。
• 依工作負載排程調整 ASG 容量，提前因應預期需求；將服務當地時間轉換為 UTC cron，並處理跨日造成的星期變化。
• 所有動態調整都限制在 ASG 的最小與最大容量內，並將排程套用至預期承接流量的部署目標。
• 將 Mixed Instances Policy、ELB 健康檢查、執行個體暖機與 Capacity Rebalance 納入容量生命週期設計。

實作內容

• 實作 CPU 階梯式向外擴縮，並以獨立且保守的低使用率警示向內縮減；同時設定執行個體暖機與冷卻控制。
• 加入可選的每執行個體 Network In 與 Network Out 向外擴縮政策。網路擴縮預設停用，必須明確啟用；這些政策不會縮減容量。
• 為正式環境 Web 工作負載建立每日及平日／週末容量排程，將服務當地時間轉成 UTC cron，並調整跨越 UTC 日期時的星期設定。
• 加入部署時的開關，可單獨停用排程動作而保留 CPU 即時擴縮政策。
• 設定 Mixed Instances Policy，依環境的分配設定混用 On-Demand 與 Spot 容量。
• 啟用 ELB 健康檢查與 Capacity Rebalance，並在有設定時依服務調整健康檢查寬限期。
• 讓 Blue/Green 目標各自獨立，使排程能跟隨目前啟用的部署目標；min=max 的固定容量群組不納入水平擴縮。

驗證與影響

• 容量排程變更有原始碼與提交紀錄，但並非每項歷史變更都有後續 synth、部署及依指標驗收的紀錄。
• Blue/Green 容量變更有 TypeScript 編譯與 CDK synth 紀錄。目前可讀取的原始碼與歷史結果不同，因此這些紀錄無法證明 AWS 實際 ASG 狀態。
• 先前的網路政策檢視發現，設定目標可能過於接近受評估執行個體系列的突發流量能力。這表示政策應依實際流量重新調整，但不能據此推論目標值或執行個體系列已在部署中變更。
• 目前沒有完整的 CDK 與 AWS Console 差異檢視、正式環境行為驗證，也沒有延遲、錯誤率、擴縮時間或成本改善的量測結果。

限制與後續工作

• 目前可讀取的 helper 使用 CPU 階梯式向外擴縮及 CPU 警示向內縮減；歷史檢視紀錄則提到 Target Tracking。應視為不同的原始碼快照，不可合併描述為單一實際設定。
• 階梯級距的意義取決於關聯的警示設定。若要將級距解讀為絕對 CPU 門檻，應先確認 synth 產生的 CloudFormation 政策。
• 共用網路政策預設停用。檢視時發現其目標可能過於接近某執行個體系列的突發流量上限；若要啟用，應依觀測到的流量與突發行為選定目標。
• ASG 政策不能超出最小與最大容量界限。固定容量群組無法向外擴縮，容量為零且未啟用的 Blue/Green 群組也不能透過擴縮政策預先暖機。
• 目前可讀取的原始碼與歷史 Blue/Green synth 紀錄不同。描述實際行為前，應先透過 CDK synth 及 AWS Console 確認目標分支設定。
• 排程是依預期需求預留容量，不能證明預測符合實際流量。仍須驗證排程與政策的互動、健康檢查、暖機時間、網路與儲存 I/O、請求量，以及負載平衡器的延遲與錯誤指標。
• Mixed Instances 的容量分配設定曾經變更。歷史數值只適用於各自的版本，不能當作目前正式環境設定。