📌 프록시란?
자신의 요청을 대신 수행 해주는 서버를 말한다.
즉, 내가 google.com 서버로 요청을 보내면 실제로는 나의 요청은 프록시 서버가 대신해서 google.com 서버로 요청을 한다.
이러한 특징으로 인해서 실제 google.com 서버는 proxy.com 서버로부터 요청이 왔다고 생각하고, 실제로 어떤 클라이언트로부터 왔는지는 알지 못한다.
4계층 수준에서 보면 클라이언트에서 요청을 보낼 때, 클라이언트와 프록시서버가 TCP연결을 수립한다.
그리고 실제 GET/google.com 과 같은 데이터를 프록시서버에 전송하고, 프록시는 실제 google.com서버와 TCP연결을 수립하고 대신 요청한다.
goocle.com서버 입장에서는 어떤 클라이언트로부터 요청이 왔는지 모르고, 단지 “나의 프록시 서버에서 요청이 왔다” 라고만 생각한다.
이렇게 프록시의 가장 큰 특징은 클라이언트가 프록시 서버에게 특정 서버로 대리요청을 하면, 실제 서버는 프록시로부터 요청을 받기 때문에 클라이언트를 알지 못한다.(프록시에서 클라이언트 정보 헤더를 추가하지 않는다면..!)
프록시의 사용 예시
- 캐싱
- 서버의 주소를 숨기고 싶을 때
- 로깅
- 사이트 차단
- 마이크로서비스
📌 리버스 프록시란?
프록시와 반대로 리버스 프록시는 클라이언트의 요청을 뒷단의 백엔드에 전달하고, 클라이언트는 자신의 요청이 어디로 배달되는지 알지 못한다.
대표적인 사례로 로드밸런서가 있다!
로드밸런서가 리버스 프록시의 역할을 수행할 수 있는데, 로드밸런서에 요청이 들어오면 뒤에있는 여러 서버로 요청을 넘겨서 응답을 받아올 수 있다.
또한 아파치 웹서버가 리버스 프록시의 역할을 수행하고, 뒷단에서 톰캣과같은 웹 애플리케이션 서버가 데이터를 운반해주는 역할을 수행하는 상황도 있다.
리버스 프록시의 사용 예시
- 캐싱
- 로드밸런싱
- API 게이트웨이
- CDN(컨텐츠 전송 네트워크)
- 마이크로서비스
📌 L4 / L7 로드밸런싱
레이어4 로드밸런싱
- tcp 연결을 수립하고 오직 세그먼트의 데이터들을 보낸다.
- 세그먼트 안에서 암호화가 되어있는지, 어떤 데이터가 들어있는지에 대해 전혀 신경쓰지 않는다.
- 목적지 IP주소와 port번호만 보고 분산을 해줄 수 있다.
레이어7 로드밸런싱
- 클라이언트와 로드밸런서간에 tcp연결을 수립하고, 데이터의 내용을 확인할 수 있다.
- 애플리케이션 레벨로 실제 데이터의 내용을 확인하여 분기해줄 수 있다.
- 레이어4 로드밸런싱에 비해 비용이 든다.(요청을 받고 처리하는 과정)
- 데이터 내용을 알아야하므로 암/복호화가 가능하고, API Gateway로써 역할을 수행할 수 있다.
- 캐싱이 가능하다.
- 인증이 가능하다.
프로젝트를 진행하면서 API Gateway로 SpringCloud를 활용한 경험이 있었는데, 리버스 프록시의 역할을 수행하면서 L7의 로드밸런싱 역할을 수행한 것 같다.
요청 데이터를 활용해서 인증을 하였고, 라우팅 기능을 수행했기 때문에 L7수준에서 역할을 수행 한 것이다. 추후에 프로젝트를 진행한다면 부하분산의 기능까지 수행해보고 싶다.(가능 하면 로컬이아닌 클라우드 환경에서 로드밸런싱과 성능측정도 해보고싶다!)
