프록시 서버 & L4 vs L7 로드밸런서 비교

프록시 서버

   - 프록시 소프트웨어가 설치된 서버

 

$ 포워드 프록시

   - 클라이언트를 위한 프록시 서버, 클라이언트 앞단에 프록시 서버가 존재

   - 프록시 서버는 인터넷 망과 연결, 인터넷 망은 서버들과 연결

   - 클라이언트가 보낸 요청을 프록시 서버가 받고 인터넷망에 연결관 서버 장비들의 요청을 보내는 방식

   - 일반적으로 사용하지 않고 특수한 목적이 있을때만 사용한다.

   - 서버장비를 구축해서 운영하지 않고 클라이언트 내에서 SW형태 프록시로 설치

   - 인프라 환경에서는 잘 사용되지 않는다 ex) 물품을 구매한것처럼 속이는 패킷을보내 적립금 무한복제

 

 

$ 리버스 프록시

   - 클라이언트의 요청을 프록시 서버가 먼저 받고 프록시 서버가 요청을 웹서버에게 포워딩해주는 방식

   - 로드밸런서를 구현하기 위해서 서버의 앞단에 배치

   - 리버스 프록시 NAT/Firewall 방화벽 구축

   - 여러개의 웹서버를 가지고 있을 때 요청을 보내면 웹서버 마다 방화벽 설정을 해야하는데 리버스 프록시를 사용하면 프록시에서 방화벽 설정을 하기 때문에 웹서버에서 방화벽 설정을 할필요가 없다. 

   - 프록시서버에서 포워딩해서 웹서버에서는 포워딩된 요청만 받을 수 있게 된다.

 

 

L4 vs L7 비교

$ L4 로드벨런싱 

   - 세션관리가 잘 되지 않는다

   - 클라이언트가 요청하는 네트워크 패킷(4계층 헤더 정보)를 가지고 트래픽을 분산

   - 클라이언트가 프록시 서버에게 tcp/80을 찍고 80과 연결된 웹서버에게 요청패킷을 전달, 웹서버는 응답 패킷을 만들어서 프록시에 보낸다.

   - 웹서버에 많은 정보들이 있어서 요청이 웹서버에 머무르는 시간이 길지만, 그 시간동안 클라이언트PC와 웹서버는 세션을 맺는데 웹서버에서 머무는 시간 내내 세션을 맺고 있는 것은 아니다.

   - 일정 시간 지나면 클라이언트와 웹서버의 세션을 끊어버린다. 끊어진 상태에서 연결하면 다른 웹서버랑 연결하게 되고 다른 데이터를 받아들이게 된다. (사용했던 정보, 임시데이터, 쿠키데이터가 날아감)

   ex) 쇼핑몰을 사용하다가 장바구니에 담고 다른일을 하면 세션이 끊어지면 ’장바구니가 비어있습니다.‘ 라는 문구

 

$ L7 로드벨런서

   - 세션관리가 뛰어나다.

   - 1웹서버의 응답데이터에 추가적인 HTTP해더를 입력

   - HTTP헤더에는 1웹서버에서 작업하던 정보가 들어가 있다. (쿠키 데이터)

   - 쿠키데이터(클라이언트가 사이트에서 작업했던 흔적 정보)가 클라이언트 PC에 저장이 되면서 동일한 웹사이트에 접속하게 되면 응답 데이터에 쿠키정보를 같이 보내게 된다. 그러면서 웹서버의 정보를 확인하고 동일한 웹서버로 연결을 하면서 세션이 끊기질 않는다.

   - 이전에 연결했었던 웹 서버 정보를 파악해서 동일한 웹서버로 연결, 한 사이트에서 세션이 유지된 상태로 연결이 가능해진다

   - 어플리케이션 단위로 데이터 통신

 

$ HA Proxy (오픈소스)

   - 고가용성을 지원

   - 이중화가 가능 (Master, backup)

   -  VRRP(이중화 게이트) 프로토콜 사용 가능

   - nginx로 사용할 수도 있지만 돈을 주고 사용해야 한다.

   - 클라이언트와 프록시 서버간에 SSL/TLS 통신도 가능

   - 여러대의 백엔드 서버가 연결되어 있는데 그 서버들이 정상적인 상태인지 실시간으로 파악이 가능, 그러면서 로드밸런서 그룹에 포함을 시킬지 제외시킬지 결정 (★Health Check★)

 

단점

1. 로그기록 

   - 엑세스 로그를 남길 때 접속한 클라이언트 기록이 남아야 하는데 리버스 프록시를 사용하면 엑세스 로그의 기록이 프록시 서버로 남는다.

   - 프록시 서버에 세팅을 클라이언트의 정보를 포함해서 넘어가도록 따로 구현을 해야한다.

 

2. 세션 관리

   - 다수의 세션을 관리하기 때문에 세션 관리가 어렵다.