前言

承接 Day 25，我們介紹了 Event-driven Lambda，看見 Serverless 架構如何幫助我們快速響應事件。

如果一個多人協作平台突然爆紅呢？例如：

• 週一早上，整個團隊同時打開行事曆，新增、修改事件。
• 某個專案中，短時間內數百個 API 請求湧入。

系統需要「動態伸縮」的能力，否則延遲過高或直接崩潰。今天我們深入探討 Serverless 背後的 Lambda Scaling 機制，從概念出發逐步解釋，讓初學者也能跟上（假設你只知道 Lambda 是 Serverless、無狀態的 FaaS 服務）。然後，補充其他類型 Instance（如容器或虛擬機器）的 Scaling 方式，形成完整的伸縮策略。

Lambda 的瞬時併發爆量

什麼是 Lambda Concurrency？

Lambda 是 Serverless 的 FaaS（Function as a Service），無需管理伺服器，自動運行程式碼。當多個請求同時進來時，Lambda 需處理「併發」（Concurrency），也就是同時執行多個 Lambda 實例（instances）。

Lambda 就像咖啡店的咖啡機。只有一臺機器時，客人多就得排隊。Lambda 會自動複製多臺機器處理訂單，這就是「併發擴展」。在雲端實務上來看，比方今天在多人協作平台，有 50 人同時建立事件，可能瞬間觸發 200 個 Lambda 請求。處理不好，系統會變慢或失敗。 於是為了解決這個問題 Concurrency 的拓展機制就出現了。

冷啟動（Cold Start）

Lambda 實例非永遠運行；無請求時，它會「睡覺」（idle）。第一次喚醒需「熱身」（初始化環境、載入程式碼），這叫冷啟動。

Concurrency Limit 與 Throttling

AWS 為每個帳戶設定併發上限（預設 1000 也就是最高只會幫你拓展出 1000 個Lambda），超過則「節流」（Throttling），拒絕額外請求。

假設 Concurrency Limit 為 8 則 Lambda 能擴展出的容器 Lambda Function <= 8

Lambda Concurrency Scaling | 自動新增容器實體

Lambda 的 Scaling 是 Serverless 核心優勢，大部分自動，AWS 處理背後細節，讓你專注程式碼而非基礎設施。我們從概念層級解釋，強調自動化而非使用者主動優化。

基本機制 — 自動擴展與容器實體

• 概念解釋：請求增加時，AWS 自動「新增容器 Lambda 實體」（輕量級容器環境，每個實例獨立運行函數）。像工廠自動增加生產線，無需人工干預。
• 如何運作：Lambda 偵測併發上升，數秒內啟動新實例，每個實例處理一個或多個請求。這是水平 Scaling，靠數量而非強化單一實例。
• 好處：多人平台流量突發時，系統自動應對，延遲保持低。Serverless 讓 Scaling 「隱形」，你寫函數，AWS 管剩下。

處理冷啟動 — 自動優化

• 概念解釋：AWS 透過重用暖實例（warm instances）最小化冷啟動。若流量可預測，可選 Provisioned Concurrency（預熱實例），但非必要。重點是自動機制讓冷啟動問題少見。
• 為什麼有效：系統自動管理實例生命週期，回收閒置資源，像雲端自動調整的彈簧床，壓力大時加彈簧。

進階概念 — Limit 管理與自動節流

• 概念解釋：接近併發上限時，AWS 自動節流多餘請求。可用 Reserved Concurrency 劃分配額（例如，為關鍵函數保留部分上限）。結合 Dead Letter Queue (DLQ)，失敗請求自動重試或儲存。
• 整合情境：爆紅平台中，AWS Scaling 引擎確保核心功能優先，自動新增實體直到上限。Serverless 的「無憂」本質：Scaling 內建，開發者只需監控。

透過這些層級，Lambda Scaling 自動新增容器實體，處理併發，讓 Serverless 真正「無伺服器」。

Auto Scaling (Application Layer) — 其他 Instance 的 Scaling

若是你所設計的系統功能較複雜，那麼很有可能即使有擴展機制 Lambda 無法滿足你的需求。

Lambda 只適合短任務 (因為 Lambda 實例無法執行超過 15 分鐘)，長任務則必須交給其他 Instance（如容器或虛擬機器）。在這種情境下 AWS Auto Scaling 提供伸縮擴展 (Elastic Scaling) 方案。

• 概念解釋：Auto Scaling 是垂直/水平擴展的自動化，適用於 ECS/EKS（容器）或 EC2（虛擬機器）。AWS 根據指標（如 CPU 使用率、請求數）自動新增/移除 Instance。
• 如何運作：設定 Auto Scaling Group (ASG)，定義最小/最大 Instance 數。流量高時，自動啟動新容器或 EC2；低時，縮減節省成本。
• 好處：混合架構，Lambda 處理瞬發，Auto Scaling 管持久任務，平台全面彈性。

流量分配的挑戰

Auto Scaling 啟動多台 ECS/EC2，使用者如何知道請求該送哪一台？若無流量分配，可能「有人超載，有人閒置」。

Application Load Balancer (ALB) — 流量分配

ALB 是 Scaling 的關鍵夥伴，處理多 Instance 的流量分發。

• 概念解釋：ALB 像交通指揮，自動將請求路由到健康 Instance（EC2 或 ECS 容器）。
• 如何運作：支援路徑規則（e.g., /projects/* 去特定服務），整合健康檢查，只送給可用實體。
• 整合 Cognito：添加驗證層，確保安全。與 Auto Scaling 結合，新增 Instance 自動註冊到 ALB。

其他 Scaling 層級

除了 Lambda 的自動容器 Scaling 和其他 Instance 的 Auto Scaling/ALB，AWS 在不同層級提供機制，全面提升彈性：

• 資料層：DynamoDB Auto Scaling（自動調整讀寫容量 RCU/WCU，應對資料爆增）。
• 流量層：CloudFront Global Edge Network（自動應對全球流量高峰，透過邊緣快取減少延遲）。
• 訊息層：SQS / Kinesis（天然可水平擴展，處理大量事件而不崩潰）。

結語

今天介紹了 Lambda 以及其他常用執行實體的 Scaling Solutions 雖然由於篇幅有限僅止於概念而未深入實作部分，但希望透過今天的文章大家能對不同運算實體的 Scaling 有更清晰的想像，在介紹完監控以及拓展 Solutions 後，我們接下來將會介紹 AWS 上的成本管理工具，讓你在拓展來拓展去的時候不會帳單噴飛！