LB Taxonomy & Architecture Model — Ba họ datapath, một mô hình resource

Why this matters in production

Câu hỏi đầu tiên mọi kỹ sư đặt ra khi gặp Cloud Load Balancing là "tôi nên dùng loại nào?". Đó là câu hỏi sai để bắt đầu. Có hơn một chục biến thể load balancer trên GCP, và nếu bạn cố ghi nhớ một bảng quyết định "use case → loại LB", bạn sẽ:

• Chọn đúng loại trong 90% trường hợp đơn giản, nhưng sai trong những trường hợp biên — đúng những lúc quyết định thực sự quan trọng (cần giữ client IP? cần global? cần WAF? cần UDP?).
• Hoàn toàn bất lực khi debug, vì bảng tra cứu không cho bạn biết packet đi đâu, connection được terminate ở đâu, hay vì sao backend lại thấy một source IP lạ.
• Không hiểu vì sao một số tính năng (Cloud Armor, SSL policy, URL routing) chỉ có ở loại này mà không có ở loại kia — và tưởng đó là giới hạn tùy tiện, trong khi thực ra nó là hệ quả trực tiếp của kiến trúc datapath.

Câu hỏi đúng để bắt đầu là: "packet thực sự đi qua cái gì, và ai terminate connection?". Khi bạn trả lời được câu này cho từng loại LB, việc chọn loại trở thành hệ quả hiển nhiên, và việc debug trở thành truy vết một datapath cụ thể thay vì đoán mò. File này xây dựng đúng khung tư duy đó.

Internal model — một mô hình resource, ba họ datapath

Lớp resource: bộ khung chung cho gần như mọi LB

Trước khi nói về sự khác nhau, hãy nắm cái giống nhau. Gần như mọi load balancer trên GCP (trừ một vài biến thể legacy như target pool) được lắp ráp từ cùng một chuỗi resource. Đây là "ngữ pháp" của Cloud Load Balancing:

   Client
     │
     ▼
┌─────────────────┐   Forwarding Rule
│ Forwarding Rule │   - Gắn một IP (VIP) + port + protocol
│  (VIP:port)     │   - Quyết định: external/internal, global/regional,
└────────┬────────┘     và load-balancing scheme (EXTERNAL_MANAGED,
         │               INTERNAL_MANAGED, EXTERNAL, INTERNAL)
         ▼
┌─────────────────┐   Target Proxy (chỉ có ở proxy LB)
│  Target Proxy   │   - target-http-proxy / target-https-proxy (L7)
│  (L7 hoặc L4)   │   - target-tcp-proxy / target-ssl-proxy (L4 proxy)
└────────┬────────┘   - Terminate TLS/TCP tại đây; gắn SSL policy tại đây
         │            - Passthrough LB KHÔNG có target proxy
         ▼
┌─────────────────┐   URL Map (chỉ có ở Application LB / L7)
│    URL Map      │   - Routing theo host, path, header, query
│  (L7 routing)   │   - Trỏ tới backend service hoặc backend bucket
└────────┬────────┘   - Proxy NLB và passthrough NLB KHÔNG có URL map
         │
         ▼
┌─────────────────┐   Backend Service
│ Backend Service │   - Health check, session affinity, balancing mode
│ (policy + health)│  - Capacity scaler, connection draining, Cloud Armor
└────────┬────────┘   - Là "bộ não" quyết định backend nào nhận request
         │
         ▼
┌─────────────────┐   Backend (endpoint thật)
│   Backend       │   - Instance Group (managed/unmanaged) HOẶC
│ (IG hoặc NEG)   │   - Network Endpoint Group (zonal/serverless/internet/PSC/hybrid)
└─────────────────┘

Hai điều cần rút ra ngay từ sơ đồ này:

1. Sự có mặt/vắng mặt của target proxy và URL map chính là ranh giới L7/L4/passthrough. Application LB (L7) có cả hai. Proxy Network LB (L4 proxy) có target proxy nhưng không có URL map (nó không đọc HTTP). Passthrough Network LB không có cả hai — không terminate gì, không routing L7 gì.

2. Backend service là nơi tập trung gần như mọi "policy" về hành vi LB. Health check, session affinity, balancing mode, capacity, connection draining, Cloud Armor đều gắn vào backend service. Khi debug hành vi LB, backend service là object bạn nhìn vào đầu tiên — không phải forwarding rule.

load-balancing scheme trên forwarding rule là trường quyết định nhiều thứ nhất: EXTERNAL_MANAGED (Envoy/GFE proxy external), INTERNAL_MANAGED (Envoy proxy internal), EXTERNAL (passthrough external hoặc Classic LB), INTERNAL (passthrough internal). Theo tài liệu Cloud Load Balancing, scheme này phải khớp xuyên suốt forwarding rule → target proxy → backend service; trộn scheme là lỗi cấu hình phổ biến khi dựng LB bằng tay.

Lớp datapath: cái thực sự forward packet

Mô hình resource ở trên chỉ là cấu hình. Cái thực sự xử lý packet là datapath, và đây mới là nơi sự khác biệt cơ bản nằm. GCP có ba họ datapath, và mọi load balancer thuộc về đúng một trong ba họ này.

Họ 1 — Google Front End (GFE). GFE là tầng proxy chạy ở biên mạng toàn cầu của Google, phân tán khắp các điểm hiện diện (PoP) trên thế giới. Đặc điểm cơ chế:

• Anycast. Một VIP duy nhất được quảng bá (advertise) từ nhiều PoP. Client trên internet kết nối tới VIP đó và mạng định tuyến họ tới GFE gần nhất về mặt mạng. Đây là lý do Global External ALB là "global": không phải vì có một con LB khổng lồ ở đâu đó, mà vì VIP tồn tại đồng thời ở mọi biên.
• Terminate TLS/TCP ngay tại edge. GFE bắt tay TLS với client tại PoP gần client nhất, rồi mở connection riêng đi tới backend qua backbone nội bộ của Google. Điều này rút ngắn RTT của TLS handshake (phần đắt nhất) xuống còn khoảng cách client→PoP.
• Sống ở control plane của Google, không tốn IP trong VPC của bạn. Bạn không thấy GFE trong VPC; nó không lấy IP từ subnet của bạn. Đổi lại, backend của bạn không bao giờ thấy IP thật của client — chỉ thấy IP của GFE và dải health-check/proxy của Google.

GFE phục vụ: Global External Application LB, Classic Application LB, Global External Proxy Network LB.

Họ 2 — Envoy (managed proxy fleet). Đây là một fleet proxy dựa trên Envoy do Google quản lý, nhưng chạy trong region và trong VPC của bạn, lấy IP từ một proxy-only subnet mà bạn phải tạo. Đặc điểm cơ chế:

• Regional (hoặc cross-region). Envoy proxy được triển khai theo region. Một regional internal ALB chỉ tồn tại trong một region; cross-region internal ALB trải nhiều region nhưng vẫn dựa trên Envoy.
• Source IP đi tới backend đến từ proxy-only subnet. Theo tài liệu proxy-only subnet, "packet gửi từ proxy tới backend VM hoặc endpoint có source IP từ proxy-only subnet". Đây là khác biệt thực tế lớn so với GFE: firewall của backend phải allow dải proxy-only subnet, không phải dải GFE toàn cầu.
• Cấu hình bằng chính mô hình resource ở trên, nhưng Envoy đọc URL map / backend service và thực thi routing/affinity theo đúng ngữ nghĩa Envoy (locality LB policy, outlier detection, v.v.).

Envoy phục vụ: Regional External ALB, Regional/Cross-region Internal ALB, Regional External Proxy NLB, Regional/Cross-region Internal Proxy NLB. Lưu ý: tài liệu mô tả Global External ALB hiện đại là "Envoy-based GFE" — tức GFE đã hội tụ về dùng Envoy làm engine, nhưng vẫn giữ đặc tính global/anycast/edge của họ GFE. Về mặt mental model vận hành (scope, IP, source IP nhìn từ backend), cứ phân loại theo "global edge anycast" (GFE) vs "regional proxy-only subnet" (Envoy regional).

Họ 3 — Maglev / Andromeda (passthrough). Đây là họ không có proxy. Không có gì terminate connection. Đặc điểm cơ chế:

• External passthrough NLB dùng Maglev; internal passthrough NLB dùng Andromeda (host vSwitch — chính là datapath bạn đã gặp ở Chương 19). Cả hai chọn backend bằng consistent hashing trên các trường của packet, không mở connection mới.
• Direct Server Return (DSR). Packet đi từ client → tới backend với IP đích vẫn là VIP của LB (được Andromeda/Maglev "lái" tới backend đã chọn). Backend xử lý và trả lời trực tiếp về client, không đi ngược qua LB. Đây là lý do passthrough NLB có throughput rất cao và độ trễ thêm gần như bằng 0 — đường về không qua LB.
• Backend thấy IP thật của client. Vì không có proxy nào thay đổi source IP, ứng dụng trên backend nhận đúng client IP ở tầng socket. Đây là khác biệt cốt lõi khiến passthrough được chọn khi cần client IP nguyên bản.

Passthrough phục vụ: External Passthrough NLB (TCP/UDP/ESP/GRE/ICMP...), Internal Passthrough NLB (TCP/UDP/ICMP/SCTP/ESP/AH/GRE...).

Hai trục phân loại — và trục nào thực sự quan trọng

Tài liệu marketing thường phân loại LB theo bốn trục: L4/L7, internal/external, global/regional, proxy/passthrough. Bốn trục này có thật, nhưng chúng không độc lập và không ngang hàng về tầm quan trọng. Thứ tự quan trọng thực sự khi reason về cơ chế:

Trục số 1 — Proxy hay Passthrough? Đây là trục quyết định nhiều nhất, vì nó định nghĩa toàn bộ mô hình datapath:

	Proxy LB	Passthrough LB
Số connection	2 (client↔proxy, proxy↔backend)	1 (client↔backend, LB chỉ lái packet)
Source IP backend thấy	IP của proxy (GFE/Envoy)	IP thật của client
Terminate TLS	Có thể (ALB/SSL proxy)	Không bao giờ
Đường về (response)	Qua proxy	Trực tiếp về client (DSR)
"Connection" sống ở đâu	Trong proxy (stateful proxy)	Trong connection-tracking table phân tán
L7 routing (host/path)	Có (nếu là ALB)	Không
Cloud Armor WAF	Có	Không (chỉ Network Edge Security L3/4)
Throughput ceiling	Giới hạn bởi proxy capacity	Gần như line-rate (không qua proxy đường về)

Trục số 2 — GFE-global hay Envoy-regional? (chỉ áp dụng cho proxy LB). Quyết định scope, anycast, IP consumption, và source IP nhìn từ backend.

Trục số 3 — Internal hay External? Quyết định VIP là public hay private, và ai có thể reach nó. Trục này quan trọng cho security nhưng không thay đổi datapath nhiều như hai trục trên.

Trục L4/L7 thực ra là hệ quả của trục 1+2: nếu có proxy và có URL map → L7 (Application LB); nếu có proxy nhưng không URL map → L4 proxy (Proxy NLB); nếu không proxy → L4 passthrough. Nên đừng coi L4/L7 là điểm khởi đầu phân loại; nó là kết quả.

Bảng taxonomy đầy đủ (tham chiếu)

Gộp lại theo họ datapath thay vì theo bảng phẳng, để bạn nhớ vì sao mỗi loại có đặc tính của nó (nguồn: Load Balancing Overview):

PROXY — họ GFE (global, anycast, edge, không tốn IP VPC)
  • Global External Application LB   L7  external  global    scheme EXTERNAL_MANAGED  (HTTP/HTTPS)
  • Classic Application LB           L7  external  global*   scheme EXTERNAL          (legacy)
  • Global External Proxy NLB        L4  external  global    scheme EXTERNAL_MANAGED  (TCP [+SSL offload])

PROXY — họ Envoy (regional/cross-region, proxy-only subnet trong VPC)
  • Regional External Application LB L7  external  regional  scheme EXTERNAL_MANAGED
  • Regional Internal Application LB L7  internal  regional  scheme INTERNAL_MANAGED
  • Cross-region Internal App LB     L7  internal  global    scheme INTERNAL_MANAGED
  • Regional External Proxy NLB      L4  external  regional  scheme EXTERNAL_MANAGED  (TCP)
  • Regional Internal Proxy NLB      L4  internal  regional  scheme INTERNAL_MANAGED  (TCP, không SSL offload)
  • Cross-region Internal Proxy NLB  L4  internal  global    scheme INTERNAL_MANAGED  (TCP)

PASSTHROUGH — họ Maglev/Andromeda (DSR, giữ client IP, không proxy)
  • External Passthrough NLB         L4  external  regional  scheme EXTERNAL  (TCP/UDP/ESP/GRE/ICMP/ICMPv6) — Maglev
  • Internal Passthrough NLB         L4  internal  regional  scheme INTERNAL  (TCP/UDP/ICMP/SCTP/ESP/AH/GRE) — Andromeda

(*Classic ALB là global ở Premium Tier, regional ở Standard Tier.)

Lưu ý cơ chế quan trọng: passthrough NLB luôn là regional. Không có khái niệm "global passthrough NLB", vì DSR và consistent hashing cần một region scope để connection tracking nhất quán. Muốn "global" cho L4, bạn phải dùng Proxy NLB (có proxy) hoặc dựng nhiều passthrough NLB regional sau một lớp DNS/anycast.

Constraints, trade-offs & failure modes

Vì sao một số tính năng "chỉ có ở proxy LB"

Đây là điểm hay bị hiểu nhầm là "giới hạn tùy tiện". Thực ra mọi giới hạn đều suy ra trực tiếp từ datapath:

• URL routing (host/path), header manipulation, traffic splitting cần một thực thể đọc và hiểu HTTP nằm trên đường đi. Passthrough không có proxy nào đọc HTTP → không thể có. Đây không phải thiếu tính năng; passthrough về định nghĩa không nhìn vào L7.
• TLS termination, SSL policy cần một thực thể kết thúc TLS. Passthrough không terminate gì → TLS đi xuyên tới backend (backend tự terminate). Muốn LB terminate TLS, bạn buộc phải dùng proxy LB (ALB hoặc SSL proxy NLB).
• Cloud Armor WAF (L7) cần đọc nội dung HTTP để match SQLi/XSS → chỉ proxy LB. Passthrough chỉ được bảo vệ bởi Network Edge Security (lọc L3/4), một cơ chế khác.
• Giữ client source IP nguyên bản cần không có proxy thay đổi IP → chỉ passthrough cho bạn điều này ở tầng socket (proxy LB phải truyền qua X-Forwarded-For hoặc PROXY protocol).

Nói cách khác: proxy và passthrough là một trade-off cơ bản, không phải hai mức "xịn/không xịn". Proxy cho bạn thông minh L7 (routing, WAF, TLS) nhưng giấu client IP và thêm một hop. Passthrough cho bạn client IP + throughput tối đa + DSR nhưng không hiểu gì về L7.

Failure mode: chọn loại LB rồi mới phát hiện nó không làm được điều bạn cần

Chuỗi sai lầm điển hình ở production:

1. Team chọn External Passthrough NLB vì "cần hiệu năng cao và giữ client IP". Sáu tháng sau cần thêm WAF chống SQLi → phát hiện passthrough không chạy được Cloud Armor L7. Phải tái kiến trúc sang Global External ALB, mất luôn client IP nguyên bản ở socket (phải đổi app để đọc X-Forwarded-For).
2. Team chọn Regional External ALB vì "Envoy hiện đại hơn". Khi mở rộng ra nhiều châu lục, phát hiện nó regional → mỗi region một VIP, phải tự dựng DNS-based routing thay vì một anycast VIP toàn cầu. Lẽ ra nên dùng Global External ALB (GFE/anycast) ngay từ đầu.
3. Team dựng Internal Passthrough NLB rồi đặt firewall chặn dải GFE — và bối rối khi health check fail, vì passthrough health check đến từ dải khác (35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22) chứ không phải dải proxy. Xem chi tiết ở file 06.

Bài học cơ chế: quyết định proxy vs passthrough và global vs regional là quyết định kiến trúc gần như không thể đảo ngược rẻ tiền, vì nó kéo theo source IP semantics, security model, và DNS topology. Phải quyết đúng dựa trên hiểu datapath, không dựa trên "loại nào mới hơn".

Constraint: load-balancing scheme phải nhất quán

Khi dựng LB thủ công (gcloud/Terraform), lỗi phổ biến nhất là trộn scheme: forwarding rule EXTERNAL_MANAGED trỏ vào backend service EXTERNAL (Classic). API sẽ từ chối, nhưng thông báo lỗi thường khó hiểu. Quy tắc: chọn scheme trước, rồi tạo mọi resource trong chuỗi với cùng scheme đó. EXTERNAL_MANAGED = Envoy/GFE proxy hiện đại; EXTERNAL = Classic/passthrough; INTERNAL_MANAGED = Envoy internal proxy; INTERNAL = passthrough internal.

Một ví dụ cô đọng: cùng một "expose web app", ba kiến trúc khác nhau

Để thấy taxonomy không phải lý thuyết suông, xét cùng một yêu cầu — "expose một web app cho người dùng" — và ba bối cảnh dẫn tới ba loại LB khác nhau vì lý do cơ chế:

• App public, người dùng toàn cầu, cần WAF + TLS + CDN: Global External ALB. Lý do cơ chế: cần anycast (global), cần proxy để terminate TLS và chạy Cloud Armor, cần URL map để route nhiều backend. Đây là "default" cho web public.
• App nội bộ, chỉ truy cập trong VPC/từ on-prem, cần L7 routing giữa microservices: Regional Internal ALB (Envoy). Lý do cơ chế: internal (private VIP), cần L7 (path routing), không cần global. Tốn một proxy-only subnet trong region.
• Game server / VoIP / cần UDP + client IP nguyên bản + throughput cực cao: External Passthrough NLB. Lý do cơ chế: passthrough giữ client IP ở socket, hỗ trợ UDP (proxy LB không), DSR cho throughput. Đánh đổi: không WAF L7, không TLS termination tại LB.

Ba lựa chọn này không phải "sở thích" — mỗi cái là đáp án duy nhất đúng cho ràng buộc cơ chế của nó.

Common mistakes / anti-patterns

Anti-pattern 1 — Chọn LB theo "L4 hay L7" trước tiên. Hiểu lầm cơ chế: coi L4/L7 là trục gốc. Hậu quả: bỏ qua câu hỏi proxy/passthrough quan trọng hơn, dẫn tới chọn proxy NLB khi thực ra cần passthrough (mất client IP) hoặc ngược lại. Sửa: hỏi "proxy hay passthrough?" và "global hay regional?" trước; L4/L7 sẽ tự lộ ra.

Anti-pattern 2 — Giả định mọi LB đều "giấu" client IP. Hiểu lầm: nghĩ load balancer luôn là proxy. Hậu quả: viết app dựa vào X-Forwarded-For rồi chuyển sang passthrough NLB và header đó biến mất (passthrough đưa client IP thẳng vào socket, không thêm header). Sửa: biết rõ datapath — proxy dùng X-Forwarded-For, passthrough dùng socket source IP.

Anti-pattern 3 — Tưởng "internal" tự động an toàn nên bỏ qua firewall. Hiểu lầm: nghĩ internal LB không cần mở firewall cho health check. Hậu quả: backend không bao giờ healthy vì firewall chặn dải prober. Sửa: bất kể internal hay external, prober đến từ các dải IP cố định của Google và phải được allow (xem file 06).

References

• Cloud Load Balancing Overview
• Application Load Balancer Overview
• External Application Load Balancer Overview
• Proxy-only Subnets for Envoy-based Load Balancers
• Internal Passthrough Network Load Balancer Overview
• External Passthrough Network Load Balancer Overview
• Backend Services Overview
• Forwarding Rules Overview