Tìm hiểu khả năng mở rộng (scalability), tính sẵn sàng cao (high availability), cách Load Balancer phân phối traffic và cách Auto Scaling Group tự động thêm/bớt EC2 Instance theo tải thực tế.
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.
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.
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.
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:
t2.nano lên u-12tb1.metal.Đâ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:
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:
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 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 |
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.
/checkout tới một nhóm server riêng được tối ưu cho thanh toán. Đồng thời, công ty dùng GWLB để đưa toàn bộ traffic đi qua một lớp firewall thế hệ mới (next-gen firewall) của bên thứ ba trước khi vào hệ thống, nhằm phát hiện tấn công sớm.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:
Một Auto Scaling Group trên AWS được định nghĩa bởi 3 con số quan trọng:
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).
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:
| 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 |
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.