24/02/06 TIL __ 메세지 브로커 와 소켓 어뎁터

 

 

 

실시간 스트리밍 사이트에서 채팅기능을 맡아 진행했는데, socket io를 이용했었다.

대용량 트래픽을 경험해 보고자 메세지큐, 메세지 브로커 등을 찾아봤었는데,

socket io의  adapter라는 애도 비슷한 역할을 하는게 아닌가?!!

 

혼돈의 카오스 였지만, 많은 정보조사를 통해 정리가 되었다. 

 

먼저 socket io에서는 mongodb  어뎁터, redis 어뎁터, ws어뎁터, ws를 이용한 커스텀 어뎁터 가 있다. 

이 어뎁터의 역할을 찾아보니, 분산된 소켓서버 간의 통신을 돕는다고 한다. 

 

 

예를 들어보자. 

1번 채팅방에 10명이 있었는데, 갑자기 1000000명이 들어왓다고 가정해 보자.

1번 채팅방은 실시간 소켓 통신이고, 이걸 저 많은 인원이 유지하고 있다고 하면? 

서버 부하가 매우 많은 상황이라고 볼 수 있다. 

이때 1번 채팅방을 1-1, 1-2 채팅방으로 서버 분산을 시킨다.

그럼 1-1과 , 1-2 는 사실 같은 채팅방인데 서로 통신하지 못하는 문제가 발생한다. 

트래픽과 서버부하를 위해 분산을 시킨건데 통신을 못하면 의미가 없지 않은가? 

그때 socket io 의 adapter를 사용한다. 

 

즉 socket io 의 adapter는 분리된 서버에서 실시간 통신을 위해 사용된다.

 

 

 

 

반면 메세지 브로커, 메세지큐는 시스템간에 비동기적으로 메세지를 처리하기 위해 사용된다. 

 

 

예를 들어보자.

a가 메세지를 보내면 큐에 담았다가 b에 준다.

이때 b1, b2, b3, b4, b5가 있다면, 이들 중 현재 가능한 요소에게 전달한다. 

처리가 불가한 요소들에게는 전달하지 않는다는 말이다.

또한 만약 이들 5개 요소 모두 들어오는 메세지 a를 처리할 수 없는 상태라면?

이 큐에 메세지를 보관한다. 그리고 가능해지면 그때 전달한다.

 

이런 장점이 있어 안정성과 확장성이 있다고 하는것이다.

그렇지만 무조건 대용량 트래픽에 메세지큐를 사용해야만 하는건 아니다. 

또 사용법에 따라 오히려 독이 될 수도 있다.

비동기 처리이고, 큐에 보관을 하기 때문에, 예상치 못한 트래픽이라면 좋은 선택지이겠지만,

예상된 트래픽이라면, 이런 장치만 믿고있기에는 너무 부족하다.

큐에 담겨지는 데이터들이 점점 늘어나고, 데이터를 처리할수 있는 애들이 부족하다면 큐가 얼만큼 버틸수 있을지 의문이기 때문이다. 

내일은 이런 것들을 실제로 적용해봐야겟다.

 

 

 

이미지 출처

https://www.linkedin.com/pulse/message-queues-10-reasons-use-queuing-ranjeet-vimal/

Message Queues – 10 Reasons to Use Message Queuing

https://channel.io/ko/blog/tech-socketio-redis-adapter-improvement

Socket.io Redis Adpater 구현을 통한 트래픽 개선