HiveMQ로 구축하는 MQTT 엔터프라이즈 배포

개요

이 글은 HiveMQ를 사용해 엔터프라이즈 환경에서 MQTT를 배포한 사례를 기술한다. 처음 접하는 독자도 이해할 수 있도록 아키텍처 개념부터 설정 포인트, 운영 관점까지 순서대로 설명한다. 핵심은 고가용성, 확장성, 보안, 모니터링을 균형 있게 설계하는 것이다.

HiveMQ 선택 이유와 엔터프라이즈 특성

왜 HiveMQ인가

HiveMQ는 MQTT 표준을 충실히 준수하면서 상용 지원과 엔터프라이즈 기능을 제공한다. 퍼시스턴스 옵션, 클러스터링, 플러그인(Extension) 프레임워크, 관리 인터페이스 등이 장점이다. 이로 인해 생산·스마트시티·제조 등 실시간 메시징이 중요한 도메인에 적합하다.

엔터프라이즈 배포에서 고려할 점

• 가용성: 노드 장애 대비 자동 복구와 데이터 복제 설계
• 확장성: 연결 수와 메시지 처리량 확장 전략
• 보안: TLS, 인증·인가, 네트워크 분리
• 운영·모니터링: 메트릭 수집과 알림 체계

아키텍처 설계 예시

대표적인 엔터프라이즈 아키텍처는 로드밸런서 앞의 HiveMQ 클러스터와 백엔드 시스템(데이터베이스, 메시지 브로커 연계, 애널리틱스)으로 구성된다. 로드밸런서가 접속을 분산시키고, 클러스터 내부에서는 세션과 구독 정보가 복제되거나 외부 퍼시스턴스에 저장된다.

배포 시나리오: Docker Compose 기반

소규모에서 시작해 점진적으로 확장할 때 Docker Compose는 빠른 검증에 유리하다. 다음은 3노드 클러스터의 예시 구성이다.

version: '3.7'
services:
  hivemq-node1:
    image: hivemq/hivemq:latest
    environment:
      HIVEMQ_NODE_ID: node1
    ports:
      - 1883:1883
    volumes:
      - ./conf-node1:/opt/hivemq/conf
  hivemq-node2:
    image: hivemq/hivemq:latest
    environment:
      HIVEMQ_NODE_ID: node2
    ports:
      - 1884:1883
    volumes:
      - ./conf-node2:/opt/hivemq/conf
  hivemq-node3:
    image: hivemq/hivemq:latest
    environment:
      HIVEMQ_NODE_ID: node3
    ports:
      - 1885:1883
    volumes:
      - ./conf-node3:/opt/hivemq/conf

위 구성은 테스트와 초기 검증용이다. 프로덕션에서는 로드밸런서와 외부 볼륨, 모니터링 에이전트를 추가한다.

Kubernetes 기반 배포 예

대규모 서비스에서는 쿠버네티스의 StatefulSet과 퍼시스턴트볼륨을 활용해 안정적인 노드 식별과 저장소를 보장한다. 서비스 Discovery와 HPA를 통해 확장성 확보가 가능하다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: hivemq
spec:
  serviceName: hivemq
  replicas: 3
  selector:
    matchLabels:
      app: hivemq
  template:
    metadata:
      labels:
        app: hivemq
    spec:
      containers:
      - name: hivemq
        image: hivemq/hivemq:latest
        ports:
        - containerPort: 1883
        volumeMounts:
        - name: data
          mountPath: /opt/hivemq/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

쿠버네티스 환경에서는 ConfigMap과 Secret으로 설정과 인증 정보를 관리한다. TLS 인증서는 Secret으로 보관하고 Ingress 또는 LoadBalancer로 외부 접속을 제어한다.

핵심 설정 포인트

클러스터링

클러스터링은 세션 일관성과 메시지 전달 보장을 위해 중요하다. 네트워크 레이턴시와 노드 수에 따라 토폴로지를 설계한다. 장애 발생 시 세션 유지 방식과 복구 정책이 운영 안정성에 직접적인 영향을 준다.

영속성(Persistence)과 스토리지

QoS 1·2 메시지를 안전하게 보관하려면 퍼시스턴스 설정이 필요하다. 로컬 디스크, 분산 스토리지(예: 네트워크 파일시스템), 혹은 외부 DB 연동을 조합해 사용한다. I/O 성능이 병목이 되지 않도록 주의가 필요하다.

보안과 인증

• TLS로 전송 계층 암호화 적용
• 클라이언트 인증과 권한 부여를 위한 외부 인증 연동(LDAP, OAuth 등)
• 관리 인터페이스 접근 제어

운영과 모니터링

운영 단계에서는 메트릭 수집과 로그 관리를 체계화한다. Prometheus와 Grafana를 이용해 연결 수, 메시지 처리량, 레이턴시, GC 등의 지표를 대시보드로 시각화한다. 알림은 임계치 기반으로 설정한다.

검증 절차와 체크리스트

• 기본 연결 검증: 대량 연결 시 동시 접속 처리 능력 확인
• 장애 시험: 노드 종료 후 세션 복구와 메시지 손실 여부 확인
• 보안 점검: 인증 실패, 인증 우회 가능성 검토
• 성능 테스트: 메시지 크기와 QoS 조합에 따른 처리량 측정

실무에서의 경험적 권장 사항

초기에는 작은 클러스터로 시작해 모니터링 데이터를 기반으로 수평 확장을 고려하는 방식이 위험을 줄인다. 또한 확장 시 세션 이동과 재연결 전략이 미치는 영향을 사전에 검증하는 것이 중요하다. 운영 중에는 백업 정책과 버전 업그레이드 절차를 문서화해 예기치 못한 복구 시간을 단축한다.

맺음말

이 사례는 HiveMQ 엔터프라이즈를 실제 환경에 배포할 때 고려해야 할 핵심 항목을 정리한 참고자료다. 배포 아키텍처, 클러스터링 사용법, 설정 포인트, 운영 관점의 체크리스트를 통해 안정적이고 확장 가능한 MQTT 인프라 설계에 도움이 되도록 구성했다.