Nginx? 무중단 배포?

무중단 배포?

서비스가 중단되지 않은 상태에서 새로운 버전을 배포하는 것

 

무중단 배포가 필요한 이유?

실제 서비스에서 한 대의 서버를 운영한다고 가정하자. 현재 사용중인 서비스의 Version은 application-V1을 배포한 서비스이다. 그런데 기능이 업데이트 되어 application-V2를 배포하려 한다. 이 새로운 버전 V2를 배포하기 위해서는 V2 버전의 빌드 파일을 서버에 배포해야 한다. V1와 V2는 서로 같은 포트를 사용하기 때문에 V2를 배포하기 위해서는 V1버전을 통해 실행하고 있는 서비스를 종료해야만 한다. 이러한 경우, V1이 종료되고 V2 버전이 실행되는 사이 유저가 서비스를 이용할 수 없는 시간이 생기는데, 이를 “다운타임” 이라고 한다.

 

 

Nginx

Nginx란 트래픽이 많은 웹사이트의 WAS를 도와주는 비동기 이벤트 기반구조의 경량화 웹 서버이다. 클라이언트로부터 요청을 받았을 때 요청에 맞는 정적 파일을 응답해주는 HTTP Web Server로 활용되기도 하고, Reverse Proxy Server로 활용하여 WAS의 부하를 줄일 수 있는 로드밸런서 역할을 하기도 한다. Nginx의 비동기 이벤트 기반구조때문에 C10K문제를 해결할 수 있었다고 한다.

 

프록시에 대한 이해를 위해 참고하자 -> https://kimdozzi.tistory.com/253

[Network] foward & reverse proxy server

 

 

Nginx의 비동기 이벤트 기반구조

대기중인 이벤트에 응답하고 이벤트를 비차단적으로 처리하여 동시에 많은 요청을 처리할 수 있다. Nginx의 가장 핵심이고, 다음과 같은 구성 요소로 구현된다.

 

멀티 프로세스 / 단일 스레드

• Nginx는 하나의 master process가 다수의 worker process를 관리한다.
• master process는 worker process를 관리하는 일만 수행하고, worker process에서 사용자의 응답에 대응하는 방식을 취한다.
• master process는 멀티 프로세스 방식으로 동작하고, worker process는 싱글 스레드 방식으로 동작한다. 각각의 worker process에 대해서는 single thread 방식으로 동작해 여러 클라이언트 요청을 동시에 처리할 수 있다.

 

이벤트 드리븐(event-driven) 프로그래밍

Nginx에서 connection을 형성하거나 제거하고 새로운 요청을 처리하는 것을 이벤트라고 한다.

1. event 들은 queue 형식으로 worker process에게 전달한다.
2. event 들이 queue에 담긴 상태에서 비동기 상태로 대기한다.
3. worker process 는 이 이벤트들을 queue에서 꺼내 처리한다.

이러한 방식을 작업이 완료될 때 까지 기다리지 않고 이벤트 큐에서 다음 이벤트를 처리하는 비동기 이벤트 드리븐 모델이라고 한다. 작업이 완료될 때 까지 기다리지 않고, 쉬지 않고 일을 하기 때문에 요청이 없을 때 프로세스를 방치시키는 Apache보다 훨씬 효율적으로 자원사용이 가능하다.

 

I/O 멀티플렉싱

nginx는 I/O 멀티플렉싱 기술을 사용하여 동시에 많은 연결을 관리할 수 있다.

 

비차단(non-blocking) 소켓

nginx는 비차단 소켓을 사용하여 입출력 작업을 수행하며, 클라이언트의 요청 및 응답을 지연 없이 처리할 수 있다.

 

 

 

Nginx의 장단점

장점

• Nginx는 비동기 이벤트 기반 구조를 사용하여 매우 빠르고 효율적인 웹 서버 기능을 제공한다. 프로세스 간의 블로킹을 최소화하고 많은 요청을 동시에 처리할 수 있어 큰 트래픽에 대한 처리에 탁월하다.
• 높은 확장성 - 여러 프로세스를 사용하므로 수천 개의 동시 연결을 처리할 수 있다.
• 리버스 프록시와 로드 밸런싱 - 리버스 프록시를 사용해 Origin 서버의 안전을 보장하고, 트래픽 분산 기능으로 트래픽이 과하게 몰리는 경우를 방지할 수 있다.

 

단점

• 동적 컨텐츠 처리 한계 - Nginx는 정적 파일에 최적화되어 있다. 하지만 백엔드 애플리케이션 서버나 API에 요청을 전달해 동적 컨텐츠를 처리하는 방법으로 한계를 극복할 수 있다.
• 요청 기반이 아닌 연결 기반 처리 - 연결 기반 처리 방식은 연결 성능을 최적화하더라도 개별 요청의 처리 속도가 느려질 수 있다. 이로 인해 특정 클라이언트의 연결에 많은 리소스가 할당되고, 이를 처리하는 동안 다른 클라이언트의 요청을 처리하는 데 있어 지연이 발생할 수 있다.
  • 극복 방법
    • 로드 밸런싱
    • Keep-Alive 연결 시간 제한
    • 전송 속도 조절
    • 워커 수 및 프로세스 관리 최적화
• 모듈 지원 제한 : Apache와 달리 Nginx는 기본적으로 컴파일 시점에 모듈을 선택적으로 포함한다. 즉, 확장 또는 제거 시 Nginx를 재컴파일해야 한다. 이렇게 함으로써 Nginx는 더 가벼운 메모리 사용량과 높은 성능을 제공할 수 있다. 하지만, 이 방식이 어떤 상황에서는 유연성을 제한하는 요소가 될 수 있다.