AWS 的 ALB (Application Load Balancer)

前幾天跟 AWS 的人開會的時候得知 ALB 的 beta program,今天就看到正式公開的消息了:「New – AWS Application Load Balancer」。

最主要的是對 WebSockets 與 HTTP/2 的支援,這個需求都喊很久了:

WebSocket allows you to set up long-standing TCP connections between your client and your server. This is a more efficient alternative to the old-school method which involved HTTP connections that were held open with a “heartbeat” for very long periods of time. WebSocket is great for mobile devices and can be used to deliver stock quotes, sports scores, and other dynamic data while minimizing power consumption. ALB provides native support for WebSocket via the ws:// and wss:// protocols.

HTTP/2 is a significant enhancement of the original HTTP 1.1 protocol. The newer protocol feature supports multiplexed requests across a single connection. This reduces network traffic, as does the binary nature of the protocol.

另外是 url routing,不過目前看起來只能設 10 條,我猜可以問問能不能加吧:

An Application Load Balancer has access to HTTP headers and allows you to route requests to different backend services accordingly. For example, you might want to send requests that include /api in the URL path to one group of servers (we call these target groups) and requests that include /mobile to another. Routing requests in this fashion allows you to build applications that are composed of multiple microservices that can run and be scaled independently.

As you will see in a moment, each Application Load Balancer allows you to define up to 10 URL-based rules to route requests to target groups. Over time, we plan to give you access to other routing methods.

再來是改善了之前抱怨很多的 health check:

Application Load Balancers can perform and report on health checks on a per-port basis. The health checks can specify a range of acceptable HTTP responses, and are accompanied by detailed error codes.


eBay 在測試環境下的 Load Balancer:Neutrino

eBay 放出了一套為了測試環境用 ScalaNetty 開發的 load balancer,Neutrino:「Announcing Neutrino for Load Balancing and L7 Switching」。

可以看到設計上加入了 log 機制,像是:

Ability to send the traffic logs to API endpoints


Traffic metrics and configuration are exposed as APIs.

Metrics can be easily published to Graphite. Neutrino is also extensible to push metrics to other metrics systems.

效能不是最主要的重點,不過在 2-core VM 裡面可以有每秒 300+ requests,對測試環境應該是夠用:

We have measured upwards of 300+ requests per second on a 2-core VM.

還有不少特殊的功能 (大量模組化的設計),對於測試環境應該頗好用?

Google 的 Load balancer:Seesaw


上個星期 Google 放出一套用 Go 寫的 Load balancer,叫 Seesaw:「Seesaw: scalable and robust load balancing」。

比較有趣的是 BGP 與 anycast VIP 的能力:

Seesaw v2 provides full support for anycast VIPs - that is, it will advertise an anycast VIP when it becomes available and will withdraw the anycast VIP if it becomes unavailable.

Google 這個規模玩的是不同 scale 的花樣...

猜測 AWS ELB 內的架構...

AWS Elastic Load Balancing (ELB) 是 AWS 在雲端上推出的 Load balancer。

在非雲端的架構上會使用 Layer 4 Switch (像是 F5Alteon),或是使用 open source 的 HAProxy

從實驗猜測 ELB 是這樣做的:

  • ELB 是 Amazon 自己開發的「軟體」,而非硬體。可能就是跑在 EC2 上,也可能為了 billing 的需求是跑在另外一個 cluster 上。
  • 在每一個有 instance 需要服務的 availability zone 上都會開一台 ELB instance 起來。
  • 每一個 ELB instance 會有一個 public IP 對外,在 ELB domain 解出來的 IP 可以查出來。

所以 ELB 的文件上會警告「每一個 AZ 的運算能力要盡可能接近」:

By default, the load balancer node routes traffic to back-end instances within the same Availability Zone.

To ensure that your back-end instances are able to handle the request load in each Availability Zone, it is important to have approximately equivalent numbers of instances in each zone.

這是因為不同 AZ 的平衡是靠 DNS round robin 處理,所以下面的例子就有建議儘量打平:

For example, if you have ten instances in Availability Zone us-east-1a and two instances in us-east-1b, the traffic will still be equally distributed between the two Availability Zones.

As a result, the two instances in us-east-1b will have to serve the same amount of traffic as the ten instances in us-east-1a.

As a best practice, we recommend that you keep an equivalent or nearly equivalent number of instances in each of your Availability Zones.

So in the example, rather than having ten instances in us-east-1a and two in us-east-1b, you could distribute your instances so that you have six instances in each Availability Zone.

而量大到一個 ELB instance 撐不住的時候,AWS 就會自動開出第二台:(目前都只放在同一個 zone 上)


以這樣的架構,當量夠大的時候,AWS 應該要有能力生出足夠多的 ELB instance 打散?之後再來觀察看看好了... 還有很多煩惱要處理 ~_~

Linode 的 NodeBalancers 第一次嘗試...

前情提要請參考上一篇「Linode 也推出 Load balancer 服務... (剛開始 beta)」。

Linode 處理的速度很快,開了 ticket 後只用了 12mins 就回應了...

首先是 data center,目前只有 Newark, NJ 這個機房有提供,而 concurrent connection 是 100 個:


接下來就卡關了,因為目前在 NJ 沒有 node,等下再開兩台玩看看吧...

Linode 也推出 Load balancer 服務... (剛開始 beta)

Linode 在「NodeBalancers - Managed Load Balancers」這邊公開了 NodeBalancer (lbass) 服務,目前在 beta 中,想要測試的人可以開 ticket 詢問。另外,API 文件也已經先公開,可以在「NodeBalancer API」這邊看到。

以 API 提供的功能看起來還算 okay,這樣就不需要自己用 Linode 提供的 IP Failover 並且在上面架 HAProxy server...

不過有些細節還是得等測試後才知道。像是 trusted IP 問題,我在「ELB 的 IP 信任問題...」有提過 EC2 的同樣問題 (前幾天用 ELB security group 解掉了)。