什麼是負載平衡?原理、6大 GCP Load Balancer 完整介紹

什麼是負載平衡?原理、6大 GCP  Load Balancer 完整介紹

專有名詞差異辭典
在文章開始前,先為大家釐清負載平衡中兩個相似的名詞:「Load Balancing」與「Load Balancer」。
● Load Balancing:負載平衡,指的是平衡負載這個動作。
● Load Balancer:負載平衡器,指的是在 Google 前端執行負載平衡的設備本身,其設定包含前端、後端服務及後端。


透過負載平衡(Load Balancing),我們可避免單一伺服器負載過高而故障。但負載平衡的原理和服務組成是甚麼?Google Cloud(原 GCP) Load Balancer(負載平衡器)有哪些種類,各自的架構和分流原理又是怎麼一回事?跟著 Cloud Ace 一次了解上面這些問題的解答吧!

什麼是負載平衡―分流原理

負載平衡(Load Balancing)顧名思義是和流量負載有關。它是在多個伺服器間分配流量,當龐大的流量進入負載平衡器時,透過分散負載的方式,避免單一伺服器負載過高,達到資源使用最佳化,進而防止單點故障(意即 A 伺服器負載過高時,透過負載平衡將請求轉到 B 伺服器)。

負載平衡分流的方式有很多種,常見的有依照地理位置分流和 URL 分流。另外,GCP 的負載平衡流程有3個步驟,分別是「使用者端發出請求」(步驟1)、「請求進入負載平衡器」(步驟2)和「將流量分配至健康的伺服器或其它後端服務」(步驟3)。其架構與流程如下圖所示。

GCP Cloud Load Balancing_架構圖
截圖自:Google Cloud 官方文件

此外 Load Balancing 通常會搭配 Autoscaling 一起使用。其目的在於當流量忽然暴增時,使用者可透過 Autoscaling 功能自動增開伺服器,避免流量過大造成伺服器癱瘓。而若是流量忽然減少,此功能也能幫我們自動關閉不需要的後端服務,有效減少資源浪費和不必要的成本。

什麼是負載平衡―服務組成

那在了解 Load Balancing 是什麼後,接著要進一步為大家介紹它服務的組成。GCP 負載平衡的設置主要分為 Frontend(前端)Backends(後端),下面我們會一一簡介這兩部分裡的一些常見名詞,幫助大家在後面能更簡單地了解各種負載平衡的架構。

Frontend(前端)

Frontend 是負載平衡裡重要的一環,訪問 GCP 資源的流量都會先傳入 Frontend,再依據連線方式與轉發規則被送往不同的後端。而就「全球負載平衡(Global Load Balancer)」來說,透過 Google 前端(Google Front Ends,即 GFEs),我們的服務可以在網路上被公開存取,使用者不論在哪都可以連到離它最近的 GFE,而使用者發出的請求會被導向離自己最近的後端。

GCP Load Balancer 前端設置_示意圖

其中,Frontend 的設置如上圖所示,基本上會有「Forwarding rule」、「Target proxy」、「SSL certificate」和「URL map」這四項,以下為大家簡單整理它們在負載平衡裡扮演的角色。

負載平衡 Frontend 基本設置
Forwarding rule(轉發規則):透過設置 IP 讓傳入流量透過此 IP 進入負載平衡器,並運用對應的 Protocol 與 Port 將流量轉至 Proxy 或是 Backend service
Target proxy(目標代理):作為 Client 與 Server 間的幫助者,透過 Proxy 設置兩段連線,並可設置 SSL 憑證安全連線
SSL certificate(SSL 憑證):用於保護網路通訊的加密協議,這個憑證可以是 Google 幫我們管理,或由我們自行管理
URL map:依照使用者訪問的 URL ,將請求導向對應的後端資源。

Backends(後端)

在負載平衡中我們需要了解的重要概念是 Backend serviceBackends 的不同,而它們兩者並非平常俗稱的網頁後端。其中,Backend service(後端服務)主要是定義負載平衡器如何分配流量到我們設置的 Backends(後端)資源,並藉由檢查資源運行狀況確保資源健康後,才將流量導向後端資源。

這邊提醒大家,要對後端資源進行健康檢查就必須設置防火牆規則(Firewall rule),允許來自 Health check 的流量,而 Health Check 的來源 IP 範圍可參考下表。另外,若要使用 Internal HTTP(S) 的負載平衡還需要多設一條「允許來自 Proxy-only subnet 流量」的規則,這點大家也需特別注意!

GCP Load Balancer 防火牆_規則圖
負載平衡後端資源的防火牆規則

了解完 Backend service(後端服務)後,接著我們來認識 Backends(後端)的「資源」。資源是一個或多個的端點,用來接收來自負載平衡器的流量。而後端資源有「Instance group」、「Cloud Storage」和「Network Endpoint Group (NEG)」這三項。

GCP Load Balancer 後端資源_示意圖

負載平衡 Backends 資源
Instance group:意思就是將多個虛擬機放在一個群組以集中管理。執行個體群組可以分為 Google 代管的「託管執行個體群組」,與我們自行管理的「非託管執行個體群組」
Cloud Storage:針對 html、css、js、圖片和影片等靜態內容,直接存在 Cloud Storage 可有效節省資源
Network Endpoint Group(NEG):即網路端點群組,可用來做更精細的負載平衡,如我們可指定流量進入特定 VM

GCP Load Balancer 的種類與架構

以上就是負載平衡的原理與組成,接下來我們繼續來認識它的種類與架構。負載平衡器可以分成兩大類,分別是「全球負載平衡器(Global)」及「區域負載平衡器(Regional)」,兩大類別底下又可分出以下六種不同的負載平衡器,使用者可依各自需求選擇。

GCP Load Balancer 種類_示意圖
GCP 的負載平衡器種類

全球負載平衡器

所謂的「全球」負載平衡,代表使用者不管在哪裡,都可以透過 「單1個」全球負載平衡器的外部 IP,連到離它最近的 Google 前端,而 Google 前端再把流量轉發至離使用者最近的後端。這裡的後端可以是全世界任一個 Google 資源(例如 VM 或 Cloud Storage)。而 GCP 的全球負載平衡器一共有三種,分別是「External HTTP(S) Load Balancer」、「External SSL Proxy Load Balancer」和「External TCP Proxy Load Balancer」。

一、External HTTP(S) Load Balancer

首先要介紹的是 External HTTP(S) Load Balancer,如同它的名稱,這個負載平衡器是給 HTTP / HTTPS 使用的。而下面我們緊接著來了解此種負載平衡器是如何分流的。

External HTTP(S) Load Balancer 架構圖

分流的第一步,負載平衡器內的 Forwarding rule 會分別指定一個外部 IP、Port(讓 User request 知道要轉發的目的地)和 Target HTTP(S) proxy(步驟1)。透過這個步驟,使用者流量可透過單一 IP 進入負載平衡器。 接著(步驟2) ,Target HTTP(S) proxy 會依 URL 將流量導向對應的後端。提醒大家,若使用 HTTPS 負載平衡器,需要在 Proxy 設置 SSL 憑證。

依 URL 分流範例
● URL = web.example.com/home → 導向 A 後端
● URL = web.example.com/news → 導向 B 後端

接著使用者的流量就會進入 Backend service (步驟3)。其中 Backend service 是會對後端資源進行檢查的一道關卡而非真正的後端,其目的是確保將流量送至健康的後端。而在經過上述步驟後,最終我們的流量才能進入真正的 Backends(步驟4)。

注意事項
若考慮使用 Google Cloud Armor 防止 DDos 攻擊CDN 緩存靜態內容,請注意這兩項服務僅適用於 External HTTP(S) Load Balancer,即 Port 80, 8080, 443 的 Web server。
本篇文章主要討論負載平衡架構。針對負載平衡所使用的 Port,讀者可參考文章結尾提供的連結,近一步了解如何選擇負載平衡以及其所使用的 Port。

二、External SSL Proxy Load Balancer

External SSL Proxy Load Balancer 的概念是,從使用者傳入的流量會分成兩段連線,而透過 SSL Proxy Load Balancer 設置 SSL 憑證,使用者即可透過加密線連至負載平衡器。接著來看詳細的分流過程。

GCP External SSL Proxy Load Balancer_架構圖
External SSL Proxy Load Balancer 架構圖

在第一段連線中(步驟1),負載平衡器內的 Forwarding rule 會指定一個外部 IP、Port 和 Target HTTP(S) proxy 然後終止。 接著流量從 SSL Target proxy 到後端會是第二段連線(步驟2),在此大家可依需求選擇是否要用 SSL 加密連線。接下來的兩個步驟(步驟3、4)就和上面介紹的 External HTTP(S) Load Balancer 一樣了。Backend service 會對後端資源進行健康檢查,最終將流量導向離使用者最近的 Backends。

三、External TCP Proxy Load Balancer

最後要介紹的 External TPC Proxy Load Balancer 與 SSL Proxy Load Balancer 非常相似,從使用者來的流量一樣會分為兩段連線,差別只在使用者到負載平衡器間的流量(第一段連線),SSL Proxy Load Balancer 有加密,而 TCP Proxy Load Balancer沒有加密。其架構如下圖所示(第一段連線無加密),分流過程和 SSL Proxy Load Balancer 相同這邊就不再贅述。

GCP TPC Proxy Load Balancer(Premium Tier)_架構圖
TPC Proxy Load Balancer(Premium Tier)架構圖

區域負載平衡器

接著我們再來認識「區域」負載平衡,它和全球負載平衡的差別在於其後端只能在單一 Region 內(但可以在不同 Zone)。此外,區域負載平衡提供的負載平衡 IP 會在 VPC Network 的子網段中,且這個 IP 只供所屬 VPC Network 內部使用。

一、External Network TCP / UDP Load Balancer

率先登場的 External Network TCP / UDP Load Balancer 是區域負載平衡器中唯一一個使用外部 IP UDP Port 的負載平衡器。而如下圖所示,它會將流量分配至同個 Region 的 Backends。

GCP External Network TCP / UDP Load Balancer_架構圖
截圖自:Google Cloud 官方文件

在分流過程裡,Forwarding rule 會指定一個外部 IP、Port 與 Protocol 將流量導向負載平衡器的 Backend service(步驟1)。 接著流量進入 Backend service 後(步驟2),Backend service 會對後端資源進行健康狀態檢查,確保流量送至健康的後端,也就是負載平衡器會使用檢查到的狀態來確定如何將流量導向至 Backends。

外部 IP 注意事項
Forwarding rule 指定的外部 IP,可以是 GCP 自動分配的也可以是我們自訂的。而此 IP 特別的地方在於它是來自 Google Region,所以是一個獨一無二的區域 IP

二、Internal TCP / UDP Load Balancer

接下來的 Internal TCP / UDP Load Balancer 屬於 Non-proxy 負載平衡,所以可設置一至多個 Forwarding rule。其中,Forwarding rule 的 Subnet 一定要跟 Load balancer 在相同 VPC 的同個 Region 內,而 Forwarding rule 會在此 Subnet 中指定一個內部 IP(我們也可以自訂 IP)。

GCP Internal TCP / UDP Load Balancer_架構圖
截圖自:Google Cloud 官方文件

其分流過程和上面的 External Network TCP / UDP Load Balancer 基本相同。但在上圖的步驟二中,由於它屬於 Non-proxy 負載平衡,傳入流量會直接傳入符合的 Port 及 Protocol 後端,所以它的連線是不會中斷的。

三、Internal HTTP(S) Load Balancer

最後要介紹的 Internal HTTP(S) Load Balancer 比較特別,因為它需要設置 Proxy-only subnet,而 Proxy-only subnet 一定要建立在該負載平衡器所在的 VPC 網路中,是個專門給 Envoy Proxy 使用的網段,後端只接收從 Proxy-only subnet 來的連線。要注意的是 Internal HTTP(S) Load Balancer 的 IP 可以跟後端在同個網段,但不能在 Proxy-only subnet 這個網段內。

以下圖為例,Internal HTTP(S) Load Balancer,IP 為 10.1.2.99 及 10.1.2.199,與後端在同個網段 10.1.2.0/24,但 Proxy-only subnet 的網段是 10.129.0.0/23,所以它的 IP 與 Proxy-only subnet 是在不同網段的。

GCP Internal HTTP(S) Load Balancer_架構圖
截圖自:Google Cloud 官方文件

在分流過程裡,首先(步驟1),Forwarding rule 會指定一個外部 IP 與 Regional HTTP(S) Target,然後客戶端透過 IP 及 Port 連線到 Load balancer’s Envoy proxies 就中斷連線。 接著(步驟2),Regional Target HTTP(S) Proxy 會依照 URL 將流量導向指定的後端。再次提醒大家,若使用 HTTPS 的負載平衡器,要記得在 Proxy 設置 SSL 憑證。

依 URL 分流範例
● URL = web.example.com/home → 導向到 A 後端
● URL = web.example.com/news → 導向到 B 後端

然後(步驟3)流量進入 Backend service 後,Backend service 會對後端資源進行健康狀態檢查以確保將流量送至健康的後端。最後(步驟4),負載平衡器會再將流量導向 Backends(Backends 必須設在與負載平衡器相同的 VPC region)。

結論

我們知道雲端服務最大的優勢之一為其彈性,而 Load Balancer 與 Autoscaling 就是雲端彈性展現的代表。這兩者幫助我們最佳化雲端資源的使用,進而避免不必要的成本支出。而大家如果想進一步了解如何選擇最適合自己的 GCP Load Balancer,可以參考《GCP – Cloud Load Balancing 之分類與選擇》這篇文章。

以上為 Load Balancing(負載平衡)的介紹,希望大家看完後能對 GCP 負載平衡有初步的認識。針對這次的內容如有任何問題歡迎留言詢問,有 GCP 相關需求或技術問題也都歡迎聯絡我們,喜歡這篇文章的話也可以留言讓我們知道!

延伸閱讀:

CDN 是什麼?Google Cloud CDN 用途、架構完整介紹
【GCP 教學】GCP HTTP(S) Load Balancer 負載平衡依照網址分流操作
【GCP教學】打造彈性、快速且安全的雲端基本服務架構 – 負載平衡 Load Balancer 和 Instance Group
GCP – Cloud Load Balancing 之分類與選擇
如何透過 GCP HTTP(S) Load Balancing 來實現 HTTP Redirect HTTPS

Cloud Ace 研討會主頁

發佈留言