MQTT 메시지 중복 처리와 제거 전략

개요

사물인터넷 환경에서 MQTT는 가볍고 효율적인 프로토콜로 널리 사용된다. 다만 네트워크 불안정이나 클라이언트 재시도 때문에 같은 메시지가 중복 전송되는 일이 빈번하다. 중복 메시지는 상태 불일치, 데이터 중복 집계, 과금 오류 등 실무에서 심각한 문제를 유발한다. 따라서 중복을 정확히 이해하고 적절한 제거 전략을 설계해야 한다.

중복 발생 원인

네트워크 및 재전송

패킷 유실이나 연결 재설정으로 송신자는 메시지를 재전송한다. 이 과정에서 수신 측이 이전 메시지를 이미 처리했어도 다시 받는 경우가 생긴다.

클라이언트 재시작과 중복

클라이언트가 갑작스럽게 재시작되면 미확인 메시지를 다시 보낼 수 있다. 세션이 유지되지 않거나 메시지 상태를 보존하지 못하면 중복 위험이 높아진다.

MQTT QoS와 중복 특성

• QoS 0: 전달 보장 없음. 중복 가능성은 낮지만 유실이 발생할 수 있다.
• QoS 1: 적어도 한 번 전달. 중복 가능성이 존재하며 수신 측에서 중복 제거 필요.
• QoS 2: 정확히 한 번 전달을 목표. 프로토콜 차원에서 중복을 줄이나 완전하지 않은 구현에서는 여전히 문제가 발생할 수 있다.

중복 제거 전략 개요

중복 제거는 송신 측, 브로커, 수신 측 중 어떤 위치에서 수행하느냐에 따라 접근법이 달라진다. 현실적으로는 수신 측에서의 중복 감지와 서버 사이드 캐시가 가장 효과적인 경우가 많다. 아래 전략을 조합해 설계한다.

1. 메시지 식별자 사용

각 메시지에 고유 ID를 부여하면 중복 판단이 쉬워진다. ID는 UUID, 타임스탬프+클라이언트ID 조합 등으로 구성할 수 있다. 식별자는 페이로드와 분리된 메타데이터로 다루는 것이 바람직하다.

2. 멱등성(Idempotency) 설계

서버 처리를 멱등하게 설계하면 같은 메시지가 여러 번 와도 결과가 동일하다. 예를 들어 상태 업데이트는 덮어쓰기 방식으로 처리하거나, 누적 연산엔 중복 체크 후 적용하는 방식을 사용한다.

3. 중복 체크 캐시

최근 수신한 메시지 ID를 일정 기간 저장해 재처리를 차단한다. 구현은 인메모리 LRU, Redis 같은 분산 캐시, 혹은 DB의 유니크 인덱스를 활용할 수 있다. TTL을 적절히 설정해 캐시 크기를 관리한다.

4. 브로커 설정과 세션 관리

브로커의 세션 유지와 QoS 설정을 적절히 구성한다. 영구 세션을 사용하면 재연결 시 미처 전송된 메시지를 계속 추적할 수 있다. 또한 브로커 플러그인으로 중복 필터링을 도입하는 방법도 있다.

구현 예시: 수신 측 중복 제거(파이썬, Redis 기반)

아래 예시는 메시지에 포함된 message_id로 Redis를 사용해 중복을 차단하는 단순한 패턴이다. 실제 환경에서는 예외 처리와 연결 복구 로직을 추가해야 한다.

import redis

r = redis.Redis(host='localhost', port=6379)

def handle_message(message_id, payload):
    key = f"msg:{message_id}"
    # SETNX로 존재하지 않을 때만 처리 예약, TTL은 60초
    if r.setnx(key, 1):
        r.expire(key, 60)
        # 실제 처리 로직
        process(payload)
    else:
        # 중복 메시지로 판단하고 무시
        pass

def process(payload):
    # 비즈니스 로직 구현
    print("처리:", payload)

구조 설계 권장사항

• 메시지 ID 표준화: 모든 발행자에 공통 포맷을 강제한다.
• TTL 정책 수립: 중복 체크 유지 기간을 서비스 요구사항에 맞춘다.
• 멱등성 우선: 핵심 명령은 멱등하게 설계해 부작용을 줄인다.
• 모니터링과 로깅: 중복 발생 빈도와 원인을 추적한다.
• 브로커 확장성 고려: 브로커 플러그인이나 미들웨어로 중복 필터를 분산 처리한다.

주의사항과 트레이드오프

중복 제거는 완벽한 해결책이 될 수 없다. 캐시 유지 비용, TTL 설계 실패 시 정상 메시지 차단, 멱등 처리의 복잡도 증가 같은 트레이드오프를 고려해야 한다. 특히 실시간성이 중요한 워크로드에서는 짧은 TTL과 빠른 캐시 접근이 필수적이다.

결론

MQTT 중복 메시지 문제는 프로토콜 특성, 네트워크 상태, 구현 방식이 얽힌 복합 이슈다. "mqtt 중복 메시지 해결", "mqtt duplicate message 처리", "중복 메시지 방지 mqtt" 같은 키워드를 염두에 두고 설계를 시작하면 주요 패턴을 놓치지 않는다. 실무에서는 메시지 ID 기반의 중복 체크, 멱등성 확보, 그리고 적절한 캐시 정책을 조합하는 것이 가장 실용적이다. 위 전략을 바탕으로 서비스 요구에 맞게 세부를 조정하면 중복에 따른 오류를 효과적으로 줄일 수 있다.