Hồi mới deploy production, mình từng tự tin rằng server t3.medium là đủ. Rồi cái ngày bài viết được share lên group 50k thành viên, traffic tăng gấp 20 lần trong 10 phút — website đơ cứng, CPU 100%, database connection pool cạn sạch. Khách hàng tràn vào hỏi "web sập rồi à?", mình ngồi restart EC2 bằng tay như người mất hồn. Sau đó mới biết: AWS đã có giải pháp cho vấn đề này từ lâu, mình chỉ chưa dùng.

AWS Auto Scaling và Load Balancer chống sập web

AWS Auto Scaling và Load Balancer là gì?

Hãy tưởng tượng một nhà hàng buffet vào cuối tuần. Bình thường chỉ cần 5 nhân viên, nhưng tối thứ Bảy khách ùa vào, bạn cần 15 người ngay lập tức — và sáng Chủ nhật lại thu về 5 người để tiết kiệm chi phí. AWS Auto Scaling chính là người quản lý nhân sự đó cho server của bạn.

Application Load Balancer (ALB) là người đứng ở cửa, điều hướng mỗi khách (request) vào bàn còn trống (server có tải thấp), đảm bảo không ai ngồi chờ quá lâu và không bàn nào bị quá tải. Hai thứ này kết hợp tạo ra kiến trúc highly available và auto-scaling — tiêu chuẩn vàng cho production workload trên AWS.

Theo AWS Well-Architected Framework, một hệ thống production đúng nghĩa phải xử lý được traffic burst mà không downtime. Không có Auto Scaling + ALB, bạn đang chạy "single point of failure" — một EC2 chết là toàn bộ service sập.

Khi nào cần dùng Auto Scaling + ALB?

Không phải mọi dự án đều cần ngay từ đầu, nhưng đây là các tín hiệu rõ ràng:

E-commerce với flash sale: Traffic tăng 10-50x trong vài phút (Haravan, Shopify Việt Nam đều gặp). Auto Scaling tự spin up EC2 mới trước khi user thấy timeout. Sau sale, thu hẹp lại tránh lãng phí $200-500/tháng tiền server idle.
SaaS B2B với giờ cao điểm: 9h sáng toàn bộ nhân viên khách hàng đăng nhập cùng lúc, 7h tối không ai dùng. Auto Scaling theo CPU threshold giúp scale từ 2 lên 8 instance rồi về lại 2, tự động hoàn toàn.
App media/content với viral content: Một bài post được chia sẻ bất ngờ, traffic tăng từ 100 lên 10.000 req/s trong 30 phút. Không có ALB, mọi request dồn vào 1 server — kết quả đã biết. Với kiến trúc đúng, hệ thống chỉ thêm instance mới trong vài phút mà không downtime.

Kiến trúc thực tế: ALB + Auto Scaling Group

Kiến trúc chuẩn gồm 3 layer chính:

1. Application Load Balancer (ALB) — nhận toàn bộ traffic từ internet qua port 80/443. ALB health-check từng instance mỗi 30 giây; instance nào fail sẽ bị loại khỏi pool tự động. ALB cũng hỗ trợ path-based routing (/api/* → backend cluster, /static/* → S3), sticky session, và WebSocket.

2. Auto Scaling Group (ASG) — quản lý fleet EC2 instances. Bạn định nghĩa:

Min capacity: số instance tối thiểu luôn chạy (thường 2 để HA)
Desired capacity: số instance mục tiêu hiện tại
Max capacity: giới hạn trên tránh bill khủng

3. Scaling Policy — quy tắc khi nào scale out/in. Có 3 loại chính:

Target Tracking: "Giữ CPU ở 60%" — AWS tự tính toán cần bao nhiêu instance
Step Scaling: CPU 70-80% → thêm 1 instance, CPU >80% → thêm 3 instance
Scheduled Scaling: 8h30 sáng thêm 4 instance, 8h tối về lại 2 instance

Hướng dẫn thiết lập từng bước

Giả sử bạn đã có một EC2 instance đang chạy web app. Đây là luồng thiết lập từ đầu:

Bước 1: Tạo Launch Template

Launch Template là "bản sao" của instance bạn muốn scale ra. Vào EC2 Console → Launch Templates → Create launch template. Chọn AMI (snapshot của app đã cấu hình), instance type (t3.medium), security group, và user data script để auto-start app khi boot:

#!/bin/bash
cd /var/www/myapp
npm install --production
pm2 start app.js --name "myapp"

Bước 2: Tạo Target Group

EC2 → Target Groups → Create target group. Chọn type là "Instances", protocol HTTP, port 3000 (hoặc port app của bạn). Cấu hình health check path là /health — đảm bảo endpoint này return HTTP 200 khi app ready.

Bước 3: Tạo Application Load Balancer

EC2 → Load Balancers → Create Load Balancer → Application Load Balancer. Chọn scheme "internet-facing", chọn ít nhất 2 Availability Zones (bắt buộc cho HA). Listener: port 443 với SSL certificate từ ACM, forward đến Target Group vừa tạo.

Bước 4: Tạo Auto Scaling Group

EC2 → Auto Scaling Groups → Create. Chọn Launch Template, chọn các subnet (multi-AZ), và quan trọng nhất: attach vào Target Group của ALB. Đặt min=2, desired=2, max=10.

Bước 5: Thêm Scaling Policy

Trong ASG → Automatic Scaling → Add policy. Chọn "Target tracking scaling", metric là "Average CPU Utilization", target value 60%. AWS sẽ tự scale out khi CPU trung bình vượt 60% và scale in khi xuống dưới.

Mẹo thực chiến: Đặt "scale-in cooldown" là 300 giây (5 phút) để tránh hệ thống scale in quá nhanh khi có spike ngắn. Scale-out cooldown nên để 60-90 giây — nhanh hơn để phản ứng kịp traffic tăng đột ngột.

Ổ gà phổ biến và cách né

Sai lầm 1: Health check path return 200 kể cả khi app chưa ready. Nhiều người set / làm health check path — nhưng nginx trả 200 ngay cả khi Node.js chưa start xong. Hậu quả: ALB route traffic vào instance "zombie", user thấy lỗi. Fix: tạo /health endpoint thật sự kiểm tra DB connection và app state trước khi return 200.

Sai lầm 2: Không test scale-in. Mọi người test scale-out (tăng tải → instance mới xuất hiện), nhưng quên test scale-in. Hệ thống scale-in không graceful sẽ kill instance đang xử lý request, gây lỗi cho user. Giải pháp: bật "Instance scale-in protection" cho các instance đang có active connections, và cấu hình connection draining 30-60 giây trên ALB.

Sai lầm 3: Session state lưu trên instance local. Khi có nhiều instance, user có thể bị route sang instance khác và mất session. Lưu session vào Redis (ElastiCache) hoặc dùng JWT stateless — đây là điều kiện tiên quyết để scale horizontal.

FAQ

Q: Chi phí ALB có đắt không? Có đáng không?
A: ALB tính theo giờ (~$0.008/giờ, khoảng $6/tháng) cộng với LCU (Loadbalancer Capacity Units) theo lượng traffic. Một app vừa thường tốn $15-30/tháng cho ALB. So với việc server sập 1 tiếng mất $X doanh thu, con số này không đáng kể. Đắt hơn ALB là không có ALB.

Q: Auto Scaling phản ứng nhanh không? Traffic tăng đột ngột 100x thì kịp không?
A: Thực tế spin up EC2 mới mất 2-5 phút (gồm boot + user data script). Với spike cực đột ngột, 2 phút đầu vẫn có thể bị quá tải. Giải pháp: kết hợp với Predictive Scaling (dự đoán theo lịch sử), hoặc set desired capacity cao hơn trước các sự kiện đã biết (flash sale, event).

Q: Có cần VPC, subnet phức tạp không?
A: ALB bắt buộc phải ở ít nhất 2 Availability Zones trong cùng VPC. Nếu đang dùng default VPC thì đã có sẵn subnet multi-AZ. Với production nghiêm túc, nên có public subnet cho ALB và private subnet cho EC2 instances — tăng security đáng kể.

Góc nhìn thực tế

Mình setup ALB + Auto Scaling cho production lần đầu mất gần một ngày, nhưng 3 tháng sau không phải wake up lúc 2h sáng vì server sập một lần nào. Đó là khoản đầu tư xứng đáng nhất. Kiến trúc này không chỉ giải quyết traffic spike — nó buộc bạn thiết kế app theo hướng stateless, dễ test và dễ maintain hơn về lâu dài. Bước tiếp theo sau khi nắm vững phần này: tìm hiểu AWS Lambda và Serverless Architecture — khi hạ tầng không còn là thứ bạn cần quản lý nữa.