2.3K 54 253

Đã đăng vào khoảng 11 giờ trước 20 phút đọc

Cấu hình Cloud Server cho API backend: Chọn CPU, RAM, SSD và băng thông như thế nào?

API backend có thể hoạt động ổn định trên một máy chủ cấu hình nhỏ trong giai đoạn thử nghiệm, nhưng nhanh chóng gặp tình trạng phản hồi chậm, quá tải CPU hoặc mất kết nối database khi lượng request tăng. Nguyên nhân thường không nằm ở việc server “yếu” hay “mạnh” nói chung, mà do cấu hình chưa phù hợp với đặc điểm workload của API. Bài viết này trình bày cách đánh giá CPU, RAM, ổ đĩa và băng thông khi lựa chọn Cloud Server cho API backend, đồng thời hướng dẫn cách kiểm tra cấu hình bằng dữ liệu thực tế thay vì chỉ dựa vào số lượt truy cập.

Lưu ý: Các mức CPU và RAM trong bài chỉ là cấu hình khởi điểm để dựng môi trường và load test, không phải cam kết về số người dùng hoặc số request mà hệ thống có thể xử lý.

1. Vì sao cấu hình API backend không thể chỉ dựa vào lượng người dùng?

Hai hệ thống có cùng 10.000 người dùng mỗi ngày vẫn có thể cần cấu hình Cloud Server hoàn toàn khác nhau.

Một API chỉ trả về dữ liệu đã cache thường sử dụng rất ít CPU. Ngược lại, một API cần truy vấn nhiều bảng database, xử lý hình ảnh, tạo báo cáo hoặc gọi nhiều dịch vụ bên ngoài có thể tiêu thụ tài nguyên lớn dù số người dùng không nhiều.

Khi lựa chọn cấu hình, cần quan tâm đến các dữ liệu sau:

Số request trung bình mỗi giây.
Số request cao nhất trong giờ cao điểm.
Số người dùng đồng thời.
Thời gian phản hồi trung bình và các percentile quan trọng.
Loại tác vụ được API thực hiện.
Dung lượng dữ liệu trả về.
Số lượng kết nối database.
Số tiến trình chạy nền.
Tốc độ tăng trưởng dữ liệu.
Khả năng cache kết quả.

Lượng truy cập theo ngày chỉ là một dữ liệu tham khảo. Chỉ số quan trọng hơn là hệ thống phải xử lý bao nhiêu request cùng lúc và mỗi request tiêu thụ bao nhiêu tài nguyên.

2. Xác định loại workload của API backend

2.1. API CRUD thông thường

Đây là nhóm API thực hiện các tác vụ như đăng nhập, xác thực người dùng, lấy danh sách sản phẩm, tạo đơn hàng hoặc cập nhật hồ sơ.

Workload này thường phụ thuộc nhiều vào database, tốc độ ổ đĩa và cách tối ưu truy vấn. Việc tăng CPU chưa chắc giúp hệ thống nhanh hơn nếu nguyên nhân nằm ở truy vấn thiếu index hoặc connection pool chưa phù hợp.

2.2. API xử lý tính toán

Nhóm này thực hiện các tác vụ tổng hợp dữ liệu, mã hóa, giải mã, tạo báo cáo, xử lý thuật toán hoặc chuyển đổi định dạng.

Đây thường là workload phụ thuộc CPU. Khi số request đồng thời tăng, CPU có thể nhanh chóng đạt mức sử dụng cao.

2.3. API xử lý file và hình ảnh

Các tác vụ upload file, resize ảnh, tạo thumbnail, chuyển đổi định dạng hoặc nén tài liệu có thể đồng thời sử dụng CPU, RAM, Disk I/O và băng thông.

Không nên xử lý toàn bộ tác vụ nặng ngay trong request chính vì người dùng sẽ phải chờ lâu và API dễ timeout. Một cách phù hợp hơn là đưa tác vụ vào queue để worker xử lý bất đồng bộ.

Client
   v
API Backend
   v
Message Queue
   v
Worker xử lý file
   v
Object Storage

2.4. API làm việc với AI hoặc dịch vụ bên ngoài

Một API backend có thể gọi AI API, cổng thanh toán, hệ thống vận chuyển, dịch vụ gửi email, SMS hoặc hệ thống của đối tác. Trong trường hợp này, thời gian phản hồi không chỉ phụ thuộc vào Cloud Server mà còn phụ thuộc vào dịch vụ bên ngoài.

Thiết lập timeout hợp lý.
Có cơ chế retry có kiểm soát.
Sử dụng circuit breaker khi cần.
Đưa tác vụ không cần trả kết quả ngay vào queue.
Cache dữ liệu ít thay đổi.
Giới hạn số request tới bên thứ ba.

3. CPU ảnh hưởng đến API backend như thế nào?

CPU xử lý mã nguồn ứng dụng, mã hóa dữ liệu, serialize JSON, xác thực token và các tác vụ tính toán.

Những dấu hiệu cho thấy API có thể thiếu CPU gồm:

CPU thường xuyên duy trì ở mức cao.
Response time tăng rõ rệt khi lượng request tăng.
Load Average vượt quá khả năng xử lý của máy chủ.
Worker hoặc process phải chờ CPU.
API bình thường khi ít người dùng nhưng chậm vào giờ cao điểm.
Tác vụ nền ảnh hưởng tới request của người dùng.

top

htop

uptime

vmstat 1

Không nên chỉ nhìn vào CPU tại một thời điểm. Cần theo dõi trong toàn bộ chu kỳ hoạt động, đặc biệt là giờ cao điểm và thời điểm chạy cronjob hoặc background job.

Khi nào nên tăng CPU?

Nếu API chậm do database, network hoặc dịch vụ bên ngoài, việc tăng CPU có thể không tạo ra khác biệt đáng kể.

Ứng dụng có nhiều tác vụ tính toán.
CPU duy trì ở mức cao trong thời gian dài.
Response time tăng tương ứng với CPU usage.
Code và database đã được tối ưu nhưng hệ thống vẫn thiếu năng lực xử lý.
Số process hoặc worker hiện tại không thể mở rộng vì thiếu CPU.

4. API backend cần bao nhiêu RAM?

RAM được sử dụng bởi hệ điều hành, runtime của ứng dụng, process hoặc worker, connection pool, cache, database, queue, Redis, buffer xử lý file và các agent giám sát.

Có thể hình dung tổng RAM cần thiết theo công thức:

Tổng RAM cần thiết
=
RAM hệ điều hành
+ RAM ứng dụng
+ RAM của toàn bộ worker
+ RAM database/cache
+ khoảng dự phòng

Có thể kiểm tra RAM, swap và các process tiêu thụ nhiều bộ nhớ bằng các lệnh sau:

free -m

ps aux --sort=-%mem | head

swapon --show

Dấu hiệu API backend thiếu RAM

Swap có thể hỗ trợ hệ thống trong một số tình huống ngắn hạn nhưng không nên được coi là phương án thay thế cho RAM. Khi ứng dụng phải đọc và ghi dữ liệu liên tục từ swap, hiệu năng có thể giảm rõ rệt.

Hệ thống sử dụng swap thường xuyên.
Process bị hệ điều hành dừng đột ngột.
Container tự restart.
API trả về lỗi không ổn định.
Database hoặc application bị kill.
Thời gian phản hồi tăng khi RAM gần đầy.
Xuất hiện thông báo Out of Memory trong log.

5. SSD và Disk I/O có quan trọng với API không?

Nhiều API backend không đọc file trực tiếp trong mỗi request, nhưng ổ đĩa vẫn ảnh hưởng tới database, log, temporary file, upload file, container image, backup và queue lưu trên ổ đĩa.

Ngoài dung lượng SSD, cần quan tâm đến IOPS, throughput, độ trễ đọc ghi và mức độ chia sẻ tài nguyên.

df -h

df -i

iostat -xz 1

Nếu I/O wait tăng cao, CPU có thể chưa sử dụng hết nhưng ứng dụng vẫn phản hồi chậm vì phải chờ dữ liệu từ ổ đĩa.

Các tình huống thường gây nghẽn Disk I/O gồm:

Ghi log quá nhiều.
Database thực hiện truy vấn toàn bảng.
Backup chạy trong giờ cao điểm.
Nhiều worker cùng đọc và ghi file.
Ổ đĩa gần đầy.
Log không được rotation.
Database và ứng dụng dùng chung một ổ đĩa có tải lớn.

6. Băng thông và network ảnh hưởng tới API ra sao?

API trả về JSON nhỏ thường không cần quá nhiều băng thông. Tuy nhiên, network có thể trở thành điểm nghẽn nếu API trả về file lớn, phục vụ hình ảnh hoặc video, đồng bộ dữ liệu giữa nhiều hệ thống, kết nối database từ xa hoặc gọi nhiều dịch vụ bên ngoài.

Có thể ước tính băng thông theo công thức:

Băng thông sử dụng
=
Số request x kích thước response trung bình x khoảng thời gian

Cần theo dõi kích thước request, kích thước response, network latency, packet loss, số kết nối đồng thời và thời gian kết nối tới dịch vụ phụ thuộc.

Không nên dùng API backend để phân phối trực tiếp các file tĩnh lớn nếu có thể chuyển chúng sang Object Storage hoặc CDN.

7. Những dữ liệu cần thu thập trước khi chọn cấu hình

Trước khi lựa chọn Cloud Server, nên chuẩn bị một bộ dữ liệu tối thiểu thay vì quyết định theo cảm tính.

Đối với hệ thống mới chưa có dữ liệu production, có thể lấy thông tin từ môi trường staging, kết quả load test, lưu lượng của hệ thống cũ, dự báo marketing hoặc số giao dịch dự kiến.

Dữ liệu	Nội dung cần thu thập
Lượng request trung bình	Request mỗi giây hoặc mỗi phút
Lượng request cao điểm	Mức lớn nhất trong thời gian peak
Response time	Trung bình và percentile
Error rate	Tỷ lệ request lỗi
Người dùng đồng thời	Số kết nối cùng lúc
Kích thước response	Dung lượng trung bình của dữ liệu trả về
Database	Dung lượng, số query và số connection
Background job	Số lượng và thời gian xử lý
File	Dung lượng upload, download và xử lý
Tăng trưởng	Dự kiến traffic và dữ liệu trong thời gian tới

8. Cách ước tính số request đồng thời

Một phép ước tính đơn giản là:

Concurrent request ≈ Request mỗi giây x thời gian phản hồi trung bình

Ví dụ, nếu API xử lý 50 request mỗi giây và mỗi request mất trung bình 0,2 giây thì hệ thống có khoảng 10 request đang được xử lý đồng thời.

Đây chỉ là cách ước tính cơ bản. Trên thực tế còn phải xét đến endpoint có thời gian phản hồi khác nhau, background job, database connection, network timeout, garbage collection, traffic tăng đột biến và retry từ client.

9. Cấu hình khởi điểm tham khảo cho API backend

Không có một cấu hình phù hợp cho mọi API. Bảng dưới đây chỉ nên được dùng làm điểm bắt đầu để dựng môi trường và thực hiện load test.

Các mức trên không phải cam kết về số lượng người dùng hoặc request có thể xử lý. Cùng một cấu hình nhưng ứng dụng được tối ưu tốt có thể cho kết quả rất khác so với ứng dụng có truy vấn chậm hoặc xử lý đồng bộ quá nhiều tác vụ.

Môi trường	CPU tham khảo	RAM tham khảo	Mục đích
Development/Test	1-2 vCPU	2-4 GB	Phát triển và kiểm thử chức năng
API production nhỏ	2-4 vCPU	4-8 GB	API CRUD, traffic chưa cao
API đang tăng trưởng	4-8 vCPU	8-16 GB	Nhiều worker, cache và request đồng thời
Workload xử lý nặng	Cần benchmark	Cần benchmark	Xử lý file, tính toán hoặc nhiều background job

Trường hợp API và database dùng chung Cloud Server

Khi application và database chạy trên cùng server, cần cộng thêm tài nguyên cho database buffer, connection, Disk I/O, backup, log và cache.

Mô hình này phù hợp với giai đoạn đầu hoặc hệ thống nhỏ. Khi tải tăng, nên cân nhắc tách database để giảm cạnh tranh tài nguyên.

Mô hình ban đầu:

Client
   v
Cloud Server
|-- Nginx
|-- API Backend
|-- Database
`-- Redis

Mô hình tách dịch vụ:

Client
   v
Load Balancer/Nginx
   v
API Backend
   |-- Database
   |-- Redis
   |-- Queue
   `-- Object Storage

10. Số worker có ảnh hưởng đến cấu hình server không?

Có. Mỗi worker có thể sử dụng thêm RAM và CPU.

Nếu cấu hình quá ít worker: request phải chờ, thời gian phản hồi tăng và CPU có thể chưa được tận dụng hết.
Nếu cấu hình quá nhiều worker: RAM bị sử dụng quá mức, tăng context switching, tăng số connection database và hệ thống dễ mất ổn định.

Số worker phù hợp phụ thuộc vào ngôn ngữ, runtime, loại workload, số CPU, lượng RAM của mỗi process, thời gian xử lý request và giới hạn connection của database.

Không nên sao chép cấu hình worker từ một hệ thống khác mà chưa đo mức sử dụng tài nguyên.

11. Load test trước khi quyết định cấu hình

Load test giúp trả lời các câu hỏi quan trọng trước khi đưa API vào production:

API xử lý được bao nhiêu request mỗi giây?
Response time tăng ở thời điểm nào?
CPU, RAM hay database trở thành bottleneck trước?
Error rate bắt đầu tăng từ mức tải nào?
Hệ thống phục hồi ra sao sau khi traffic giảm?

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 10 },
    { duration: '3m', target: 10 },
    { duration: '1m', target: 30 },
    { duration: '3m', target: 30 },
    { duration: '1m', target: 0 },
  ],
};

export default function () {
  const response = http.get('https://api.example.com/v1/products');

  check(response, {
    'status is 200': (r) => r.status === 200,
    'response under 500 ms': (r) => r.timings.duration < 500,
  });

  sleep(1);
}

Kịch bản thực tế nên bao gồm nhiều endpoint như đăng nhập, lấy dữ liệu, tạo dữ liệu, cập nhật dữ liệu, upload file, tìm kiếm và endpoint có truy vấn nặng.

Trong thời gian load test, cần theo dõi đồng thời tài nguyên máy chủ:

top
free -m
iostat -xz 1
vmstat 1

Có thể sử dụng k6 để tạo một kịch bản kiểm thử cơ bản:

Ngoài ra cần theo dõi response time, request per second, error rate, database connection, slow query, queue length, disk latency và network throughput.

Không nên load test trực tiếp trên production nếu chưa có phương án kiểm soát rủi ro.

12. Khi nào nên scale up?

Scale up là tăng tài nguyên cho Cloud Server hiện tại, chẳng hạn tăng CPU, RAM, hiệu năng ổ đĩa hoặc băng thông.

Kiến trúc hiện tại vẫn đáp ứng được nhu cầu.
Hệ thống chưa cần nhiều node.
Bottleneck đã được xác định rõ.
Việc nâng cấu hình có thể xử lý vấn đề trong ngắn hạn.
Ứng dụng chưa được thiết kế để chạy trên nhiều instance.

Scale up dễ thực hiện nhưng tài nguyên của một server luôn có giới hạn và hệ thống vẫn phụ thuộc vào một điểm duy nhất.

13. Khi nào nên scale out?

Scale out là tăng số lượng API server và phân phối request qua Load Balancer.

Traffic thay đổi lớn theo thời điểm.
Một server không còn đủ khả năng xử lý.
Hệ thống cần High Availability.
API có thể chạy theo mô hình stateless.
Cần bảo trì một node mà không làm gián đoạn toàn bộ dịch vụ.

                    .-- API Server 1
Client -> Load Balancer
                    |-- API Server 2
                    `-- API Server 3

Trước khi scale out, cần xử lý các yêu cầu sau:

Session không lưu cục bộ trên từng server.
File upload không chỉ lưu trên ổ đĩa local.
Các instance dùng chung database hoặc storage.
Có Load Balancer và health check.
Cấu hình và secret được quản lý nhất quán.
Log và monitoring được tập trung.

Nếu ứng dụng vẫn lưu session, file hoặc trạng thái quan trọng trên một máy chủ, việc thêm nhiều API instance có thể gây lỗi không nhất quán.

14. Những sai lầm thường gặp khi chọn cấu hình API backend

Chỉ dựa vào số người dùng

Số người dùng không phản ánh trực tiếp số request đồng thời hoặc mức tiêu thụ tài nguyên.

Tăng RAM khi chưa xác định bottleneck

API chậm không đồng nghĩa với thiếu RAM. Nguyên nhân có thể nằm ở database, network, code hoặc dịch vụ bên ngoài.

Đặt application, database và worker trên một server quá lâu

Mô hình này đơn giản nhưng các thành phần có thể cạnh tranh CPU, RAM và Disk I/O khi traffic tăng.

Không giới hạn connection database

Quá nhiều worker có thể tạo ra quá nhiều connection, khiến database trở thành điểm nghẽn.

Xử lý tác vụ nặng trong request chính

Xử lý ảnh, tạo báo cáo hoặc gửi nhiều email nên được đưa vào queue nếu không cần trả kết quả ngay lập tức.

Không có khoảng tài nguyên dự phòng

Nếu hệ thống luôn hoạt động sát giới hạn, một đợt traffic tăng nhỏ hoặc cronjob bất thường cũng có thể gây quá tải.

Không thực hiện load test

Cấu hình được chọn theo cảm tính sẽ khó dự đoán được hệ thống hoạt động ra sao trong giờ cao điểm.

Không theo dõi sau khi đưa vào production

Load test chỉ mô phỏng một phần hoạt động thực tế. Sau khi triển khai vẫn cần monitoring liên tục để điều chỉnh cấu hình.

15. Checklist cấu hình Cloud Server cho API backend

Tài nguyên

Đã xác định workload chính của API.
Đã đo CPU và RAM trên staging.
Đã kiểm tra Disk I/O.
Đã ước tính băng thông.
Có khoảng tài nguyên dự phòng.
Đã load test với traffic gần thực tế.

Application

Đã cấu hình số worker phù hợp.
Có timeout cho request.
Có connection pool.
Có giới hạn kích thước request.
Tác vụ nặng đã được đưa vào queue.
API có rate limit nếu cần thiết.

Database

Database có index phù hợp.
Đã kiểm tra slow query.
Có giới hạn connection.
Có backup tự động.
Đã kiểm tra khả năng restore.

Bảo mật

Sử dụng HTTPS.
Hạn chế port không cần thiết.
Không đăng nhập root bằng mật khẩu.
Secret không được lưu trực tiếp trong source code.
Hệ điều hành và package được cập nhật.
Có cơ chế chống brute force hoặc request bất thường.

Monitoring

Theo dõi CPU và RAM.
Theo dõi dung lượng ổ đĩa.
Theo dõi response time.
Theo dõi error rate.
Theo dõi database connection.
Có cảnh báo khi dịch vụ ngừng hoạt động.
Log được rotation và lưu trữ phù hợp.

Kết luận

Cấu hình Cloud Server cho API backend không nên được lựa chọn chỉ dựa trên số lượt truy cập hoặc một bảng cấu hình cố định. Một quyết định phù hợp cần bắt đầu từ việc xác định loại workload, số request đồng thời, mức sử dụng CPU, RAM, Disk I/O, network và các dịch vụ phụ thuộc.

Có thể bắt đầu bằng một cấu hình vừa đủ để dựng môi trường, sau đó thực hiện load test và theo dõi hệ thống trong production. Khi xuất hiện bottleneck, cần xác định đúng nguyên nhân trước khi tăng tài nguyên.

Nếu ứng dụng đã được tối ưu nhưng vẫn thường xuyên quá tải, đội ngũ có thể cân nhắc scale up Cloud Server hoặc chuyển sang kiến trúc nhiều API instance kết hợp Load Balancer, cache, queue và storage độc lập.

Gợi ý bước tiếp theo

Khi cần chủ động lựa chọn CPU, RAM, SSD, băng thông và khả năng mở rộng cho API backend, bạn có thể tham khảo giải pháp Cloud Server của Bizfly Cloud và đối chiếu cấu hình với dữ liệu load test của hệ thống. Xem giải pháp Cloud Server Bizfly Cloud