5 NGINX 동작 원리

참고자료

5.1 NGINX process model 과 기본 기능

5.1.1 Master Process

NGINX를 실행시키면 가장 먼저 실행되는 프로세스이다. 이하에 나오는 다른 역할의 프로세스들을 시작시키는 역할 또한 한다.

Master Proces는 (linux기준) systemd로 관리되는 프로그램이다. systemd 는 Linux의 가장 기본 구성요소이고, 가장 먼저 뜨는 프로세스로 PID=1을 가지고 있다. 운영체제 시스템 수준에서 프로세스들을 관리한다. 그래서 master process의 parent pid 가 1인 것을 확인할 수 있다.

ps -ef --forest | grep nginx

master process는 다음 기능들을 한다.

• configuration
• port binding
• start worker/helper process as child process
  • Fork 를 사용한다.
• reload configuration gracefully

5.1.2 Worker Process

Network 요청에 대한 모든 일을 한다. Master process로 부터 받은 설정을 이용해서 connection, proxy, read/write 등을 한다.
upstream server와 연결하는 프로세스이다.

worker process는 single thread 이고 모든 동작을 비동기로 처리한다. worker process 들 사이는 동작과 메모리 공간이 독립적이다.

worker_processes auto;

• 설정을 하면, CPU 코어 수에 맞게 worker process 의 수가 뜬다.
• worker process는 각 요청을 비동기로 처리하기 때문에 worker process가 코어의 수보다 많을 필요는 없다.
  • 불필요한 context switching이 일어나지 않도록 하자.

5.1.3 Cache Loader

시작할 때 실행되는 프로세스로, disk 에 있는 cache를 메모리로 올리는 역할을 한다.
역할을 다 하면 종료된다.

5.1.4 Cache Manager

주기적으로 실행되어 디스크 캐시를 비워 메모리 사이즈를 일정 크기 이내로 유지하도록 한다.

5.2 Worker Process 내부 동작

모든 worker thread 는 master process로부터 fork 될때, master process의 메모리에 있는 설정을 copy 받는다.
listen socket 또한 master process로부터 공유받고, socket event 를 받을 수 있다. (accept_mutex, kernel_socket_sharing 로 가능하다.)

worker process로 연결이 맺어지면, 위 그림과 같이 state machine으로 동작한다. 각 동작, 구성의 사이는 비동기로 동작한다.

state machine이란?
State machine은 어떤 시스템이나 프로그램이 여러 개의 ‘상태(state)’ 중 하나에 머물며 동작하다가, 특정 조건이나 입력에 따라 다른 상태로 전이(transition)되는 논리적 구조이다.
이때 각 상태는 특정 동작을 수행하고, 상태 간 전이는 미리 정의된 규칙에 따라 이루어진다.
예를 들어 버튼을 눌렀을 때 “대기 → 실행” 상태로 바뀌고, 일정 시간이 지나면 다시 “대기” 상태로 돌아오는 식이다.
이런 상태 전이 구조는 흐름을 명확히 하고 복잡한 로직을 간결하게 관리할 수 있게 해준다.
state machine은 주로 UI, 네트워크 연결, 게임 로직, 통신 프로토콜 등에서 많이 사용된다.
직접 기능을 수행한다기보다, 프로그램의 전체 동작 흐름을 구조화하고 설명하는 추상적인 모델이다.
복잡한 프로그램을 설계할 때 상태 단위로 나눠 사고할 수 있어서 유지보수와 디버깅이 쉬워진다.

• worker process 는 listen socket 또는 connection socket 으로부터의 event 를 기다린다.
  • 이것이 가능한 이유는 비동기 IO 멀티플렉싱 기술인 epoll, kqueue 가 운영체제 레벨에서 가능하기 때문이다.
• 이벤트가 오면
  • listen socket 으로부터 이벤트가 오면, connection socket 을 만들고 다시 wait 상태로 돌아간다. (이걸 깨워주는 건 epoll이다)
  • connection 소켓으로 이벤트가 오면, 해당 connection 에서 필요한 state 에 맞는 동작을 한 뒤 다시 wait 으로 돌아간다.

멀티플렉싱이란?

5.3 NGINX Update

5.3.1 Configuration Update

NGINX는 새로운 설정을 적용할 때 downtime 없이 적용할 수 있다.

• -s reload 요청이 들어오면, 마스터 프로세스는 설정파일을 다시 읽어서 메모리에 올린다.
• 새로운 설정으로 요청을 처리할 수 있는 worker process 들을 fork 한다.
• master process는 old worker process에게 (gracefully) exit 시그널을 보낸다.
• old worker process는 여전히 old config 를 메모리에 들고 요청을 처리한다.
  • master process 의 (gracefully) exit 받으면 listen socket 으로부터의 이벤트는 받지 않는다. 더 이상의 새로운 요청을 받지 못한다.
  • 기존 connection이 모두 close 되면 자신을 종료한다.
• 트래픽이 적지 않다면, reload 할 때 순간적으로 CPU, memory 사용량이 튀어 오를 수 있다.

5.3.2 Upgrade NGINX

NGINX는 바이너리를 업그레이드 할 때도 downtime없이 Graceful migration 을 할 수 있다.

• 새로운 master 프로세스를 띄운다.
• old master process에는 SIGUSR2 시그널을 보낸다.
• 사용하고 있는 listen, connection socket 에 대해서 new master, old master 프로세스가 모두 공유한다.
• listen socket 에 대한 공유가 끝나면, old master 프로세스는 SIGQUIT 요청을 받는다.
• 기존 연결이 모두 close 되면 old master 프로세스는 종료된다.