프록시란 너무 범용적인 단어입니다. Spring Proxy, Proxy 패턴, Network Proxy 등에서 널리 사용되는 단어인데, 이번에 저희가 살펴볼 내용은 Network Proxy 입니다.
프록시 서버란 쉽게말해 "통신을 대신 처리하는 서버" 입니다. 클라이언트와 서버간의 중계 서버로, 통신을 대리 수행하는 서버입니다.
몰론 위와 같이 프록시 서버가 없이 클라이언트와 서버가 직접적으로 인터넷을 통해 통신은 가능합니다. 다만 이런 방식을 채택하면 클라이언트의 IP주소가 유출될 수 있다는 위험성이 존재합니다. (자세한 내용은 조금뒤에 설명드리겠습니다)
이 외에도 다양한 이유로 프록시 서버를 통해 클라이언트와 서버가 프록시 서버를 통해 간접적으로 통신하는데, 이들을 계속 알아봅시다.
정리) 프록시 서버 : 클라이언트와 서버간의 통신을 중계해서 대리 수행해주는 서버. 클라이언트와 서버는 직접적으로 통신하는 일을 방지할 수 있습니다.
프록시서버는 크게 Forward Proxy, Reverse Proxy 2종류로 나뉩니다.
일반적으로 부르는 "프록시 서버" 는 Forward Proxy 를 의미합니다. 예를들어 아래처럼
이런 표현들에서 사용하는 프록시라는 것이 Forward Proxy 입니다.
Forward Proxy 의 특징중 하나는 바로 캐싱입니다. 캐싱이란 자주 요청하는 결과 데이터를 캐시에 저장해놓고, 해당 데이터를 재요청하는 경우 서버에 재요청하지 않고 프록시 서버의 캐시에 저장해놓은 데이터를 리턴하는 방식 을 의미합니다.
예를들어 첫번째 클라이언트가 가요차트 1등 그룹이 누구인지 정보를 얻고싶어서, 서버에게 요청을 보냈다고 해봅시다.
여러개의 서버중 가요차트 정보를 제공해주는 담당 서버는 클라이언트가 원하는 정보를 아래처럼 제공해주겠죠? Forward Proxy 서버와 인터넷을 통해 정보를 주고받을 겁니다.
그런데 이때 프록시 서버는 그냥 단순히 원하는 정보를 제공해주는 것이 아닙니다. 캐시에다가 가요차트 1등 그룹이 누구인지를 저장해놓는 것이죠.
그러고 추후 여러 클라이언트들이 가요차트 1등 그룹이 누군지를 알고 싶을때 프록시 서버는 캐시에 저장해놓았던 데이터를 제공해주는 것입니다. 즉, 서버까지 귀찮게 도달하지 않더라도 캐시에 저장해놓은 데이터를 프록시 서버가 대신 제공해주는 것이죠.
이러한 캐싱의 특징으로 얻을 수 있는 장점은 다음과 같습니다.
- 1) 전송 시간절약
- 2) 불필요한 외부 전송을 하지 않아도 된다.
- 3) 외부 요청이 감소한다 : 네트워크 병목현상 감지
인터넷, 서버를 통하지 않기 떄문에 전송 시간이 절약됩니다. 또한 불필요한 외부 전송을 하지 않아도 되고 외부 요청이 감소됨으로써 네트워크 병목현상을 방지할 수 있습니다.
다음으로는 익명성이라는 특징이 있습니다. 익명성을 지닌다는 것은 클라이언트가 보낸 요청을 감춘다는 의미입니다.
클라이언트가 서버로 직접 호출할때는 저희(클라이언트)의 IP주소, 장비 정보, OS정보등을 그대로 서버에게 전달해야합니다.
만일 Forward Proxy 를 사용한다면 저희 클라이언트가 요청했지만 마치 Forward Proxy 가 요청을 한 것처럼 서버들에게 Forward Proxy 의 정보들을 전달해 줄 수 있습니다.
즉, 클라이언트의 IP주소 같은 정보를 서버에 직접 제공하지 않고, 대신 Forward Proxy 의 정보를 제공하는 것이죠. 이게 익명성입니다.
서버는 응답받은 요청을 누가 보냈는지 알지 못하게 됩니다.
예를들어 서버가 받은 요청 IP 는 곧 proxy IP 입니다. (서버가 받은 요청 IP = proxy IP)
Reverse Proxy 는 Forward Proxy 과 거의 유사하나, 큰 차이점을 뽑자면 Forward Proxy 와 달리 인터넷-서버 사이에 위치하고 있다는 점입니다.
이들의 특징도 간단히 알아봅시다.
Forward Proxy 와 동일하게 캐싱이 가능합니다. 그로 인해 얻어내는 장점도 동일하죠. 캐싱이 무엇인지는 앞서 살펴봤으니 자세한 설명은 생략하겠습니다!
다음 특징은 보안적이다 라는 것입니다. 서버의 정보를 클라이언트로부터 숨길 수 있다는 점입니다.
클라이언트는 요청을 할때 어떤 서버에 요청을 하는지, 또 해당 서버의 정보는 무엇인지 직접 알지 못합니다. 대신 클라이언트 입장에서 서버인 Reverse Proxy 에게 요청을 전달합니다.
클라이언트들은 Reverse Proxy 를 실제 서버라고 생각하고 요청을 합니다. 따라서 실제 서버들의 IP는 클라이언트로부터 안전하게 보호됩니다.
정리해보자면 아래와 같습니다.
다음으로 로드밸런싱이 가능하다는 점입니다. 로드밸런싱은 상황에 따라서 할지말지를 결정해야합니다. (하는 경우도 있고, 하지 않는 경우도 있습니다. 선택적임)
로드밸런싱(Load Balancing) 이란 쉽게 말하면 부하분산입니다. 해야할 작업 및 요청을 적절히 분배시켜서 서버의 부하를 분산시키는 것입니다.
로드밸런서란 여러대의 서버가 분산(나누어) 처리할 수 있도록 요청을 나누어주는 서비스다.
저희는 왜 로드밸런싱을 써야하며? 이것은 왜 Reverse Proxy 에서 활용되는 것일까요?
예를들어 최대 10명의 요청을 동시간대에 처리가능한 서버를 구축하고 배포했다고 가정해봅시다.
그런데 서비스 사용자가 많아져서 10명이 넘어가는 사람들이 요청을 보내는 경우가 발생한다면, 서버에 부여하는 부하가 커질겁니다. 과부하가 걸리는 것이죠.
앞서 로드밸런싱을 알아봤는데, 특징을 정리하고 추가적인 장점을 나열해보자면 다음과 같습니다.
여기서 저는 비용적인 부분을 생각해 논리적인 Scale out 방식을 생각했습니다.
Scale out을 하기 위해서 무조건 해야 하는 일이 로드밸런싱입니다!
로드밸런싱을 통해 무중단 서비스와 배포가 가능해집니다.
로드밸런서의 종류는 네트워크 계층의 7 Layer 를 기준으로 나누어져있다고 합니다. 저희는 이중에 L4, L7 정도만 알고 넘어갑시다.
ex) 예를들어 http: //msung99.velog.io 에 접근시 서버 A와 B로 로드 밸런싱을 해주는것이다.(나눠줌)
어떤 사이트로 들어갔을 때 우리가 80번 포트로 접근을 하게되죠. 이를 그냥 서버 A와 B로 요청을 고르게 나눠주는 것이다. 이게바로 L4 로드밸런서입니다.
ex) 예를들어 http: //msung99.velog.io 에 접근시 "http: //msung99.velog.io" URL의 뒤에다 무엇을 붙이는가에 따라서, 혹은 Query Param 에 따라서 그 애플리케이션을 요청하는 방법에 따라서 어떤 서버로 로드밸런싱을 할지 결정하는게 L7이다.
이 방식은 기본적으로 Reverse Proxy 를 기반으로 동작합니다.
Reverse Proxy 는 로드밸런싱만을 위해 개발된 프로그램이 아니기 때문에 기본적인 로드밸런싱의 기능만이 있지만 그만큼 비용적으로 저렴하고 구축이 쉽다는 장점이 있다.
.
좋은글 잘보고갑니다 👍👍