本文整理了 GCP Cloud Load Balancing  和 AWS Elastic Load Balancing  的服務，我們將從以下三個功能面相去做比較：
• Global or Regional
• Internal or external
• Protocol Type

Overview GCP Load Balancing

GCP Cloud Load Balancing (以下簡稱 GCP LB) 種類很多，依照功能三個面向排列組合的類型如下：
• Global external load balancing (對外), 有三種 Protocols:
     • HTTP(S) load balancing
     • SSL Proxy load balancing
     • TCP Proxy load balancing
• Regional external load balancing (對外)
     • Network load balancing
• Regional internal load balancing (對內)
     • Internal load balancing
要建立 LB 的時候，會有三種選項，如下圖：

種類眾多，依據開始提到的三個面向，整理如下圖：

我們可以這樣理解：
• 需要 Global 的服務，就用 HTTP(S) or Proxy LB
     • 依據商業需求，透過 Forwarding Rules 轉導流量
• 需要 Internal Service 對接的，看範圍，可以選擇 TCP
     • 通常是內部的服務對接，這樣的 Case 在大型系統很常見，也很需要。
• UDP 則只有單一 Regional 才能使用。
透過這樣理解後，就不難選擇適當的 LB 了。

官方文件有很多的描述，整理幾個我覺得很棒的 Features:
• Single Global IP Address  是 GCP LB 最讓人津津樂道的功能，一個 IP 打全球！如果使用 AWS ELB ，因為是使用 EIP ，IP 來源是動態且無法管控的。
• Load distribution algorithm : 提供 requests per second (RPS) and CPU utilization modes 兩種演算法分流，AWS ELB 只有根據 AZ 平均流量而已。
     • Traffic 自動分配到適當的 region
• WebSocket proxy support : 預設就有的！
• Forwarding Rules : 支援很多種方式，包含
     • Name
     • Region
     • IP Address (regional only)
     • IP Protocol (TCP, UDP; AH , ESP , ICMP, SCTP )
     • Ports
     • Target-pool or target-intance

HTTP(S) Load Balancing

下圖是 HTTP(S) Load Balancing 的架構組成：

整理幾個重要的元件說明：
1.Global Forwarding Rule: 如何轉倒流量的規則，支援很多種方式
2.Target Proxies: 設定 HTTP request / response 常見的 header，像是 X-Forwarded-Proto, X-Forwarded-For
• 他有一個參數叫 X-Cloud-Trace-Context 紀錄追蹤 HTTP Request，可以透過 Stackdriver. 這在 Microservice 架構找問題很重要的追蹤參考。
3.URL Maps: 比對 URL-based routing 然後導流，有點像是 AWS ALB 的 Target Group
4. Backend Services
• 由 health checks  、Session affinity、一到多個 backends 組成
     • 每個 Backend 由一個 Instance Group  組成 (相當於 AWS AutoScaling Group)
     • 一個 Backend service 在每個 zone 可以有 500 endpoints

如果是 Cross-Region，那麼導流、以及 Backend Service 的概念如下：

也可以根據 URL Maps 設計導流不同的 Instance Group，如下圖：

TCP / SSL Proxy Load Balancing

TCP 和 SSL Proxy Load Balancing 有以下共同特性：
   • Scope: Global, 把流量導向全球各個 Region
• Proxy: Connection 經過 Load Balancing 之後，複製新的 Connection，轉向 Backend Instance。
       • Backend Instance 看不到 Client IP Address
       • 需要 Enable Proxy Protocol 

要注意的 Proxy LB 跟 HTTP(S) LB 的差異：
   • SSL Proxy Load Balancing 可以處理 HTTPS，但是建議使用 HTTPS Load Balancing。
        • HTTPS Load Balancing 支援 HTTP/2、SPDY/3.1、拒絕不是 HTTP 的 Request / Response、整合 Cloud CDN … 等
        • SSL Proxy Load Balancing 則是給不是 HTTP 的協定，但需要安全加密使用 ，像是 Websockets、IMAP Over SSL
        • 更多詳細參閱 FAQ  說明

Network Load Balancing: TCP / UDP

主要特性：
• Scope: Regional
• Non-proxied：可以處理 TCP / UDP / SSL 。但是只是把 Connection pass-through 給後端
• Session Affinity：
• 目的：Client 的連線持續在固定的 Backend Instance
• 實作是利用 Source IP / Port, Destination IP / Port 做 Hash。
• 預設是 None.

Overview AWS Elastic Load Balancing

AWS Elastic Load Balancing  現在有三大類，整理如下：

Classic Load Balancing

• 歷史最悠久，簡單容易使用，但是效能最差，需要開 Support Ticket pre-warm，內容要回答一堆問題，新手很難上手。
• 無法處理瞬間巨量：因為需要 pre-warm 所以會有 Thoughtput 的問題，如果有密集度很高的 RPS 衝進來，會無法處理，而且這問題不容易發現。

實際上我就遇過因為 ELB Scale Out 太慢，造成系統效能問題。架構效能大概是這樣：

External ELB -> App1 -> Internal ELB -> App2

發現 ELB 無法乘載的時候，他會開始 Scale-Out，但是在完成之前，會出現以下現象：
• External ELB 瞬間會出現少量 5XX
• Internal ELB 瞬間出現大量 Surge Queue
原因是 ELB Scale-Out 太慢，瞬間 RPS 密度太高，造成 Throughput 不夠用，後來解法就是常態性的 pre-warm，造成很多額外的問題。

Application Load Balancing

• Layer 7
• 支援 URL Routing-base
• 支援 Multiple TLS w/ SNI 

Network Load Balancing

• Layer 4, TCP only
• 支援 URL Routing-base
• 支援固定 IP
• 支援 RPS 到百萬等級 (終於)

Compare GCP Load Balancing with AWS

整理兩者個比較如下：

可以看見 GCP Load Balancing 幾乎完勝。當然，對於不是 Global Business 的需求，AWS ELB 也還是很好用的。

參考資料

• Google Cloud Load Balancing
• AWS Elastic Load Balancing
• Google Cloud Platform for AWS Professionals
• Globally scalable microservices with Container Engine & Cloud Load Balancing 

Public Cloud Comparison

• Google Cloud vs AWS: a comparison
• A Side-by-Side Comparison of AWS, Google Cloud and Azure
• Public Cloud Services Comparison