Kiến trúc, cách hoạt động và cấu hình cơ bản của Nginx

Nginx (Engine X) là một HTTP web server mã nguồn mở nổi tiếng, được phát triển ban đầu bởi Igor Sysoev vào năm 2004 để giải quyết vấn đề C10k problem (xử lý 10.000 kết nối đồng thời). Hiện nay, Nginx không chỉ là một web server mà còn là một reverse proxy, load balancer và HTTP cache mạnh mẽ.

1. Tổng quan về Nginx

• Nginx là một HTTP web server, reverse proxy, load balancer, content cache, TCP/UDP proxy server, và mail proxy server.
• Được biết đến với tính linh hoạt, hiệu suất cao, ổn định, tiêu thụ tài nguyên thấp, và cấu hình đơn giản.
• Xử lý đồng thời hàng nghìn kết nối hiệu quả nhờ cơ chế event-driven (hướng sự kiện) và non-blocking I/O.

2. Thành phần chính của kiến trúc Nginx

Thành phần chính của kiến trúc Nginx

Master Process:

• Quản lý toàn bộ vòng đời của Nginx.
• Đọc và kiểm tra file cấu hình (nginx.conf).
• Tạo và khởi động các worker processes.
• Xử lý tín hiệu từ hệ thống (như khởi động lại, reload, dừng).
• Không trực tiếp xử lý yêu cầu từ client.

Worker Processes:

• Xử lý các yêu cầu từ client, phục vụ static content, hoặc chuyển tiếp yêu cầu đến backend.
• Làm việc độc lập và tận dụng event-driven để xử lý nhiều kết nối cùng lúc.
• Số lượng worker_processes thường bằng số core CPU để tận dụng tối đa tài nguyên.

Cache Loader Process (tùy chọn):

• Nạp nội dung cache từ ổ đĩa vào bộ nhớ khi khởi động lại.

Cache Manager Process (tùy chọn):

• Quản lý kích thước và dọn dẹp nội dung cache định kỳ.

3. Cách hoạt động của Worker Process

Worker Process tuân theo mô hình event-driven, sử dụng cơ chế như epoll (trên Linux) để xử lý nhiều kết nối đồng thời trên một luồng (thread) duy nhất.

A. Khởi tạo và chờ sự kiện

Khởi tạo: Sau khi được Master Process tạo ra, Worker Process đọc thông tin cấu hình từ tệp cấu hình Nginx và thiết lập vòng lặp sự kiện (event loop) để theo dõi các kết nối mới, các yêu cầu I/O, hoặc các tác vụ cần xử lý.

Chờ sự kiện: Worker Process đăng ký các sự kiện cần theo dõi (như kết nối mới, dữ liệu đến, hoặc ghi dữ liệu xong) với hệ thống thông qua cơ chế epoll.

B. Xử lý kết nối

Nhận sự kiện từ epoll: Khi có sự kiện (như một yêu cầu mới từ client), epoll thông báo cho Worker Process và Worker Process xử lý sự kiện đó ngay lập tức.

Không chặn kết nối: Worker Process không chặn khi chờ dữ liệu hoặc tài nguyên. Nếu dữ liệu chưa sẵn sàng (ví dụ: chưa đọc xong body yêu cầu), Worker Process tạm ngừng và tiếp tục xử lý các kết nối khác trong hàng đợi.

Xử lý song song: Dù mỗi Worker Process chỉ chạy một luồng nhưng nó có thể xử lý hàng nghìn kết nối đồng thời bằng cách xen kẽ giữa các sự kiện trong vòng lặp.

C. Xử lý yêu cầu

Phân tích yêu cầu: Phân tích cú pháp HTTP request (headers, method, URL, v.v.), kiểm tra tính hợp lệ và thực hiện các bước được chỉ định trong cấu hình.

Thực hiện nhiệm vụ: Phục vụ nội dung tĩnh, proxy request đến backend server, hoặc xử lý SSL/TLS.

D. Gửi phản hồi

Chuẩn bị phản hồi: Tạo HTTP response với status code, headers, và body.

Gửi phản hồi: Ghi dữ liệu qua socket hoặc gửi từng phần nếu dữ liệu lớn (chunked response).

E. Kết thúc hoặc giữ kết nối

Sau khi xử lý xong, Worker Process sẽ đóng kết nối nếu không có yêu cầu tiếp theo hoặc giữ kết nối mở nếu HTTP keep-alive được bật.

4. Cấu hình Worker Processes

A. Worker Processes

File cấu hình: /etc/nginx/nginx.conf (Thông thường, file cấu hình có thể nằm trong /usr/local/nginx/conf hoặc /etc/nginx hoặc /usr/local/etc/nginx).

Tùy chỉnh thông qua tham số worker_processes (mặc định: auto = số core CPU).

Ví dụ:

worker_processes auto;

B. Worker Connections

Mỗi worker process có thể xử lý nhiều kết nối đồng thời.

Số kết nối đồng thời tối đa được cấu hình qua directive worker_connections.

Ví dụ:

worker_connections 1024;

Công thức tính số kết nối đồng thời tối đa:
Max Connections = worker_processes × worker_connections

Ví dụ:

• worker_processes 4;
• worker_connections 1024;
• Max Connections = 4 × 1024 = 4096 kết nối đồng thời.

C. Use Epoll (Linux-specific)

Trên hệ thống Linux, nên bật cơ chế epoll để tối ưu hóa hiệu suất xử lý sự kiện.

Ví dụ:

use epoll;

D. CPU Affinity

Chỉ định mỗi Worker Process sử dụng một CPU core cụ thể để giảm chi phí chuyển đổi.

Ví dụ:

worker_cpu_affinity auto;

5. Kết luận

Nginx với kiến trúc hướng sự kiện và khả năng xử lý đồng thời vượt trội, phù hợp cho:

• Máy chủ web (nội dung tĩnh).
• Máy chủ proxy ngược (Reverse Proxy).
• Bộ cân bằng tải (Load Balancer) và quản lý cache.
• Làm gateway cho các ứng dụng microservices.

Việc hiểu rõ kiến trúc và tối ưu cấu hình Nginx giúp nâng cao hiệu suất, giảm thiểu tài nguyên và đảm bảo hệ thống ổn định cho các ứng dụng web quy mô lớn.

Lời khuyên: Nếu bạn đang làm việc với Nginx, việc thử nghiệm và giám sát hiệu năng (monitoring) là điều cần thiết để tối ưu hóa cho từng trường hợp sử dụng cụ thể. Các công cụ như Nginx amplify, Prometheus + Grafana rất hữu ích trong việc này.

Tài liệu tham khảo:

• Explaining Nginx Internal Architecture
• Inside Nginx: How We Designed for Performance & Scale

Nguyễn Thị Mỹ Phương Developer