peer-to-peer load balancing

Node.JS 카테고리에서 다루기에 적절한 내용은 아닌 듯 합니다만..

피어 투 피어 로드 밸런싱이 어떤것인지에 대해서만 간단하게 남겨보려고 합니다.

 

일반적으로 어플리케이션 서버에서는 이런 로드밸런싱을 고려한적은 없었던 듯 합니다.

대체로 많이 사용하는건 역방향 프록시(reverse prorxy)를 통한 로드밸런싱이고, 쉽게 사용할 수 있는 nginx 또는 클라우드 서비스를

사용한다면 AWS 의 ALB 나 CLB 등이 있을 것 같습니다.

 

위와 같은 역방향 프록시의 사용은 외부로부터 네트워크 인프라의 복잡성을 숨길 수 있고, 외부에서 사용할 수 있는 유일한

엔트리 포인트를 제공합니다. 하지만 만약 내부에서만 사용해야 하는 경우엔 피어 투 피어 로드밸런싱이 강점을 가질 수 있습니다.

 

만약 A 에서 B 로 요청을 보내야 하는 경우 역방향 프록시를 구성한다면 A -> 역방향 프록시 -> B 와 같은 구조가 되겠지만,

피어 투 피어 로드밸런싱은 이런 역방향 프록시를 제거하고 로드 밸런싱을 A 가 직접 하는 방식입니다.

물론 이런 상황에선 잘 러닝하고 있는 서버 또는 서비스에 대한 정보를 갖고 있는 로드 밸런서와 같은 수준으로 A 가 B 에 대해
아주 잘 알고 있어야겠죠.

 

 

위 그림은 로드 밸런서가 있을때와, 피어 투 피어 로드 밸런싱을 할 때의 구조 차이입니다.

굳이 그림이 필요없는 수준이긴 합니다만.. 피어 투 피어 로드 밸런싱의 장점은 아래와 같습니다.

 

• 기존 로드 밸런서에 생길 수 있는 병목 또는 유일한 엔트리 포인트에 접근이 실패한 경우의 핸들링에 걱정할 필요 없는 분산 통신
• 상대적으로 인프라 구성의 복잡도가 감소함
• 네트워크 홉이 줄어들어 더 빠른 통신 가능

물론 반대로 아래와 같은 단점도 갖고 있습니다.

 

• 네트워크 인프라 부분이 그대로 노출이 됨 (기존 역방향 프록시 구성을 통해 감췄던 인프라 부분이 드러나게 됨)
• 로드 밸런싱을 직접 해야하니 그만큼 구현에 부담이 생김

위의 단점 외에도, 사실 장점으로 써있는 부분들은 근래의 어플리케이션 서버에서 신경쓸만한 부분은 아니라고 생각하긴 합니다.

예전엔 어땠는지 모르겠지만 로드밸런서 하나 없어진 정도가 체감이 될 정도의 네트워크 속도 향상을 가져오는지도 잘 모르겠고,

인프라 구성의 복잡도가 감소할지는 몰라도 구현에 대한 부담은 그만큼 증가하면서 그 부분의 관리 및 유지 보수 비용을 생각하면

그냥 역방향 프록시로 구성하는게 훨씬 나을 것 같습니다.

 

실제로 p2p system 에선 이런 피어 투 피어 로드 밸런싱을 사용하는지는 모르겠지만, 이런 방식은 mq 에선 흔히 사용되는 패턴이라고

합니다. 예를 들어 ZeroMQ 의 경우 브로커라 불리는 ROUTER socket 에서 worker 인 REQ 또는 DEALER socket 에 연결 및

메세지를 주고 받는 부분이 그러합니다. worker socket 이 준비 되었는지, 어떤 worker socket 이 가장 놀고 있는지에 대한 목록 관리가

worker 에서 주는 메세지를 통해 브로커에서 이뤄지고 그걸 바탕으로 브로커에선 worker 에 작업을 다시 보내는 방식으로 구현되어 있기 때문에 이는 근본적으로 피어 투 피어 로드 밸런싱을 구현한다고 볼 수 있습니다.

 

위의 내용을 바탕으로 든 개인적인 생각은 피어 투 피어 로드 밸런싱을 직접 구현하는 일은 거의 없을 것 같고, 이런 방식으로 구현되어 있는

서비스를 적절한 곳에 가져다 쓰는 것이 어플리케이션 서버 개발자인 저에게 더 중요할 것 같다는 내용을 덧붙여봅니다.
피어 투 피어와 비슷한.. 예를 들어 redis 의 pub/sub 기능을 사용할 때 우리는 메세지를 받아야하는 서버들이 어떠한 채널을 subscribe 하고 특정 이벤트가 발생했을 때 publish 하는 부분에 대해 신경쓸 뿐, subscribe 하고 있는 서버가 몇개가 있고 이벤트는 어떤식으로 보내야하는지에 대한 부분은 redis 에 온전히 맡겨버리니까요.