네트워크 통신

네트워크 병렬 서버 로드 밸런싱 - 프록시 서버

마달랭 2024. 11. 26. 18:42
반응형

 

개요

다수의 클라이언트가 서버로 요청을 보내는 경우, 한개의 서버로 모든 클라이언트의 로직을 처리한다면 해당 서버에는 과부하가 걸릴 것이고 클라이언트는 응답을 늦게 받거나 서버가 뻗어버릴 것이다.

그렇다면 서버를 병렬로 두어 여러가지 서버를 둔다고 가정을 해보자

클라이언트 입장에서는 각 서버의 IP주소와 포트번호를 알아야 연결 요청을 진행할 수 있다.

그럼 클라이언트 입장에서 어떤 IP주소와 포트번호로 연결 요청을 해야할까?

또한 연결 요청한 서버가 과부하 상태라면 어떻게 할까?

이를 관리 해주기 위한 로드밸런싱이 필요하다.

 

 

프록시 서버

네트워크 프록시

 

네트워크 프록시

개요프록시(Proxy)는 네트워크 통신에서 중개 서버 역할을 하는 시스템이다.클라이언트와 서버 사이에서 데이터를 중계하거나 대리로 처리하는 기능을 수행한다.클라이언트가 직접 목적지 서버

zzzz955.tistory.com

 

과거 프록시 서버에 대한 내용을 작성한 이력이 있으니 해당 글을 먼저 참고해 보아도 좋다.

 

프록시 서버는 클라이언트와 서버간의 중개 서버 역할을 한다.

클라이언트는 우선적으로 프록시 서버로 연결 요청을 한다.

그럼 프록시 서버에서 특정 우선 순위를 통해 가장 가중치가 낮거나 높은 서버로 연결한다.

즉 클라이언트 ↔ 프록시 서버 ↔ 서버1의 관계가 만들어진다.

이를 통해 프록시 서버는 클라이언트와 서버를 연결해 주고, 데이터를 전송만 해준다.

서버 측에서는 받은 데이터를 갖고 내부 로직을 통해 응답을 생성 후 다시 전송해 주기만 하면 된다.

 

이를 통해 서버 과부하가 발생하지 않도록 프록시 서버가 로드 밸런싱을 진행해 준다.

프록시 서버를 둘 경우 당연히 클라이언트의 접속과 요청이 많을 것이라 가정한 상태이다.

따라서 비동기 I/O 모델을 사용해야 하며, 정확한 요청에 따른 부하 분산 기능을 수행해야 한다.

 

이 외에도 다양한 서버 병렬 분산 방법이 있지만 현재 흐름에서는 데이터가 클라이언트와 서버 간에 프록시 서버를 통해 항상 전달된다.

이를 통해 프록시 서버가 트래픽을 중재하므로 보안 및 로드 밸런싱 관점에서 유리하다.

하지만, 모든 입출력 연산이 프록시 서버를 거치기 때문에 프록시 서버의 부하가 증가할 수도 있다.

프록시 서버가 초기 연결만 중재 하되, 이후에는 클라이언트와 백엔드 서버 간 직접 연결을 설정하는 방식을 고려할 수도 있다. 이를 커넥션 핸드오프라 한다.

 

 

데이터 흐름

  1. 클라이언트 → 프록시 서버(IP:포트)로 연결 요청.
  2. 프록시 서버가 클라이언트의 요청을 accept.
  3. 프록시 서버가 부하 분산 로직(개발자가 알아서)으로 적합한 서버 선택(예: 서버1).
  4. 프록시 서버 → 서버1(IP:포트)로 연결 요청.
  5. 서버1이 프록시 서버의 요청을 accept.
  6. 클라이언트 → 프록시 서버: 데이터 쓰기 요청.
  7. 프록시 서버가 데이터를 읽고 → 서버1에 데이터 쓰기 요청.
  8. 서버1이 데이터를 읽고 내부 로직 처리 후 → 결과 데이터 생성.
  9. 서버1 → 프록시 서버: 결과 데이터를 쓰기 요청.
  10. 프록시 서버가 데이터를 읽고 → 클라이언트에 데이터 쓰기 요청.
  11. 클라이언트가 데이터를 읽음.
  12. 클라이언트 → 프록시 서버: 연결 종료 요청.
  13. 프록시 서버 → 서버1: 연결 종료 요청.
  14. 서버1이 연결을 종료하고 응답 후 소켓 닫기.
  15. 프록시 서버가 클라이언트와 연결 종료 후 소켓 닫기.
  16. 클라이언트가 소켓 종료.

 

 

커넥션 핸드오프

프록시 서버가 초기 연결만 중재하고, 이후 데이터 전송은 클라이언트와 서버 간 직접 통신이 이루어지도록 하는 방식

이를 통해 프록시 서버의 부하를 줄이고, 클라이언트와 서버 간의 통신 효율을 극대화할 수 있다.

 

클라이언트와 백엔드 서버 간의 직접 연결로 레이턴시 감소하여 효율적 데이터 전송이 가능하다.

백엔드 서버 추가 시 프록시의 부하 증가 없이 확장 가능하다.

 

하지만, 프록시 서버가 트래픽을 제어하지 않으므로 보안 관점에서 관리 어렵다.

소켓 핸들 전달, NAT 설정 등 구현 복잡도가 증가하여 복잡성의 이슈가 있다.

클라이언트와 백엔드 서버 간 연결 상태를 모니터링하기 어려울 수 있어 연결 상태 관리가 힘들다.

 

실제 구현에서는 FD 전달 방식과 NAT 리다이렉션이 자주 사용되며, 프록시 서버의 역할에 따라 최적의 방식을 선택해야 한다.

만약 구현 복잡도를 줄이고 싶다면, HAProxy나 Envoy와 같은 로드 밸런싱 솔루션에서 커넥션 핸드오프 기능을 활용하는 것도 좋은 방법이다.

 

728x90
반응형

'네트워크 통신' 카테고리의 다른 글

네트워크 병렬 서버 로드 밸런싱 - DNS, Anycast  (1) 2024.11.26
네트워크 IOCP  (0) 2024.11.26