nginx의 기본적인 역할은 요청을 받고 응답하는 역할을 한다.
이는 flask에서도 같은 역할을 하지만, nginx를 사용할 때 여러 가지 장점이 있기 때문에 flask 단일로 사용하지 않고, nginx를 사용한다.
-> 사용하는 이유는 여러가지가 있지만, 간단한 주 목적은 "리버스 프록시"를 위해 사용된다.
이는 밑에 더 자세히 설명하도록 하고, web의 관점에서 nginx, uwsgi, flask를 비교해보자.
-> 어떤 백엔드 서버가 있을 때, 프록시 행위를 거꾸로 하는 것이다.
일단 프록시의 개념을 살펴보면,
클라이언트 -> 서버로 요청을 할 때 중간에서 프록시 서버가 이를 잡아서, 자신을 통해서 서버에 접속할 수 있도록 도와준다. 즉 서버 입장에서 보면, 어떤 클라이언트가 이 요청을 했지?? 알 수가 없다.
ex) 사용자가 google.com 에 연결하려고 하면 사용자 PC 가 직접 연결하는게 아니라 포워드 프록시 서버가 요청을 받아서 google.com 에 연결하여 그 결과를 클라이언트에 전달(forward) 해 준다.
통상의 프록시 서버는 LAN -> WAN의 요청을 대리로 수행하지만
리버스 프록시는, WAN -> LAN의 요청을 대리한다.
ex) 리버스 프록시로 웹 서버를 설정할 경우 사용자가 example.com 웹 서비스에 데이터를 요청하면 Reverse Proxy 는 이 요청을 받아서 내부 서버(보통 WAS)에서 데이터를 받은후에 이 데이터를 사용자에게 다시 전달하게 된다.
요즘은 서버가 단일 서버가 아니고 여러 개의 서버로 구성이 된다. ex) 네이버 서버
그런데 이러한 네이버에 접속을 하더라도 우리 눈에는 마치 하나의 컴퓨터 인 것처럼 동작한다.
즉,
클라이언트로 응답을 할 때 클라이언트가 이 응답이 어떤 서버에서 왔는지 특정하여 알지 못하도록 하고, 마치 하나의 서버에서 동작하는 것처럼 느껴지게 한다.
또한,
요청을 많이 받는 서버가 있다면, 요청을 좀 줄여주고, 적은 서버는 늘려주는 등의 핸들링 과정(로드 밸런싱)을 해야 되는데, 그 때 이루어지는 행위가 리버스 프록시다.
위에서 설명한 3.의 이유, nginx가 이 reverse proxy를 지원한다. 다시 말해서, 서버에서 다른 서버와의 상호작용을 지원하기 때문에 nginx를 사용하는 것이다.
리버시 프록시를 cluster로 구성해 놓으면 가용성을 높일 수 있고 사용자가 증가하는 상황에 맞게 Web Server 나 WAS 를 유연하게 늘릴 수 있는 장점이 있다.
리버스 프록시 앞에 L4 나 load balancer 를 붙이면 Round Robin(RR), Least connection 등 상황에 맞는 분배 알고리즘을 적용해 서비스 신뢰성을 높일 수 있다.
보통 기업의 네트워크 환경은 비무장 지대(DMZ; Demilitarized Zone) 라고 하는 내부 네트워크와 외부 네트워크 사이에 위치하는 구간이 존재 하는데,
위 그림과 같이 DMZ 내에 외부에 서비스를 제공하는 서버(메일 서버, 웹 서버, DNS 서버)를 배치하고 네트워크는 1, 2차 방화벽으로 보호한다.
example.com 서비스를 제공하려면 WAS를 DMZ 에 놓고 서비스해도 되지만 이런 서비스는 보통 내부의 DBMS 서버와 연결되어 있다.
만약 WAS 가 최전방에 있으면 WAS 가 털릴 경우 DBMS 와 관련 서버까지 모두 같이 털리는 심각한 보안 문제가 발생할 수 있다.
이 때문에 DMZ 존에 웹 서버를 두고 리버스 프락시로 설정하고 WAS는 내부망에 위치하여 설정한다.
리버스 프록시로 동작하는 웹 서버만 내부 WAS와 연결하도록 설정하여 웹 서버가 해킹 당해도 2차 방화벽을 다시 뚫어야 하는 식으로 보안에 더 강해질 수 있다.
참조 :