Auto-scale Cloud Mùa Sale 11.11, 12.12 cho Seller Đa Sàn

Auto-scale (tự động mở rộng) là cơ chế để hạ tầng cloud tự thêm máy chủ hoặc container khi tải tăng và tự thu hẹp khi tải giảm, dựa trên các chỉ số như CPU, số request hay độ dài hàng đợi. Trong mùa sale 11.11, 12.12, đây là lớp bảo vệ giúp website bán hàng và hệ thống quản lý đơn đa sàn không sập lúc 0h — nhưng chỉ khi được thiết kế đúng.

Thực tế, nhiều hệ thống đã “bật auto-scale” vẫn gặp lỗi trong 15 phút đầu flash sale. Bài viết giải thích vì sao, và hướng dẫn 6 bước thiết lập auto-scale hiệu quả cho seller đa sàn trên Sunteco Cloud.

Tóm tắt nhanh

Auto-scale theo phản ứng (reactive) thường cần vài phút để máy mới sẵn sàng, trong khi traffic flash sale tăng vọt trong vài giây. Cần kết hợp scale theo lịch (scheduled) trước giờ G.

Scale máy chủ ứng dụng là chưa đủ: database và API của sàn mới là điểm nghẽn thường gặp nhất.

Ứng dụng phải stateless (không lưu session, file trên máy) thì máy mới thêm vào mới dùng được.

Hàng đợi tin nhắn (Sun Kafka Highway) giúp “san phẳng” đỉnh đơn hàng thay vì để database chịu toàn bộ.

Auto-scale là gì? Scale ngang và scale dọc khác nhau thế nào?

Auto-scale là tự động điều chỉnh tài nguyên theo tải. Có hai cách: scale dọc (vertical) là nâng cấu hình một máy chủ, và scale ngang (horizontal) là thêm nhiều máy chủ chạy song song. Với TMĐT mùa sale, scale ngang là lựa chọn chính vì không cần dừng hệ thống và gần như không có giới hạn trên.

Tiêu chí	Scale dọc (vertical)	Scale ngang (horizontal)
Cách làm	Tăng vCPU, RAM của một máy chủ	Thêm máy chủ hoặc container giống hệt nhau
Thời gian gián đoạn	Thường phải khởi động lại	Không gián đoạn nếu có cân bằng tải
Giới hạn	Bị chặn bởi cấu hình tối đa của một máy	Gần như không giới hạn
Phù hợp cho	Database chính, ứng dụng khó tách	Web, API, worker xử lý đơn
Yêu cầu	Đơn giản	Ứng dụng stateless + Load Balancer

Vì sao server vẫn sập lúc 0h dù đã bật auto-scale?

Server sập lúc mở sale vì traffic tăng nhanh hơn tốc độ hạ tầng kịp mở rộng, hoặc vì điểm nghẽn nằm ở chỗ auto-scale không chạm tới. Đây là 5 nguyên nhân phổ biến nhất mà đội kỹ thuật Sunteco gặp khi rà soát hệ thống TMĐT:

Độ trễ khởi tạo. Một máy chủ ảo mới cần vài phút để khởi động, cài ứng dụng và qua kiểm tra sức khỏe. Đỉnh traffic flash sale chỉ cần vài giây. Container khởi động nhanh hơn nhiều, nhưng vẫn cần image được chuẩn bị sẵn.
Database là cổ chai. Thêm 10 máy chủ web nghĩa là thêm 10 lần kết nối tới cùng một database. Nếu không có read replica và connection pooling, database sập trước.
Ứng dụng lưu trạng thái trên máy. Session đăng nhập, giỏ hàng hoặc file upload lưu trên ổ đĩa máy chủ khiến máy mới thêm vào không phục vụ được người dùng cũ.
Ngưỡng scale đặt quá cao. Chờ CPU chạm 90% mới scale thì lúc máy mới sẵn sàng, các máy cũ đã quá tải.
Giới hạn API của sàn. Hệ thống quản lý đơn gọi API của sàn để lấy đơn, cập nhật tồn kho; sàn giới hạn số request mỗi giây. Thêm máy chủ không giúp được — cần hàng đợi và cơ chế gọi lại có kiểm soát.

Auto-scale hoạt động như thế nào?

Auto-scale vận hành theo một vòng lặp gồm 5 bước: đo chỉ số, so với ngưỡng, thêm tài nguyên, kiểm tra sức khỏe, rồi thu hẹp khi tải giảm.

[ẢNH 1 — Sơ đồ vòng lặp auto-scale]

Đo: hệ thống giám sát (Sun Monitor) thu CPU, RAM, số request/giây, độ dài hàng đợi theo chu kỳ vài chục giây.
So ngưỡng: khi chỉ số vượt ngưỡng (ví dụ CPU trung bình trên 60% liên tục 2 phút), chính sách scale được kích hoạt.
Mở rộng: tạo thêm container hoặc máy chủ từ image chuẩn, trong giới hạn tối thiểu–tối đa đã đặt.
Kiểm tra sức khỏe: Load Balancer chỉ chuyển traffic vào máy mới khi máy đó trả lời health check thành công.
Thu hẹp: khi tải giảm dưới ngưỡng thấp trong thời gian đủ dài (cooldown), hệ thống gỡ bớt tài nguyên để tiết kiệm chi phí.

Với flash sale, vòng lặp phản ứng này nên đi kèm scale theo lịch: tăng sẵn số máy 30–60 phút trước giờ mở sale, giữ đến khi qua đỉnh, rồi trả về cho chính sách tự động.

Kiến trúc auto-scale cho seller đa sàn trên Sunteco Cloud

Một kiến trúc chịu được mùa sale có 5 lớp, mỗi lớp hấp thụ một phần tải để lớp phía sau không bị dồn ép.

[ẢNH 2 — Sơ đồ kiến trúc auto-scale 5 lớp]

Lớp	Vai trò mùa sale	Dịch vụ Sunteco
1. Biên (edge)	Phục vụ ảnh, video, CSS, JS từ node gần người mua; chặn phần lớn request trước khi tới máy chủ	Sun CDN + Sun S3
2. Phân tải	Chia request cho các máy khỏe, loại máy lỗi khỏi vòng phục vụ	Sun Load Balancer
3. Ứng dụng	Web, API, worker đồng bộ đơn tự scale theo tải	Sun Container (Spinner), Sun VM
4. Đệm	Nhận đơn từ nhiều sàn vào hàng đợi, xử lý dần theo sức chịu của database	Sun Kafka Highway
5. Dữ liệu	Ghi vào bản chính, đọc từ các bản sao	Sun Database + read replica

Toàn bộ 5 lớp được theo dõi bởi Sun Monitor, gửi cảnh báo qua email hoặc chat khi chỉ số vượt ngưỡng. Sun Container phù hợp nhất cho các dịch vụ không trạng thái cần scale nhanh như API đồng bộ tồn kho, tính giá, nhận webhook từ sàn. Ứng dụng chạy trên Sun VM được mở rộng bằng cách nhân bản máy từ cùng một image phía sau Sun Load Balancer [đội sản phẩm xác nhận cơ chế autoscaling group của Sun VM trước khi đăng].

Hướng dẫn 6 bước thiết lập auto-scale trước 11.11, 12.12

Sáu bước dưới đây nên hoàn tất trước ngày sale ít nhất 2 tuần, để còn thời gian kiểm thử tải và sửa lỗi.

Bước 1: Đo baseline và dự báo đỉnh traffic

Lấy số liệu request/giây, số đơn/phút và CPU của ngày thường và của đợt sale gần nhất. Hệ số đỉnh = traffic đỉnh mùa sale trước ÷ traffic trung bình ngày thường. Nhân hệ số này với mức tăng trưởng dự kiến để ra mục tiêu năng lực, rồi cộng thêm 30–50% dự phòng.

Bước 2: Đưa ứng dụng về dạng stateless và đẩy nội dung tĩnh ra CDN

Chuyển session, giỏ hàng sang bộ nhớ đệm dùng chung (Redis) hoặc database; chuyển file upload, ảnh sản phẩm sang Sun S3; phục vụ toàn bộ tài nguyên tĩnh qua Sun CDN. Sau bước này, bất kỳ máy chủ nào cũng phục vụ được bất kỳ người dùng nào — điều kiện bắt buộc để scale ngang.

Bước 3: Cấu hình Load Balancer và health check

Đặt Sun Load Balancer trước nhóm máy chủ ứng dụng. Health check nên gọi một endpoint kiểm tra cả kết nối database, không chỉ trả về “OK”. Bật kết nối giữ lâu (keep-alive) và thời gian chờ hợp lý để không giữ kết nối treo khi tải cao.

Bước 4: Đặt chính sách scale phản ứng và scale theo lịch

Tham số	Giá trị tham khảo	Lý do
Số máy tối thiểu	2	Không có điểm chết đơn lẻ
Số máy tối đa	Theo dự báo bước 1 + 50%	Chặn chi phí vượt kiểm soát
Ngưỡng scale out	CPU trung bình 60–65% trong 2 phút	Có thời gian cho máy mới khởi động
Ngưỡng scale in	CPU dưới 30% trong 10–15 phút	Tránh thêm–bớt liên tục
Scale theo lịch	Tăng lên 60–70% mức tối đa trước giờ G 30–60 phút	Đón đỉnh 0h mà không phải chờ phản ứng

Bước 5: Bảo vệ database và đệm đơn hàng bằng hàng đợi

Thêm read replica cho các truy vấn đọc (trang sản phẩm, tìm kiếm), dùng connection pooling để giới hạn số kết nối. Đơn hàng từ các sàn đi vào Sun Kafka Highway trước, worker đọc ra và ghi vào database theo tốc độ an toàn. Cách này cũng giúp tôn trọng giới hạn gọi API của sàn: worker gọi lại theo nhịp có kiểm soát thay vì dồn hàng nghìn request cùng lúc.

Bước 6: Kiểm thử tải và diễn tập sự cố

Dùng k6, JMeter hoặc Locust giả lập traffic tăng dần tới 1,5 lần mục tiêu ở bước 1, đo thời gian phản hồi p95 và tỷ lệ lỗi. Diễn tập ít nhất một kịch bản: tắt ngẫu nhiên một máy chủ giữa bài test để xác nhận Load Balancer tự loại máy lỗi.

Auto-scale mùa sale tốn bao nhiêu chi phí?

Chi phí auto-scale chỉ phát sinh cho tài nguyên thêm vào trong giờ cao điểm, nên rẻ hơn nhiều so với chạy cấu hình đỉnh cả tháng. Cách ước tính đơn giản:

Chi phí tháng sale = (Số máy nền × giá/giờ × 720 giờ)
                   + (Số máy thêm × giá/giờ × số giờ cao điểm)

Ví dụ: 2 máy nền chạy cả tháng, thêm 6 máy trong 8 giờ cao điểm của 3 ngày sale (10.10, 11.11, 12.12) = 2 × 720 + 6 × 24 = 1.584 giờ-máy, so với 8 × 720 = 5.760 giờ-máy nếu chạy cấu hình đỉnh cả tháng — giảm khoảng 72% giờ máy. Đơn giá theo cấu hình xem tại Bảng giá dịch vụ cloud Sunteco. Sunteco không tính phí data transfer, nên lượng ảnh, video tăng vọt mùa sale không làm hóa đơn băng thông tăng theo.

4 sai lầm thường gặp khi cấu hình auto-scale

Chỉ scale lớp web: database, cache và API bên ngoài vẫn là giới hạn thật.
Không đặt số máy tối đa: một vòng lặp lỗi hoặc bot có thể đẩy hóa đơn lên bất ngờ.
Image máy chủ cũ: máy mới khởi động bằng phiên bản code cũ, gây lỗi không đồng nhất.
Thay đổi code sát ngày sale: nên đóng băng thay đổi (code freeze) 5–7 ngày trước sale.

Cần danh sách việc cụ thể theo từng mốc thời gian? Xem checklist chuẩn bị hạ tầng sale cuối năm. Nếu bạn là seller Shopee hoặc TikTok Shop, đọc thêm cloud cho seller Shopee và cloud cho TikTok Shop, hoặc quay lại hướng dẫn tổng quan giải pháp cloud thương mại điện tử.

Câu hỏi thường gặp về auto-scale mùa sale

Auto-scale hoạt động thế nào?

Auto-scale theo dõi các chỉ số như CPU, số request hoặc độ dài hàng đợi. Khi chỉ số vượt ngưỡng, hệ thống tự tạo thêm máy chủ hoặc container và Load Balancer chuyển traffic sang; khi tải giảm, tài nguyên thừa được gỡ bớt.

Cần chuẩn bị gì trước flash sale để server không sập?

Cần ứng dụng stateless, CDN cho nội dung tĩnh, Load Balancer có health check, chính sách scale theo lịch trước giờ mở sale, read replica cho database, hàng đợi cho đơn hàng và một đợt kiểm thử tải ở mức 1,5 lần dự báo.

Chi phí auto-scale cloud có đắt không?

Không, vì bạn chỉ trả tiền cho tài nguyên thêm vào trong giờ cao điểm. So với chạy cấu hình đỉnh cả tháng, auto-scale thường giảm phần lớn số giờ máy chủ phải trả.

Bật auto-scale có đảm bảo website không sập không?

Không hoàn toàn. Auto-scale chỉ mở rộng phần được cấu hình; nếu database, cache hoặc API của sàn là điểm nghẽn, hệ thống vẫn lỗi. Cần thiết kế cả kiến trúc và kiểm thử tải trước.

Seller nhỏ chỉ bán trên sàn có cần auto-scale không?

Không. Seller chỉ bán trên sàn dùng hạ tầng của sàn. Auto-scale cần khi bạn có website riêng, công cụ quản lý đơn đa sàn tự xây hoặc hệ thống livestream riêng.