[개발 지식] WebSocket과 Message Queue의 차이

들어가며

필자가 비트코인 선물 거래 모의 투자 서비스를 개발하면서 한 가지 의문점이 들었다.

현재 기능 중에서 사용자의 수익률과 수익 금액 등과 같이 실시간으로 변경되는 데이터들을 백엔드 단에서 계산을 하는데, 이를 마찬가지로 프론트 화면으로 실시간 전송을 해야한다.

당연하게도 WebSocket을 사용하여 해당 데이터를 실시간으로 전달하려고 했으나, 한 가지 궁금증이 생겼다.

그렇다면 Message Queue(이하, MQ)로는 해당 기능을 만들 수 없는 것인가?

Client와 Server가 항상 양방향으로 연결되어 실시간 동시성 통신을 하는 WebSocket의 특성상, 리소스 사용량이 많을 것인데, 그렇다면 Message Queue로 대체하는 것이 좀 더 효율적이지 않을까하고 말이다.

따라서, 이번 시간에는 두 가지 개념의 특징과 차이점을 알아보고 위 의문점에 대해서 필자가 내린 결론을 알아보도록 하자.

 

공통점과 차이점

둘은 모두 이벤트 기반의 통신을 지원한다.

따라서, REST API와 같이 요청할 때마다 값을 주고 받는 것이 아니라, 특정 이벤트가 발생하면 값을 송수신하는 방식이다.

그렇다면 어떤 점이 차이가 있을까?

먼저 Message Queue부터 알아보자

 

Message Queue

MQ의 가장 큰 특징은 비동기적이라는 것이다.

비동기가 무엇인지 간단하게 말하자면, 일을 순차적으로 처리하지 않고 나중에 해당 일을 처리해도 된다는 것이다.

예를 들어서 빨래와 청소를 해야한다고 할 때, 빨래를 세탁기에 넣고 세탁기가 끝날 때까지 기다리다가 청소를 이어서 한다면 이는 동기적이다.

반면, 빨래를 세탁기에 넣고 바로 청소를 진행한다면 이는 비동기적이다.

동기와 비동기에 대해서 더 자세한 설명을 얻고 싶다면 아래의 링크를 통해 필자가 과거에 작성한 글을 참고하기를 바란다.

https://justgotothedesk.tistory.com/134

[개발 지식] 동기와 비동기

아무튼, MQ는 이름에서 알 수 있듯이 메시지를 전달하는 매개체이기에 이를 사용할 때는 목적에 맞게 크게 세 가지로 나뉜다.

값을 송신하는 Producer, 값을 전달하는 Broker(여기서는 MQ가 되겠다.), 그리고 값을 수신하는 Consumer가 있다.

연결을 유지하지 않아도 메시지를 보낼 수 있다는 특징이 있고, 메시지를 일시적으로 저장할 수가 있다.

따라서, 예기치 못한 오류로 인하여 Producer나 Consumer가 메시지를 송수신하지 못하고 유실된다고 해도, 복구가 가능하다.

그렇기에 금융권과 같이 신뢰성이 많이 높은 도메인과 같이 데이터를 반드시 처리해야 하는 경우에 사용하는 것이 좋다.

 

 

WebSocket

반면 WebSocket은 항상 연결을 유지하면서 양방향 통신을 지원하는 프로토콜이다.

따라서, 연결이 끊기면 메시지를 받을 수가 없다는 단점이 존재한다.

하지만, 비동기적이지 않기 때문에 데이터가 실시간으로 업데이트 되어야 하는 경우에 사용하는 것이 바람직하다.

 

조금 더 효율적으로 차이를 보려면 아래의 표를 참고하기를 바란다.

특징	Message Queue	WebSocket
통신 방식	비동기 메시지 전달 (브로커를 통해 데이터 전송)	양방향 실시간 연결 (클라이언트-서버 직접 연결)
구성 요소	Producer, Broker, Consumer	Client, Server
연결 방식	비연결성 (Connectionless)	항상 연결됨 (Persistent Connection)
메시지 전달 보장	메시지 영구 저장 (Persistence)	연결이 끊기면 데이터 손실 가능
데이터 전송 모델	Pub/Sub, Queue 모델	Request-Response, Pub/Sub 가능
주요 사용 사례	비동기 작업 처리, 이벤트 큐, 데이터 스트리밍	실시간 채팅, 주식 시세, 알림 시스템

 

 

필자의 선택

그렇다면 필자는 어떤 것을 선택했을까?

그 전에 정말로 MQ의 리소스 사용량이 적은 것인지를 알아보았다.

 

Message Queue

MQ의 경우에는 메시지 전송 시점에만 CPU 자원을 사용한다.

따라서, 일반적인 상황에서는 CPU 자원 소모가 낮지만, 메시지를 큐에 따로 저장하기 때문에 메모리 사용량이 높다.

 

WebSocket

반면, WebSocket에서는 연결을 항상 유지해야 하기 때문에 일반적인 상황에서도 CPU 자원 소모량이 높다.

그러나 연결을 유지하는 각 클라이언트 당 일정한 메모리 자원을 사용하기 때문에 메모리 사용량은 MQ에 비해서 낮다.

 

이 역시도 아래의 표를 참고하기를 바란다.

비교 항목	Message Queue	WebSocket
CPU 사용량	낮음 (메시지 전달 시점에만 사용)	높음 (연결 유지 + 실시간 데이터 처리)
메모리 사용량	큼 (메시지를 저장해야 함)	중간 (연결을 유지하지만, 메시지 저장 안 함)
네트워크 사용량	중간 (메시지 크기에 따라 다름)	큼 (지속적인 연결 유지 필요)
연결 지속성	연결 없음 (필요할 때만 연결)	항상 연결 유지 (Persistent Connection)
확장성 (Scalability)	높음 (Pub/Sub 및 분산 가능)	낮음 (동시 연결 수가 많아지면 부하 증가)
리소스 관리	메시지 큐를 통해 부하 조절 가능	고객 수가 많아질수록 부하 급증

 

결론

현재 실시간으로 보여줘야하는 데이터는 수익률과 수익 금액, 그리고 청산 여부로 크게 세 가지이다.

해당 데이터들은 RDBMS에 영구적으로 저장된 평단가 데이터를 바탕으로 계산되기 때문에 Client가 수신하지 못하고 유실되더라도 다시 전송하기 수월하다.

따라서, MQ를 사용하는 것은 비효율적이라고 판단하여 WebSocket을 선택하기로 했다. (사실 처음부터 WebSocket을 사용하려고는 했어요 ㅎㅎ)

그리고 비트코인 가격이 실시간으로 변경되기 때문에 이에 맞게 세 가지 데이터도 비동기 수신이 아닌, 실시간으로 수신되어 Client가 확인하는 것이 맞다고 판단하였다.

무엇보다, 비록 모의 투자라고 할 지라도 자산과 관련된 내용이기에 신뢰가 높아야한다는 생각이 가장 컸다.

 

마치며

이번 시간에는 이렇게 MQ와 WebSocket에 대해서 간단하게 알아보았다.

MQ를 공부하면서 가장 의문이 든 점은 WebSocket처럼 지속적으로 연결이 되어있지 않은데, 어떻게 메시지가 전송되었는지를 알고 수신하는가이다.

따라서, 다음 시간에는 MQ의 Subscriber가 어떻게 이벤트를 즉시 수신하는가에 대해서 알아보도록 하겠다.