[NGINX] Forward/Reverse Proxy Server & Load Balancing

이전에 왜 Nginx가 이 세상에 나오게 됐는지 알아봤으니 이제는 Nginx의 기능에 대해 하나씩 알아가볼 예정이다.

가장 대표적인 기능이라고 생각드는 리버스 프록시에 대해 먼저 다뤄보고자한다.

우선 Proxy Server에 대해 이해하고 Forward Proxy 그리고 Reverse Proxy에 대해서 알아보고자 한다.

이때 Reverse Proxy가 Nginx와 같은 웹 서버 역할을 하므로 Reverse Proxy가 가질 수 있는 특징(장점)이 곧 웹 서버인 Nginx가 가질 수 있는 특징(장점)이라고 볼 수 있다.

프록시 서버(Proxy Server)

Proxy Server

우선 '프록시'란? '대리인'을 뜻한다. 뭔가를 대신해준다는 의미인 것 같다.

그렇다면 프록시 서버란 무엇일지 생각해보면 대신 처리해주는 서버 라고 생각해볼 수 있다.

정확히 말하면 클라이언트와 서버 사이에 중계 서버로 대리로 통신을 수행하는 기능을 하는 것을 보고 프록시 서버라고 한다.

 

포워드 프록시(Forward Proxy)

Forward Proxy를 통해 3가지 이점을 얻을 수 있다.

1. 보안 (Security)
   보통 정부, 학교, 기업 등과 같은 기관은 해당 기관에 속한 사람들의 제한적인 인터넷 사용을 위해 방화벽을 사용한다.
   포워드 프록시 서버는 방화벽과 같은 개념으로 제한을 위해 사용 된다고 보면 된다.
   즉, 특정 클라이언트 들이 방문하고자 하는 웹사이트에 직접적으로(directly) 방문하는 것을 방지할 수 있다. 예를 들어, 포워드 프록시 서버에 제약을 설정하여서 특정 사이트에 접속하는 것을 막을 수 있다.
2. 캐싱 (Caching)
   우리가 어떤 웹 페이지에 접근하면 프록시 서버는 해당 페이지 서버의 정보를 캐싱(임시보관)해둔다. 그래서 똑같이 해당 페이지에 접근하거나, 다른 클라이언트가 해당 페이지를 요청할 때 , 캐시된 정보(페이지)를 그대로 반환할 수 있고, 이는 서버의 부하를 줄이는 효과도 낼 수 있며 더불어 전송 시간을 감소시킬 수 있다.
3. 암호화 (Encryption) + 익명성 (Anonymous)
   클라이언트의 요청은 포워드 프록시 서버를 통과할 때 암호화된다. 암호화된 요청은 다른 서버를 통과할 때 필요한 최소한의 정보만 갖게 되는데, 이는 클라이언트의 ip 를 (보안을 위해) 감춰주는 보안 효과를 내준다. 
   즉, 서버가 받은 요청의 ip는 Foward Proxy의 ip가 되는 것이다.

Reverse Proxy

Reverse Proxy

Reverse Proxy는 웹 서버/WAS 앞에 위치하여 클라이언트의 요청을 해당 웹 서버/WAS에 전달한다. 클라이언트는 웹서비스에 접근할때 웹서버에 요청하는 것이 아니라 프록시로 요청하게 되고, 프록시가 서버로 부터 요청받은 데이터를 들고오는 방식이다.

 

여기서 Revere는 처음에 뭔가 뒤집힌다는 의미라고 생가했는데 그게아니라 Forward의 반댓말인 Reverse로 즉, 배후, 뒷단이라는 의미이다. 그래서 클라이언트쪽으로 데이터(response)를 보내는게 포워드 프록시라면, 그 반대편인 서버 쪽으로 데이터(request)를 보내는게 리버스 프록시이다. 

1. 캐싱 (Caching)
   : 클라이언트가 요청한 내용을 캐싱. Forward Proxy와 동일하며 엄밀히 말하면 이 캐싱이 프록시의 본래 기능이다.
   ex) 미국에 웹서버를 둔 서비스를 사용하는 한국 유저가 한국에 리버스 프록시 서버를 둔 경우 어떠한 데이터들을 캐싱하여 프록시 서버에 두는 경우 매번 미국까지 가지 않고 한국에 있는 프록시 서버를 통해 성능 향상을 이룰 수 있다.
2. 보안 (Security)
   : 서버 정보를 클라이언트로부터 숨김.
   즉, 클라이언트 입장에서는 Reverse Proxy가 실제 서버라고 생각하여 요청하는 것이다.
   이러한 방법으로 클라이언트에게 실제 서버의 IP를 숨길 수 있다.
   
   
3. SSL 암호화
   : 마지막으로 SSL 암호화에도 좋다. 본래 서버가 클라이언트들과 통신을 할때 SSL(or TSL)로 암호화, 복호화를 할 경우 비용이 많이 들게 된다. 그러나 리버스 프록시를 두고 리버스 프록시 서버에서 들어오는 요청을 모두 복호화하고 나가는 응답을 암호화해주므로 클라이언트와 안전한 통신을 할수 있으며 본래 서버의 부담을 줄여줄 수 있다.
4.  로드 밸런싱(Load Balancing)
   : 목차를 따로 빼서 조금 더 자세하게 다뤄보겠다.

이전 포스팅에서도 봤듯이  
Web Server(Nginx, Apache)를 WAS(Tomcat)와 분리하여 WAS 앞단에 두는 경우 우리는 Web Server를 보고 Reverse Proxy라고 할 수 있다.

 

로드 밸런싱(Load Balancing)

꽤나 중요한 포인트 같다.

쿠팡이나 네이버 같은 대규모 트래픽이 발생하는 경우 하나의 싱글 서버로 모든 트래픽을 처리하기에는 한계가 있을 것이다.

하나의 서버에 부하가 가는 것이다. 

이런 경우 해결책으로 하드웨어의 성능을 올리는 방법이 있을 것이다. 이것을 Scale Up 이라고 한다. 그렇지만 이것 또한 엄청난 트래픽이 발생하여 이 하드웨어 성능을 뛰어넘는 요청이 들어올 수도 있다.

이런 경우에 Scale Out을 해야한다. 이것은 서버를 여러 대로 나누어 하나의 서버가 담당해야하는 요청을 줄여주는 것이다.

그때 이제 로드 밸런서가 필요한데 여러 대의 서버가 분산 처리할 수 있도록 요청을 나누어주는 서비스이다. 

 

OSI 7 Layers 기준으로 어떤 것을 나누는 지에 따라 다른데 L4, L7에 집중하는 것이 좋을 것 같다.

우선, L4는 Transport Layer(IP&PORT) Level에서의 로드 밸런싱이다. https://ai-back-end.tistory.com이 ip주소로 요청이 들어왔을 때 서버A와 서버B로 나누어 로드 밸런싱해주는 것이다.

L4 Load Balancing

L7은 Application Layer(User Request) Level에서 로드 밸런싱이다. 다시한번  https://ai-back-end.tistory.com이 IP로 요청이 들어올때 /category/~와 /manage/~ 이렇게 요청 내용(URL, 헤더, 쿠키 등)에 따라 서버A와 서버B로 나누어 로드 밸런싱해주는 것이다.

L7 Load Balancing