ALB Under The Hood: Bên Dưới “Nàng Lễ Tân Thông Minh” Thật Sự Là Gì?

Khi bạn tạo một Application Load Balancer trên AWS, bạn nhận được đúng một thứ duy nhất: một DNS name dài ngoằng kiểu my-alb-123456789.ap-southeast-1.elb.amazonaws.com. Không có IP tĩnh. Không có server nào bạn có thể SSH vào. Vậy bên dưới cái DNS name đó, thật sự là gì?

Bài viết này sẽ “lật mặt” kiến trúc ẩn sau ALB — từ đội quân load balancer nodes âm thầm hoạt động, đến cơ chế scaling, và lý do tại sao ALB không bao giờ có static IP.

1. Load Balancer Nodes — “Đội Quân Ẩn Mình”

Khi bạn tạo ALB và chọn 3 Availability Zones (AZ), AWS không tạo ra “một cái load balancer”. Thay vào đó, AWS triển khai ít nhất 1 load balancer node trong mỗi AZ mà bạn đã chọn. Vậy với 3 AZs, bạn có tối thiểu 3 nodes.

Nodes scale như thế nào?

Mỗi node bắt đầu ở kích thước large. Khi traffic tăng, AWS sẽ scale vertical (nâng cấp node) theo progression:

large → xlarge → 2xlarge → 4xlarge

Khi một node đã đạt 4xlarge mà vẫn chưa đủ capacity, AWS sẽ chuyển sang scale horizontal — thêm node 4xlarge mới vào AZ đó. Tổng cộng, một ALB có thể scale lên tối đa 100 nodes across tất cả AZs.

Subnet phải đủ “rộng”

Mỗi node tiêu thụ 1 IP address trong subnet. Vì vậy, AWS yêu cầu:

• Subnet tối thiểu /27 CIDR (32 IPs, trong đó ít nhất 8 IPs phải còn trống)
• Nếu bạn có 50 nodes (10/AZ × 5 AZs), bạn cần thêm khoảng 10 IPs/AZ để còn room cho scaling

Chuyện gì xảy ra khi subnet hết IP? ALB sẽ rơi vào trạng thái active_impaired — nó vẫn hoạt động nhưng không thể scale thêm, dẫn đến 5xx errors và timeout cho users. Đây là một lỗi “thầm lặng” mà nhiều team không nhận ra cho đến khi traffic spike xảy ra.

Tip: Luôn dùng subnet /27 trở lên cho ALB. Nếu hệ thống của bạn có traffic lớn, hãy cân nhắc /26 hoặc /25 để đảm bảo headroom cho scaling.

2. Tại Sao ALB Chỉ Có DNS Name, Không Có Static IP?

Đây là câu hỏi kinh điển: NLB có thể gắn Elastic IP (static), vậy tại sao ALB thì không?

Câu trả lời nằm ở chính cơ chế scaling vừa mô tả ở trên:

• ALB liên tục thêm/bớt nodes để đáp ứng traffic. Mỗi node có IP riêng.
• Khi một node mới được thêm → IP mới xuất hiện
• Khi một node bị remove → IP cũ biến mất

Nếu AWS cấp static IP cho ALB, bạn sẽ gắn IP vào node nào? Node đó có thể bị remove bất cứ lúc nào. Đó là lý do AWS chọn giải pháp DNS abstraction: một DNS name trỏ đến danh sách IPs hiện tại của các nodes.

DNS hoạt động ra sao?

Khi client resolve DNS name của ALB:

1. Route 53 trả về multiple A records — mỗi record là IP của một node đang active
2. Alias record có TTL cố định 60 giây (không thể thay đổi)
3. Khi ALB scale (thêm/bớt nodes), Route 53 tự động cập nhật danh sách IPs
4. Client sẽ nhận được IPs mới sau tối đa 60 giây

Vậy NLB làm thế nào để có Static IP?

NLB hoạt động ở Layer 4 — nó chỉ forward TCP/UDP packets mà không cần inspect nội dung. Kiến trúc của NLB đơn giản hơn nhiều:

• NLB tạo 1 Elastic Network Interface (ENI) cố định per AZ
• Mỗi ENI có thể gắn 1 Elastic IP (static)
• Bên trong, AWS dùng Hyperplane technology để scale capacity mà không cần thêm ENI

Nói cách khác: NLB “giấu” sự phức tạp scaling bên dưới một ENI cố định. ALB không làm được điều này vì nó cần nhiều nodes thực sự để xử lý Layer 7 traffic (inspect HTTP headers, routing rules, SSL termination…).

Tip thực tế: Nếu bạn cần static IP cho ALB (ví dụ: đối tác yêu cầu whitelist IP), hãy đặt NLB phía trước ALB. AWS hỗ trợ đăng ký ALB như một target group type của NLB, cho phép bạn kết hợp static IP của NLB với routing thông minh của ALB.

3. ALB Scaling — “Tăng Tốc Như Tên Lửa, Hạ Cánh Như Lông Vũ”

ALB scaling có một đặc điểm thú vị: bất đối xứng.

• Scale up: Cực kỳ aggressive. ALB có thể gấp đôi capacity trong vòng 5 phút
• Scale down: Rất conservative. AWS giảm từ từ để tránh tình huống vừa scale down xong thì traffic lại spike

LCU Reservation — “Đặt Chỗ Trước” Cho Traffic Spike

Trước đây, nếu bạn biết sắp có đợt traffic lớn (Black Friday, Flash Sale), bạn phải liên hệ AWS Support để “pre-warm” ALB. Bây giờ, AWS cung cấp tính năng LCU (Load Balancer Capacity Unit) Reservation — cho phép bạn tự đặt trước capacity.

Cách hoạt động:

1. Xác định peak load dự kiến từ CloudWatch metrics (PeakLCUs) hoặc load testing
2. Set LCU Reservation qua Console hoặc ELBV2 API
3. ALB sẽ provision capacity tối thiểu bằng mức bạn đặt
4. Nếu traffic vượt mức reservation → ALB vẫn auto-scale bình thường phía trên

Automation pattern cho planned events:

EventBridge Scheduler (1 tiếng trước event)
    → Lambda function
        → Đọc ALB info từ DynamoDB
        → Gọi ELBV2 API để set LCU Reservation
        → Sau event, reset về mức bình thường

Lưu ý: LCU Reservation được thiết kế cho khoảng thời gian ngắn (vài giờ đến vài ngày), không phải cho permanent capacity planning. Reserved LCUs sử dụng Reserved rate (rẻ hơn), phần vượt mức dùng standard on-demand rate.

4. Cross-Zone Load Balancing

Khi ALB có nodes ở nhiều AZs, traffic được phân phối như thế nào?

Mặc định: Bật ở ALB level

Với cross-zone load balancing bật (mặc định), mỗi ALB node phân phối traffic đến tất cả targets across mọi AZ, không chỉ targets trong AZ của nó.

Ví dụ: Bạn có 10 targets ở AZ-a và 5 targets ở AZ-b. Với cross-zone bật, mỗi target nhận ~6.67% traffic (1/15), bất kể nằm ở AZ nào.

Khi nào nên tắt cross-zone?

Bạn có thể tắt cross-zone ở target group level trong một số trường hợp:

• Muốn giữ traffic trong cùng AZ để giảm latency
• Sử dụng zonal shift (AZ evacuation) cho disaster recovery
• Muốn kiểm soát chặt traffic distribution

Chi phí

Một điểm quan trọng: ALB không tính phí cross-zone data transfer giữa ALB nodes và targets. Đây là khác biệt lớn so với NLB — nơi cross-zone data transfer bị charge phí. Điều này làm ALB trở nên cost-effective hơn cho các deployment trải đều nhiều AZs.

5. Connection Handling — ALB Là Một Reverse Proxy Thực Thụ

Nhiều người nghĩ ALB chỉ đơn giản “forward” request đến backend. Thực tế, ALB là một full reverse HTTP proxy — nó terminate kết nối TCP từ client và tạo kết nối TCP mới đến backend.

HTTP Multiplexing & Connection Pooling

Đây là một trong những lợi ích lớn nhất mà ít người biết:

• ALB nhận requests từ hàng ngàn clients qua hàng ngàn TCP connections
• Nhưng khi gửi đến backend, ALB sử dụng một số ít persistent TCP connections
• Nhiều client requests được multiplex qua cùng một backend connection

Điều này giúp backend server tiết kiệm đáng kể CPU, memory và bandwidth — thay vì phải maintain hàng ngàn connections, backend chỉ cần handle vài chục connections từ ALB.

HTTP/2: Hỗ trợ nhưng có giới hạn

ALB hỗ trợ HTTP/2 từ phía client (multiplexing, header compression, binary framing). Tuy nhiên, khi forward đến backend, ALB convert HTTP/2 streams thành HTTP/1.1 requests riêng lẻ. Nghĩa là:

• Client → ALB: HTTP/2 (nhiều streams trên 1 connection)
• ALB → Backend: HTTP/1.1 (mỗi stream thành 1 request riêng)

HTTP/2 stream multiplexing và prioritization không được preserve khi đi qua ALB.

Timeout Configuration — Nguồn Gốc Của 502/504

ALB có 2 timeout quan trọng:

Best practice quan trọng: Backend keep-alive timeout phải lớn hơn ALB idle timeout.

Tại sao? Nếu backend đóng connection trước ALB (ví dụ backend timeout 30s, ALB timeout 60s), sẽ xảy ra race condition:

1. ALB nghĩ connection vẫn active → gửi request qua
2. Backend đã đóng connection → trả về RST
3. ALB trả về 502 Bad Gateway cho client

Fix: Set backend keep-alive timeout = ALB idle timeout + 5-10 giây buffer. Ví dụ: ALB idle timeout 60s → backend keep-alive 70s.

6. Làm Sao Request Đến Đúng Một Node? — Phân Phối Tải Ở Lớp DNS

Trước khi nói về cách ALB chọn target backend, có một câu hỏi nền tảng hơn: nếu ALB có 6 nodes (2/AZ × 3 AZs), khi client gửi request, cái gì quyết định request đó đến node nào trong 6 cái đó? Có một “router trung tâm” nào đứng trước phân phối không?

Câu trả lời sẽ làm bạn ngạc nhiên: Không có “router trung tâm” nào cả. Việc chọn node hoàn toàn diễn ra ở lớp DNS, phía client — trước khi packet đầu tiên rời khỏi máy client.

Cơ chế hoạt động

1. Client query DNS: Browser/app hỏi “IP của my-alb-123.elb.amazonaws.com là gì?”

2. Route 53 trả về danh sách IPs:

   • Trả về tối đa 8 IPs trong một response (mỗi IP là 1 node của ALB)
   • Thứ tự được shuffle ngẫu nhiên trong mỗi response
   • TTL cố định 60 giây
   • Chỉ trả về IPs của healthy nodes — node đang impaired bị loại khỏi response

3. Client chọn 1 IP:

   • Đa số OS/library lấy IP đầu tiên trong response (browser, JVM, libcurl, Go net/http…)
   • Một số advanced client thử IP kế tiếp nếu IP đầu fail
   • Client cache IP trong khoảng = TTL (60s)

4. Client mở TCP connection thẳng đến IP đó — node đó handle toàn bộ TCP/TLS connection trong suốt thời gian connection sống.

Vậy “thuật toán phân phối node” thực ra là gì?

Đây là điều nhiều người không nhận ra: ALB không có một load balancing algorithm giữa các node. Sự phân phối tải giữa các node hoàn toàn dựa vào:

• Random shuffle của Route 53 trong mỗi DNS response
• Luật số lớn (Law of Large Numbers) — khi đủ nhiều client query, phân phối ngẫu nhiên sẽ “đều” về mặt thống kê

Nói cách khác: phân phối tải giữa các node chỉ “đều” khi bạn có hàng ngàn clients mỗi giây. Với traffic thấp, có thể có node “rảnh” trong khi node khác bận — chuyện bình thường.

Tóm lại: ALB Có 2 Lớp “Quyết Định” Hoàn Toàn Tách Biệt

Khi một request đi qua ALB, có 2 quyết định độc lập:

Lớp 1 (chọn node) AWS đã quyết — bạn không config gì ngoài chọn region và AZs. Lớp 2 (chọn target) bạn control được qua target group settings, đây là phần section tiếp theo nói chi tiết.

Tip thực tế: Nếu bạn thấy traffic distribution không đều giữa các ALB node (qua CloudWatch per-node metrics), đừng vội nghĩ ALB lỗi — hãy kiểm tra DNS caching behavior của client trước.

7. Load Balancing Algorithms — ALB Quyết Định Gửi Request Đến Target Nào?

Sau khi request đã đến một ALB node (qua cơ chế DNS ở section 6), node đó phải chọn target backend nào trong target group để forward. Đây mới là chỗ ALB có 3 thuật toán với triết lý và use case riêng. Bạn config thuật toán này ở target group level (không phải ở ALB level).

7.1. Round Robin — “Xoay Vòng” (Default)

Đây là thuật toán mặc định của ALB và cũng là dễ hiểu nhất.

Cách hoạt động:

Targets được xếp thành một vòng tròn. Request đầu tiên đi đến target #1, request tiếp theo đến #2, rồi #3… Hết vòng thì quay lại #1.

Ưu điểm:

• Đơn giản, dễ predict
• Phân phối đều khi tất cả request đều “tương tự nhau” (cùng độ phức tạp, cùng response time)
• Không cần ALB track state nhiều

Nhược điểm:

• Không quan tâm backend đang bận hay rảnh. Nếu target A đang xử lý 50 request “nặng” và target B đang rảnh, Round Robin vẫn cứ luân phiên gửi request mới cho A.
• Không phù hợp khi request có độ phức tạp không đồng đều (ví dụ: API endpoint mix giữa nhanh và chậm)

Dùng khi: Request đồng đều, backend đồng đều (cùng instance type, cùng workload). Đa số use case web app thông thường.

7.2. Least Outstanding Requests (LOR) — “Ai Rảnh Hơn Thì Làm”

Thuật toán này thông minh hơn: ALB đếm số request đang in-flight (đã gửi đi nhưng chưa nhận response) đến từng target, và chọn target nào có ít in-flight request nhất.

Cách hoạt động:

ALB maintain một counter cho mỗi target: tăng khi gửi request, giảm khi nhận response.

Ưu điểm:

• Tự cân bằng tải động dựa trên capacity thực tế của target. Target nào chậm → ít in-flight giảm chậm → ALB tự động gửi ít request hơn cho nó.
• Xử lý cực tốt khi request có độ phức tạp không đồng đều. Ví dụ: API GraphQL có query đơn giản (10ms) lẫn query phức tạp (2 giây) — LOR sẽ tự phân bổ hợp lý.
• Phù hợp khi target instances không đồng đều (mix giữa instance lớn và nhỏ trong target group)
• Hữu ích cho WebSocket hoặc long-lived connections — nơi một số connection có thể “ngốn” target lâu

Nhược điểm:

• ALB phải track in-flight count → tốn ít resource hơn round robin (nhưng không đáng kể)
• Không phù hợp khi dùng sticky session — vì sticky session sẽ override quyết định của LOR

Dùng khi: Request có response time biến thiên lớn (mix nhanh/chậm), API có nhiều endpoint khác nhau, microservices với workload không đồng đều.

7.3. Weighted Random với Anomaly Mitigation — “Xác Suất Có Trọng Số + Phát Hiện Bất Thường”

Đây là thuật toán mới nhất (AWS công bố cuối 2023). Tên dài nhưng ý tưởng có 2 phần:

Phần 1: Weighted Random

Thay vì chọn theo thứ tự (Round Robin) hay theo counter (LOR), ALB chọn target ngẫu nhiên có trọng số. Nếu mọi target có weight bằng nhau → giống random thuần. Nếu có weight khác nhau → target weight cao có xác suất được chọn cao hơn.

Phần 2: Anomaly Mitigation — Tự Phát Hiện Target “Lỗi Lén”

Đây là phần thực sự thú vị. ALB liên tục giám sát các target và phát hiện những target có hành vi “bất thường” so với phần còn lại của target group:

• Target có HTTP 5xx rate cao bất thường (nhưng chưa fail health check)
• Target có connection errors cao bất thường
• Target có response time dài bất thường

Khi phát hiện anomaly, ALB tự động giảm weight của target đó (gửi ít traffic hơn) mà không cần wait health check fail. Đây là một dạng circuit breaker tự động ở mức load balancer.

Ưu điểm:

• Bảo vệ end user khỏi các lỗi “lén lút” — target chưa hỏng hẳn (vẫn pass health check) nhưng đang trả về lỗi
• Tự động phục hồi khi target trở lại bình thường
• Đặc biệt hữu ích trong môi trường deployment liên tục — nếu một version mới có bug, ALB tự giảm traffic vào instance lỗi mà không cần can thiệp

Nhược điểm:

• Có thể “false positive” trong một số case (target đang xử lý request hợp pháp nhưng nặng → bị giảm traffic oan)
• Khó debug hơn — bạn thấy traffic distribution không đều và phải hiểu rằng ALB đang “punish” một target nào đó

Dùng khi: Production-critical workload cần resilience cao, môi trường có deploy liên tục, API service mà bạn muốn auto-detect bad deployments.

Bảng So Sánh Nhanh

Sticky Session Đứng Ở Đâu?

Sticky session (session affinity) không phải là một algorithm — nó là một lớp override đứng trên top của các algorithm trên. Cách hoạt động:

1. Request đầu tiên: ALB dùng algorithm (Round Robin / LOR / Weighted Random) chọn target X
2. ALB set cookie AWSALB trong response, encode target X
3. Request tiếp theo từ cùng client: ALB đọc cookie → forward thẳng đến target X (bỏ qua algorithm)

Điều này hữu ích cho stateful application (giỏ hàng, session-based auth không dùng JWT). Nhưng đánh đổi là mất tính cân bằng tải — nếu target X chết, client mới được route lại.

Tip: Nếu app của bạn stateless (dùng JWT, session lưu Redis), đừng bật sticky session — nó chỉ làm giảm hiệu quả load balancing.

Kết Luận — Checklist Cho Production

ALB không phải “một cái load balancer” — nó là một fleet các nodes tự động scale để đáp ứng traffic. Hiểu được kiến trúc bên dưới giúp bạn tránh nhiều lỗi production phổ biến.

Checklist khi deploy ALB:

• Subnet ALB dùng /27 trở lên, đảm bảo ít nhất 8 free IPs per AZ
• Không hardcode IP của ALB — luôn dùng DNS name hoặc Route 53 alias
• Set backend keep-alive lớn hơn ALB idle timeout (mặc định 60s) để tránh 502
• Dùng LCU Reservation trước các planned traffic events (Flash Sale, launch)
• Monitor SurgeQueueLength và SpilloverCount — nếu SpilloverCount > 0, backend đang quá tải
• Cần static IP? Đặt NLB trước ALB thay vì tìm cách gắn IP cho ALB
• Chọn đúng load balancing algorithm: workload đồng đều dùng Round Robin, không đồng đều dùng LOR, production-critical bật Weighted Random + Anomaly Mitigation