Nginx Worker Process/Connection 구조가 처리량에 미치는 영향

작성자:

Nginx Worker Process/Connection 구조가 처리량에 미치는 영향

Nginx는 높은 처리량과 낮은 자원 사용량으로 유명한 웹 서버이자 리버스 프록시다.
이러한 성능의 핵심에는 Worker Process와 Worker Connection 구조가 있다.
이 글에서는 Nginx가 요청을 처리하는 내부 구조를 기준으로, Worker 설정이 실제 처리량(Throughput)과 동시 접속 성능에 어떤 영향을 미치는지 기술적으로 분석한다.

1. Nginx 프로세스 모델의 기본 구조

Nginx는 Master Process + 다수의 Worker Process 구조를 사용한다.

  • Master Process
    • 설정 파일 로드
    • Worker 생성 및 관리
    • 무중단 재시작 및 시그널 처리
  • Worker Process
    • 실제 클라이언트 요청 처리
    • 네트워크 I/O 수행
    • 이벤트 루프 기반 비동기 처리

중요한 점은 모든 요청 처리는 Worker가 담당하며, Master는 데이터 처리에 관여하지 않는다는 것이다.

2. Worker Process와 CPU 코어의 관계

Nginx Worker Process는 싱글 스레드 이벤트 루프로 동작한다.
즉, 하나의 Worker는 한 번에 하나의 CPU 코어만 사용할 수 있다.

이 때문에 일반적으로 권장되는 설정은 다음과 같다.

  • worker_processes = CPU 코어 수
  • 각 Worker를 서로 다른 코어에 스케줄링

이 구조의 효과는 다음과 같다.

  • CPU 캐시 활용도 향상
  • 락 경합 최소화
  • 컨텍스트 스위칭 감소

Worker 수가 코어 수보다 적으면 CPU를 충분히 활용하지 못하고,
과도하게 많으면 오히려 컨텍스트 스위칭 비용으로 처리량이 감소한다.

3. Worker Connection의 의미와 역할

worker_connections는 하나의 Worker가 동시에 유지할 수 있는 최대 연결 수를 의미한다.

중요한 점은 다음과 같다.

  • 하나의 클라이언트 연결 = 1 connection
  • 프록시 환경에서는
    • 클라이언트 연결 1
    • 백엔드 서버 연결 1
      → 총 2 connections 사용 가능

즉, 실제 처리 가능한 동시 요청 수는 생각보다 빨리 소진될 수 있다.

4. 최대 동시 연결 수 계산 방식

Nginx의 이론적인 최대 동시 연결 수는 다음과 같이 계산된다.

  • 최대 연결 수 = worker_processes × worker_connections

예시

  • worker_processes 8
  • worker_connections 4096

→ 최대 32768 connections

하지만 이는 이론적 수치이며, 실제 처리량은 다음 요소들에 의해 제한된다.

  • CPU 처리 속도
  • 메모리
  • 네트워크 대역폭
  • Keep-Alive 사용 여부
  • 프록시 연결 구조

5. 이벤트 기반 처리 구조가 처리량에 미치는 영향

Nginx는 epoll(kqueue) 기반 이벤트 모델을 사용한다.
이 구조는 다음과 같은 특징을 가진다.

  • 스레드 생성 없이 수천 개 연결 처리
  • 연결 수 증가에 따른 오버헤드 최소화
  • 대기 상태 연결이 거의 자원 소모 없음

이 덕분에 Nginx는

  • 동시 접속 수가 많아질수록
  • 스레드 기반 서버(Apache prefork 등)보다
    처리량 격차가 커진다.

6. Keep-Alive 설정과 처리량의 관계

Keep-Alive는 연결 재사용을 통해 성능을 높일 수 있지만,
Worker Connection 소모 측면에서는 양날의 검이다.

  • 장점
    • TCP handshake 감소
    • 응답 속도 향상
    • CPU 사용량 감소
  • 단점
    • 연결이 오래 유지됨
    • worker_connections 점유 시간 증가

트래픽이 매우 많은 환경에서는

  • Keep-Alive 시간을 짧게
  • 또는 조건부로 제한
    하는 것이 전체 처리량에 유리한 경우도 많다.

7. 프록시 서버에서의 Worker Connection 병목

Nginx를 리버스 프록시로 사용할 경우,
Worker Connection은 다음과 같이 소모된다.

  • 클라이언트 → Nginx : 1 connection
  • Nginx → 백엔드 : 1 connection

즉, 하나의 요청이 Worker Connection 2개를 동시에 사용할 수 있다.

이 경우

  • worker_connections 값이 낮으면
  • 백엔드 응답이 느릴수록
    Worker가 빠르게 포화 상태에 도달한다.

고처리량 프록시 환경에서는

  • worker_connections 충분히 증가
  • upstream keepalive 설정 병행
    이 필수적이다.

8. 처리량 관점에서의 병목 발생 지점

Worker 구조로 인해 처리량 병목은 주로 다음 지점에서 발생한다.

  • Worker Process 수 부족 → CPU 미사용
  • Worker Connection 부족 → 접속 대기 발생
  • Keep-Alive 과다 → 연결 고착
  • 백엔드 응답 지연 → Worker 점유 시간 증가
  • 네트워크 대역폭 한계

특히 Worker는 멀티스레드가 아니기 때문에
하나의 요청이 오래 걸리면 해당 Worker의 이벤트 루프 전체에 영향을 준다는 점이 중요하다.

9. 실무 환경에서의 설정 전략

고처리량 환경에서 일반적으로 사용되는 전략은 다음과 같다.

  • worker_processes = CPU 코어 수
  • worker_connections는 예상 동시 연결 수 기준으로 넉넉히 설정
  • 프록시 환경에서는 connection 2배 사용 고려
  • Keep-Alive 시간 최소화
  • 느린 백엔드 요청 타임아웃 설정
  • access log 비동기 처리 또는 최소화

이러한 설정은 단일 Worker의 점유 시간을 줄이는 방향으로 설계되어야 한다.

10. 정리 및 결론

Nginx의 높은 처리량은
단순히 빠른 네트워크 처리 때문이 아니라,
Worker Process와 Worker Connection의 이벤트 기반 구조에서 나온다.

핵심 요약

  • Worker Process는 CPU 코어 단위로 처리량을 결정
  • Worker Connection은 동시 접속 한계를 직접 제한
  • 프록시 환경에서는 Connection 소모가 2배 이상 발생
  • Keep-Alive는 처리량과 자원 사용의 균형이 중요
  • 병목은 Worker 수가 아니라 Worker 점유 시간에서 발생

Nginx 성능 튜닝의 핵심은
“Worker를 얼마나 많이 두느냐”가 아니라,
Worker가 얼마나 빠르게 요청을 처리하고 해제하느냐에 있다.

댓글 남기기