Nginx

Web server

Nginx를 알아보기 전 Web server가 뭔지 알아보자.

• HTTP 프로토콜 기반으로 동작한다.

• 클라이언트로 부터 요청을 받아 정적 파일을 응답해준다.

• Web Application Server(WAS)가 너무 많은 역할을 담당하면 트래픽을 감당하지 못할 수 있다. WAS 앞에 Web Server를 둬서 정적 리소스는 Web Server가 처리하도록하고, 애플리케이션 로직같은 동적인 처리를 WAS한테 요청해서 처리한다.
  • 이를 통해 WAS 장애 발생 시 Web Server에서는 별도의 화면 처리가 가능하다.
• 대표적으로 Apache와 Nginx가 있다.

Apache 동작구조

Nginx와의 비교를 위해 Apache가 어떻게 동작하는지 알아보자.

• 클라이언트로부터 요청이 들어올 때 마다 새 프로세스 또는 쓰레드를 생성한다.
  이를 MPM(Multi Process Module)이라 한다.

• 문제점은 프로세스나 쓰레드 생성 비용은 비싸기 때문에, 요청이 많아질수록 리소스 소모가 심하다는 점이다.

Nignx

• Nginx 역할

  • 위에서 이야기 한 Web Server의 역할을 수행한다.

  • 여러 WAS들에게 트래픽을 분산시켜주는 로드밸런서 역할을 수행한다.
    • 로드밸런서란 말 그대로 여러 서버에게 트래픽을 분산시켜주는 주체를 의미하고 이를 로드밸런싱이라고 한다.
  • 리버스 프록시가 가능하다.
    • 프록시란 대리자라는 뜻을 가지는데, 일반적인 프록시는 클라이언트가 누군지를 숨겨주는 역할을 한다.
      즉 서버에선 클라이언트가 누구인지 식별할 수 없다.
    • 리버스 프록시란 반대로 클라이언트에서 서버가 누구인지 식별할 수 없다. 단지 서버를 대리하는 존재만을 알게 된다.
      서버가 누군지를 숨겨주는 역할을 한다.
    • 요청하는 클라이언트에서는 서버에 직접 요청하는게 아니라 Nginx 서버에 요청을 하므로 실제 요청을 처리하는
      서버는 알 수 없다는 이야기다. 이로 인해 보안성이 향상될 수 있다.
• 기존 Nginx
  • Nginx는 요청을 비동기로 처리한다. 요청당 프로세스 또는 쓰레드를 생성하지 않고 하나의 Worker process가 여러 요청을 처리한다.
  • 프로세스 수는 일정하기 때문에 메모리를 적게 사용하고 이로 인해 Context Switching이 적게 발생한다.
  • MPM 방식인 Apache에 비해 성능히 좋을 수 밖에 없다. 하지만 문제점이 있다. 아래를 보자.
  • 여러 이벤트를 한번에 수신하고, 이를 하나씩 처리하며 필요한 작업을 수행한다.
  • 대부분 이벤트 처리는 매우 빠르게 수행된다.
• 문제점
  • 문제점은 요청이 Blocking 될 수 있다는 점이다. 예로 아래와 같은 작업들이다.
    • 동기 방식으로 DB에서 응답을 받는 경우
    • 뮤텍스 또는 라이브러리 함수 호출
  • 위와 같은 요청들을 처리하는 동안 Worker porcess는 다른 작업을 수행할 수 없으므로 이벤트를 처리할 수 없어 성능이 매우 저하된다는 점이다.
  • 그래서 Nginx는 Thread pool 개념을 도입했다.
• Nginx Thread pool
  • Nginx 1.7.11 버전 및 Nginx Plus release 7 부터 Thread pool 방식을 도입했다.
    • 현재 stable version은 1.202 버전이다.
  • worker process가 요청을 TASK QUEUE에 넣으면, 각 요청들을 Thread pool에 있는 Thread들이 수행한다.
    수행 결과를 다시 worker process에게 전달한다.

Thread pool 개념을 도입했다고 해서 기본적으로 적용되지 않는다.
1.7.11 버전 이상에서 별도의 설정이 필요하다는 점에 유의하자. (적용 방법은 공식문서에 나와있다.)

Worker process란?

• Master process는 설정파일 read, 포트바인딩과 같은 권한이 필요한 작업을 수행하고 세 개의 Child process를 만든다.
• Cache Loader process
  • 서버 시작 시 실행되고, 디스크의 캐시를 메모리에 올려놓는 역할을 한다.
• Cache Manager process
  • 주기적으로 실행되고, 캐시에서 항목을 정리하여 정해진 크기 내에서 유지한다.
• Worker process
  • 모든 작업을 수행한다.
  • 네트워크 연결 처리 + 컨텐츠 read + 디스크에 write + upstream 서버와 통신
  • 각 Worker process는 Non-Blocking 방식으로 여러 요청을 처리하여 Context Switching을 최소화 한다.
  • 각 Worker process는 단일 스레드로 동작한다.

Nginx가 성능이점

• asynchronous + Non-Blocking
  • 위에서도 계속 이야기 했지만 Nginx는 기본적으로 비동기로 여러 요청을 한번에 처리한다.
  • 동시에 Non-Blocking 형태로 Blocking 되는 현상이 발생하지 않는다.
  • 비동기, 논블로킹에 관한 이야기는 CS 지식이므로 여기서 자세히 이야기 하지는 않겠다.
• 효율적인 설정 갱신
  • 내가 이해한 바로는, 우리가 Nginx 설정 값을 수정할 때 쓰는 nginx.conf 파일을 수정했을 때
    간단하고 효율적으로 작업을 수행한다는 것이다.
• 어떻게 효율적으로 수행 하는지 간단히 과정을 살펴본다.
  • 설정 값들을 다시 로드하고, 새로운 Worker porcess를 만들어서 트래픽을 처리하기 시작한다.
  • 이전 Worker Process는 트래픽을 더이상 받지 않는다. 현재 처리중인 요청을 모두 처리하고 이전 Worker Process는 완전히 종료된다.

CS 카테고리 내 다른 글 보러가기