목차
Nginx 란?
Nginx 란 높은 성능을 가진 비동기, 이벤트 기반 구조의 경량화 웹 서버 프로그램 입니다.
Nginx는 프로젝트에서 어떤 역할을 할까요?
Nginx는 웹 서버와 리버스 프록시 서버로 주로 활용됩니다.
Nginx는 웹 서버로서 사용자들의 요청에 따라 정적 파일을 응답해 주기도 하고 Reverse Proxy Server로 WAS의 부하를 줄일 수 있는 로드밸런서의 역할을 하기도 합니다.
Nginx 를 사용하면 어떤 장점이 있을까요?
Nginx는 동시 접속 처리 능력이 뛰어납니다. Nginx는 비동기, 이벤트 기반 방식으로 요청을 처리합니다. 이벤트가 발생하면 코드가 동작하는 원리로 비동기적인 동작을 가능하게 하여 여러 이벤트를 병렬로 처리합니다. 이는 대량의 트래픽이 발생하는 웹 사이트의 효과적으로 처리하 빠른 응답을 가능하게 합니다.
Nginx는 다양한 기능을 지원합니다. HTTP 서버의 역할 뿐만 아니라 리버스 프록시, 로드 밸런서, 메일 프록시 등의 기능을 지원합니다. 이런 다양한 기능 덕에 웹 서버의 부하를 줄이고, 서비스의 안정성과 확장성을 향상시킵니다.
Nginx는 WAS의 부하를 줄여줍니다. Nginx는 로드밸런서로 여러 서버에 걸쳐 요청을 분산시킵니다. 이는 서비스의 가용성을 높이고 병목 현상을 줄이줍니다.
Nginx는 캐시를 지원합니다. 자주 사용되는 정적 컨텐츠를 캐싱함으로 사용자 요청에 더욱 빠르게 제공합니다. 이는 서버 부하를 줄여줍니다.
Nginx는 보안을 지원합니다. Nginx는 SSL과 TLS를 통해 HTTPS를 지원합니다. 이는 트래픽을 암호화하여 중간에서 데이터가 탈취되는 것을 방지하고, 클라이언트와 서버 간의 안전한 연결을 보장합니다.
Nginx를 사용하면 응답이 빨리지고, 보안이 높아져 웹 사이트의 성능을 향상시키고 사용자 경험을 개선하는데 크게 기여합니다.
Web Server
Nginx는 웹 서버라 말했습니다. 웹 서버란 무엇일까요? 웹 서비스의 흐름을 보면 웹 서버를 이해하는데 도움이 될 것 입니다.
Web Client가 요청을 보냅니다.
이 때 요청이 정적 요청인 경우 Web Server에서 해당되는 정적 컨텐츠 응답을 전송합니다.
요청이 동적인 경우 Web Server는 이에 해당되는 WAS 서버에 요청을 보내고 응답을 받아 client에게 전달합니다.
즉 그림에서 보듯 Web Server는 Web Client의 요청을 받아 적절한 응답을 해주는 역할을 합니다.
Web Server 란?
Web Server 란 웹 클라이언트 요청에 따라 적절한 응답을 전달하는 소프트웨어 입니다.
HTTP 프로토콜을 사용하여 클라이언트와 통신합니다.
HTMl, CSS, JS(JavaScript), 이미지 파일과 같은 정적 컨텐츠를 응답합니다.
동적 컨텐츠를 제공하기 위해 웹 애플리케이션 서버인 WAS와 통신하기도 합니다.
이 때, 로드밸런싱을 통해 클라이언트 요청에 적절한 응답을 해주는 WAS에 요청을 보냅니다.
또한, 캐싱을 지원해 자주 사용하는 정적 컨텐츠를 캐시로 저장하여 빠르게 제공합니다.
웹 서버는 정적 컨텐츠를 직접 처리하고 로드밸런싱을 통해 여러 WAS의 부하를 고르게 분산시키는 방법 등으로 WAS의 부담을 덜어줍니다.
대표적인 웹 서버로는 Nginx와 Apache 등이 있습니다.
즉, Web Server 는 웹 클라이언트의 요청에 따라 적절한 응답을 전달하고 정적 컨텐츠 전송 위임과 로드밸런싱으로 WAS 부담을 덜어준다는 것을 알았습니다. 그렇다면 WAS란 무엇일까요?
Web Application Server(WAS) 란?
Web Application Server를 줄인 WAS는 클라이언트 요청에 대해 동적인 처리를 담당하는 소프트웨어 입니다.
WAS는 웹 서버와 달리 애플리케이션 로직을 실행할 수 있고 데이터베이스 연동, 트랜잭션 관리, 보안, 로깅 등의 기능을 제공합니다. 예를 들면, 회원 가입이나 로그인 등의 로직을 처리하는 영역이 WAS 입니다.
WAS는 웹 애플리케이션의 안정성과 성능을 향상시키며 개발자들이 애플리케이션 개발에 집중할 수 있게 해줍니다. 대표적인 WAS로는 Tomcat, JBoss 등이 있습니다. 참고로 Node.js는 웹 서버, WAS 둘 다 사용이 가능합니다.
WAS는 로직을 처리하는 것만으로도 많은 역할을 하고 있기 때문에 Web Server를 앞에 두었습니다. Web Server는 정적 컨텐츠 제공 역할을 맡으므로 WAS가 동적 처리에 집중할 수 있게 했고 적절한 WAS로 경로를 설정하여 부하를 분산해 WAS의 부담을 줄여줍니다. 이를 통해 트래픽이 몰린 웹 사이트가 빠른 응답을 할 수 있게 해줍니다.
Web Server는 로드밸런싱을 통해 WAS 요청을 분산한다고 언급했습니다. 이는 Web Server가 Reverse Proxy 기능을 하는 것과 면밀한 관계가 있습니다.
Reverse Proxy
Reverse Proxy를 알아보기 전 Proxy에 대해 먼저 알아보겠습니다.
Proxy(프록시)
프록시는 네트워크에서 다른 네트워크에 대한 요청을 중계해주는 역할을 하는 서버나 서비스를 가리킵니다. 프록시(Proxy)는 "대리" 라는 의미이며 프록시를 사용하면 클라이언트는 서버와 직접 통신하지 않고 프록시 서버를 통해 통신합니다. 프록시는 주로 클라이언트와 서버 사이에서 작동하며 요청과 응답을 중계해주는 중개자 역할을 합니다.
프록시는 포워드 프록시와 리버스 프록시가 있습니다.
Forward Proxy는 클라이언트와 서버 사이에 있으며 그 중 클라이언트 측에 위치하며 클라이언트의 요청을 서버로 전달하고, 서버의 응답을 클라이언트에게 반환하는 역할을 하는 서버입니다.
포워드 프록시를 시용하면 클라이언트 IP 주소가 웹 서버에 노출되지 않아 보안이 강화됩니다. 또한 특정 IP 주소, 도메인, URL에 대한 접근을 제한할 수 있습니다. 또한 캐싱을 통해 네트워크 성능을 개선할 수 있습니다. 포워드 포워드는 자주 요청하는 페이지나 데이터를 캐싱합니다.
Nginx는 Forward Proxy로 사용할 수도 있지만 주로 Reverse Proxy로 사용됩니다.
Reverse Proxy 란?
Reverse Proxy란 클라이언트와 서버 사이에 있으며 백엔드 서버 측에 위치하며 클라이언트의 요청을 적절한 백엔드 서버로 전달하고, 그 서버의 응답을 클라이언트에게 반환하는 역할을 하는 서버입니다.
리버스 프록시를 사용하면 로드밸런싱, 보안, SSL/TLS 지원, 캐싱 등 여러 이점을 얻을 수 있습니다.
로드밸런싱이란 서버 요청을 서버들에게 고르게 분산시키는 프로세스 입니다. 로드밸런싱은 모든 서버가 균등한 작업 부하를 받도록 하여 한 서버에 과부하가 몰리지 않게 합니다. 또한 특정 서버가 과부하 상태이거나 실패해서 작동할 수 없는 상태일 때, 다른 서버로 트래픽을 옮겨 서비스 중단을 방지합니다. 로드밸런싱은 성능 향상과 빠른 응답 시간을 얻을 수 있습니다.
리버스 프록시는 보안을 강화합니다. 리버스 프록시는 클라이언트의 요청을 필터링하고 내부 서버의 정보를 숨겨 보안을 강화합니다.
리버스 프록시는 SSL/TLS을 지원합니다. SSL/TLS은 인터넷 통신을 암호화하여 정보를 보호하는 프로토콜 입니다. SSL/TLS 지원을 통해 클라이언트와 리버스 프록시 사이의 통신이 암호화 됩니다. 이는 HTTP의 암호화된 버전인 HTTPS를 올바르게 처리하게 되어 보안이 강화됩니다.
리버스 프록시는 캐싱을 지원합니다. 리버스 프록시는 백엔드 서버의 응답을 캐시에 저장합니다. 동일한 요청이 들어온 경우 리버스 프록시는 백엔드 서버에 요청을 보내지 않고 캐시에 저장된 응답을 제공합니다. 이를 통해 백엔드 서버의 부하를 줄이고 응답 시간을 빠르게 합니다.
비동기, 이벤트 기반 구조
Nginx는 비동기, 이벤트 기반 구조 경량화 웹 서버라 했습니다. 그렇다면 비동기, 이벤트 기반 구조란 무엇일까요?
이것을 알기 위해서는 Nginx가 만들어진 배경과 Nginx의 구조를 아는 것이 도움이 됩니다.
Nginx 만들어진 배경
Nginx는 러시아 소프트웨어 엔지니어인 Igor Sysoev에 의해 개발되었습니다. 2000년대 초반, 그는 웹 트래픽이 급증하면서 동시 접속 요청을 효율적으로 처리하기 위한 목적으로 Nginx를 만들었습니다.
당시 가장 널리 사용되던 웹 서는 Apache 였습니다.
Apache 웹 서버는 Process-Driven, 프로세스 기반 방식입니다. 프로세스 기반은 작업이나 요청을 처리하기 위해 독립적인 프로세스를 생성하고 사용하는 방식입니다. 즉, 요청이 들어올 때 마다 새로운 프로세스를 생성하여 처리합니다.
그런데 프로세스를 생성하는 시간은 오래 걸리기 때문에 Prefork 방식을 이용했습니다. Prefork란 프로세스를 미리 만들어 놓고 클라이언트의 요청이 오면 미리 만들어놓은 프로세스를 할당하는 방식입니다.
Prefork 방식의 장점은 프로세스 생성에 대한 오버헤드를 최소화하고, 요청에 빠르게 응답할 수 있다는 것 입니다. 또한 각 클라이언트의 요청이 독립된 프로세스에서 처리되므로, 한 프로세스의 문제가 생겨도 다른 프로세스에 영향을 주지 않아 시스템에 안정성을 높일 수 있었습니다.
하지만 Prefork 방식은 동시에 많은 수의 클라이언트 연결을 처리하는데 문제가 생길 수 있습니다.
많은 수의 동시 연결이 들어오면 연결이 온 만큼 프로세스를 생성하게 되는데 이는 상당한 메모리를 사용하게 됩니다. 이는 느린 응답 같은 시스템 성능 저하로 이어집니다. 메모리는 한정적인 자원이므로 메모리 사용량이 계속 증가하면 결국 더 이상 새로운 프로세스를 생성할 수 없게 되어 새로운 연결을 처리하지 못하게 됩니다.
또한 실행중인 프로세스가 많아지면서 CPU는 프로세스를 처리 할 때, 컨텍스트 스위칭을 굉장히 많이 해야했습니다. 이는 CPU의 부하를 증가시켰습니다.
이러한 메모리 부족과 CPU의 부하는 C10K 문제를 일으켰습니다.
C10K 문제란 Concurrent 10000 clients/connections Problem의 줄임말로 웹 서버가 동시에 수천 개의 클라이언트 연결을 효과적으로 처리하지 못하는 상황을 가리킵니다.
Prefork 방식은 요청이 적을 땐 적합한 방법이었지만 2000년에 접어들어 컴퓨터가 보급되면서 대량의 동시 연결 요청이 늘어난 지금 환경에는 맞지 않는 방식이 되었습니다.
그래서 대량의 동시 연결 요청을 처리하기 위해 Nginx가 만들어졌습니다.
Nginx 구조
Nginx의 구조는 대량의 동시 연결 요청을 효울적으로 처리하기 좋아 높은 트래픽을 가진 사이트에서 널리 사용됩니다.
Nginx의 구조는 Master Process와 Worker Process로 구성되어 있습니다.
Master Process는 Nginx의 설정을 읽거나 포트에 바인등 하는 등 주요한 기능을 합니다. 또한 Worker Process를 생성합니다.
Worker Process는 실질적으로 모든 클라이언트의 요청을 처리합니다. Worker Process는 Nginx 설정에 개수를 정할 수 있습니다. 기본적으로는 CPU의 코어 수에 맞게 할당됩니다. 클라이언트의 요청이 증가한다고 Worker Process가 증가하지않습니다.
그 외에 Cacher Loader, Cacher Manager 와 같은 Helper Process 들이 있습니다.
Worker Process 가 만들어 질 때 지정된 listen 소켓을 받습니다. 그리고 소켓에 새로운 클라이언트 요청이 들어오면 Connection을 형성하고 처리합니다. Connection은 정해진 Keep-Alive 시간만큼 유지됩니다. 하지만 Connection이 형성되었다고 해서 Worker Process가 해당 Connection 하나만 담당하지 않습니다.
형성된 Connection으로부터 아무런 요청이 없다면 새로운 Connection을 형성하거나 이미 만들어진 Connection으로부터 들어온 요청을 처리합니다.
Nginx에서 이러한 Connection 형성과 제거, 새로운 요청을 처리하는 것을 이벤트 라고 합니다.
Event-Driven (이벤트 기반)
Nginx는 Event-Driven, 이벤트 기반 방식입니다. 이벤트 기반이란 특정한 이벤트가 발생했을 때에만 작업을 수행하는 방식입니다. 또한 비동기로 이벤트를 처리하기 때문에 한 프로세스가 끝날 때 까지 대기하지 않고 다른 일을 처리합니다. 이러한 특징으로 이벤트 기반 방식은 프로세스를 효율적으로 활용해 서버 자원을 최대한 활용할 수 있습니다.
Nginx 작동 과정
1. 마스터 프로세스 생성
Nginx가 실행되면서 가장 먼저 Master Process 가 생성됩니다. Master Process는 설정 파일을 로드하고 유효성을 검사합니다. 또한 필요에 따라 Worker Process를 생성하거나 재시작 합니다.
2. Worker Process 생성
Master Process는 Worker Process를 Nginx의 설정한 수 만큼 생성합니다. Worker Process는 일반적으로 CPU 코어 수만큼 생성하며, 각 Worker Process는 독립적으로 클라이언트 요청을 처리합니다.
3. 연결 수립
클라이언트가 요청을 하면 Worker Process 중 하나가 해당 요청을 받아 처리합니다. 이 때 각 요청은 이벤트로 처리되며 이벤트들은 이벤트 큐에 담기며 비동기 상태로 대기합니다.
4. 이벤트 처리
Worker Process는 이벤트 큐에서 이벤트를 가져와 처리하고 요청에 대한 응답을 생성합니다. 워커 프로세스는 비동기 처리 방식과 Non Blocking I/O 모델을 사용하므로, 워커 프로세스는 한 이벤트의 처리가 끝나기를 기다리지 않고 바로 다음 이벤트를 처리할 수 있습니다. 이는 워커 프로세스가 한 번에 여러 요청을 동시에 처리할 수 있게 합니다.
5. 응답 반환
Worker Process는 생성된 응답을 클라이언트에게 반환하고, 이벤트 처리를 완료합니다.
Nginx의 이런 작동 방식은 높은 트래픽과 수 많은 동시 연결을 효율적으로 처리할 수 있도록 합니다. 또한 이 방식은 Worker Process가 서버 자원을 최대한 활용하도록 하여 높은 성능과 확장성을 제공합니다.
Nginx의 정리
Nginx는 비동기, 이벤트 기반 구조의 경량화 웹 서버 입니다.
Nginx는 정적 컨텐츠를 제공하는 Web Server와 로드밸런싱을 지원하는 Reverse Proxy로 주요 사용됩니다.
Nginx는 대량의 동시 요청을 처리하는데 탁월합니다. 그 이유는 비동기, 이벤트 기반 구조 때문입니다.
마스터 프로세스와 워커 프로세스로 이루어져 있으며 워커 프로세스가 클라이언트의 요청을 처리합니다.
이 때 요청마다 프로세스를 생성하는 아파치 프로세스와 다르게 워커 프로세스는 한정된 갯수로 클라이언트 요청을 처리합니다.
이것이 가능한 이유는 요청이 없으면 방치되는 아파치 프로세스와 달리 워커 Nginx는 요청을 이벤트 큐에 쌓고 워커 프로세스들은 이 이벤트들을 처리하기 때문에 쉬지 않고 계속 작업하는게 가능하고 동시에 여러 요청을 처리할 수 있습니다.
이러한 구조는 Nginx가 효율적으로 자원을 활용하여 수 많은 동시 연결을 효율적으로 처리하게 합니다.
Nginx의 장점과 단점
Nginx의 장점
- 정적 파일 처리 능력
- 리버스 프록시, 로드 밸런싱 기능
- SSL/TLS 지원
- 이벤트 기반 구조로 높은 동시 연결 처리 능력
- 효율적인 자원 사용
Nginx 단점
- 동적 컨텐츠 처리에 약함
- 모듈과 호환성 및 다양성이 Apache에 비해 부족함
