[Infra] 프록시의 개념 및 프록시의 4가지 장점

많이 들어봤으며 이곳저곳에서 사용되는 프록시.

 

왜 우리는 프록시를 써야하고 왜 지금까지 프록시를 써왔을까?

 

 

Proxy

네트워크에서 프록시는 서버나 클라이언트 사이에 존재하는 중계기라고 할 수 있다.

 

프록시를 사용한 예시는 다음과 같다.

 

교내 수강신청 사이트에 수강목록을 살펴본다고 가정해보자.

• 클라이언트는 수강신청 사이트로 접근한다.
• 클라이언트는 수강 목록을 살펴보기 위해 프록시 서버로 수강 록 데이터를 요청한다.
• 프록시 서버는 실제 수강신청 서버로 수강목록 데이터를 요청한다.
• 수강신청 서버에서는 프록시 서버가 보낸 요청을 받고 결과를 응답한다.
• 프록시 서버는 프록시 서버에서 받은 데이터를 클라이언트에게 전달해준다.

위의 예제에서 알 수 있듯 프록시 서버 말 그대로 중개인이다.

 

프록시 서버는 서버이면서 동시에 클라이언트이기도 하다는 것이 포인트이다.

 

그렇다면 프록시 서버를 쓰는 이유는 뭘까?

 

왜?

굳이굳이 중간에 프록시 서버를 두어 귀찮은 작업들을 추가로 수행하는 것인가라고 한다면 다음과 같은 이점이 존재하기 때문이다.

1. 클라이언트는 더 빠른 속도의 인터넷 이용이 가능하다.
2. 클라이언트의 데이터가 더 안전하게 보호할 수 있다.
3. 안전한 필터를 제공한다.
4. 네트워크 병목 현상(요청이 몰려 서버가 과부하되는 현상)을 방지할 수 있다.

차례대로 구체적으로 알아보자.

 

클라이언트는 더 빠른 속도의 인터넷 이용이 가능하다.

 

참고 블로그 사진

 

 

프록시 서버를 두었다면 위의 그림과 같은 모습으로 구성이 될 것이다.

 

사용자가 서버로 수강목록 정보를 검색한다.

 

참고 블로그 사진

 

그럼 프록시 서버가 해당 응답에 대한 결과를 저장 (캐시)하여 사용자에게 응답해주고,
만약 다른 클라이언트가 같은 요청을 보내면 서버에게 요청하는 것이 아니라 프록시 서버에 존재하는 캐시 데이터로 응답한다.

 

참고 블로그 사진

 

그럼 사용자는 요청에 따라 프록시 서버에서 바로 결과를 받기 때문에 더욱 빠른 체감으로 서비스 이용이 가능해진다.

 

 

그렇다면 한가지 궁금증이 생길 수 있다.

 

원래 데이터가 수정되었다면 원래 캐싱 데이터는 의미가 없는 것 아닌가?

 

해당 문제를 해결하기 위해 2가지 방법이 사용된다고 한다.

• 웹훅
  • 서버에서 데이터가 변경되었을 때, 프록시 서버에 자동으로 알림을 보내는 방식
  • 프록시 서버에 HTTP 요청을 자동으로 보내 캐시 갱신 및 무효화
• 푸시 알림
  • 서버에서 데이터 변경 사실을 직접 푸시하는 방식
  • 웹훅과 유사하지만, 보다 복잡한 시스템에서 사용되며 실시간으로 캐시 갱신이 필요한 경우 유용

실제 서비스에서는 데이터의 신선도를 유지하면서도 서버의 부하를 줄이기 위해 캐싱 시간을 적절히 설정해야 한다.

 

많이 사용되지 않는 정적 컨텐츠에 대해서 캐싱 작업은 굉장히 유용할 수 있고

반복적으로 변경되는 데이터의 경우는 관련해서 trade-off가 중요할 것 같다.

 

클라이언트의 데이터를 더 안전하게 보호할  수 있다.

프록시 서버는 보안적으로 더 좋다.

 

클라이언트는 매 요청을 수강신청 서버가 아닌 프록시 서버로 요청하기 때문에 실제 리소스가 있는 서버의 IP를 몰라도 된다.

 

참고 블로그 사진

 

그럼 클라이언트는 실제 리소스가 위치한 서버에 대한 정보를 아무것도 알지 못하게된다.

그리고 프록시만 정보를 알기 때문에 실제 리소스가 더 안전하게 보관될 수 있는 것이다.

 

 

안전한 필터를 제공한다.

참고 블로그 사진

 

프록시 서버는 서버로부터 응답받은 결과를 가지고 클라이언트에게 다시 응답해주는 서버라고 위에서 이야기 했다.

 

하지만 이 과정에서 필터링을 적용한다면 사용자에게 특정 리소스만 보여지게 할 수 있는데,
그에 대한 활용이 성인 사이트의 필터링이다.

 

네트워크 병목 현상(요청이 몰려 서버가 과부하되는 현상)을 방지할 수 있다.

프록시 서버의 해당 이점은 중요하고 재미있는 개념이다.

 

병목 현상 방지를 위해 사용되는 개념은 로드 밸런싱이다.

병목 현상을 막아주기 위해 생긴 개념이 바로 로드 밸런싱이라는 개념인데, 가볍게 무엇이 로드 밸런싱인지 알아보자.

 

로드 밸런싱이란?

 

부하분산 또는 로드 밸런싱은 컴퓨터 네트워크 기술의 일종으로,
중앙처리장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을 나눠준다고 생각하면 된다.

 

서버에 가해지는 부하(=로드)를 분산(=밸런싱)해주는 장치 또는 기술이다.

 

사업의 규모가 확장되고, 클라이언트의 수가 늘어나게 되면 기존 서버만으로는 정상적인 서비스가 불가능해질 것이다.
그렇기에 증가한 트래픽에 대처할 수 있는 방법이 필요해젔고 그 방법은 크게 두 가지다.

• Scale up
• Scale out

Scale Up(질적 향상)

참고 블로그 사진

Scale Up은 서버 자체의 성능을 높이는 것으로 질적 향상을 뜻한다.

 

Scale Out(양적 향상)

참고 블로그 사진

여러 대의 서버를 두는 것이 곧 양적 향상이며 해당 방법으로 Scale Out를 구현할 수 있다.

 

이런 Scale Out에서는 동일한 기능을 수행하는 서버를 여러 대로 분리하는 것을 뜻하는데,
이 과정에서 로드 밸런서가 해당 서버의 요청에 따라 다양한 서버로 요청을 분산시킨다.

 

즉, 한 서버에 요청이 몰려 과부하 되는 현상이 발생한다면 프록시는 로드 밸런싱을 통해서 병목 현상을 방지한다.

 

 

참고 블로그

https://wonit.tistory.com/331

[Infrastructure] Proxy의 개념과 왜 우리는 프록시를 쓰고 있는가? 프록시의 4가지 장점을 빠르게 이해