Load Balancing & Auto Scaling

1. Scalability & HA

Trước khi đi vào Load Balancer và Auto Scaling Group, ta cần hiểu rõ hai khái niệm nền tảng của mọi hệ thống chạy trên cloud: Scalability (khả năng mở rộng) và High Availability (tính sẵn sàng cao). Đây là hai khái niệm liên quan chặt chẽ với nhau nhưng KHÔNG đồng nhất — đề thi CLF-C02 rất thích hỏi để phân biệt chúng.

Scalability nghĩa là một ứng dụng hoặc hệ thống có khả năng xử lý tải (load) ngày càng lớn hơn bằng cách “thích nghi” — tức là được cấp thêm tài nguyên khi cần. Có hai cách để mở rộng: mở rộng theo chiều dọc (Vertical Scalability) và mở rộng theo chiều ngang (Horizontal Scalability, còn gọi là Elasticity).

Hãy tưởng tượng một trung tâm tổng đài (call center) tiếp nhận điện thoại của khách hàng. Khi lượng gọi tăng lên, trung tâm có hai lựa chọn: (1) đào tạo một nhân viên hiện có trở nên giỏi hơn, xử lý nhanh hơn, nhận nhiều cuộc gọi liên tiếp hơn (mở rộng theo chiều dọc — nâng cấp năng lực của MỘT người); hoặc (2) tuyển thêm nhiều nhân viên mới để cùng nhận điện thoại song song (mở rộng theo chiều ngang — tăng SỐ LƯỢNG người). Toàn bộ chương này sẽ dùng lại analogy này để giải thích các dịch vụ AWS liên quan.

2. Vertical Scalability

Vertical Scalability (Scale Up/Down) nghĩa là tăng kích thước (công suất) của một instance duy nhất. Ví dụ: ứng dụng của bạn đang chạy trên một EC2 Instance loại t2.micro (ít CPU, ít RAM). Khi lượng người dùng tăng, bạn chuyển ứng dụng đó sang chạy trên t2.large (nhiều CPU, nhiều RAM hơn) — đây chính là scale up theo chiều dọc.

Cách mở rộng này rất phổ biến với các hệ thống không phân tán (non-distributed systems), điển hình là cơ sở dữ liệu (database) truyền thống. Một database thường khó chia ra chạy trên nhiều máy nhỏ cùng lúc, nên khi cần mạnh hơn, người ta thường nâng cấp máy chủ lên loại “khỏe” hơn.

Tuy nhiên, Vertical Scalability luôn có giới hạn phần cứng: bạn không thể phóng to một instance mãi mãi. Trên AWS, dải kích thước instance đi từ t2.nano (0.5 GB RAM, 1 vCPU) cho tới u-12tb1.metal (12.3 TB RAM, 448 vCPU) — rất lớn, nhưng vẫn là một con số hữu hạn. Quay lại analogy call center: một nhân viên dù được đào tạo giỏi đến đâu cũng chỉ nhận được tối đa một số cuộc gọi nhất định trong một khoảng thời gian — không thể vô hạn.

3. Horizontal Scalability

Horizontal Scalability (Scale Out/In) nghĩa là tăng số lượng instance hoặc hệ thống tham gia phục vụ ứng dụng, thay vì làm cho một instance mạnh hơn. Cách này ngầm định rằng hệ thống của bạn là một hệ thống phân tán (distributed system) — nhiều máy cùng làm việc song song, chia sẻ tải với nhau.

Horizontal Scalability rất phổ biến với các ứng dụng web và ứng dụng hiện đại ngày nay, và trở nên rất dễ thực hiện nhờ các dịch vụ cloud như EC2 — bạn chỉ cần bấm vài lần là có thêm server mới trong vài phút, thay vì phải mua và lắp đặt phần cứng vật lý.

Quay lại call center: thay vì có 1 nhân viên siêu giỏi, bạn tuyển thêm 5, 10, 100 nhân viên khác để cùng nhận điện thoại song song. Khi lượng gọi giảm, bạn có thể giảm số nhân viên trực (scale in). Đây chính là cách EC2 kết hợp với Auto Scaling Group và Load Balancer hoạt động — chủ đề chính của chương này.

4. High Availability

High Availability (HA) thường đi kèm với Horizontal Scaling (dù về lý thuyết chúng là hai khái niệm khác nhau). HA nghĩa là chạy ứng dụng/hệ thống của bạn ở ít nhất 2 Availability Zone (AZ) khác nhau, với mục tiêu: nếu một AZ (một trung tâm dữ liệu) gặp thảm họa và sập hoàn toàn, ứng dụng của bạn vẫn tiếp tục chạy bình thường ở AZ còn lại.

Ví dụ dễ hiểu: công ty bạn có một tòa nhà văn phòng ở New York. Nếu chỉ có duy nhất tòa nhà này và nó gặp hỏa hoạn, toàn bộ hoạt động công ty ngừng lại. Nhưng nếu công ty có thêm một tòa nhà thứ hai ở San Francisco, khi New York gặp sự cố, San Francisco vẫn hoạt động — công ty không bị “chết” hoàn toàn.

Đối với EC2, mô hình đầy đủ trông như sau:

Vertical Scaling: tăng kích thước instance (scale up/down) — ví dụ từ t2.nano lên u-12tb1.metal.
Horizontal Scaling: tăng số lượng instance (scale out/in) — thực hiện thông qua Auto Scaling Group kết hợp Load Balancer.
High Availability: chạy các instance của cùng một ứng dụng trải trên nhiều AZ — thực hiện bằng ASG multi-AZ và Load Balancer multi-AZ.

5. Scalability, Elasticity, Agility

Đây là bộ ba khái niệm mà đề thi rất thích gài để kiểm tra khả năng phân biệt của bạn:

Scalability (khả năng mở rộng): khả năng của hệ thống đáp ứng được tải lớn hơn, bằng cách làm phần cứng mạnh hơn (scale up) hoặc thêm nhiều node hơn (scale out). Đây là một “khả năng” hệ thống có thể có, không nhất thiết là tự động.
Elasticity (tính đàn hồi): khi một hệ thống đã có khả năng scale, elasticity là khi việc scale đó diễn ra tự động theo tải thực tế — hệ thống tự “phình ra” khi tải tăng và tự “co lại” khi tải giảm. Đây là đặc trưng rất “cloud-friendly”: bạn chỉ trả tiền cho đúng phần mình dùng (pay-per-use), luôn khớp với nhu cầu thực tế, và tối ưu chi phí. Elasticity chính là điều Auto Scaling Group mang lại.
Agility (sự linh hoạt/nhanh nhạy): khái niệm này KHÔNG liên quan trực tiếp đến scalability — đây là “cái bẫy” hay gặp trong đề thi. Agility nói về việc các tài nguyên IT mới chỉ cách bạn một cú click chuột, giúp giảm thời gian để có được tài nguyên phục vụ cho developer từ hàng tuần (phải mua, lắp đặt phần cứng vật lý) xuống chỉ còn vài phút.

6. Load Balancer là gì

Load Balancer là một máy chủ (hoặc dịch vụ) đứng ở giữa, nhận traffic từ Internet và chuyển tiếp (forward) traffic đó đến nhiều máy chủ EC2 Instance phía sau (downstream). Nói đơn giản, nó giống như một “người điều phối” đứng ở cửa vào tòa nhà call center, phân chia đều các cuộc gọi tới cho từng nhân viên đang rảnh, để không ai bị quá tải còn người khác lại ngồi không.

Vì sao chúng ta cần dùng Load Balancer? Có nhiều lý do quan trọng:

Phân tải (spread the load): chia đều traffic cho nhiều instance phía sau, tránh một instance bị quá tải.
Một điểm truy cập duy nhất (single point of access): người dùng chỉ cần biết một địa chỉ DNS duy nhất của ứng dụng, không cần biết có bao nhiêu server phía sau hay địa chỉ IP cụ thể của chúng.
Xử lý lỗi mượt mà (seamlessly handle failures): khi một instance phía sau bị lỗi, Load Balancer tự động ngừng gửi traffic tới nó và chuyển sang các instance còn khỏe mạnh, người dùng hầu như không nhận ra sự cố.
Kiểm tra sức khỏe định kỳ (health checks): Load Balancer liên tục “hỏi thăm” các instance phía sau xem chúng có còn hoạt động tốt không.
Chấm dứt SSL (SSL Termination): Load Balancer có thể xử lý việc mã hóa/giải mã HTTPS thay cho các instance phía sau, giúp instance nhẹ tải hơn.
Tính sẵn sàng cao trên nhiều AZ: Load Balancer có thể phân traffic tới các instance nằm ở nhiều Availability Zone khác nhau.

7. ELB & 4 loại Load Balancer

ELB (Elastic Load Balancer) là một Load Balancer được AWS quản lý (managed). Điều này rất khác với việc bạn tự dựng một Load Balancer riêng (ví dụ tự cài phần mềm trên một EC2 Instance):

AWS đảm bảo (guarantee) ELB sẽ hoạt động ổn định.
AWS lo toàn bộ việc nâng cấp (upgrades), bảo trì (maintenance), và đảm bảo tính sẵn sàng cao (high availability) cho ELB.
AWS chỉ cung cấp một số nút điều chỉnh cấu hình (configuration knobs) hạn chế — đổi lại sự đơn giản, dễ dùng.
Ngược lại, nếu bạn tự dựng Load Balancer, chi phí thiết lập ban đầu có thể rẻ hơn nhưng đòi hỏi nỗ lực vận hành rất lớn (bảo trì liên tục, tự tích hợp với các dịch vụ khác).

AWS cung cấp 4 loại Load Balancer, ứng với các lớp (layer) khác nhau trong mô hình OSI:

Loại Load Balancer	Lớp OSI	Giao thức hỗ trợ	Đặc điểm chính
Application Load Balancer (ALB)	Layer 7	HTTP / HTTPS / gRPC	Hiểu nội dung request, định tuyến thông minh theo URL/path
Network Load Balancer (NLB)	Layer 4	TCP / UDP	Hiệu năng siêu cao, độ trễ cực thấp
Gateway Load Balancer (GWLB)	Layer 3	Giao thức GENEVE trên IP Packet	Điều hướng traffic tới các thiết bị bảo mật (firewall) bên thứ ba
Classic Load Balancer (CLB)	Layer 4 & 7	—	Thế hệ cũ, đã bị AWS ngừng hỗ trợ (retired) từ 2023

8. ALB, NLB & GWLB

Network Load Balancer (NLB) hoạt động ở Layer 4, hỗ trợ giao thức TCP/UDP. Đây là loại có hiệu năng cao nhất, có thể xử lý tới hàng triệu request mỗi giây, với độ trễ (latency) rất thấp. NLB cũng cho phép gán một địa chỉ IP tĩnh (Static IP) thông qua Elastic IP — hữu ích khi hệ thống khác cần whitelist một địa chỉ IP cố định để kết nối tới ứng dụng của bạn.

Application Load Balancer (ALB) hoạt động ở Layer 7, hỗ trợ HTTP/HTTPS/gRPC. Vì hiểu được nội dung ở lớp ứng dụng, ALB có các tính năng định tuyến (HTTP Routing) rất mạnh: có thể định tuyến theo đường dẫn URL (ví dụ /api đi tới nhóm server A, /images đi tới nhóm server B), theo hostname, theo header… ALB dùng DNS tĩnh (một URL cố định) làm điểm truy cập.

Gateway Load Balancer (GWLB) hoạt động ở Layer 3, sử dụng giao thức GENEVE đóng gói trên các IP Packet. Mục đích của GWLB khác hẳn hai loại trên: nó không cân bằng tải cho ứng dụng web của bạn, mà dùng để điều hướng traffic tới các thiết bị bảo mật ảo của bên thứ ba mà bạn tự triển khai trên EC2 Instance — ví dụ firewall, hệ thống phát hiện xâm nhập (intrusion detection). Người dùng gửi traffic → NLB/ALB xử lý traffic hướng tới ứng dụng chính; đồng thời, một luồng traffic riêng có thể được GWLB chuyển hướng qua các “Virtual Appliance bảo mật” của bên thứ ba để kiểm tra trước khi cho phép tiếp tục.

9. Auto Scaling Group (ASG)

Trong thực tế, lượng truy cập vào website hoặc ứng dụng của bạn luôn thay đổi theo thời gian — có lúc cao điểm (giờ vàng, sự kiện flash sale), có lúc rất thấp (nửa đêm). Trên cloud, bạn có thể tạo mới hoặc loại bỏ server rất nhanh chóng — đây chính là lợi thế mà Auto Scaling Group (ASG) khai thác.

Mục tiêu của ASG bao gồm:

Scale out: tự động thêm EC2 Instance mới khi tải tăng lên.
Scale in: tự động loại bỏ EC2 Instance khi tải giảm xuống.
Đảm bảo luôn có một số lượng máy tối thiểu (minimum) và tối đa (maximum) đang chạy — không bao giờ vượt quá hoặc thiếu hụt các ngưỡng này.
Tự động đăng ký (register) các instance mới vào Load Balancer, để chúng ngay lập tức nhận được traffic.
Tự động thay thế (replace) các instance bị lỗi/không khỏe mạnh (unhealthy).
Tiết kiệm chi phí: chỉ chạy đúng số lượng máy cần thiết ở “công suất tối ưu” — đây chính là một trong những nguyên lý cốt lõi của điện toán đám mây: trả tiền theo đúng nhu cầu sử dụng thực tế, không phải mua dư “cho chắc” như hạ tầng vật lý truyền thống.

10. Cấu trúc & hoạt động ASG

Một Auto Scaling Group trên AWS được định nghĩa bởi 3 con số quan trọng:

Minimum size: số lượng instance tối thiểu luôn phải chạy, dù tải thấp đến đâu.
Desired Capacity (Actual Size): số lượng instance mà ASG cố gắng duy trì ở thời điểm hiện tại — con số này có thể tự thay đổi theo các chiến lược scaling.
Maximum size: số lượng instance tối đa được cho phép chạy, dù tải cao đến đâu — đây cũng là một cách kiểm soát chi phí, tránh việc scale out vô hạn gây tốn kém ngoài dự tính.

ASG sẽ tự động scale out/in để giữ số lượng instance nằm trong khoảng từ min đến max, theo đúng desired capacity được tính toán tại từng thời điểm.

Trong một kiến trúc thực tế, luồng traffic thường đi như sau: người dùng gửi request tới Load Balancer → Load Balancer phân phối request đó tới các EC2 Instance đang chạy bên trong Auto Scaling Group. Sự kết hợp Load Balancer + ASG chính là “công thức chuẩn” của AWS để xây dựng một ứng dụng vừa có khả năng mở rộng (scalable), vừa có tính sẵn sàng cao (highly available), vừa tối ưu chi phí (cost-efficient).

11. Chiến lược Scaling

ASG cho phép nhiều chiến lược khác nhau để quyết định khi nào thì scale out hay scale in:

Manual Scaling: bạn tự tay cập nhật kích thước của ASG (ví dụ đổi Desired Capacity) thông qua console/API — không có sự tự động hóa nào.
Dynamic Scaling – Simple/Step Scaling: khi một CloudWatch Alarm được kích hoạt (ví dụ CPU trung bình vượt quá 70%), ASG sẽ thêm 2 instance; khi CPU giảm xuống dưới 30%, ASG sẽ loại bỏ 1 instance. Cách này dựa trên các ngưỡng (threshold) cụ thể mà bạn tự định nghĩa.
Dynamic Scaling – Target Tracking Scaling: đơn giản và “thông minh” hơn — bạn chỉ cần đặt một mục tiêu, ví dụ “giữ CPU trung bình của toàn ASG ở khoảng 40%”, và AWS sẽ tự tính toán, thêm/bớt instance sao cho luôn bám sát mục tiêu đó, không cần bạn tự định nghĩa từng ngưỡng scale.
Scheduled Scaling: scale trước dựa theo các mẫu sử dụng (usage pattern) đã biết trước theo thời gian. Ví dụ: tăng Minimum Capacity lên 10 vào 5 giờ chiều mỗi thứ Sáu, vì bạn biết chắc traffic sẽ tăng cao vào giờ đó.

Chiến lược	Cách hoạt động	Phù hợp khi
Manual	Người vận hành tự chỉnh tay	Thử nghiệm, kiểm soát chặt
Simple/Step Scaling	Alarm CloudWatch kích hoạt theo ngưỡng cụ thể	Cần kiểm soát chi tiết từng bước tăng/giảm
Target Tracking	Tự động bám theo một chỉ số mục tiêu (ví dụ CPU 40%)	Muốn đơn giản, ít cấu hình
Scheduled	Đặt sẵn theo thời gian biết trước	Tải có tính lặp lại, dự đoán được theo giờ/ngày

12. Predictive Scaling

Predictive Scaling là một tính năng của ASG sử dụng Machine Learning để dự đoán lượng traffic trong tương lai dựa trên dữ liệu lịch sử. Dựa trên dự đoán đó, ASG sẽ tự động chuẩn bị (provision) sẵn số lượng EC2 Instance phù hợp trước khi tải thực sự tăng lên, thay vì chỉ phản ứng sau khi tải đã tăng (như Dynamic Scaling).

Tính năng này đặc biệt hữu ích khi tải của ứng dụng có các mẫu lặp lại theo thời gian có thể dự đoán được — ví dụ traffic luôn tăng vào 8 giờ sáng mỗi ngày làm việc, hoặc tăng mạnh vào các ngày lễ mua sắm định kỳ mỗi năm. Nhờ chuẩn bị trước, ứng dụng tránh được tình trạng “trễ” trong vài phút đầu khi Dynamic Scaling còn đang phản ứng và khởi động instance mới.

Tổng kết chương

Scalability (Vertical/Horizontal): Vertical = phóng to một máy (có giới hạn phần cứng), Horizontal = tăng số lượng máy (hệ thống phân tán, dễ làm trên cloud).
High Availability: chạy ứng dụng trên ít nhất 2 AZ để sống sót qua thảm họa mất một trung tâm dữ liệu.
Elasticity vs Agility: Elasticity = tự động scale theo tải (pay-per-use); Agility = có tài nguyên IT mới chỉ trong vài phút, không liên quan trực tiếp đến scaling.
Load Balancer: phân phối traffic, cung cấp một điểm truy cập duy nhất, health check, SSL termination, chịu lỗi tốt.
4 loại ELB: Classic (đã retired), Application (Layer 7, HTTP/HTTPS), Network (Layer 4, TCP/UDP, siêu nhanh), Gateway (Layer 3, điều hướng tới firewall bên thứ ba).
Auto Scaling Group: tự động scale out/in EC2 Instance trong khoảng min-max, thay thế instance lỗi, tích hợp chặt với Load Balancer, đây chính là hiện thân của Elasticity trên AWS.
Chiến lược Scaling: Manual, Simple/Step, Target Tracking, Scheduled, và Predictive Scaling (dùng Machine Learning để dự đoán trước tải).