AWS ELB 是利用 EC2 + Auto Scaling Group / Launch Configuration 實作的 (我猜的)。之前 觀察 Cloudtrail 更加應證此現象。而每一個 ELB 後面有多少台 EC2 可以從 ENI 的數量看得出來。但是 EC2 的數量卻跟 ELB 後面的 Backend 數量不成比例。整理觀察到的現象 …

Backend 數量與 ELB ASG 機器數

以下是我們公司服務的幾個例子：

• ELB A: 約數十台, 數種角色 (t2, c4), 從 ENI 可以發現有 4 張 ENI => 推論此 ELB 可能有 4 台 EC2.
• ELB B: 約數十台, 數種角色 (t2, m3), 從 ENI 可以發現有 4 張 ENI => 推論此 ELB 可能有 4 台 EC2.
• ELB C: 數十台機器，單一角色 (c4.xlarge), 從 ENI 可以發現有 3 張 ENI => 推論此 ELB 可能有 3 台 EC2.

所以從上述狀況可以推論幾件事情：

• ELB 自身 ASG (Auto-Scale Group) 的機器數 (EC2 Qty)，跟 Backend 註冊 (Register) 的數量不是等比關係
• ELB 自身 ASG 的應該有不同的 Launch Configuration (LG)，然後依據狀況自動選擇適當的 LG 執行。每個 LG 都指定不同的 Instance Type.
• ELB 的機器 (EC2) 不是 CPU / Memory / IO bound, 而是 Network bound，AWS 並沒有提供類似的 Instance Type, 所以應該是利用 EC2 裡面的 Placement Group 實作。與 VPC 的 NAT Gateway 實作應該類似 (參閱 Unknown ENI Delete Action in CloudTrial 的描述).

ELB 的 CloudWatch Metric

ELB 的監控有很多數值，其中有兩個要注意的：

• Surge Queue Length: 因為 backend server 是不健康的狀態，所以 request 被 queue 在 ELB, 還沒送給 instance 的數目. 上限是 1024 個. 滿了就會被丟掉. 丟掉的數值則是 Spillovers.
• Spillovers: ELB request queue 滿了之後，被 ELB reject 的數量
• Backend Connection Errors: ELB 跟 Backend Server 失敗的連線數

通常在搶購的時候，瞬間衝進來的量會非常大，這時候就要注意這些。正常的 Surge Queue 和 Spillovers 都是 0，只跳起來就表示有問題，可能就是機器不健康了，要去檢查機器狀態。

延伸閱讀 (站內)

• Unknown ENI Delete Action in CloudTrial
• Study Notes - AWS ELB (Elastic Load Balance)
• Lambda Network Traffic Test in VPC with Endpoint
• Study Notes - EC2 Auto Scaling Group Group
• AWS Study Roadmap

參考資料

• Monitor Your Load Balancer Using Amazon CloudWatch
• Understanding the new ELB metrics in CloudWatch
• Placement Groups
• Elastic Network Interfaces (ENI)