High Availability & Scalability – ELB và Auto Scaling Group

1. Scalability và High Availability

Scalability (khả năng mở rộng) nghĩa là ứng dụng hoặc hệ thống của bạn có thể chịu được tải lớn hơn bằng cách “thích nghi” — tăng thêm sức mạnh hoặc tăng thêm số lượng máy. Đây là một trong những lý do cốt lõi khiến người ta chuyển lên cloud: trên hạ tầng truyền thống, muốn phục vụ nhiều người dùng hơn thì phải mua máy mới, chờ hàng về, cắm vào rack; trên cloud bạn làm việc đó trong vài phút.

Có hai kiểu scalability, và bạn phải phân biệt được chúng vì đề thi hỏi rất nhiều:

Vertical Scalability — tăng kích thước của instance.
Horizontal Scalability (còn gọi là elasticity) — tăng số lượng instance.

Scalability có liên quan tới High Availability (tính sẵn sàng cao) nhưng không phải là một thứ. Một cách dễ hình dung là nghĩ về một tổng đài điện thoại (call center): bạn có thể thay một nhân viên mới vào nghề bằng một nhân viên lâu năm xử lý nhanh hơn (vertical), hoặc bạn tuyển thêm nhiều nhân viên cùng lúc (horizontal), hoặc bạn mở thêm một tổng đài ở thành phố khác để nếu tổng đài này mất điện thì vẫn còn tổng đài kia (high availability).

Vertical Scalability

Vertical scaling là tăng kích thước của instance. Ví dụ: ứng dụng của bạn đang chạy trên một t2.micro; scale vertically nghĩa là chuyển nó sang chạy trên t2.large.

Rất phổ biến với các hệ thống không phân tán (non distributed), ví dụ một database.
RDS và ElastiCache là hai dịch vụ có thể scale theo chiều dọc.
Luôn có một giới hạn cho việc scale dọc, vì cuối cùng bạn vẫn bị chặn bởi giới hạn phần cứng.

Horizontal Scalability

Horizontal scaling là tăng số lượng instance / hệ thống phục vụ ứng dụng. Điều này hàm ý ứng dụng của bạn phải là một hệ thống phân tán (distributed system) — nhiều máy cùng làm một việc.

Rất phổ biến với web application và các ứng dụng hiện đại.
Nhờ các dịch vụ cloud như Amazon EC2, việc scale ngang trở nên dễ dàng: chỉ cần bật thêm máy.

High Availability

High Availability thường đi đôi với horizontal scaling. Nó nghĩa là chạy ứng dụng của bạn ở ít nhất 2 trung tâm dữ liệu — trên AWS thì chính là 2 Availability Zone. Mục tiêu duy nhất: sống sót khi mất một data center.

High availability có thể ở dạng passive (thụ động) — ví dụ RDS Multi AZ, máy standby ngồi chờ, không nhận traffic.
High availability có thể ở dạng active (chủ động) — đúng với mô hình horizontal scaling, mọi máy đều đang phục vụ.

Hãy hình dung: “tòa nhà thứ nhất ở New York, tòa nhà thứ hai ở San Francisco” — nếu New York mất điện, hệ thống vẫn chạy.

Áp dụng cho EC2

Mục tiêu	Cách làm với EC2
Vertical Scaling (scale up / down)	Tăng instance size — từ `t2.nano` (0.5 GB RAM, 1 vCPU) đến `u-12tb1.metal` (12.3 TB RAM, 448 vCPU)
Horizontal Scaling (scale out / in)	Tăng số lượng instance — dùng Auto Scaling Group và Load Balancer
High Availability	Chạy instance của cùng một ứng dụng trên nhiều AZ — Auto Scaling Group multi AZ, Load Balancer multi AZ

2. Load balancing là gì?

Load balancer (bộ cân bằng tải) là những server đứng ở giữa, nhận traffic từ người dùng rồi chuyển tiếp xuống nhiều server phía sau (ví dụ nhiều EC2 instance). Người dùng chỉ biết một địa chỉ duy nhất là load balancer; việc chọn máy nào để xử lý là chuyện của load balancer.

Vì sao nên dùng load balancer? Slide liệt kê những lý do sau:

Phân tán tải ra nhiều instance phía dưới.
Cung cấp một điểm truy cập duy nhất (DNS) cho ứng dụng của bạn.
Xử lý mượt mà các sự cố của instance phía dưới — một máy chết thì traffic tự đi sang máy khác.
Thực hiện health check định kỳ tới các instance.
Cung cấp SSL termination (HTTPS) cho website.
Áp dụng stickiness bằng cookie.
High availability giữa các zone.
Tách biệt traffic public với traffic private.

Vì sao chọn Elastic Load Balancer?

Elastic Load Balancer (ELB) là load balancer được AWS quản lý (managed). Bạn có thể tự dựng load balancer riêng (chạy HAProxy, Nginx trên EC2 chẳng hạn) và tốn ít tiền hơn, nhưng đổi lại là rất nhiều công sức của chính bạn.

AWS bảo đảm nó hoạt động.
AWS lo nâng cấp, bảo trì, high availability.
AWS chỉ cho bạn một vài nút cấu hình — đơn giản nhưng ít tùy biến.
Nó được tích hợp với rất nhiều dịch vụ AWS khác: EC2, EC2 Auto Scaling Group, Amazon ECS, AWS Certificate Manager (ACM), CloudWatch, Route 53, AWS WAF, AWS Global Accelerator.

Health Check

Health check là thứ cực kỳ quan trọng với load balancer: nhờ nó mà load balancer biết instance nào còn sống để nhận request.

Health check được thực hiện trên một port và một route — /health là đường dẫn phổ biến nhất.
Nếu phản hồi không phải 200 (OK) thì instance bị coi là unhealthy và load balancer ngừng gửi traffic tới.

Ví dụ một cấu hình health check điển hình:

Protocol: HTTP
Port: 4567
Endpoint: /health

Security Group cho Load Balancer

Mô hình bảo mật kinh điển với ELB là hai tầng Security Group:

Security Group của Load Balancer: cho phép HTTP/HTTPS từ bất kỳ đâu (người dùng Internet).
Security Group của ứng dụng (EC2): chỉ cho phép HTTP từ Security Group của Load Balancer — nghĩa là không ai có thể gọi trực tiếp vào EC2, mọi traffic buộc phải đi qua load balancer.

3. Bốn loại Load Balancer trên AWS

AWS có 4 loại managed Load Balancer. Nhìn chung nên dùng thế hệ mới vì nhiều tính năng hơn. Một số load balancer có thể dựng ở dạng internal (private) hoặc external (public).

Loại	Năm	Viết tắt	Giao thức hỗ trợ
Classic Load Balancer (v1 – thế hệ cũ)	2009	CLB	HTTP, HTTPS, TCP, SSL (secure TCP)
Application Load Balancer (v2 – thế hệ mới)	2016	ALB	HTTP, HTTPS, WebSocket
Network Load Balancer (v2 – thế hệ mới)	2017	NLB	TCP, TLS (secure TCP), UDP
Gateway Load Balancer	2020	GWLB	Hoạt động ở layer 3 (Network layer) – IP Protocol

Classic Load Balancer (v1)

CLB là thế hệ đầu tiên, giờ đã cũ:

Hỗ trợ TCP (Layer 4), HTTP & HTTPS (Layer 7).
Health check dựa trên TCP hoặc HTTP.
Có hostname cố định: XXX.region.elb.amazonaws.com.

Luồng đi của request là: Client → listener của CLB → (internal) → EC2.

Application Load Balancer (v2)

ALB hoạt động ở Layer 7 (HTTP) — nghĩa là nó “đọc hiểu” được nội dung HTTP của request và có thể ra quyết định dựa trên đó. Đây là loại load balancer bạn sẽ dùng cho hầu hết web application.

Cân bằng tải tới nhiều ứng dụng HTTP trên nhiều máy (qua target group).
Cân bằng tải tới nhiều ứng dụng trên cùng một máy (ví dụ các container).
Hỗ trợ HTTP/2 và WebSocket.
Hỗ trợ redirect (ví dụ từ HTTP sang HTTPS).

Điểm mạnh nhất của ALB là routing table trỏ tới các target group khác nhau:

Routing theo path trong URL — example.com/users và example.com/posts.
Routing theo hostname trong URL — one.example.com và other.example.com.
Routing theo Query String, Headers — example.com/users?id=123&order=false.

Vì thế ALB rất phù hợp với micro service và ứng dụng container (ví dụ Docker & Amazon ECS). Nó còn có tính năng port mapping để chuyển tiếp tới một port động trong ECS. Nếu dùng Classic Load Balancer thay thế, bạn sẽ cần nhiều CLB, mỗi ứng dụng một cái — tốn kém và khó quản lý hơn nhiều.

Target group của ALB có thể là:

EC2 instance (có thể được quản lý bởi một Auto Scaling Group) – qua HTTP.
ECS task (do chính ECS quản lý) – qua HTTP.
Lambda function – request HTTP được dịch thành một event JSON.
IP Address – bắt buộc phải là private IP.

Một ALB có thể route tới nhiều target group, và health check nằm ở cấp target group.

Ví dụ điển hình: một External ALB nhận traffic HTTP từ web, route /user sang “Target Group for Users application” và route /search sang “Target Group for Search application”, mỗi target group có health check riêng. Với query string routing, bạn có thể cho ?Platform=Mobile đi vào Target Group 1 (EC2 trên AWS) còn ?Platform=Desktop đi vào Target Group 2 (máy on-premises, routing theo private IP).

Những điều cần biết về ALB:

Có hostname cố định: XXX.region.elb.amazonaws.com.
Các application server không thấy trực tiếp IP của client, vì ALB thực hiện connection termination — server chỉ thấy private IP của load balancer.
IP thật của client được chèn vào header X-Forwarded-For. Ngoài ra còn có X-Forwarded-Port (port) và X-Forwarded-Proto (protocol).

Network Load Balancer (v2)

NLB hoạt động ở Layer 4, nghĩa là nó chỉ quan tâm tới TCP/UDP chứ không đọc nội dung HTTP. Đổi lại, nó cực nhanh.

Chuyển tiếp traffic TCP & UDP tới instance của bạn.
Xử lý được hàng triệu request mỗi giây.
Độ trễ cực thấp (ultra-low latency).
NLB có một static IP cho mỗi AZ, và hỗ trợ gán Elastic IP — rất hữu ích khi khách hàng của bạn cần whitelist một IP cụ thể.
NLB được dùng khi cần hiệu năng cực cao, hoặc khi traffic là TCP / UDP.

Target group của NLB:

EC2 instance.
IP Address – bắt buộc là private IP.
Application Load Balancer (NLB có thể đứng trước một ALB).
Health check hỗ trợ giao thức TCP, HTTP và HTTPS.

Gateway Load Balancer

GWLB là loại đặc biệt nhất, dùng để triển khai, scale và quản lý một đội (fleet) các thiết bị ảo mạng của hãng thứ ba trên AWS — ví dụ firewall, hệ thống phát hiện & ngăn chặn xâm nhập (Intrusion Detection and Prevention Systems), hệ thống Deep Packet Inspection, các thiết bị thao tác payload…

Hoạt động ở Layer 3 (Network Layer) – làm việc với IP packet.
Nó kết hợp hai chức năng trong một:
- Transparent Network Gateway — một điểm vào/ra duy nhất cho toàn bộ traffic.
- Load Balancer — phân tán traffic tới các virtual appliance của bạn.
Dùng giao thức GENEVE trên port 6081.

Luồng traffic là: Users (source) → Gateway Load Balancer → target group gồm các 3rd Party Security Virtual Appliances → quay lại GWLB → Application (destination); việc chuyển hướng traffic vào GWLB được cấu hình qua Route Table.

Target group của GWLB chỉ gồm: EC2 instance và IP Address (bắt buộc private IP).

4. Các tính năng chung của ELB

Sticky Sessions (Session Affinity)

Bình thường load balancer gửi mỗi request tới một máy bất kỳ. Stickiness cho phép ép cùng một client luôn được chuyển tới cùng một instance phía sau load balancer.

Hoạt động với Classic Load Balancer, Application Load Balancer và Network Load Balancer.
Với CLB & ALB, cookie dùng cho stickiness có thời hạn (expiration date) do bạn kiểm soát.
Use case: đảm bảo người dùng không bị mất dữ liệu session.
Nhược điểm: bật stickiness có thể gây mất cân bằng tải giữa các EC2 instance phía sau.

Có hai nhóm cookie phục vụ stickiness:

Nhóm cookie	Ai sinh ra	Tên cookie	Ghi chú
Application-based – Custom cookie	Do target sinh ra	Bạn tự đặt tên	Có thể chứa bất kỳ attribute nào ứng dụng cần; tên cookie phải khai báo riêng cho từng target group; không được dùng `AWSALB`, `AWSALBAPP`, `AWSALBTG` (ELB giữ riêng)
Application-based – Application cookie	Do load balancer sinh ra	`AWSALBAPP`
Duration-based	Do load balancer sinh ra	`AWSALB` cho ALB, `AWSELB` cho CLB

Cross-Zone Load Balancing

Đây là một chi tiết rất hay bị hỏi. Hãy hình dung bạn có 2 EC2 ở AZ 1 và 8 EC2 ở AZ 2, và ELB có một node ở mỗi AZ. Traffic tới hai node được chia đều 50 / 50.

Không bật Cross-Zone Load Balancing: request chỉ được chia cho các instance thuộc node ELB của AZ đó. Kết quả: 2 máy ở AZ 1 mỗi máy nhận 25, còn 8 máy ở AZ 2 mỗi máy chỉ nhận 6.25 — rất lệch.
Bật Cross-Zone Load Balancing: mỗi node ELB phân phối đều cho tất cả instance đã đăng ký ở mọi AZ. Kết quả: cả 10 máy đều nhận 10.

Mặc định và chi phí khác nhau theo từng loại load balancer:

Load Balancer	Mặc định	Phí dữ liệu giữa các AZ
Application Load Balancer	Bật (có thể tắt ở cấp Target Group)	Không tính phí inter-AZ
Network Load Balancer & Gateway Load Balancer	Tắt	Có tính phí ($) dữ liệu inter-AZ nếu bật
Classic Load Balancer	Tắt	Không tính phí inter-AZ nếu bật

SSL/TLS và certificate

SSL certificate cho phép traffic giữa client và load balancer được mã hóa trên đường truyền (in-flight encryption).

SSL viết tắt của Secure Sockets Layer, dùng để mã hóa kết nối.
TLS viết tắt của Transport Layer Security, là phiên bản mới hơn. Ngày nay người ta chủ yếu dùng certificate TLS nhưng vẫn quen gọi là “SSL”.
Public SSL certificate được cấp bởi các Certificate Authority (CA): Comodo, Symantec, GoDaddy, GlobalSign, Digicert, Letsencrypt…
Certificate có ngày hết hạn (do bạn đặt) và phải được gia hạn.

Với load balancer:

Load balancer dùng certificate X.509 (SSL/TLS server certificate).
Bạn có thể quản lý certificate bằng ACM (AWS Certificate Manager), hoặc tự upload certificate của mình.
Với HTTPS listener: bạn phải chỉ định một default certificate, và có thể thêm một danh sách certificate tùy chọn để phục vụ nhiều domain. Client dùng SNI (Server Name Indication) để cho biết hostname nó muốn truy cập. Bạn cũng có thể chỉ định một security policy để hỗ trợ các phiên bản SSL/TLS cũ (cho legacy client).

Mô hình thường gặp: người dùng → HTTPS (đã mã hóa) qua Internet → LOAD BALANCER → HTTP trong private VPC → EC2 instance.

Server Name Indication (SNI)

SNI giải quyết bài toán: làm sao nạp nhiều SSL certificate lên cùng một web server để phục vụ nhiều website khác nhau.

Đây là một giao thức “mới hơn”, và nó yêu cầu client phải khai báo hostname của server đích ngay trong bước SSL handshake đầu tiên.
Server sau đó tìm certificate đúng, hoặc trả về certificate default.
Chỉ hoạt động với ALB & NLB (thế hệ mới) và CloudFront.
Không hoạt động với CLB (thế hệ cũ).

Tổng hợp khả năng chứa certificate của từng ELB:

Load Balancer	Số SSL certificate
Classic Load Balancer (v1)	Chỉ một certificate — muốn nhiều hostname với nhiều certificate thì phải dựng nhiều CLB
Application Load Balancer (v2)	Nhiều listener với nhiều certificate, hoạt động nhờ SNI
Network Load Balancer (v2)	Nhiều listener với nhiều certificate, hoạt động nhờ SNI

Connection Draining

Khi một instance đang bị de-register (rút khỏi load balancer) hoặc bị đánh dấu unhealthy, những request đang xử lý dở dang (“in-flight requests”) cần thời gian để hoàn tất. Tính năng này chính là để chờ chúng xong.

Tên gọi khác nhau theo loại ELB: Connection Draining cho CLB, Deregistration Delay cho ALB & NLB.
Trong thời gian đó, ELB ngừng gửi request mới tới instance đang de-register, nhưng chờ các kết nối hiện có hoàn tất; các kết nối mới được thiết lập tới toàn bộ instance còn lại.
Giá trị từ 1 đến 3600 giây, mặc định 300 giây.
Có thể tắt bằng cách đặt giá trị 0.
Nếu request của bạn ngắn, hãy đặt giá trị thấp để instance rút ra nhanh.

5. Auto Scaling Group (ASG)

Trong thực tế, tải trên website và ứng dụng của bạn thay đổi liên tục. Trên cloud, bạn có thể tạo và hủy server rất nhanh — và Auto Scaling Group chính là thứ tự động làm việc đó thay bạn.

Mục tiêu của một ASG:

Scale out (thêm EC2 instance) khi tải tăng.
Scale in (bớt EC2 instance) khi tải giảm.
Đảm bảo luôn có số lượng instance tối thiểu và tối đa đang chạy.
Tự động đăng ký instance mới vào load balancer.
Tạo lại một EC2 instance nếu instance trước đó bị terminate (ví dụ vì unhealthy).
ASG miễn phí — bạn chỉ trả tiền cho các EC2 instance bên dưới.

Một ASG được định nghĩa bởi ba con số: Minimum Capacity, Desired Capacity và Maximum Capacity; nó scale out trong khoảng đó tùy nhu cầu. Khi kết hợp với một Elastic Load Balancer, ELB còn có thể kiểm tra health của các EC2 instance trong ASG, và instance nào unhealthy sẽ được thay thế.

Các thuộc tính của một ASG

Trái tim của ASG là một Launch Template (các “Launch Configuration” cũ đã bị deprecated). Launch Template mô tả instance mới sẽ được tạo ra như thế nào:

AMI + Instance Type
EC2 User Data
EBS Volumes
Security Groups
SSH Key Pair
IAM Roles cho EC2 instance

Những thứ sau không nằm trong Launch Template mà nằm ở chính ASG:

Thông tin Network + Subnets
Thông tin Load Balancer
Min Size / Max Size / Initial Capacity
Scaling Policies

CloudWatch Alarm và scaling

Bạn có thể scale một ASG dựa trên CloudWatch alarm:

Một alarm theo dõi một metric (ví dụ Average CPU, hoặc một custom metric).
Các metric như Average CPU được tính trên toàn bộ instance của ASG, không phải từng máy riêng lẻ.
Dựa trên alarm đó, bạn tạo scale-out policy (tăng số instance) và scale-in policy (giảm số instance).

Các Scaling Policy

Nhóm	Policy	Cách hoạt động
Dynamic Scaling	Target Tracking Scaling	Đơn giản nhất để thiết lập. Ví dụ: “tôi muốn CPU trung bình của ASG luôn ở khoảng 40%”
Dynamic Scaling	Simple / Step Scaling	Khi một CloudWatch alarm kích hoạt (ví dụ CPU > 70%) thì thêm 2 unit; khi alarm khác kích hoạt (ví dụ CPU < 30%) thì bớt 1 unit
—	Scheduled Scaling	Dự đoán trước theo các mẫu sử dụng đã biết. Ví dụ: tăng min capacity lên 10 vào 5 giờ chiều thứ Sáu
—	Predictive Scaling	Liên tục dự báo tải và lên lịch scaling trước khi tải tới

Nên scale theo metric nào?

Chọn sai metric thì ASG sẽ phản ứng sai. Slide gợi ý bốn lựa chọn tốt:

CPUUtilization — CPU trung bình trên toàn bộ instance của bạn.
RequestCountPerTarget — để đảm bảo số request trên mỗi EC2 instance giữ ổn định. Ví dụ đặt Target Value là 3 request trên mỗi target.
Average Network In / Out — nếu ứng dụng của bạn bị nghẽn ở mạng (network bound).
Bất kỳ custom metric nào mà bạn tự push lên CloudWatch.

Scaling Cooldown

Sau mỗi lần scaling xảy ra, ASG bước vào cooldown period (mặc định 300 giây).

Trong thời gian cooldown, ASG sẽ không launch hay terminate thêm instance nào — để các metric có thời gian ổn định trở lại.
Logic là: có scaling action xảy ra → nếu default cooldown đang có hiệu lực thì bỏ qua action; nếu không thì launch hoặc terminate instance.
Lời khuyên: dùng một AMI đã cài sẵn mọi thứ (ready-to-use AMI) để giảm thời gian cấu hình, nhờ đó instance mới phục vụ request nhanh hơn và bạn có thể giảm cooldown period.

Tóm tắt nhanh

Chủ đề	Cần nhớ
Vertical scaling	Tăng size instance; dùng cho hệ thống non-distributed như RDS, ElastiCache; có giới hạn phần cứng
Horizontal scaling	Tăng số lượng instance; = elasticity; cần hệ thống phân tán
High Availability	Chạy trên ≥ 2 AZ; passive (RDS Multi AZ) hoặc active (horizontal scaling)
CLB (2009)	HTTP, HTTPS, TCP, SSL; chỉ 1 SSL certificate; không hỗ trợ SNI
ALB (2016)	Layer 7; routing theo path / hostname / query string / header; target group gồm EC2, ECS task, Lambda, private IP; IP client nằm trong `X-Forwarded-For`
NLB (2017)	Layer 4, TCP/UDP; hàng triệu request/giây, ultra-low latency; static IP mỗi AZ + Elastic IP; target có thể là ALB
GWLB (2020)	Layer 3, IP packet; đứng trước các 3rd party virtual appliance (firewall, IDS/IPS); GENEVE port 6081
Sticky Sessions	Cùng client → cùng instance; dùng cookie `AWSALB` (ALB), `AWSELB` (CLB), `AWSALBAPP` (application cookie); cấm dùng tên `AWSALB`/`AWSALBAPP`/`AWSALBTG` cho custom cookie
Cross-Zone LB	ALB: bật sẵn, miễn phí inter-AZ · NLB/GWLB: tắt sẵn, có phí nếu bật · CLB: tắt sẵn, miễn phí
SNI	Nhiều certificate trên một listener; chỉ ALB, NLB, CloudFront — không có CLB
Connection Draining	CLB gọi là Connection Draining, ALB/NLB gọi là Deregistration Delay; 1–3600 giây, default 300, đặt 0 để tắt
ASG	Min / Desired / Max; Launch Template; miễn phí (chỉ trả tiền EC2); tự thay instance unhealthy
Scaling policy	Target Tracking · Simple/Step · Scheduled · Predictive
Metric để scale	`CPUUtilization`, `RequestCountPerTarget`, Average Network In/Out, custom metric
Cooldown	Default 300 giây; dùng ready-to-use AMI để giảm xuống