Hyen Dev
[Nginx] Nginx란? 본문
최근에 회사에서 배포를 하면서 nginx 설정을 한 번 잘못했다가 에러 해결에 고생을 하면서 nginx에 대해 좀 더 제대로 공부를 해야겠다는 생각을 하게 되었다. nginx에 대해 알기 위해 먼저 웹 서버가 무엇인지부터 알아보려고 한다.
웹 서버
웹 서버란 클라이언트가 웹 브라우저에서 어떤 페이지를 요청하면, 해당 요청을 받아들여 정적 콘텐츠를 제공하는 서버이다.
여기서 정적 컨텐츠란 단순 HTML 문서, CSS, javascript, 이미지 등 즉시 응답가능한 컨텐츠이다.
웹 서버의 역할은 크게 2가지가 있다.
- 앞에서 말한 정적 컨텐츠를 클라이언트로 전달하거나 전달받아 저장하여 처리한다.
- 동적컨텐츠 요청이 들어왔을 때, 해당 요청을 WAS에게 넘겨주고, WAS에서 처리한 결과를 클라이언트에게 전달해준다.
대표적인 웹 서버로 Apache, Nginx가 있다.
WAS
WAS는 Web Server와 Web Container가 합쳐진 형태로, 웹 서버 기능들을 구조적으로 분리하여 처리하고자하는 목적으로 제시되었다.
WAS도 웹 서버와 동일하게 HTTP 기반으로 동작하며 웹 서버가 하는 기능 대부분을 was에서도 처리 가능하다.
주로 DB 서버와 같이 수행되어 데이터베이스 조회나 다양한 로직 처리가 필요한 비즈니스 로직(서버사이드 코드)을 처리할 수 있어 동적 컨텐츠 역시 전달할 수 있다.
대표적인 WAS로는 Tomcat이 있다.
웹 서버와 WAS의 효율적인 사용
웹 서버가 할 수 있는 일을 WAS로도 전부 가능하다면, 웹 서버는 굳이 필요하지 않을까? 라는 생각을 할 수도 있다.
하지만 기본적으로 DB 조회 및 다양한 로직을 처리하는데 집중해야는 WAS가 정적 콘텐츠 요청까지 처리하게 되면, 부하가 커지고 동적 컨텐츠 처리가 지연되면서 수행 속도가 느려지게 될 것이다. 이에 따라 페이지 노출 시간이 늘어나는 문제가 발생하여 효율성이 크게 떨어질 것이다.
위 그림과 같이 웹 서버를 앞단에 두고, was는 웹 서버가 처리하기 힘든 서버 사이드 코드의 로직을 수행하도록 하면 웹 서버와 함께 사용자에게 양질의 컨텐츠를 제공할 수 있다.
이것 말고도 "fail over(장애 극복)" 처리를 하는데에도 웹 서버와 WAS를 분리하는게 유리하다.
사람들이 많이 접속하여 서버를 여러 대 사용하는 대용량 웹 애플리케이션의 경우, 웹 서버와 WAS를 분리하여 무중단 운영을 위한 장애 극복에 쉽게 대응할 수 있다.
만약 사용중인 WAS에서 문제가 생겨 WAS를 재시작해야하는 경우가 생긴다면, 이때 앞단의 웹 서버에서 해당 WAS를 사용하지 못하도록 요청을 차단하고, 그 다음 WAS를 재시작한다면, 사용자들은 WAS에 문제가 발생한지 모르고 이용할 수 있다.
Nginx
그렇다면 Nginx란 가벼움과 높은 성능을 목표로 하는 웹 서버 이다.
Nginx는 트래픽이 많은 웹사이트의 확장성을 도와주는 비동기 이벤트 기반구조로 이루어져 있다.
Nginx의 구조
Nginx는 하나의 Master Process와 다수의 Worker Process로 구성되어 실행된다.
Master Process는 설정 파일을 읽고, 다수의 Worker process를 관리한다.
Wokrer Process는 실제로 일을 하는 프로세스 이며, 모든 요청은 Worker Process에서 처리한다.
Worker Process의 개수는 설정 파일에서 정의하고, 보통 CPU 코어 수만큼 생성된다.
그래서 코어가 담당하는 프로세스를 바꾸는 횟수를 줄이기에 CPU의 컨텍스트 스위칭을 줄이게 된다.
worker process가 생성될 때 각자 listen 소켓을 지정받는데, 해당 소켓에 새로 클라이언트 요청이 들어오면 커넥션을 형성하고 처리한다.
커넥션은 정해진 Kepp Alive 시간만큼 유지되는데, 커넥션이 형성되었다고 해서 worker process가 하나의 커넥션만을 담당하진 않는다.
형성된 커넥션에 아무런 요청이 없으면 새로운 커넥션을 형성하거나 이미 만들어진 다른 커넥션으로부터 들어온 요청을 처리한다.
Nginx에서는 이러한 connection 형성과 제거, 그리고 새로운 요청을 처리하는 것을 이벤트(event)라고 하며, 이러한 방식을 이벤트 기반(Event-Drived) 방식이라고 한다.
worker process는 OS 커널로부터 커넥션을 queue 형식으로 전달받는다.
worker process로 전달된 큐에 담긴 이벤트들은 비동기 상태로 대기하며 worker process는 큐에서부터 이벤트를 하나씩 꺼내어 처리한다.
여기서 worker process는 하나의 쓰레드로 동작하며, 커넥션 연결 후 요청이 없으면 다른 커넥션의 요청을 처리하거나 새로운 커넥션을 형성한다.
이러한 구조적 특징 덕분에 커넥션마다 쓰레드를 생성하여 커넥션 연결 후 요청이 없다면 방치되는 Apache보다 훨씬 효율적으로 자원 사용이 가능해지며, 요청 처리율도 훨씬 높다.
Nginx의 장점
1. 자원의 효율적인 사용
: Apache처럼 클라이언트의 요청마다 thread를 생성하는게 아니라 worker process, 즉 단일 thread를 이용하여 자원의 효율성을 보장한다. 이때문에 적은 메모리 사용 & CPU 사용을 보장한다.
2. 동시적인 요청 처리(비동기 처리)
: 여러 요청을 비동기적인 이벤트 기반으로 동시에 처리한다.
3. Reverse Proxy
: 요청을 다른 서버로 전달하는 reverse proxy 서버로 활용되어 was의 부하를 줄이는 로드 밸런서로 사용할 수도 있다.
(리버스 프록시랑 로드 밸런싱 관련해서는 얘기할게 많기 때문에 추후 더 자세하게 글을 작성할 예정이다)
4. SSL 지원
: SSL(Secure Sockets Layer)은 웹 사이트와 사용자 간의 통신을 암호화하고 보안을 유지하는데 사용되는 프로토콜이다.
SSL은 HTTPS(HTTP Secure)로 알려진 보안 HTTP 프로토콜의 기반 기술이다. SSL 프로토콜을 사용하여 웹 서버와 클라이언트 간에 보안 연결을 설정하고, SSL 인증서를 사용하여 서버의 신원을 인증한다. 이를 통해 중간자 공격과 같은 보안 위협을 방지하고, 사용자의 개인 정보와 웹 사이트의 기밀 정보를 보호할 수 있다. Nginx는 이러한 HTTPS 인증서를 제공해줄 수 있다.
이 밖에도 여러 장점들이 있지만 일단은 이 정도만 적어보려고 한다.
해당 글에서는 Nginx에 대해 중점적으로 다루다보니 Apache가 단점만 있는 것처럼 설명하였는데 각각 장단점이 있으니 본인의 프로젝트에 맞는 걸 잘 사용하길 바란다.