nginx란 - 대체 nginx가 뭔데?

얼마 전부터 nginx라는 키워드가 눈에 밟히기 시작했다.

 

도커를 공부하는데 보는 글마다 nginx 이미지를 쓰고 있고, 쿠버네티스의 Ingress에서는 nginx ingress controller를 쓴다고 하고.. 심지어 사이트가 죽거나 했을 때 보게 되는 502 Bad Gateway 화면에도 nginx라는 단어가 들어가있다!

 

나름 친숙한 502 Bad Gateway 화면

사실 nginx가 통칭 HTTP 서버라는 건 어느 정도 들어서 알고 있었지만, 구체적으로 무엇을 하는 녀석인지는 몰랐다. 직접적으로 사용하지는 않는데, 남들이 다 쓰는 그 용어.. 대체 무슨 뜻인지 궁금한 사람들이 있을까 싶어, 한 번 정리해보았다.

 

HTTP 서버, 웹 서버

nginx가 웹 서버라는 건 워낙 유명하다. 위키 백과에서도 nginx를 웹 서버 소프트웨어라고 이야기하고 있다.

 

문제는 웹 서버가 정확히 뭘 하는 녀석인지, 우리가 개발할 때 쓰는 웹 프레임워크들과는 뭐가 다른건지- 바로 이 부분이다. 그 차이를 이해하기 위해서는 우선, 웹 서버와 WAS(Web Application Server)를 구분해야 한다.

 

웹 서버 vs WAS

웹 서버

MDN Web Docs에 의하면 웹 서버에는 두 가지 측면 - 하드웨어적 측면과 소프트웨어적 측면이 있다고 하는데, 하드웨어야 뭐 당연한 부분이니 우리는 소프트웨어적 측면에 집중해보자.

 

웹 서버는 한 마디로 정의하면 "클라이언트로부터 HTTP 요청을 받아 요청에 해당하는 파일을 HTTP를 통해 보내주는 프로그램"이라고 할 수 있다.

 

웹 서버가 우리가 통상적으로 이야기하는 API 서버나 사이트와 다른 점이 무엇일까? 그건 바로 동적으로 컨텐츠를 바꿀 수 없다는 점이다. /index.html 이라는 주소로 HTTP 요청을 보내면, 실제 웹 서버가 돌아가는 환경의 파일 시스템에 있는 index.html이라는 파일을 전송할 뿐, 파라미터에 따라 데이터를 다르게 내려준다거나 할 수는 없다.

 

단순하게 생각하면, 웹 서버는 그냥 파일을 내려주는데, 그 전송 형식이 HTTP(HyperText Transfer Protocol)이라고 보면 된다. 이같은 매커니즘이라면 우리가 사용하는 S3같은 오브젝트 스토리지에 퍼블릭으로 접근해서 가져올 수 있는 것 역시, AWS 리전의 어딘가에 웹 서버가 돌아가고 있는 것이라고 생각해볼 수 있다.

WAS

WAS는 이 웹 서버의 정적인 호스팅 기능에 더해, HTTP 요청을 보고 클라이언트에게 파일을 전송하기 전에 파일의 컨텐츠를 적절하게 바꾸거나 채워서 내려보낸다.

 

이렇게 동적으로 컨텐츠를 업데이트하기 위해 WAS에서는 필연적으로 HTTP 요청을 해석하는 로직을 구현하게 된다. 백엔드 개발을 할 때 사용하는 Spring, Express, Flask 같은 웹 프레임워크들이 이에 해당한다.

 

개발자가 작성하는 GET, POST 같은 이른바 "엔드포인트"들은 사실 REST 아키텍처의 제약 조건을 따르는 인터페이스에 맞추어 구성된 것이고, 결국은 요청에 맞게 컨텐츠를 동적으로 업데이트해서 내려보내주는게 본질이다.

 

정리하면,

• nginx - 웹 서버, 정적 컨텐츠 호스팅.
• 웹 프레임워크 - WAS, 정적 컨텐츠 호스팅 + 로직에 따라 동적으로 컨텐츠를 변경

 

프록시

nginx는 프록시(Proxy)로도 사용할 수 있다. 프록시는 클라이언트와 서버 사이에서 데이터를 중계하는 시스템이나 프로그램으로, 인터넷을 사용한다면 반드시 프록시를 사용한다고 해도 과언이 아닐 정도로 인터넷 곳곳에 퍼져있는 개념이다.

 

프록시를 구분할 때 크게 포워드 프록시(Forward Proxy), 리버스 프록시(Reverse Proxy)로 나누는데, 그 차이는 프록시 서버를 어디에 위치시키는지에 따라 달라진다.

 

포워드 프록시 (Forward Proxy)

포워드 프록시는 클라이언트와 외부 리소스 사이에 위치한다. 즉, 요청을 날리는 클라이언트에 좀 더 가까이 있다고 볼 수 있다.

 

우리가 흔히 사용하는 VPN이 포워드 프록시를 활용한 것이라고 볼 수 있다. 프록시를 사용하면 요청자의 IP가 아닌 프록시 서버의 IP로 요청을 하게 되므로 일반적인 방법으로는 접근이 불가능한 리소스를 우회해서 가져올 수 있다.

 

회사에서는 사내에서 사용하는 인프라에 대한 접근을 특정 방법으로 한정하거나(VPN 설정을 하지 않으면 접근이 불가), 반대로 외부 인터넷 접속 시 접근할 수 있는 사이트를 제한할 때 사용하기도 한다.

 

이외에도 포워드 프록시는 로컬 스토리지를 가지고 클라이언트가 요청한 리소스를 캐싱하는 데 사용될 수 있다.

 

리버스 프록시 (Reverse Proxy)

리버스 프록시는 외부에 노출시키려는 리소스 앞 단에 위치한다. 백엔드 개발자 입장에서는 이 리버스 프록시가 중요한데, 리버스 프록시가 로드 밸런싱 기능을 제공하기 때문!

 

서버가 여러 대 떠있을 경우, 앞 단에 nginx와 같은 리버스 프록시를 두면 지정한 로드 밸런싱 방식에 따라서 들어오는 트래픽을 각 서버로 분배해준다. 실제로 AWS의 Elastic Beanstalk은 기본적으로 nginx을 사용해 리버스 프록시를 구성해준다.

 

이제 Bad Gateway 페이지가 뜨는 이유를 알았다! 502 Bad Gateway 에러는 이러한 프록시가 로드 밸런싱 역할을 하면서, 연결되어 있는 서버로부터 정상적인 응답을 받지 못했을 때 발생한다.

 

이렇게 로드 밸런싱되어 있는 서비스는 자연스럽게 어떤 포트가 개방되어 있는지, IP는 무엇인지 외부에서 쉽게 알 수 없게 되고, 결과적으로 보안적인 이점도 얻는다. 보안 취약점이 있을 수도 있는 새로운 기술이나 웹 프레임워크를 사용하려고 할 때, 앞 단에 (2004년 이후로 꾸준히 사용되고 검증된) nginx 프록시를 두면 악의적인 공격으로부터 훨씬 안전하다.

 

마치며

처음 nginx가 나왔던 시기, nginx가 풀고자 했던 문제는 "어떻게 하면 10000명 이상의 클라이언트의 동시 요청을 효율적으로 처리할 수 있을까?" 하는 문제였다.

 

멀티 프로세스 / 멀티 쓰레드 기반으로 동작하는 유사한 웹 서버인 Apache와 비교했을 때, 싱글 프로세스에 이벤트 기반으로 동작하는 nginx는 작은 요청이 대량으로 발생하는 인터넷 생태계에서 훨씬 효율적으로 동작했고, 이러한 이점으로 얼마 전 기존 Apache 웹 서버의 사용량을 추월하기 시작했다. (싱글 스레드의 이벤트 기반? NodeJS가 떠오른다)

 

이 때문에 nginx라는 키워드가 곳곳에서 많이 보이는 게 아닌가 싶다. 정리하면,

nginx는 HTTP 서버, 프록시 기능을 가진 웹 서버 소프트웨어이다.
가벼우면서도 강력한 기능으로 다양한 분야에서 활용되고 있다.

 

이제야 이 글을 이해할 수 있어...

nginx 리버스 프록시, 캐시 이제는 안다!

@turastory