MQTT 메시지 보증 추적과 로깅 아키텍처

개요

IoT와 마이크로서비스 환경에서 MQTT는 가볍고 효율적인 메시징을 제공한다. 그러나 전송 보증(QoS)과 재전송, 중복 처리 등은 시스템 신뢰성에 직접적인 영향을 준다. 본문은 mqtt 메시지 추적 구현과 mqtt 로깅 아키텍처를 연계하여 전달 보증을 검증하고 문제를 진단하는 방법을 설명한다.

왜 메시지 보증 추적이 필요한가

운영상의 문제와 가시성

브로커 장애, 네트워크 단절, 클라이언트 재시작 등은 메시지 손실이나 중복을 유발한다. 단순 로그만으로는 송신자와 수신자 간의 상태를 연결하기 어렵다. 따라서 각 메시지의 라이프사이클을 추적하는 체계가 필요하다.

규제와 감사

금융, 제조, 헬스케어 등 일부 도메인에서는 메시지의 전달 여부와 시점이 감사 대상이다. delivery 보고서 mqtt 형태의 기간별 보고서를 자동 생성하면 컴플라이언스 요구사항을 충족시킬 수 있다.

핵심 개념

상태 추적(Correlation)

메시지마다 고유 ID(correlation id)를 부여하고, 송신-중계-수신 과정의 이벤트를 이 ID로 연결한다. 이 과정에서 생성되는 이벤트는 다음과 같다.

PUBLISHED: 퍼블리셔가 메시지를 발행한 시점
BROKER_ACK: 브로커가 QoS에 따라 수신 또는 처리 확인을 한 시점
DELIVERED: 구독자에게 실제로 전달된 시점
CONSUMED 또는 PROCESSED: 구독자가 메시지를 처리 완료한 시점
ERROR 또는 TIMEOUT: 전달 실패나 만료 발생 시점

아키텍처 구성 요소

1. 퍼블리셔 측 엔벨로프

퍼블리셔는 원본 메시지에 메타데이터를 포함시킨다. 최소한의 메타데이터는 correlation_id, timestamp, qos, topic 이다. 이 정보는 추적과 상관분석의 기초가 된다.

2. 브로커와 플러그인

브로커에 플러그인을 추가해 PUBLISH/ACK/DELIVER 이벤트를 캡처한다. 예를 들어 EMQX나 Mosquitto의 확장 포인트를 이용해 이벤트를 외부 추적 시스템으로 전송한다.

3. 추적 수집기(Delivery Tracker)

수집기는 이벤트를 받아 상태 머신으로 전환한다. 이 컴포넌트는 다음 기능을 수행한다.

이벤트 집계 및 타임스탬프 정렬
상태 변환 로직 적용(QoS별 재시도, 중복 판단)
실패 감지 및 알림 트리거

4. 중앙 로깅/스토리지

이벤트와 패킷 메타데이터는 검색성과 집계 성능을 고려하여 저장한다. 일반적으로 ELK(Elasticsearch)나 ClickHouse, TimescaleDB 등을 사용한다. 저장 스키마는 다음과 같이 설계한다.

{
  "correlation_id": "uuid-v4",
  "event_type": "PUBLISHED|BROKER_ACK|DELIVERED|CONSUMED|ERROR",
  "topic": "sensors/room1/temperature",
  "qos": 1,
  "client_id": "device-123",
  "timestamp": "2026-03-20T10:15:30Z",
  "payload_size": 128,
  "metadata": { "retries": 2 }
}

추적 흐름과 처리 절차

추적 처리의 기본 흐름은 다음과 같다.

퍼블리셔가 메시지 발행 시 correlation_id 포함
브로커 플러그인이 PUBLISH 이벤트를 캡처해 추적 수집기로 전송
브로커가 ACK 또는 PUBREC/PUBREL(Pub/Sub QoS 2) 이벤트를 생성하고 전송
구독자에게 DELIVERED 이벤트를 기록하고, 소비시 CONSUMED 이벤트를 추가
수집기는 이벤트를 합쳐 최종 상태(성공, 중복, 실패)를 판정하고 보고서 생성

상태 판정 규칙 예시

간단한 상태 판정 로직은 다음과 같다.

수신된 PUBLISHED만 있고 일정 시간 내 BROKER_ACK가 없으면 타임아웃
BROKER_ACK가 있으나 DELIVERED가 없으면 라우팅 문제 또는 구독자 오프라인
DELIVERED는 있으나 CONSUMED가 없으면 소비 로직 문제

실전 구현 예제(간단한 의사코드)

// 퍼블리셔: 메시지 발행 시
let msg = {
  correlation_id: generateUUID(),
  topic: "devices/+/data",
  qos: 1,
  payload: { temp: 23.5 }
};
mqtt.publish(msg.topic, JSON.stringify(msg.payload), { qos: msg.qos, properties: { correlation_id: msg.correlation_id } });

// 브로커 플러그인: 이벤트 전송
emitTrackingEvent({ correlation_id: msg.correlation_id, event_type: 'PUBLISHED', timestamp: now(), client_id: client.id });

// 추적 수집기: 상태 업데이트
onEvent(e) {
  storeEvent(e);
  updateState(e.correlation_id);
}

보고서와 알림

delivery 보고서 mqtt 형태는 주기적으로 생성해 SLA와 실패율을 확인한다. 보고서는 다음 항목을 포함하면 유용하다.

전체 메시지 수
성공 전달 비율(QoS별)
평균 지연 시간(PUBLISH->DELIVERED)
타임아웃 및 에러 목록

운영 고려사항

성능과 비용

모든 이벤트를 장기 보관하면 비용과 검색 속도에 영향을 준다. 요약 이벤트와 원본 이벤트를 분리 보관하고, 원본은 보존 기간을 짧게 설정한다.

프라이버시와 보안

페이로드에 민감한 정보가 있다면 로깅 이전에 마스킹 또는 해시 처리한다. 로그 접근 권한은 최소한으로 설정한다.

모니터링

실시간 대시보드와 경고 체계를 마련해 전달 실패 패턴을 즉시 파악한다. 지표로는 실패율, 평균 지연, 재시도 횟수 등을 모니터링한다.

결론

MQTT 환경에서 메시지 보증을 신뢰할 수 있게 만들려면 단순한 브로커 설정만으로는 부족하다. mqtt 메시지 추적 구현을 통해 퍼블리셔와 구독자 사이의 이벤트를 연계하고, mqtt 로깅 아키텍처로 데이터를 저장·분석하면 문제 원인 파악과 SLA 준수가 쉬워진다. 위에서 제시한 구성요소와 절차를 기반으로 단계적으로 도입하면 안정적인 전달 보증 체계 구축에 도움이 된다.

목차

개요