DevOps On AWS 03: Elastic Load Balancer - Cân bằng tải cho ứng dụng hiện đại

Chào mừng bạn đến với phần 3 của series "DevOps On AWS"! Sau khi đã tìm hiểu về AWS và IAM cũng như EC2 Elastic Compute Cloud, hôm nay chúng ta sẽ khám phá một thành phần cực kỳ quan trọng trong kiến trúc ứng dụng hiện đại: Load Balancer và cụ thể là AWS Elastic Load Balancer.

Bài viết này sẽ đưa bạn từ những khái niệm cơ bản về cân bằng tải, các thuật toán load balancing, đến việc hiểu rõ các loại Elastic Load Balancer trên AWS và cách áp dụng trong các tình huống thực tế.

1. Load Balancing - Tại sao cần cân bằng tải?

1.1. Vấn đề của kiến trúc một máy chủ đơn

Hãy tưởng tượng bạn có một ứng dụng web đang chạy trên một máy chủ duy nhất. Ban đầu, với vài trăm người dùng, mọi thứ hoạt động hoàn hảo. Nhưng khi ứng dụng của bạn trở nên phổ biến và lưu lượng truy cập tăng lên gấp 10 lần, bạn sẽ gặp phải những vấn đề sau:

Hiệu suất bị giới hạn:

• CPU và RAM của máy chủ sẽ bị quá tải
• Thời gian phản hồi tăng lên đáng kể
• Người dùng phải chờ đợi lâu hơn

Điểm lỗi đơn (Single Point of Failure):

• Nếu máy chủ gặp sự cố, toàn bộ ứng dụng ngừng hoạt động
• Bảo trì cần thời gian ngừng hoạt động
• Không có khả năng chịu lỗi

Không thể mở rộng:

• Mở rộng theo chiều dọc có giới hạn vật lý
• Chi phí tăng theo cấp số nhân
• Không linh hoạt trong việc điều chỉnh tài nguyên

1.2. Giải pháp: Mở rộng theo chiều ngang với Load Balancer

Load Balancer ra đời để giải quyết những vấn đề trên bằng cách:

Phân phối tải đều:

• Chia lưu lượng truy cập đến nhiều máy chủ phía sau
• Tối ưu hóa việc sử dụng tài nguyên
• Tăng thông lượng tổng thể của hệ thống

Tăng độ tin cậy:

• Nếu một máy chủ gặp sự cố, lưu lượng tự động chuyển sang máy chủ khác
• Kiểm tra sức khỏe liên tục để phát hiện sự cố sớm
• Bảo trì không cần thời gian ngừng hoạt động

Khả năng mở rộng linh hoạt:

• Dễ dàng thêm/bớt máy chủ phía sau
• Tự động mở rộng dựa trên các chỉ số
• Chi phí tối ưu theo nhu cầu thực tế

2. Kiến trúc cân bằng tải: Mở rộng dọc vs Mở rộng ngang

2.1. Mở rộng theo chiều dọc (Scale Up)

Mở rộng theo chiều dọc là việc nâng cấp phần cứng của máy chủ hiện tại để tăng khả năng xử lý.

Ưu điểm:

• Đơn giản trong triển khai và quản lý
• Không cần thay đổi kiến trúc ứng dụng
• Phù hợp với ứng dụng cũ

Nhược điểm:

• Có giới hạn về khả năng nâng cấp
• Chi phí tăng theo cấp số nhân
• Vẫn tồn tại điểm lỗi đơn
• Thời gian ngừng hoạt động trong quá trình nâng cấp

Ví dụ thực tế:

• Trước nâng cấp: t3.medium (2 vCPU, 4GB RAM) - $30/tháng
• Sau nâng cấp: c5.2xlarge (8 vCPU, 16GB RAM) - $250/tháng

2.2. Mở rộng theo chiều ngang (Scale Out)

Mở rộng theo chiều ngang là việc thêm nhiều máy chủ có cấu hình tương tự để xử lý tải.

Ưu điểm:

• Không có giới hạn về khả năng mở rộng
• Chi phí tuyến tính
• Khả năng chịu lỗi - một máy chủ lỗi không ảnh hưởng toàn hệ thống
• Mở rộng linh hoạt lên/xuống

Nhược điểm:

• Phức tạp hơn trong kiến trúc
• Cần bộ cân bằng tải
• Quản lý trạng thái phức tạp hơn
• Độ trễ mạng giữa các node

Ví dụ thực tế:

• 3x t3.medium instances: 3 × $30 = $90/tháng
• Tăng lên 5x instances khi cần: 5 × $30 = $150/tháng

2.3. So sánh chi tiết

3. Load Balancer vs API Gateway

3.1. Load Balancer

Mục đích chính: Phân phối lưu lượng truy cập vào các máy chủ phía sau

Hoạt động ở tầng:

• Tầng 4 (Transport): TCP/UDP - định tuyến dựa trên IP và cổng
• Tầng 7 (Application): HTTP/HTTPS - định tuyến dựa trên nội dung yêu cầu

Chức năng chính:

• Phân phối tải theo các thuật toán
• Kiểm tra sức khỏe
• Terminate SSL
• Duy trì phiên làm việc

3.2. API Gateway

Mục đích chính: Quản lý và điều phối các request API từ Client

Hoạt động ở tầng: Chỉ hoạt động ở Tầng 7 (Application)

Chức năng chính:

• Xác thực và phân quyền
• Giới hạn tần suất
• Biến đổi yêu cầu/phản hồi
• Quản lý phiên bản API
• Giám sát và phân tích

3.3. So sánh chi tiết

3.4. Khi nào sử dụng Load Balancer vs API Gateway?

Sử dụng Load Balancer khi:

• Cần phân phối lưu lượng đến nhiều services
• Tập trung vào hiệu suất và tính khả dụng
• Yêu cầu định tuyến đơn giản
• Lưu lượng TCP/UDP

Sử dụng API Gateway khi:

• Kiến trúc microservices
• Cần các tính năng quản lý API
• Xác thực/phân quyền phức tạp
• Quản lý phiên bản và biến đổi API

Sử dụng cả hai khi:

• Microservices quy mô lớn
• API Gateway ở phía trước cho quản lý API
• Load Balancer ở phía sau cho mỗi microservice

3.5. Kong Gateway trong hệ sinh thái

Nếu bạn đang tìm hiểu về giải pháp tự triển khai API Gateway ở tầng ứng dụng thay vì sử dụng dịch vụ quản lý của AWS, Kong Gateway là một lựa chọn mạnh mẽ và phổ biến. Kong kết hợp cả chức năng của Load Balancer và API Gateway trong một nền tảng thống nhất.

Tôi đã viết một bài chi tiết về Kong Gateway và cách triển khai trong môi trường microservices tại: API Gateway với Kong - Giải pháp toàn diện cho Microservices

Kong Gateway cung cấp:

• Cân bằng tải với nhiều thuật toán
• Tính năng quản lý API nâng cao
• Hệ sinh thái plugin phong phú (150+ plugin)
• Hiệu suất cao (xây dựng trên Nginx)

4. Các thuật toán Load Balancing

4.1. Round Robin

Cách hoạt động: Phân phối các yêu cầu tuần tự đến từng máy chủ theo thứ tự.

Ưu điểm:

• Đơn giản, dễ triển khai
• Phân phối đều các yêu cầu
• Không cần theo dõi trạng thái máy chủ

Nhược điểm:

• Không xem xét dung lượng máy chủ
• Có thể quá tải máy chủ yếu hơn

Ví dụ phân phối:

• Yêu cầu 1 → Máy chủ A
• Yêu cầu 2 → Máy chủ B
• Yêu cầu 3 → Máy chủ C
• Yêu cầu 4 → Máy chủ A (lặp lại)

Trường hợp sử dụng: Khi tất cả máy chủ có cấu hình tương đương

4.2. Weighted Round Robin

Cách hoạt động: Tương tự Round Robin nhưng có trọng số cho mỗi máy chủ.

Ví dụ cấu hình:

• Máy chủ A: Trọng số = 3
• Máy chủ B: Trọng số = 2
• Máy chủ C: Trọng số = 1

Phân phối lưu lượng:

• 3 yêu cầu đầu tiên → Máy chủ A
• 2 yêu cầu tiếp theo → Máy chủ B
• 1 yêu cầu cuối → Máy chủ C

Trường hợp sử dụng: Khi máy chủ có dung lượng khác nhau

4.3. Least Connections

Cách hoạt động: Gửi yêu cầu đến máy chủ có ít kết nối hoạt động nhất.

Ưu điểm:

• Tốt cho các kết nối dài hạn
• Tự động thích ứng với tải máy chủ
• Phân phối hiệu suất tốt hơn

Nhược điểm:

• Nếu req lên quá nhanh thì sẽ không đếm kịp connection dẫn đến quá tải service ít connection đó ngay lập tức
• Phức tạp hơn trong triển khai
• Cần theo dõi trạng thái kết nối

Trường hợp sử dụng: Kết nối WebSocket, kết nối cơ sở dữ liệu

4.4. Least Response Time

Cách hoạt động: Gửi yêu cầu đến máy chủ có thời gian phản hồi thấp nhất.

Chỉ số được theo dõi:

• Thời gian phản hồi trung bình
• Kết nối hoạt động hiện tại
• Trạng thái sức khỏe máy chủ

Thuật toán: Máy chủ tốt nhất = MIN(Thời gian phản hồi + Kết nối hoạt động)

Trường hợp sử dụng: Ứng dụng quan trọng về hiệu suất

4.5. IP Hash

Cách hoạt động: Sử dụng hash của IP ứng dụng khách để quyết định máy chủ.

Hàm hash: Máy chủ = hash(IP_Client) % số_lượng_máy_chủ

Ưu điểm:

• Duy trì phiên làm việc mà không cần sticky sessions
• Định tuyến xác định
• Triển khai đơn giản

Nhược điểm:

• Phân phối không đều nếu có NAT
• Khó thêm/bớt máy chủ

Trường hợp sử dụng: Ứng dụng dựa trên phiên làm việc không có lưu trữ chung

4.6. Thuật toán dựa trên Health Check

Kiểm tra sức khỏe chủ động:

• Bộ cân bằng tải chủ động ping đến endpoint để kiểm tra sức khỏe
• Endpoint kiểm tra sức khỏe HTTP (ví dụ: GET /health)
• Mong đợi phản hồi 200 OK với payload JSON

Kiểm tra sức khỏe thụ động:

• Giám sát lỗi yêu cầu thực tế
• Theo dõi mã phản hồi và thời gian chờ
• Tự động đánh dấu máy chủ không khỏe mạnh

5. AWS Elastic Load Balancer (ELB)

AWS cung cấp ba loại Elastic Load Balancer, mỗi loại phục vụ cho các trường hợp sử dụng khác nhau:

5.1. Application Load Balancer (ALB)

Hoạt động ở Layer 7 (Application)

Tính năng chính:

• Lưu lượng HTTP/HTTPS
• Định tuyến dựa trên đường dẫn và máy chủ
• Hỗ trợ WebSocket và HTTP/2
• Tích hợp với các dịch vụ AWS
• Định tuyến yêu cầu nâng cao

Ví dụ quy tắc định tuyến:

• api.example.com/users/* → Nhóm mục tiêu dịch vụ người dùng
• api.example.com/orders/* → Nhóm mục tiêu dịch vụ đơn hàng
• api.example.com/admin/* → Nhóm mục tiêu dịch vụ quản trị

Giá cả (us-east-1):

• $0.0225 mỗi giờ
• $0.008 mỗi LCU (Load Balancer Capacity Unit)

5.2. Network Load Balancer (NLB)

Hoạt động ở Layer 4 (Transport)

Tính năng chính:

• Lưu lượng TCP/UDP/TLS
• Hiệu suất cực cao (hàng triệu yêu cầu/giây)
• Địa chỉ IP tĩnh
• Bảo toàn IP nguồn
• Độ trễ thấp

Trường hợp sử dụng:

• Ứng dụng trò chơi
• Thiết bị IoT
• Nền tảng giao dịch tài chính
• Ứng dụng thời gian thực

Giá cả (us-east-1):

• $0.0225 mỗi giờ
• $0.006 mỗi NLCU (Network Load Balancer Capacity Unit)

5.3. Classic Load Balancer (CLB)

Bộ cân bằng tải cũ

Tính năng:

• Layer 4 và Layer 7
• Hỗ trợ EC2-Classic và VPC
• Cân bằng tải cơ bản

⚠️ Đã lỗi thời: AWS khuyến nghị chuyển sang ALB hoặc NLB

5.4. So sánh chi tiết các loại ELB

7. Các tình huống thực tế và mô hình giải pháp

7.1. Tình huống 1: Thương mại điện tử với đột biến lưu lượng

Bài toán:

• Website bán hàng với lưu lượng bình thường 1,000 yêu cầu/giây
• Trong các sự kiện sale có thể tăng lên 50,000 yêu cầu/giây
• Cần đảm bảo thời gian hoạt động 99.99%

Mô hình kiến trúc đề xuất:

CloudFront CDN (CDN) ↓
Application Load Balancer ↓
Auto Scaling Group ↓
RDS với Read Replicas + ElastiCache Redis

Thành phần chính:

• CloudFront CDN: Lưu cache nội dung tĩnh toàn cầu
• Application Load Balancer: Phân phối lưu lượng đều
• Auto Scaling Group: Tự động mở rộng dựa trên CPU/yêu cầu
• RDS Read Replicas: Mở rộng đọc cơ sở dữ liệu
• ElastiCache: Lưu cache dữ liệu truy cập thường xuyên

Chiến lược tự động mở rộng:

• Chính sách theo dõi mục tiêu dựa trên sử dụng CPU (70%)
• Mở rộng từ từ cho đột biến lưu lượng nhanh
• Mở rộng theo lịch cho các sự kiện có thể dự đoán

7.2. Tình huống 2: Microservices với nhiều môi trường

Bài toán:

• 15 microservices
• 3 môi trường: develop, staging,production
• Cần endpoint dựa trên dịch vụ và môi trường

Mô hình nhiều ALB:

Môi trường develop:
├── ALB develop
│ ├── api.prod.company.com/orders/* → Dịch vụ đơn hàng │ ├── api.prod.company.com/payments/* → Dịch vụ thanh toán
│ └── api.prod.company.com/notifications/* → Dịch vụ thông báo Môi trường Staging:
├── ALB Staging
│ ├── api.staging.company.com/users/* → Dịch vụ người dùng (Staging)
│ ├── api.staging.company.com/orders/* → Dịch vụ đơn hàng (Staging)
│ └── ...

Hạ tầng dưới dạng mã:

• Sử dụng Terraform để quản lý nhiều môi trường
• ALB riêng biệt cho mỗi môi trường
• Module chia sẻ để tái sử dụng
• Biến cụ thể cho môi trường

7.3. Tình huống 3: Ứng dụng trò chơi với lưu lượng UDP

Bài toán:

• Trò chơi nhiều người chơi thời gian thực
• Giao thức UDP cho dữ liệu trò chơi
• TCP cho sảnh/ghép cặp
• Cần bảo toàn IP ứng dụng khách

Mô hình Network Load Balancer:

Cổng Internet ↓
Network Load Balancer
├── UDP Listener (Cổng 7777) → Máy chủ trò chơi
└── TCP Listener (Cổng 8080) → Máy chủ sảnh

Đặc điểm:

• NLB bảo toàn IP nguồn cho hệ thống chống gian lận
• Độ trễ cực thấp cho trò chơi thời gian thực
• Địa chỉ IP tĩnh cho cấu hình ứng dụng khách
• Cân bằng tải cross-zone cho tính khả dụng cao

8. Chiến lược Health Checks và giám sát

8.1. Thực hành tốt nhất cấu hình Health Check

Thiết kế kiểm tra sức khỏe HTTP:

• Endpoint sức khỏe chuyên dụng (/health, /healthcheck)
• Kiểm tra các dependence downstream (cơ sở dữ liệu, cache, API ngoại)
• Trả về JSON có cấu trúc với trạng thái chi tiết
• Sử dụng mã trạng thái HTTP phù hợp (200, 503)

Ví dụ điểm cuối Health Check nâng cao:

• Kiểm tra kết nối cơ sở dữ liệu
• Xác minh tính khả dụng của Redis/cache
• Xác thực khả năng truy cập API ngoại
• Giám sát dung lượng đĩa và sử dụng bộ nhớ
• Trả về phiên bản dịch vụ và thời gian hoạt động

8.2. CloudWatch Metrics và giám sát

Chỉ số chính cần giám sát:

• RequestCount: Tổng số yêu cầu
• TargetResponseTime: Thời gian phản hồi trung bình từ mục tiêu
• HTTPCode_Target_2XX_Count: Phản hồi thành công
• HTTPCode_Target_5XX_Count: Lỗi máy chủ
• HealthyHostCount/UnHealthyHostCount: Trạng thái sức khỏe mục tiêu
• TargetConnectionErrorCount: Lỗi kết nối

Thiết lập cảnh báo CloudWatch:

• Cảnh báo thời gian phản hồi cao (> 2 giây)
• Cảnh báo mục tiêu không khỏe mạnh (> 0 mục tiêu không khỏe)
• Cảnh báo tỷ lệ lỗi cao (lỗi 5XX > 5%)
• Cảnh báo số lượng máy chủ khỏe mạnh thấp

8.3. Phân tích Access Logs

Bật Access Logs của ALB:

• Lưu trữ nhật ký trong S3 bucket
• Sử dụng chính sách vòng đời cho tối ưu chi phí
• Định dạng nhật ký có cấu trúc cho phân tích

Phân tích nhật ký với AWS Athena:

• Truy vấn các yêu cầu chậm (thời gian phản hồi > 5 giây)
• Phân tích mẫu lưu lượng theo giờ/ngày
• Xác định user agent và địa chỉ IP hàng đầu
• Giám sát phân phối địa lý của các yêu cầu

9. Thực hành tốt nhất về bảo mật

Security Group của ALB:

• Cho phép HTTP (cổng 80) và HTTPS (cổng 443) từ Internet (0.0.0.0/0)
• Cho phép lưu lượng kiểm tra sức khỏe
• Từ chối tất cả lưu lượng đến khác

Security Group của mục tiêu:

• Chỉ cho phép lưu lượng từ security group của ALB
• Chỉ định cổng chính xác (80, 8080, v.v.)
• Không truy cập Internet trực tiếp
• Cho phép lưu lượng đi cho các API ngoại

10. Chiến lược tối ưu chi phí

10.1. Hiểu mô hình giá ALB

Thành phần giá ALB:

• Chi phí cố định: $0.0225 mỗi giờ = $16.20 mỗi tháng
• Chi phí biến đổi: $0.008 mỗi LCU

Yếu tố tính toán LCU:

• Kết nối mới: 25 kết nối/giây mỗi LCU
• Kết nối hoạt động: 3,000 kết nối/phút mỗi LCU
• Băng thông: 1 GB/giờ cho mục tiêu EC2 mỗi LCU
• Đánh giá quy tắc: 1,000 đánh giá/giây mỗi LCU

Ví dụ tính toán chi phí: Tình huống: Website thương mại điện tử

• 100 kết nối mới/giây = 4 LCU
• 10,000 kết nối hoạt động/phút = 3.33 LCU
• 500 MB/giờ băng thông = 0.5 LCU
• 2,000 đánh giá quy tắc/giây = 2 LCU

Chiều cao nhất: 4 LCU Chi phí hàng tháng: $16.20 + (4 × $0.008 × 24 × 30) = $39.24

10.2. Kỹ thuật tối ưu

1. Điều chỉnh kích thước Target Groups:

• Sử dụng phiên bản nhỏ hơn với Auto Scaling
• Thay vì: 4x phiên bản c5.2xlarge ($1,000/tháng)
• Dùng: 8x phiên bản c5.large với Auto Scaling ($520/tháng - tiết kiệm 48%)

2. Chiến lược Reserved Instances:

• Mua RI cho dung lượng cơ sở
• Sử dụng On-Demand cho lưu lượng cao điểm
• Kết hợp điều khoản 1 năm và 3 năm

3. Tích hợp Spot Instances:

• Các loại phiên bản hỗn hợp trong Auto Scaling Group
• 30% On-Demand cho cơ sở
• 70% Spot Instances cho dung lượng bổ sung
• Chiến lược phân bổ đa dạng

Kết luận

Elastic Load Balancer là xương sống của kiến trúc cloud hiện đại trên AWS. Qua bài viết này, chúng ta đã khám phá:

🎯 Kiến thức cốt lõi:

• Khái niệm Load Balancing và sự cần thiết trong mở rộng theo chiều ngang
• Sự khác biệt Tầng 4 vs Tầng 7 trong cân bằng tải
• Thuật toán cân bằng tải và các trường hợp sử dụng phù hợp
• So sánh Load Balancer vs API Gateway

⚙️ Tìm hiểu sâu AWS ELB:

• Application Load Balancer (ALB) cho HTTP/HTTPS với định tuyến nâng cao
• Network Load Balancer (NLB) cho hiệu suất cực cao TCP/UDP
• Mẫu triển khai thực tế và quyết định kiến trúc
• Chiến lược Health checks và giám sát

💼 Ứng dụng kinh doanh:

• Kỹ thuật tối ưu chi phí và hiểu biết về giá cả
• Thực hành tốt nhất về bảo mật với WAF và Security Groups
• Nhiều tình huống thực tế từ thương mại điện tử đến trò chơi

Xem nhiều hơn bài viết của tôi tại đây nhé: codeeasy.blog

Tags: #AWS #DevOps #LoadBalancer #ELB #CloudArchitecture #Infrastructure