메시지 스트리밍 MQTT와 WebSocket 무엇을 적용하는게 좋을까?

사이드 프로젝트 팀에서 채팅 기능을 구현하기로 했다.

 

Pub/Sub 메시지 스트림을 어떤 방식으로 구현할지 논의하던 중, 회사에서 대량의 데이터를 DB에 저장하기 위해 MQTT를 사용했던 경험이 떠올랐다.

 

물론 WebSocket이 널리 사용되는 이유가 있겠지만, 왜 MQTT 방식은 잘 사용되지 않는지에 대한 의문이 들었다.

 

IoT 기기에서 데이터를 받아오기 위해 주로 쓰이는 기술이라는 것과, 낮은 배터리 성능이나 불안정한 네트워크 환경에서 적합하다는 사실은 알고 있었지만, MQTT와 WebSocket의 차이점을 더 깊이 이해하고 싶어서 관련 자료를 조사해 정리해보았다.

1. MQTT (Message Queuing Telemetry Transport)

MQTT는 경량의 Publish/Subscribe 기반 메시징 프로토콜로, 낮은 대역폭과 신뢰성 있는 데이터 전송을 요구하는 소형 장치 간의 통신에 최적화되어 있다. IoT(Internet of Things) 환경에서 널리 사용되며 Non-TCP 환경에서도 동작한다.

 

사실 프로토콜이라고 하기보단 메시지 통신 방법을 정의한 것 이라고 하는 것이 보다 정확한 표현일 것이라고 생각한다.

 

Non-TCP 환경에서도 동작한다는 것 자체가 통신 프로토콜에 의존하지 않는다는 뜻이며, 일반적으로는 TCP/IP 위에서 동작하지만, UDP나 Websocket에서도 동작할 수 있다.

 

1-1. MQTT 동작 원리

MQTT 구조도

MQTT는 브로커(Broker)와 클라이언트(Client)로 구성된다.

• 브로커: 메시지를 수신하고, 해당 주제를 구독한 클라이언트에게 전달하는 역할
• 클라이언트: 메시지를 발행하거나 구독하는 장치. 각 클라이언트는 특정 주제(topic)에 메시지를 발행하거나 해당 topic을 구독하여 데이터를 수신한다.

브로커는 다양한 종류의 오픈 소스 브로커가 있으며 대표적으로 Mosquitto, Mosca, RabbitMQ, EMQ, VerneMQ등이 있다.

1-2. 발행/구독 구조

MQTT는 주제(topic)를 기반으로 메시지를 전송한다. topic은 계층 구조로 되어 있으며, /로 구분된다.

• 발행자(Publisher)는 주제에 메시지를 보내고
• 구독자(Subscribe)는 해당 주제를 구독하여 메시지를 받는다.

MQTT는 우리가 흔히 알던 HTTP의 요청/응답 구조가 아닌 발행/구독 구조를 갖고 있기 때문에 Many to Many 전송이 유리하다.

 

또한 QoS(Quality of Service)을 통해 메시지 전송 후  전송한 메시지를 삭제하지 않고 완료 패킷(PUBACK)을 기다리기 때문에 전송의 실패한 메시지를 주기적으로 재전송할 수 있다.

2. WebSocket

WebSocket은 클라이언트(웹 브라우저)와 서버 간에 양방향(full-duplex) 통신을 가능하게 하는 프로토콜이다.

 

HTTP와 달리, 클라이언트와 서버가 상호작용을 계속 유지할 수 있어, 클라이언트에서 새로운 데이터가 있는지 확인할 필요 없이 서버에서 먼저 보내주는 것도 가능하다.

 

최초 HTTP 핸드쉐이크 연결 시에만 요청/응답을 사용하며, 연결이 성립되면 TCP기반 양방향 통신이 이루어진다.

2-1. WebSocket vs. HTTP

• HTTP는 요청-응답 방식으로 클라이언트가 서버에 요청을 보내야만 서버가 응답 가능하다.
• WebSocket은 한 번 연결이 되면, 추가적인 요청 없이도 서버에서 데이터를 전송할 수 있어 실시간 통신에 효율적.

2-2. 사용 사례

• 채팅 애플리케이션: 실시간으로 메시지를 주고받기 때문에 채팅 시스템에서 WebSocket이 자주 사용
• 실시간 주식 데이터: 주식 거래소에서 실시간 가격 변동을 즉시 클라이언트에 전달할 때 사용됨.

3. WebSocket vs MQTT?

MQTT와 WebSocket은 개념적으로도 다르고 사용 목적이 다르기 때문에 직접적으로 비교하는 것은 조금 부적절하다.

 

비유해보자면, WebSocket은 클라이언트와 서버가 직접 소통할 수 있도록 길을 만든 것이라면, MQTT는 중간에 브로커가 메시지를 받아 클라이언트에게 전달하는 방식이기 때문에 우체국과 같은 방법이라고 할 수 있다.

 

따라서 웹 브라우저 환경에서 MQTT를 사용하는 것은 결국, TCP나 UDP같은 통신 프로토콜을 사용해야 한다는 것인데

 

결국 WebSocket을 통해 이를 구현해야 MQTT 통신을 사용할 수 있다는 뜻이 된다.

 

정리하자면 MQTT방식을 이용하기 위해선 WebSocket도 사용해야 한다는 것.

 

무언가 특별한 이유가 없다면 MQTT와 WebSocket을 복잡하게 구현하여 사용하는 것보다, WebSocket만 사용하는 것이 구현이 더 간단하고 성능도 좋다.

 

결론!

단순 채팅 서비스를 구현한다고 치면 MQTT가 과도한 기술일 수 있다.

 

또한 MQTT는 웹 브라우저에서 사용하는 것을 상정하고 만들어진 기술이 아니기 때문에 이를 서포트하는 라이브러리도 적다!

 

우리의 목표는 웹 브라우저 내에서 채팅 기능을 구현하는 것이기 때문에 MQTT를 사용할 특별한 이유를 찾지 못한다면 WebSocket를 사용하는 것이 유리할 것이다.

 

Reference

https://www.quora.com/What-are-the-pros-and-cons-of-WebSockets-versus-MQTT-as-real-time-web-infrastructure-for-the-Internet-of-Things

https://stackoverflow.com/questions/42265001/how-to-publish-a-message-to-a-specific-client-in-mosquitto-mqtt

http://www.steves-internet-guide.com/mqtt-protocol-messages-overview/