How Elastic Load Balancing (ELB) Implement?


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 QueueSpillovers 都是 0,只跳起來就表示有問題,可能就是機器不健康了,要去檢查機器狀態。

延伸閱讀 (站內)

參考資料


Comments