Chương 05: ELB & Auto Scaling

Tổng Quan

Elastic Load Balancing (ELB) phân phối traffic đến nhiều targets. Auto Scaling tự động tăng/giảm số lượng EC2 instances theo nhu cầu. Hai dịch vụ này kết hợp tạo nên kiến trúc High Availability + Scalable.

1. Elastic Load Balancer (ELB)

1.1 Tại sao cần Load Balancer?

Phân phối traffic đều đến nhiều servers.
Phát hiện instance lỗi → ngừng gửi traffic đến instance đó.
Cung cấp 1 DNS endpoint duy nhất cho ứng dụng.
Terminate SSL/TLS tại LB (giảm tải cho backend).

1.2 Các loại Load Balancer

Loại	Layer	Protocol	Use case
ALB (Application LB)	Layer 7	HTTP, HTTPS, WebSocket	Web apps, microservices, container-based
NLB (Network LB)	Layer 4	TCP, UDP, TLS	Ultra-low latency, gaming, IoT, millions req/s
GLB (Gateway LB)	Layer 3	IP Protocol	3rd-party virtual appliances (firewall, IDS)

Classic Load Balancer (CLB) là thế hệ cũ → không dùng nữa, nhưng có thể xuất hiện trong đề thi.

1.3 ALB (Application Load Balancer) - Chi tiết

Tính năng chính:

Routing dựa trên: URL path (/users vs /orders), hostname (api.example.com), query string, HTTP headers.
Hỗ trợ Target Groups: EC2 instances, ECS tasks, Lambda functions, private IP addresses.
Fixed Response và Redirect rules.
Cung cấp IP không cố định → dùng DNS name.

                    ┌─ Target Group 1 (EC2 instances)
Client → ALB ──────┤  Rule: path = /api/*
                    │
                    └─ Target Group 2 (Lambda)
                       Rule: path = /webhook

1.4 NLB (Network Load Balancer) - Chi tiết

Xử lý hàng triệu requests/giây với latency cực thấp (~100ms vs ~400ms ALB).
Có 1 static IP per AZ (hoặc gán Elastic IP).
Dùng khi cần: static IP, extreme performance, TCP/UDP protocol.

1.5 Các Khái Niệm Quan Trọng

Sticky Sessions (Session Affinity):

Đảm bảo user luôn được gửi đến cùng 1 instance.
Dùng cookie (Application-based hoặc Duration-based).
Nhược điểm: Có thể gây mất cân bằng tải.

Cross-Zone Load Balancing:

Bật: Traffic được phân phối đều cho tất cả instances ở mọi AZ.
Tắt: Traffic chỉ phân phối trong AZ mà LB node nằm.
ALB: Bật mặc định (miễn phí). NLB: Tắt mặc định (tính phí nếu bật).

Connection Draining (Deregistration Delay):

Khi 1 instance bị đánh dấu unhealthy → LB chờ hoàn thành requests đang xử lý (mặc định 300 giây) trước khi ngừng gửi traffic.

SSL/TLS Termination:

LB có thể terminate SSL → backend nhận traffic HTTP (giảm tải CPU).
Dùng AWS Certificate Manager (ACM) để quản lý SSL certificates.
SNI (Server Name Indication): Cho phép 1 LB sử dụng nhiều SSL certificates cho nhiều domains.

2. Auto Scaling Group (ASG)

2.1 ASG là gì?

Tự động tăng (scale out) hoặc giảm (scale in) số lượng EC2 instances.
Đảm bảo luôn có minimum instances chạy.
Tích hợp với ELB: tự đăng ký/gỡ instances khỏi Target Group.

2.2 Cấu hình ASG

Tham số	Ý nghĩa
Minimum Capacity	Số instances tối thiểu phải chạy
Desired Capacity	Số instances mong muốn hiện tại
Maximum Capacity	Số instances tối đa được phép

2.3 Launch Template

Định nghĩa cấu hình EC2 cho ASG: AMI, instance type, key pair, security groups, user data, IAM role.
Thay thế Launch Configuration (cũ, không khuyến khích).

2.4 Scaling Policies

Policy	Cách hoạt động	Ví dụ
Target Tracking	Giữ metric ở mức mục tiêu	CPU trung bình = 50%
Step Scaling	Thêm/bớt instances theo mức alarm	CPU >70%: +2 instances, CPU >90%: +4
Simple Scaling	Thêm/bớt 1 lượng cố định	CPU >70%: +1 instance, đợi cooldown
Scheduled	Scale theo lịch trình	8AM: min=10, 10PM: min=2
Predictive	ML dự đoán traffic tương lai	Dựa trên lịch sử traffic

💡 Best Practice: Dùng Target Tracking là lựa chọn đầu tiên (đơn giản, hiệu quả).

2.5 Scaling Cooldown

Sau mỗi scaling activity, ASG chờ (mặc định 300 giây) trước khi scale tiếp.
Tránh tình trạng thêm/bớt instances liên tục.

2.6 Health Checks

EC2 Health Check: Kiểm tra trạng thái EC2 (running/stopped).
ELB Health Check: Kiểm tra response HTTP từ ứng dụng (khuyến khích dùng).
Instance unhealthy → ASG sẽ terminate và thay thế bằng instance mới.

3. Kiến Trúc High Availability Điển Hình

                    Internet
                       │
                 ┌─────┴─────┐
                 │    ALB    │ (Multi-AZ)
                 └─────┬─────┘
            ┌──────────┼──────────┐
            ▼          ▼          ▼
    ┌──────────┐ ┌──────────┐ ┌──────────┐
    │   EC2    │ │   EC2    │ │   EC2    │
    │  (AZ-a) │ │  (AZ-b) │ │  (AZ-c) │
    └──────────┘ └──────────┘ └──────────┘
         │              │           │
         └──────────────┼───────────┘
                        ▼
                 ┌──────────┐
                 │ RDS (AZ-a)│──Multi-AZ──▶ Standby (AZ-b)
                 └──────────┘

Exam Tips 💡

ALB = HTTP/HTTPS (Layer 7). NLB = TCP/UDP (Layer 4). Câu hỏi nói "routing based on URL path" → ALB.
Cần static IP → NLB (ALB không có static IP).
Target Tracking là scaling policy được khuyến khích nhất.
Cross-Zone LB đảm bảo traffic đều giữa các AZ.
SNI cho phép multiple SSL certs trên 1 ALB/NLB.
ASG + ALB = combo HA + Scalability chuẩn mực.

Câu Hỏi Ôn Tập 📝

Câu 1: Ứng dụng web cần routing: /api/* đến App servers, /static/* đến S3 qua Lambda. Dùng LB nào?

Xem đáp án

ALB — Hỗ trợ path-based routing (Layer 7) và target groups cho cả EC2 lẫn Lambda.

Câu 2: Ứng dụng gaming cần latency cực thấp, xử lý triệu kết nối TCP. Cần static IP cho whitelist firewall. Dùng LB nào?

Xem đáp án

NLB — Layer 4, ultra-low latency, hỗ trợ static IP per AZ.

Câu 3: Bạn muốn ASG giữ CPU trung bình ở mức 60%. Dùng scaling policy nào?

Xem đáp án

Target Tracking Scaling Policy với target value = 60% cho metric CPUUtilization.

⬅️ Chương 04: EC2 & Compute | Chương 06: S3 & Storage ➡️

← Chương trước EC2 & Compute Chương tiếp →S3 & Storage