MQTT 클러스터링과 고가용성(HA) 설계

서론: 왜 MQTT 클러스터링과 고가용성이 필요한가

사물인터넷 환경에서 연결되는 단말 수가 늘면 단일 브로커는 병목과 단일 실패점이 된다. 따라서 mqtt 클러스터링 구성과 mqtt 고가용성 설계는 서비스 연속성과 메시지 전달 신뢰성 확보에 필수 요소다. 이 글은 기본 개념부터 아키텍처 패턴, 구성 예제까지 실무 수준의 흐름으로 정리한다.

기본 개념 정리

브로커와 세션

브로커는 클라이언트의 연결을 관리하고, 구독과 발행 메시지를 중개한다. 클라이언트 세션(session)은 연결 상태, 구독 목록, QoS 1·2의 전달 보장 상태를 포함한다. 세션이 유실되면 QoS 보장이 깨질 수 있다.

클러스터링의 목표

클러스터링은 다음 목표를 가진다.

무중단 서비스: 단일 노드 장애 시 서비스 지속
부하 분산: 다수 연결과 메시지 처리 분산
데이터 일관성: 세션·발행 상태의 정합성 유지

아키텍처 패턴

공유 상태(Shared Store) 패턴

세션과 메시지 상태를 외부 저장소(예: Redis, Cassandra)에 보관한다. 브로커는 상태를 읽고 쓰며, 장애 복구 시 다른 노드가 상태를 이어받는다. 상태 동기화가 핵심이며 지연이 성능에 영향 줄 수 있다.

모든노드 동기화(Multi-master) 패턴

브로커 간에 상태를 자체적으로 복제한다. 예를 들어 VerneMQ는 Erlang의 분산 특성을 이용해 세션을 분산 관리한다. 복제 지연과 일관성 모델을 고려해야 한다.

프록시/로드밸런서 패턴

로드밸런서를 앞단에 두어 연결을 분산시킨다. 세션 스티키(Sticky session)를 사용하면 세션이 동일 브로커에 붙도록 할 수 있다. 반면 스티키 없이 클러스터 상태 공유가 잘 되어야 한다.

핵심 구성 요소와 고려사항

세션 지속성

영구 세션(persistent session) 필요 여부 판단
세션 저장소 선택: Redis, PostgreSQL, Cassandra 등
저장소 장애 대비 복제와 백업 전략

메시지 전달 보장(QoS)과 재전달

QoS 1·2 지원을 위해 미확인 메시지 상태를 안전하게 보관해야 한다. 브로커 간 상태 공유가 없으면 재전달이나 중복 처리가 복잡해진다.

로드 밸런싱과 연결 관리

L4 로드밸런서(Haproxy, Nginx Stream)로 TCP 연결 분산
스티키 세션 사용 시 단일 노드의 상태 집중 가능성 확인
GLB(DNS 라운드로빈)는 연결 유지와 헬스체크가 어려움

운영 측면: 모니터링과 장애 조치

모니터링 지표

연결 수, 구독 수, 메시지 처리량
큐 길이, 미확인 메시지 수, 에러 비율
노드별 CPU·메모리·네트워크 지연

헬스체크와 자동 교체

로드밸런서는 주기 헬스체크로 문제 노드를 배제한다. 컨테이너 환경에서는 오케스트레이터가 재시작과 자동 스케일을 수행한다. 상태 저장소가 제대로 동작해야 빠른 재배치가 가능하다.

구성 예제: EMQX를 이용한 3노드 클러스터 + HAProxy

아래 예제는 Docker Compose 기반의 간단한 클러스터와 HAProxy 구성이다. 운영 환경에서는 네트워크, 보안, 인증, 저장소 지속성 등을 추가로 설정해야 한다.

version: '3.8'
services:
  emqx1:
    image: emqx/emqx:5.0
    environment:
      - EMQX_NAME=emqx1
      - EMQX_HOST=emqx1
      - EMQX_NODE__COOKIE=secretcookie
    networks:
      - emqxnet
  emqx2:
    image: emqx/emqx:5.0
    environment:
      - EMQX_NAME=emqx2
      - EMQX_HOST=emqx2
      - EMQX_NODE__COOKIE=secretcookie
    networks:
      - emqxnet
  emqx3:
    image: emqx/emqx:5.0
    environment:
      - EMQX_NAME=emqx3
      - EMQX_HOST=emqx3
      - EMQX_NODE__COOKIE=secretcookie
    networks:
      - emqxnet
  haproxy:
    image: haproxy:2.4
    volumes:
      - ./haproxy.cfg:/usr/local/etc/haproxy/haproxy.cfg:ro
    ports:
      - 1883:1883
    networks:
      - emqxnet
networks:
  emqxnet:
    driver: bridge

global
  maxconn 4096
defaults
  log global
  mode tcp
  timeout connect 5s
  timeout client 1m
frontend mqtt_front
  bind *:1883
  default_backend mqtt_back
backend mqtt_back
  balance roundrobin
  option tcp-check
  server emqx1 emqx1:1883 check
  server emqx2 emqx2:1883 check
  server emqx3 emqx3:1883 check

테스트와 검증

테스트 항목 목록.

연결 급증 시 처리량과 지연 측정
단일 노드 강제 종료 후 세션 지속성 확인
네트워크 분할 시 메시지 정합성 검증
복구 시 중복 전달 여부 확인

권장 체크리스트

세션 저장 방식을 명확히 결정하고 장애 시 복구 절차 문서화
로드밸런서와 헬스체크를 통한 빠른 장애 감지 구성
모니터링·알림 체계를 구축해 임계치 도달 시 자동 대응
백업 주기와 저장소 복제 정책을 수립
성능 테스트를 통해 스케일 한계점을 명확히 파악

결론

mqtt 클러스터링 구성과 mqtt 고가용성 설계는 단순한 노드 증설을 넘어 상태 관리와 장애 복구 전략 수립이 핵심이다. 아키텍처 선택은 요구하는 일관성·성능·운영 복잡도를 균형 있게 고려해 결정해야 한다. 위 구성과 체크리스트를 바탕으로 실제 환경에 맞는 단계적 적용을 권장한다.

목차