Nginx란?
- 트래픽이 많은 웹사이트의 서버(WAS)를 도와주는 비동기 이벤트 기반 구조의 경량화 웹 서버 프로그램
- 클라이언트로부터 요청을 받았을 때 요청에 맞는 정적 파일을 응답해주는 HTTP Web Server로 활용
- Reverse Proxy Server로 활용하여 WAS의 부하를 줄일 수 있는 로드밸런서 역할
- Apache보다 동작이 단순하고, 전달자 역할만 하기 때문에 동시접속 처리에 특화됨
Nginx의 장단점
Nginx의 장점
- 이벤트 중심 접근 방식을 사용하여 클라이언트 요청 제공
- 제한된 하드웨어 리소스로도 여러 클라이언트 요청을 동시에 효율적으로 처리
- 단일 스레드를 통해 여러 연결을 처리 가능
- 최소한의 리소스로 웹 서버의 아키텍처를 개선하기 위해 독립형 HTTP 서버로 배치 가능
Nginx의 단점
- 동적 컨텐츠를 기본적으로 처리 할 수 없음
- 동적 콘텐츠에 대한 PHP 및 기타 요청을 처리하려면 NGINX가이를 실행하기 위해 외부 프로세서로 전달하고 렌더링 된 콘텐츠가 다시 전송 될 때까지 기다려야함
(프로세스 속도 저하 / 즉, 동적 웹 페이지 컨텐츠를 가진 모든 요청을 위해 외부 자원과 연계(php-fpm))
Nginx(웹서버)의 역할
1. 정적 파일을 처리하는 HTTP 서버로서의 역할
- HTML, CSS, Javascript, 이미지와 같은 정보를 웹 브라우저(Chrome, Iexplore, Opera, Firefox 등)에 전송하는 역할 (HTTP 프로토콜을 준수)
2. 응용프로그램 서버에 요청을 보내는 리버스 프록시로서의 역할
- 라이언트는 가짜 서버에 요청(request)하면, 프록시 서버가 배후 서버(reverse server)로부터 데이터를 가져오는 역할
(프록시 서버가 Nginx, 리버스 서버가 응용프로그램 서버)
Nginx가 만들어진 배경
1. CERN httpd 웹 서버가 만들어진 후, 1995년 UNIX 기반으로 NCSA HTTPd가 만들어짐
- 버그가 굉장히 많아서 개발자들이 사용할 때 불편함을 많이 느낌
2. Apache Server 개발
- 1의 버그 문제 때문에 개발됨
- Apache 같은 경우 요청이 들어오면 connection을 생성
(새로운 클라이언트의 요청이 올 때마다 새로운 process를 생성) - 프로세스를 생성하는 과정은 시간이 오래 걸리기 때문에 프로세스를 미리 만들어 놓는 PREFORK라는 방식을 이용했음
(만들어놓은 프로세스가 없다면 추가로 프로세스를 생성)
- 이런 구조 덕분에 개발자는 다양한 모듈을 만들어서 서버에 빠르게 기능을 추가할 수 있었으며,
확장성이 높고 Apache Server를 통해 동적 콘텐츠를 처리할 수 있게됨
3. 컴퓨터가 많이 보급됨으로 인해 요청이 많아짐
- 서버에 동시에 연결된 connection이 많아져 더 이상 새로운 connection을 생성하지 못하게 되었음 (C10K)
C10K(connection 10000 problem)
connection 10000개의 문제
Apache Server의 구조적 문제점
- 메모리 부족: connection이 연결될 때마다 프로세스를 생성
- 무거운 프로그램: 확장성이 좋다는건 곧 리소스가 않다는 걸 의미
- CPU 부하 증가: 많은 connection 요청이 들어오면 context switching을 많이 하기에 CPU 부하가 증가
4. 2004년 Nginx 개발
- 초창기 Nginx는 Apache와 함께 사용하기 위해 만들어짐
(Apache의 구조적 한계를 극복하기 위해 사용하려함)
- Nginx
- 수많은 동시 connection을 유지
- 정적 파일에 대한 요청 처리
- 동적 파일에 대한 요청 시 Apache 서버와 connection 형성
- Apache
- 동적 파일에 대한 요청 처리
Nginx의 구조
설정파일을 읽고, 설정에 맞게 worker process를 생성하는 master process가 있음
이벤트(event)
connection 형성과 제거, 새로운 요청을 처리하는 것
- worker process
- 실제로 일을 하는 프로세스
- worker process가 만들어질 때 지정된 listen 소켓을 배정받음
(해당 소켓에 새로운 클라이언트 요청이 들어오면 connection을 형성하고 처리)connection은 정해진 Keep-Alive 시간만큼 유지됨
connection이 형성되었다고 해서 worker process가 해당 connection 하나만 담당하지는 않음
- 이벤트들을 os커널이 queue형식으로 worker process에게 전달
- 이 이벤트들은 queue에 담긴 상태에서 비동기 상태로 대기
- worker process는 하나의 스레드로 이벤트를 꺼내서 처리
❗❗ worker process가 쉬지 않고 일을 하기에, 요청이 없을 때 프로세스를 방치시키는 Apache Server보다 훨씬 효율적으로 자원을 사용할 수 있음! ❗❗
Apache와 Nginx 성능 비교
메모리 사용률
- 동시 connection 수가 늘어나도 Nginx는 메모리 사용률이 낮고 일정함
초당 요청 수
- 동시 connection 수가 많아졌을 때 처리하는 초당 요청 수가 Apache 보다 현저히 높음
정리
Apache의 한계
클라이언트 접속마다 Process 혹은 Thread 를 생성하는 구조
1만 클라이언트로부터 동시접속 요청이 들어온다면
CPU 와 메모리 사용이 증가하고 추가적인 Process/Tread 생성비용이 드는 등 대용량 요청에서 한계를 보임
또한, Apache 서버의 프로세스가 blocking 될 때 요청을 처리하지 못하고 처리가 완료될 때까지 대기상태에 있음
(이는 Keep Alive(접속대기) 로 해결이 가능하지만, 효율이 떨어짐)
Nginx 의 정리
Event-Driven 방식으로 동작
프로그램 흐름이 이벤트에 의해 결정 됨
한 개 또는 고정된 프로세스만 생성하고,
그 내부에서 비동기로 효율적인 방식으로 task 를 처리하기 때문에
Apache 와 달리 동시접속자 수가 많아져도 추가적인 생성비용이 들지 않음
- 비동기 이벤트 기반으로 요청하여 적은양의 스레드가 사용되기 때문에 CPU소모가 적음
- Apache 와 달리 CPU 와 관계없이 I/O 들을 전부 Event Listener로 미루기 때문에 흐름이 끊이지 않음
- context switching 비용이 적음
Nginx를 이용한 무중단 배포
기존 배포 방식의 문제점
새로운 Jar가 실행되기 전까진 기존 Jar를 종료시켜놓기 때문에 서비스가 안됨
(배포하는 시간 동안은 어플리케이션 종료)
예전에는 배포라고 하면 팀의 아주 큰 이벤트이기 때문에 다같이 코드를 합치는 날과 배포를 하는 날을 정하고 배포했으며,
특히 배포일에는 사용자가 적은 새벽 시간에 개발자들이 모두 남아 배포 하는 경우가 태반이였음
Nginx를 이용한 무중단 배포 방법 소개
- 무중단 배포 중 가장 저렴
(가장 편리한 AWS 블루 그린 배포 방식이 있으나 비쌈) - 클라우드 인프라가 구축되어 있지 않아도 사용 가능
(기존 AWS 사용 시 배포를 위해 AWS EC2 인스턴스가 추가로 필요하지 않음)Amazon Elastic Compute Cloud(Amazon EC2)
하나의 EC2 혹은 서버에 Nginx 1대 + jar 2대를 사용하는 것
예) Nginx는 80(http), 443(https) 포트를 할당하고,
스프링부트1은 8081포트로,
스프링부트2는 8082포트로 실행
스프링부트2에 새로운 jar파일 업로드 후
정상 작동을 확인하면 Nginx가 바라보는 포트 번호를 수정
참고사이트
Nginx란 무엇인가? - JuHyeong.dev
7) 스프링부트로 웹 서비스 출시하기 - 7. Nginx를 활용한 무중단 배포 구축하기 - 기억보단 기록을
