Forward proxy / Reverse proxy / Load Balancer 의 공통점
위와같이 그림들은 각각의 키워드들을 간략하게 그림으로 표현한 것이다. 조금씩 다르지만 대체적으로 비슷한 모양을 하고 있는 걸 알 수 있다.
Proxy Server
추상화를 해보자면 위와같이 할 수 있다. 추상화를 했더니 클라이언트와 서버 사이에 징검다리를 해주는 서버가 하나 있는 것을 확인할 수 있는데 이런 서버를 프록시 서버라고 부르기로 했다.
나뉘어진 역할
포워드 프록시, 리버스 프록시, 로드 밸런싱은 모두 프록시서버로 행할 수 있는 기능이라고 생각을 해주면 이해하기 편할 것이다.
Proxy Server의 정의
프록시서버를 한번 정리 해보자면 클라이언트와 서버 사이에서 대리인의 역할을 하는 서버 정도로 정리해 볼 수 있다.
Forward proxy
위와같이 누군가가 만들어 놓은 프록시 서버가 있다. 이 프록시 서버는 포워드 프록시의 기능을 할 것이다. 지금부턴 간략하게 포워드 프록시라고 부르도록 하겠다. 그리고 오른쪽에는 서버가 있고 이 서버는 서비스를 위한 서버라고 생각하면 된다. 그리고 클라이언트가 있을 것이다. 클라이언트와 별도의 설정을 거치지 않았다면 클라이언트의 요청은 바로 다이렉트로 서버로 도달을 할 것이다. 하지만 클라이언트가 '프록시 서버를 이용하겠다. 포워드 프록시를 이용하겠다.' 라는 별도의 설정을 해주었다면 클라이언트의 요청은 포워드 프록시를 거쳐서 서버에 도달하게 될 것이다. 즉, 포워드 프록시는 클라이언트의 역할을 하는 프록시 서버라고 생각을 해 주면 된다. 클라이언트는 왜 이런 귀찮은 설정까지 해가면서 포워드 프록시를 사용하는 걸까?
장점
1) 캐싱
캐싱 기능을 이용할 수 있다. 위 그림에서 클라이언트의 요청이 포워드 프록시를 거쳐 서버에 도달하게 되는데 당연히 서버는 이에 대한 응답을 정해야된다. 그 과정에서 포워드 프록시는 클라이언트의 요청 정보와 서버의 응답 정보를 매칭하여 자신에게 맵핑을 해줄 수 있다. 즉 캐싱을 해둘 수가 있는 것이다. 그래서 클라이언트가 동일한 서버에 동일한 요청을 보내게 되면 캐싱되어 있는 응답을 전달해줄수 있다. 즉 성능 향상을 극대화할 수 있다.
2) 익명성
클라이언트의 익명성을 유지할 수 있다. 위 그림에서 서버의 입장에서 바라 보자. 서버에서는 자신에게 보낸 요청의
주체가 누구인지 정확하게 알 수가 없다. 서버 입장에서는 자신에게 요청을 보낸 주체가 포워드 프록시로 인지한다. 클라이언트가 요청을 보냈는지는 알 수가 없다. 그렇기 때문에 클라이언트의 익명성을 유지하기 위해서 포워드 프록시를 사용하는 경우도 종종 있다.
3) 콘텐츠 필터
콘텐츠 필터링 기능을 이용하기 위해서이다. 이번에는 응답의 과정을 한 번 들여다 보기전에 이 프록시 서버를 만든 사람이 그럴일은 없겠지만 고양이를 정말 싫어 하는 사람이라고 가정해보자. 서버응답에 고양이와 관련된 컨텐츠가 포함되어있다. 그렇다면 프록시 서버에서는 응답을 읽어서 고양이와 관련된 콘텐츠가 있다는 것을 확인한 뒤 해당 응답을 클라이언트에게 전달하지 않고 자체적인 응답을 보내 줄 수가 있다. 이 기능을 왜 굳이 사용하나라고 생각할 수 있는데 고양이를 성인컨텐츠와 같은 걸로 대입해 보면 바로 이해가 될 것이다.
4) 접근 제한
이번에는 클라이언트가 고양이 혐오증에 걸린 사람이 만든 프록시 서버를 통해서 고양이 사진이 잔뜩 들어있는 서비스에 접속을 하려고 한다고 가정해보자. 프록시 서버는 클라이언트 요청을 확인하고 해당 서버에는 고양이와 관련된 컨텐츠가 많다는 것을 확인한 뒤 해당 접근을 차단해버릴수 있다. 그리고 자신이 만들어 낸 응답을 자체적으로 돌려줄 수 있을 것이다.
Reverse proxy
포워드 프록시와 한 가지 크게 다른 점이라면 리버스 프록시의 프록시 서버는 서버 개발자가 설정을 한다는 것이다. 즉 클라이언트의 요청을 프록시 서버가 받는 것은 동일하지만 클라이언트를 대신하여 요청을 보내는 것이 아니라 서버를 대신하여 클라이언트의 요청을 받는다는 점이다.
장점
1) 캐싱
포워드 프록시와 동일하다.
2) 보안
클라이언트의 입장에서는 자신이 요청 보내는 주소 즉, 아이피와 포트 번호가 리버스 프록시로 연결이 되어 있다. 뒤에 있는 서버의 아이피 주소와 포트는 웹으로 들어가지 않아 보안쪽으로 조금 더 우수하다고 할 수 있다.
3) SSL 중앙화 관리
만약에 만든 서비스 잘 돼서 서버를 여러 개 두고 있다. 그런데 클라이언트의 요청을 https로 받기로 한다면 각각의 서버마다 ssl 인증서를 관리를 해줘야 될 필요가 있다. 굉장히 번거로운 일이된다.
그렇기 때문에 중간에 프록시 서버 즉, 리버스 프록시를 두어서 리버스 프록시 통신 할 때만 https로 통신을 하고 그리고 개별적인 서버와 통신을 할 때는 http로만 통신을 해서 ssl 인증서를 리버스 프록시에서만 관리할 수 있게 해 줄 수가 있다.
4) 로드 밸런싱
로드 밸런싱을 리버스 프록시의 기능, 장점 중 하나로 넣은 이유는 로드 밸런싱 같은 경우에는 로드 밸런싱을 해주는 로드 밸런서라는 서버를 이용해서 할 수도 있지만 리버스 프록시 자체적으로도 가능하기 때문이다.
Load Balancer
로드밸런싱은 서버의 부하를 분산해주는 기능이다. 서버의 부하를 왜 분산해주어야 할까?
만약에 서비스가 잘 되었는데 서버가 너무 가냘파서 불이 나버렸다면 서버를 확장해야할 필요성을 느끼게된다. 이때 확장에는 두 가지 방식이 있다.
첫 번째 방식은 스케일 업 방식이다. 스케일 업 방식은 하나의 서버를 하드웨어적으로 업그레이드 하는 방식이다. 이 확장의 방식에는 큰 문제점이 하나 있는데 바로 비용적인 부분이다. 어느 순간부터는 성능이 상승하는 것에 비해서 가격이 너무 너무 확 상승해버린다. 즉, 가성비가 너무 안 나온다.
두 번째 방식은 스케일 아웃 방식이다. 스케일 아웃 방식은 하나의 서버를 하드웨어적으로 업그레이드 하는 것이 아닌 여러 개의 서버를 두어 부하를 분산해주는 방식으로 확장하는 방식이다. 이 경우에도 역시 하나의 문제점이 존재한다.
바로 클라이언트의 요청을 어떻게 분배해줄것인가 이다. 이때 이 역할을 해주는 것이 바로 로드 밸런싱이다.
정리
포워드 프록시는 클라이언트의 역할을 대신하는 프록시 서버이고, 리버스 프록시는 서버의 기능을 대신해주는 프록시 서버이고, 로드 밸런싱은 서버의 부하를 분산해주는 기능인데 로드밸런서라는 프록시 서버로도 가능하지만 리버스 프록시만으로도 가능하다.
같이 보면 좋은 글
[10분 테코톡] 🔥미르의 JDK Dynamic Proxy vs CGLIB Proxy 정리
[10분 테코톡] 기론, 리버의 JDK Dynamic Proxy와 CGLIB 정리
참고
https://www.youtube.com/watch?v=JqCgJI-Nk88&ab_channel=%EC%9A%B0%EC%95%84%ED%95%9C%ED%85%8C%ED%81%AC
'개발 관련 강의 정리 > 10분 테코톡' 카테고리의 다른 글
| [10분 테코톡] 이오의 OSI 7계층 정리 (0) | 2023.06.25 |
|---|---|
| [10분 테코톡] 🌱 시드의 제네릭 정리 (0) | 2023.06.24 |
| [10분 테코톡] 레고의 Ajax 정리 (0) | 2023.06.22 |
| [10분 테코톡] 달리의 WEB의 응답과 요청 과정 정리 (0) | 2023.06.21 |
| [10분 테코톡] 여우의 Web Server와 WAS 정리 (0) | 2023.06.20 |
댓글