Post

RabbitMQ Classic vs Quorum

rabbitMQ 고가용성을 위해 클러스터링을하여 사용하게 되면 queue 타입에 대해 고민해볼 필요가 있다고 봅니다. queue 타입 설명과 차이점에 대해 소개합니다.

Classic

기본 큐 타입으로 RabbitMQ 초기부터 제공된 전통적인 방식

  • 단일 리더 구조: 하나의 노드가 큐 데이터를 저장하고 관리
  • 고가용성: 미러링을 통해 복제 가능
  • 장애복구 메커니즘
    • 마스터 노드 장애 감지
    • 슬레이브 중 하나가 자동으로 새 마스터로 승격
    • 기존 마스터의 모든 메시지 상속

Classic 방식은 다른 노드에 복제할 때 비동기로 복제하고 있기 때문에 메세지 손실이 발생 가능성이 높습니다

sequenceDiagram
    participant P as Producer
    participant M as Master Node
    participant S1 as Slave Node 1
    participant S2 as Slave Node 2
 
    
    rect rgb(200, 250, 200)
        Note over M: 메시지 우선 처리
        P->>+M: 메시지 발행
        M-->S1: 비동기 백그라운드 복제
        M-->S2: 비동기 백그라운드 복제
        Note over M: 메시지 큐에 즉시 저장
    end
    
    rect rgb(250, 220, 200)
        Note over M: 마스터 노드 장애 발생!
        Note over S1,S2: 불완전한 복제 상태
        S1->>+S2: 새 마스터 선출
        Note over S1: 일부 메시지만 복제된 상태
    end
    
    rect rgb(161, 190, 247)
        Note over M: 마스터 노드 복구
        Note over S1,S2: 메시지 동기화 시도
        Note over M: 일부 메시지 유실 가능성
    end

Quorum

고가용성과 데이터 일관성을 중점으로 설계된 큐 타입

  • 다중 리더(리플리카) 구조: 여러 노드에 데이터를 분산 및 복제
  • 고가용성: Raft 합의 알고리즘 사용

장애복구 메커니즘

  • 리더 노드 장애감지
  • 리더선출을 하여 팔로워노드가 리더 노드로 승격

Quorum 방식은 과반수 노드에 동시에 저장하고 있기 때문에 메세지 손실 가능성이 적습니다.

sequenceDiagram
    participant P as Producer
    participant L as Leader Node
    participant F1 as Follower 1
    participant F2 as Follower 2
    
    rect rgb(200, 250, 200)
        Note over L,F2: Raft 합의 과정
        P->>+L: 메시지 발행
        L->>F1: Write Ahead Log 복제
        L->>F2: Write Ahead Log 복제
        F1-->>L: 복제 완료
        F2-->>L: 복제 완료
        L->>P: 메시지 발행 완료
    end
    
    rect rgb(250, 220, 200)
        Note over L: Leader 노드 장애!
        F1->>F2: Leader 선출 과정
        Note over F1: 새로운 Leader로 선출
    end
    
    rect rgb(161, 190, 247)
        Note over F1,F2: WAL에서 복구
        F1->>F2: 상태 동기화
        Note over F1,F2: 운영 계속
    end

차이점

특징Classic QueueQuorum Queue
구조단일 리더다중 리더 (Raft)
주요 장점빠른 성능, 단순함고가용성, 데이터 일관성
주요 단점고가용성 제한적성능 저하 가능성
적합한 환경소규모 메시징 시스템중요한 메시지 손실 방지 필요
This post is licensed under CC BY 4.0 by the author.