APACHE

• 요청이 들어오면 커넥션을 생성하기 위해서 프로세스를 생성한다.
  • 클라이언트의 새로운 요청이 들어올때마다 프로세스를 생성한다.
  • 프로세스를 생성하는것은 비용이 많이 든다. -> 미리 프로세스들을 만들어두는 PREFORK방식을 사용
  • 요청이 많이 들어와서 미리 만들어놓은 프로세스를 다 사용한다면 새로운 프로세스 생성

C10K (Concurrent Connections to the Kernel)

• 1999년 이전까지는 서버가 처리하는 요청의 양이 그 당시 기술로서 감당 가능했다. 하지만 1999년 부터 컴퓨터가 많이 보급됨에 따라 트래픽이 굉장히 증가했다.
• C10K문제는 많은 요청으로 인하여 서버에 커넥션이 연결되어 있을때 더이상 커넥션을 생성할 수 없는 상태이다.
• 한번 연결된 커넥션은 길게 유지될 수도 있다. (요청시 보내는 header의 keep-alive값에 의해 얼마나 커넥션이 유지될지 결정된다.) -> 한번 커넥션을 연결할 때 비용이 많이 들기 때문.
  • "Connection: keep-alive" 헤더를 사용하면 클라이언트와 서버 간의 TCP 연결을 재사용할 수 있다. 이렇게 하면 새로운 요청을 처리하기 위해 매번 새로운 TCP 연결을 설정할 필요가 없어져서 성능이 향상되고 서버 부하가 감소한다. 그러나 이 값이 너무 크면 리소스를 오랫동안 소비하게 되어 다른 클라이언트의 연결을 받기 어려워질 수도 있어 조절이 필요한 부분이다.

APACHE의 문제

• 커넥션이 연결될때 마다 프로세스 생성 -> 메모리 부족
• 여러가지 기능을 쉽게 추가할 수 있는 확장성 -> 프로세스가 차지하는 리소스의 양 증가
• 많은 요청이 들어옴에 따라 많은 프로세스가 생성되고 CPU는 많은 Context Switching을 하며 일을 수행해야함. -> CPU부하 증가

NGINX 등장

• NGINX와 APACHE를 함께 사용하면 APACHE의 구조적인 문제인 많은 수의 커넥션을 연결할 수 없다는 문제를 해결할 수 있다.
• NGINX는 웹서버이므로 클라이언트의 정적 파일 요청을 처리할 수 있다.
• 클라이언트의 동적 파일 요청만을 APACHE와 커넥션을 연결하여 APACHE의 리소스를 로직 처리에 사용

NGINX는 어떻게 많은 동시 커넥션을 유지할 수 있을까

• 만들어지는 프로세스의 수가 APACHE보다 적기 때문에 가능하다.
• NGINX의 구조를 보면 Master Process와 Worker Process가 있다.
  • 실질적으로 일하는 프로세스는 Worker Process이다.
  • Worker Process가 만들어질때 각자 지정된 listen soket을 배정 받는다.
• 클라이언트가 요청을 하면 Worker Process의 Listen soket으로 요청이 들어오고 Worker Process에 커넥션이 생성되고 요청을 처리한다.
• 요청 시 Header에 담긴 Keep-Alive시간 만큼 커넥션이 유지된다.
• Worker Process는 하나의 커넥션이 생성되었다고해서 하나의 커넥션만 담당하지 않는다.
  • 연결된 커넥션에서 아무런 요청이 없다면 새로운 커넥션을 생성하거나 만들어진 다른 커넥션으로부터 요청을 처리한다.
• NGINX에서 커넥션 생성, 커넥션 제거, 새로운 요청 처리를 이벤트라고 한다.
• 이벤트들은 Queue형식으로 Worker Process로 전달된다.
• APACHE와 비교해서 장점 : 쉬는 프로세스가 없다. APACHE의 경우 하나의 요청을 처리하고 해당 클라이언트로부터 요청이 없다면 쉬고있는 프로세스가 많다.
• Worker Process는 Queue에서 작업을 꺼내 처리하다가 Disk I/O와 같이 시간이 오래 걸리는 작업인 경우에는 Thread Pool에 해당 작업을 위임하고 다음 작업을 처리한다.
  

NGINX에서의 EVENT

• 커넥션 생성
• 커넥션 제거
• 새로운 요청의 처리

• Worker Process는 CPU의 코어 갯수만큼 생성한다. -> CPU 코어가 Context Switching하는 횟수롤 대폭 감소

NGINX의 장점

• 프로세스를 적게 만든다. -> NGINX의 설정을 동적으로 변경하는것을 가능하게 한다.
  

• 개발자가 설정 파일을 변경하고 NGINX에 해당 설정 파일을 적용하면 Master Process는 해당 설정 파일이 적용된 Worker Process를 새로 생성한다.

• 기존의 Worker Process는 더이상 새로운 커넥션을 생성하지 않도록 한다.

• 기존의 Worker Process들은 현재 Queue에 존재하는 이벤트들을 모두 처리한 후 기존의 Worker Process는 종료된다.

동적 설정 변경은 언제 쓸까?

• NGINX가 여러 동시 커넥션을 관리하는 도중 뒷단의 서버가 추가되는 경우
• 이 경우에는 NGINX가 로드 밸런서의 역할을 담당한다.
• NGINX가 많은 동시 커넥션을 담당하고 있다면 설정을 변경하기 위해서 종료하는것은 어렵다.
• 동적 설정을 변경한다면 기존 커넥션들을 통한 요청을 처리하면서 새로운 서버를 추가할 수 있다.

NGINX vs APACHE

2008년 스마트 폰의 등장

• 동시 커넥션 수 증가 -> 많은 기업에서 NGINX 선택
• APACHE도 MPM모듈 도입
  • APACHE 서버를 어떤 방식으로 운영할지 선택할 수 있게끔 해주는 모델
  • 안정성, 하위 호환 -> 기존의 PreFork
  • 성능 향상 -> Worker라는 쓰레드 생성
• 다양한 성능 테스트에서 APACHE보다 NGINX가 우위
• NGINX : 웹 서버 보완, 특히 C10K문제
• APACHE : 하위 호환성, 확장성(다양한 모듈 추가 가능)

NGINX의 다양한 기능들

웹서버 가속기

• 서버에서는 복호화 과정보다 로직 처리에 리소스를 더 활용할 수 있다.
• NGINX와 Server는 같은 네트워크 안에 있는 경우가 많기 때문에 Http통신을 하더라도 보안적인 위험이 적다.

• 위 경우에는 NGINX가 클라이언트 쪽에 더 가까이 있는 경우
• 서버에서 한번 받은 응답을 캐싱하여 클라이언트에게 전달한다.