Cách dự tính tài nguyên Cloud server cho mùa cao điểm

Mùa cao điểm có thể đến từ nhiều tình huống: flash sale, chiến dịch quảng cáo lớn, livestream bán hàng, lễ Tết, mở bán sản phẩm hoặc một sự kiện khiến lượng truy cập tăng mạnh trong thời gian ngắn. Một hệ thống hoạt động ổn định vào ngày thường vẫn có thể phản hồi chậm, phát sinh lỗi 5xx hoặc ngừng dịch vụ khi số request đồng thời vượt quá khả năng xử lý.

Vì vậy, việc dự tính tài nguyên cho mùa cao điểm không nên chỉ dựa vào cảm tính hoặc đơn giản là “tăng gấp đôi CPU và RAM”. Cách làm phù hợp hơn là chuyển dự báo kinh doanh thành các chỉ số kỹ thuật như request mỗi giây, người dùng đồng thời, mức sử dụng CPU, RAM, Disk I/O, băng thông, số connection database và độ dài hàng đợi.

Bài viết này trình bày cách xây dựng kế hoạch capacity planning cho Cloud Server trước mùa cao điểm, từ việc thu thập baseline, xác định hệ số tăng trưởng, load test đến lựa chọn giữa scale up và scale out.

Lưu ý: Các công thức trong bài là cách ước tính ban đầu. Cấu hình cuối cùng nên được xác nhận bằng dữ liệu monitoring và load test trên chính hệ thống cần triển khai.

1. Vì sao không nên chỉ nhìn vào số lượt truy cập?

Một website có 100.000 lượt truy cập mỗi ngày chưa chắc cần hạ tầng mạnh hơn một website chỉ có 20.000 lượt truy cập.

Điểm khác biệt nằm ở cách traffic phân bố.

Ví dụ:

• Website A có 100.000 lượt truy cập nhưng phân bổ đều trong 24 giờ.
• Website B chỉ có 20.000 lượt truy cập nhưng 50% tập trung trong 15 phút đầu của một chương trình mở bán.

Trong trường hợp thứ hai, hệ thống có thể chịu áp lực lớn hơn nhiều vì phải xử lý lượng request đồng thời rất cao.

Ngoài ra, cùng một lượt truy cập nhưng workload cũng khác nhau:

• Trang tin tức chủ yếu đọc dữ liệu và có thể cache.
• Website thương mại điện tử phải kiểm tra giá, tồn kho và tạo đơn hàng.
• Hệ thống đặt vé phải xử lý transaction và tránh bán trùng.
• API báo cáo phải truy vấn lượng dữ liệu lớn.
• Ứng dụng AI có thể gọi model hoặc dịch vụ bên ngoài.

Do đó, không nên chỉ dựa vào pageview hoặc session. Những chỉ số quan trọng hơn gồm request mỗi giây, người dùng đồng thời, response time, error rate, CPU, RAM, database connection, Disk I/O, băng thông và cache hit ratio.

2. Bắt đầu bằng baseline của hệ thống hiện tại

Trước khi dự báo mùa cao điểm, cần biết hệ thống đang vận hành như thế nào ở ngày bình thường.

Baseline là tập hợp các số liệu cho biết mức tải hiện tại và lượng tài nguyên mà hệ thống đang sử dụng.

Nhóm	Chỉ số cần theo dõi
Traffic	RPS, request/phút, pageview
Application	Response time, P95, P99, error rate
CPU	CPU trung bình và mức peak
RAM	RAM sử dụng, available memory, swap
Disk	IOPS, throughput, latency, dung lượng
Database	Query/s, connection, slow query, lock
Network	Bandwidth, latency, packet loss
Cache	Hit ratio, miss, eviction
Queue	Job vào, job xử lý, backlog

Không nên chỉ xem giá trị trung bình. CPU trung bình trong ngày có thể chỉ 30% nhưng vẫn tăng lên 90% trong vài phút vào giờ cao điểm. Nếu chỉ nhìn average CPU, đội ngũ có thể đánh giá sai khả năng chịu tải.

Một baseline tốt phải trả lời được câu hỏi: ở mức traffic hiện tại, hệ thống đang dùng bao nhiêu tài nguyên?

3. Xác định traffic dự kiến trong mùa cao điểm

Nguồn dữ liệu có thể đến từ:

• Kết quả campaign trước.
• Dự báo của Marketing.
• Ngân sách quảng cáo.
• Số email hoặc SMS dự kiến gửi.
• Lượng người đăng ký trước.
• Lịch mở bán.
• Lưu lượng cùng kỳ năm trước.

Có thể tính hệ số tăng trưởng:

Hệ số tăng trưởng
=
Traffic cao điểm dự kiến
/
Traffic hiện tại trong cùng khoảng thời gian

Ví dụ ngày thường có 4.000 lượt truy cập trong một giờ, campaign dự kiến đạt 16.000 lượt trong cùng một giờ:

16.000 / 4.000 = 4

Hệ số tăng trưởng bằng 4.

Tuy nhiên, không nên áp dụng hệ số 4 cho toàn bộ hệ thống. Landing page có thể tăng 5 lần, đăng nhập tăng 3 lần, tạo đơn hàng tăng 8 lần và background job tăng 10 lần. Vì vậy cần phân tích theo từng luồng người dùng.

4. Chuyển traffic thành request mỗi giây

Request mỗi giây, hay RPS, là một trong những chỉ số dễ dùng nhất để lập kế hoạch hạ tầng.

RPS trung bình
=
Tổng số request
/
Tổng thời gian tính bằng giây

Giả sử hệ thống dự kiến nhận 720.000 request trong một giờ:

720.000 / 3.600 = 200 RPS

Nhưng đây chỉ là mức trung bình. Trong thực tế, traffic thường tập trung mạnh vào một số thời điểm. Vì vậy cần thêm hệ số peak.

Nếu peak cao gấp 2,5 lần trung bình:

RPS peak
=
200 x 2,5
=
500 RPS

Khi load test, không nên chỉ test ở 200 RPS. Nên kiểm tra thêm 300, 400, 500 RPS và một mức cao hơn để xác định giới hạn thật của hệ thống.

5. Phân biệt request trình duyệt và request về origin

Một pageview có thể tạo hàng chục request gồm HTML, CSS, JavaScript, hình ảnh, font, API và tracking.

Nếu website sử dụng CDN:

Người dùng
   |
   v
CDN
   |
   |-- Hình ảnh
   |-- CSS
   |-- JavaScript
   `-- Font

Origin
   |
   |-- HTML động
   |-- API
   `-- Database

Ví dụ một trang tạo 50 request nhưng 40 request được CDN cache và chỉ 10 request phải về origin. Khi capacity planning, tải thực tế của Cloud Server cần tập trung vào 10 request còn lại.

Nếu tính toàn bộ 50 request như tải backend, cấu hình có thể bị dự tính quá cao. Ngược lại, nếu chỉ tính một pageview là một request, hạ tầng có thể bị đánh giá thấp hơn thực tế.

6. Ước tính số request đồng thời

Có thể dùng công thức:

Concurrent request
≈
RPS x response time

Ví dụ 300 RPS và response time trung bình 0,2 giây:

300 x 0,2 = 60 request đồng thời

Nếu hệ thống bắt đầu chậm và response time tăng lên 1 giây:

300 x 1 = 300 request đồng thời

Đây là lý do một hệ thống có thể chuyển từ trạng thái bình thường sang quá tải rất nhanh.

Response time tăng
        |
        v
Request tồn tại lâu hơn
        |
        v
Số request đồng thời tăng
        |
        v
Worker và connection bị chiếm
        |
        v
Response time tiếp tục tăng

7. Dự tính CPU

CPU thường xử lý logic application, PHP, Node.js, Java, serialize JSON, mã hóa, compression, xử lý hình ảnh và background worker.

Có thể dùng mức CPU hiện tại làm điểm tham khảo.

Ví dụ:

• 4 vCPU.
• 100 RPS.
• CPU peak khoảng 35%.

Mùa cao điểm dự kiến 300 RPS.

35% x 3 = 105%

Điều này cho thấy cấu hình hiện tại có khả năng không đủ.

Tuy nhiên, CPU không phải lúc nào cũng tăng tuyến tính vì cache có thể giảm tải, database có thể thành bottleneck trước CPU, worker có thể đạt giới hạn hoặc lock làm request phải chờ.

Dấu hiệu thiếu CPU

• CPU duy trì cao trong thời gian dài.
• Load Average tăng liên tục.
• Response time tăng cùng CPU usage.
• Queue tăng nhanh.
• Worker không xử lý kịp.
• Background job ảnh hưởng request người dùng.

Không nên thiết kế server hoạt động sát 100% CPU trong giờ peak. Cần có khoảng tài nguyên dự phòng.

8. Dự tính RAM

RAM được sử dụng bởi hệ điều hành, web server, application worker, database, Redis, queue, container và monitoring agent.

Có thể tính:

RAM tổng
=
OS
+ Application
+ Worker
+ Database
+ Cache
+ Tiến trình nền
+ Dự phòng

Ví dụ:

Thành phần	RAM
OS và agent	1 GB
Application	2 GB
10 worker	4 GB
Redis	1 GB
Database	3 GB
Dự phòng	2 GB
Tổng	13 GB

Trong trường hợp này, cấu hình 8 GB RAM sẽ không đủ dù server ngày thường chỉ sử dụng khoảng 5 GB.

Khi RAM thiếu, hệ thống có thể sử dụng swap. Nếu swap tăng mạnh, Disk I/O và response time cũng có thể tăng, thậm chí process bị OOM Kill.

9. Dự tính database

Trong hệ thống giao dịch, database thường là bottleneck trước application server.

Cần theo dõi query mỗi giây, connection, slow query, lock, deadlock và Disk latency. Một lỗi phổ biến là scale application nhưng quên giới hạn của database.

Ví dụ mỗi application server dùng tối đa 30 connection, mùa cao điểm scale lên 8 server:

30 x 8 = 240 connection

Nếu database chỉ xử lý ổn định khoảng 150 connection, việc thêm application server có thể khiến hệ thống lỗi nhanh hơn. Trước mùa cao điểm nên kiểm tra connection pool, index, slow query và transaction.

10. Dự tính Disk I/O và Storage

Disk phục vụ database, log, session, queue, file upload, container và backup. Vì vậy cần theo dõi IOPS, throughput, latency, I/O wait, dung lượng trống và inode.

Ví dụ 5 triệu request/ngày, mỗi request tạo 500 byte access log:

5.000.000 x 500 byte
≈ 2,5 GB/ngày

Nếu giữ log 30 ngày thì riêng access log đã khoảng 75 GB. Cần cấu hình log rotation, nén log và cảnh báo dung lượng.

11. Dự tính băng thông

Có thể ước tính:

Bandwidth
≈
RPS x kích thước response trung bình

Ví dụ 500 RPS và response trung bình 100 KB:

500 x 100 KB
=
50 MB/s

Quy đổi gần đúng:

50 MB/s x 8
≈ 400 Mbps

Nếu phần lớn dữ liệu là hình ảnh, video, CSS hoặc JavaScript, nên chuyển tải sang CDN để Cloud Server tập trung xử lý HTML động, API và transaction.

12. Dự tính cache

Cache có thể giảm đáng kể tải về application và database. Nếu có 1.000 request tới một endpoint và cache hit đạt 90% thì chỉ khoảng 100 request phải xuống backend.

Trước mùa cao điểm nên kiểm tra cache hit ratio, TTL, Redis memory, eviction và warm cache.

Một rủi ro cần tránh là cache stampede: nhiều key cùng hết hạn khiến lượng lớn request đồng thời xuống database. Có thể giảm rủi ro bằng warm cache, TTL lệch nhau và cơ chế lock khi rebuild cache.

13. Dự tính queue và worker

Các tác vụ như gửi email, SMS, tạo hóa đơn hoặc xử lý ảnh nên được đưa vào queue khi không cần phản hồi ngay.

Job backlog
=
Job tạo mới - Job xử lý

Nếu hệ thống tạo 600 job/phút nhưng worker chỉ xử lý 400 job/phút thì mỗi phút tồn thêm 200 job. Backlog tăng liên tục là dấu hiệu cần tăng worker hoặc tối ưu thời gian xử lý.

14. Cần bao nhiêu tài nguyên dự phòng?

Không nên cấu hình đúng bằng mức peak dự kiến. Hệ thống cần headroom cho sai số dự báo, traffic spike, retry, deployment hoặc một node gặp lỗi.

Tài nguyên kế hoạch
=
Tài nguyên peak x hệ số dự phòng

Ví dụ load test cho thấy cần 8 vCPU và chọn hệ số dự phòng 1,25:

8 x 1,25 = 10 vCPU

Hệ số dự phòng cần điều chỉnh theo mức độ quan trọng của hệ thống, không dùng một tỷ lệ cố định cho mọi workload.

15. Scale up hay scale out?

Scale up

Scale up là tăng CPU, RAM, Disk hoặc băng thông cho máy chủ hiện tại.

Phù hợp khi:

• Hệ thống chưa hỗ trợ nhiều instance.
• Cần triển khai nhanh.
• Bottleneck nằm rõ ở server.
• Traffic chưa quá lớn.

Ưu điểm là đơn giản, nhưng một máy chủ vẫn là single point of failure và có giới hạn tài nguyên tối đa.

Scale out

Scale out là tăng số lượng application server:

                    |-- App Server 1
User -> Load Balancer
                    |-- App Server 2
                    `-- App Server 3

Phù hợp khi traffic biến động lớn, cần High Availability hoặc muốn autoscaling.

Trước khi scale out cần đảm bảo session không lưu local, file upload không nằm riêng trên từng server, có shared storage, Load Balancer, health check và log tập trung.

16. Load test trước mùa cao điểm

Đây là bước quan trọng nhất.

Không nên chỉ test một endpoint nhẹ. Kịch bản cần gần với hành vi thực tế:

• Trang chủ.
• Trang sản phẩm.
• Tìm kiếm.
• Đăng nhập.
• Thêm giỏ hàng.
• Checkout.
• API.
• Upload.
• Background job.

Nên test theo nhiều mức:

Warm-up
   |
   v
Traffic bình thường
   |
   v
Traffic tăng dần
   |
   v
Peak dự kiến
   |
   v
Spike cao hơn dự kiến
   |
   v
Giảm tải và theo dõi phục hồi

Các chỉ số cần theo dõi gồm RPS, P95, P99, error rate, CPU, RAM, Disk I/O, database connection, queue backlog, cache hit và network.

17. Ví dụ một kế hoạch capacity

Giả sử website hiện tại có peak 100 RPS, CPU khoảng 35% trên 4 vCPU, RAM 5/8 GB và 60 database connection. Campaign dự kiến tăng tải 3 lần.

Ước tính ban đầu:

CPU: 35% x 3 ≈ 105%
Database connection: 60 x 3 ≈ 180

Kết quả cho thấy cấu hình hiện tại có nguy cơ thiếu CPU và database phải được kiểm tra lại giới hạn connection.

Một kiến trúc có thể cân nhắc:

User -> CDN -> Load Balancer -> App 1 / App 2 / App 3
                              |
                              v
                        Redis + Database

CDN xử lý tài nguyên tĩnh, Load Balancer chia request động và Redis giảm tải database. Các con số cuối cùng vẫn cần xác nhận bằng load test.

18. Checklist trước mùa cao điểm

Traffic

• Đã xác định RPS hiện tại.
• Đã xác định RPS peak.
• Có hệ số tăng trưởng.
• Có hệ số spike.
• Đã xác định endpoint nặng.

Cloud Server

• Đã kiểm tra CPU.
• Đã kiểm tra RAM.
• Đã kiểm tra swap.
• Đã kiểm tra Disk I/O.
• Đã kiểm tra băng thông.
• Có tài nguyên dự phòng.

Database

• Đã kiểm tra slow query.
• Đã kiểm tra index.
• Đã kiểm tra connection pool.
• Đã kiểm tra lock.
• Đã kiểm tra backup.
• Đã thử restore.

Cache và CDN

• Đã kiểm tra cache hit.
• Đã warm cache.
• Đã kiểm tra TTL.
• Đã kiểm tra CDN.
• Đã loại trừ nội dung động.

Monitoring

• Có dashboard.
• Có alert.
• Có người trực.
• Có quy trình xử lý sự cố.
• Có kế hoạch rollback.

Kết luận

Dự tính tài nguyên cho mùa cao điểm không phải là việc nhân CPU và RAM hiện tại theo mức traffic dự kiến. Để capacity planning chính xác hơn, cần chuyển dự báo kinh doanh thành các chỉ số kỹ thuật như RPS, concurrent request, CPU, RAM, Disk I/O, băng thông, database connection và queue backlog.

Quy trình nên gồm bốn bước:

1. Thu thập baseline của hệ thống hiện tại.
2. Dự báo traffic và xác định mức peak.
3. Load test theo hành vi thực tế.
4. Chuẩn bị scale, monitoring và phương án rollback.

Nếu hệ thống hiện tại chỉ thiếu một phần tài nguyên, scale up Cloud Server có thể là cách triển khai nhanh. Nếu traffic biến động lớn và ứng dụng đã hỗ trợ nhiều instance, scale out qua Load Balancer sẽ phù hợp hơn.

Quan trọng nhất là không đợi đến ngày diễn ra chiến dịch mới bắt đầu xử lý. Capacity planning cần được thực hiện đủ sớm để đội ngũ có thời gian load test, tối ưu database, kiểm tra cache và chuẩn bị phương án mở rộng.