이 글에서는 먼저 메시지 미들웨어가 보통 해결해야 하는 문제들, 이 문제를 해결하는 데 어떤 어려움이 발생하는지, Apache RocketMQ가 Alibaba가 고성능 및 고처리량 분산 메시지 미들웨어 오픈 소스로 해결할 수 있는지, 그리고 이러한 문제들이 명세에서 어떻게 정의되는지에 대해 다룹니다. 이 글에서는 독자들이 RocketMQ를 빠르게 이해할 수 있도록 RocketMQ의 아키텍처 설계를 소개할 것입니다.
1. 메시지 미들웨어가 해결해야 할 문제는 무엇인가요? 게시/구독은 메시지 미들웨어의 가장 기본적인 기능이며, 전통적인 RPC 통신과도 관련이 있습니다. 여기서 자세히 말하지는 않겠습니다.
메시지 우선순위 명세에서 설명된 우선순위는 메시지 큐를 의미합니다. 각 메시지는 일반적으로 정수로 표현되는 서로 다른 우선순위를 가지며, 우선순위가 높은 메시지가 먼저 전달됩니다. 만약 메시지가 완전히 메모리 큐에 있다면 우선순위에 따라 정렬하여 전달 전에 우선순위가 높은 메시지가 먼저 전달되도록 할 수 있습니다.
RocketMQ의 모든 메시지는 영속성이기 때문에 우선순위에 따라 정렬되면 오버헤드가 매우 커지므로, RocketMQ는 메시지 우선순위를 특별히 지원하지는 않지만, 유사한 기능을 임시 해결책으로 구현할 수 있습니다. 즉, 우선순위가 높은 큐와 일반 우선순위의 큐를 구성하고, 서로 다른 큐에 다른 우선순위를 보내는 식입니다.
우선순위 문제는 두 가지 범주로 요약할 수 있습니다:
- 우선순위가 달성되는 한, 엄밀한 의미의 우선순위는 아니며, 우선순위는 보통 높음, 중간, 낮음 또는 여러 단계로 나뉩니다. 각 우선순위는 서로 다른 주제로 표현할 수 있으며, 메시지를 보낼 때 우선순위를 나타내는 다른 주제를 지정할 수 있습니다. 이는 대부분의 우선순위 문제를 해결할 수 있지만, 비즈니스 우선순위의 정확성을 저하시킵니다.
- 엄격한 우선순위, 우선순위는 0 ~ 65535와 같은 정수로 표현되며, 이러한 우선순위 문제는 일반적으로 다른 주제로 해결하기에 적합하지 않습니다. MQ가 이 문제를 해결하려면, MQ의 성능에 큰 영향을 미칠 것입니다. 비즈니스가 정말로 엄격한 우선순위 지정이 필요한지 확인해야 하며, 만약 우선순위가 몇 개로 압축된다면 비즈니스에 얼마나 큰 영향을 미칠지 확인해야 합니다.
메시지 순서는 전송된 순서대로 소비할 수 있는 메시지의 유형을 의미합니다. 예를 들어, 주문은 주문 생성, 주문 결제, 주문 완료 3가지 메시지를 생성합니다. 섭취할 때는 이 순서대로 섭취하는 것이 의미가 있습니다. 하지만 동시에 주문은 병행해서 소비할 수 있습니다.
RocketMQ는 메시지가 질서 있게 유지되도록 엄격히 보장할 수 있습니다.
메시지 필터 브로커 메시지 필터링
브로커에서는 소비자의 요구에 따라 필터링하는 것이 불필요한 메시지 전송을 줄이는 장점이 있습니다.
단점은 중개인의 부담이 증가하고 실행이 상대적으로 복잡하다는 점입니다.
1. Taobao Notify는 메시지 유형별 직접 필터링과 유연한 문법 표현식 필터링 등 다양한 필터링 방식을 지원하며, 거의 가장 까다로운 필터링 요구를 충족시킬 수 있습니다.
2. Taobao RocketMQ는 간단한 메시지 태그, 메시지 헤더 및 본문에 의한 필터링을 지원합니다.
3. 유연한 구문 표현식 필터링도 CORBA 알림 명세에서 지원합니다.
소비자 측 메시지 필터링
이 필터링은 애플리케이션에서 완전히 맞춤화할 수 있지만, 단점은 소비자에게 쓸모없는 메시지가 많이 전송된다는 점입니다.
메시지 지속화에는 여러 가지 일반적인 지속성 방법이 있습니다:
- Mysql과 같은 데이터베이스에 저장하세요.
- levelDB, Berkeley DB 및 기타 KV 스토리지 시스템과 같은 KV 저장소로 보존하세요.
- Kafka, RocketMQ와 같은 파일 레코드 형태의 지속성
- Beanstalkd, VisiNotify 같은 메모리 데이터의 영구 이미지를 만드세요
- (1), (2), (3) 세 가지 영속성 방법 모두 메모리 큐 버퍼를 확장할 수 있으며, (4)는 브로커가 종료되고 재시작된 후에도 이전 메모리에서 데이터를 복원할 수 있는 메모리 이미지입니다.
JMS와 CORBA 알림 명세서는 어떻게 지속할지 명시적으로 명시하지 않지만, 영속성 부분의 성능이 전체 메시지 미들웨어의 성능을 직접 결정합니다.
RocketMQ는 성능을 향상시키기 위해 Linux 파일 시스템 메모리 캐시를 최대한 활용합니다.
메시지 신뢰성이 메시지 신뢰성에 영향을 미치는 여러 상황이 있습니다:
- 중개인은 정상적으로 마감합니다
- 중개인 붕괴
- OS 크래시
- 기계는 전원이 끊기지만, 전원 공급 장치는 즉시 복구할 수 있습니다.
- 기계가 켜지지 않습니다(CPU, 메인보드, 메모리 등 주요 장치에 손상되었을 수 있습니다).
- 디스크 장치 손상.
(1), (2), (3), (4)는 모두 하드웨어 자원을 즉시 복구할 수 있는 상황이며, RocketMQ는 메시지가 손실되거나 소량의 데이터가 손실되지 않도록 보장할 수 있습니다(플래싱 방식이 동기식인지 비동기식인지에 따라 다릅니다).
(5) (6) 단일 실패 지점으로, 일단 발생하면 복구할 수 없으며, 이 단일 지점에 있는 모든 메시지가 손실됩니다. 두 경우 모두 RocketMQ는 비동기 복제로 인해 메시지의 99%가 손실되지 않도록 보장하지만, 손실될 수 있는 메시지는 매우 적습니다. 동기식 이중 쓰기 기술은 성능 저하를 불가피하게 하는 단일 지점을 완전히 피할 수 있어, 통화 관련 애플리케이션과 같이 매우 높은 메시지 신뢰성 요구가 필요한 상황에 적합합니다.
RocketMQ는 버전 3.0부터 동기식 이중 쓰기를 지원합니다.
저지연 메시징은 메시지가 브로커에 도달한 직후 메시지가 누적되지 않고 소비자에게 도달할 수 있습니다.
RocketMQ는 메시지가 매우 실시적이며, 실시간 메시지가 푸시보다 낮지 않도록 하기 위해 긴 폴링 풀 방식을 사용합니다.
적어도 한 번은 각 메시지가 한 번씩 전달되어야 한다는 뜻입니다.
RocketMQ Consummer는 먼저 메시지를 로컬 영역으로 가져온 후, 소비가 완료된 후 ACK를 서버에 반환합니다.
딱 한 번뿐이야- 전송 메시지 단계는 중복 메시지 전송을 허용하지 않습니다.
- 메시지 소비 단계에서는 중복된 메시지를 소비할 수 없습니다.
위의 두 조건이 모두 충족될 때만 메시지를 "정확히 한 번만"으로 간주할 수 있으며, 위 두 가지 조건을 달성하기 위해 분산 시스템 환경에서는 막대한 오버헤드가 필연적으로 발생합니다. 따라서 높은 성능을 추구하기 위해 RocketMQ는 이 기능을 보장하지 않으며, 비즈니스 내에서 중복 제거가 필요하므로 소비자 메시지는 놪등성(놪등성)이어야 합니다. RocketMQ가 중복 없음을 엄격히 보장할 수는 없지만, 정상적인 상황에서는 반복 전송 및 소비가 거의 없으며, 네트워크 이상 현상, 소비자 시작 및 정지, 메시지 중복과 같은 기타 비정상적인 상황만 발생합니다.
이 문제의 근본 원인은 네트워크 통화에 불확실성이 존재하기 때문이며, 즉 성공도 실패도 없는 세 번째 상태에 해당하기 때문에 메시지 반복 문제가 발생합니다.
브로커스 버퍼가 꽉 찼다면 어떻게 해야 하나요? 브로커의 버퍼는 보통 브로커 내 큐의 메모리 버퍼 크기를 의미하며, 보통 크기가 제한되어 있습니다. 버퍼가 가득 찼다면 어떻게 되나요?
다음은 CORBA 알림 명세에서 처리되는 방식입니다:
- RejectNewEvents는 새 메시지를 거부하고 RejectNewEvents 오류 코드를 프로듀서에게 반환합니다.
- 특정 정책에 따라 기존 메시지를 폐기하세요
- AnyOrder - 오버플로우 시 어떤 이벤트든 버릴 수 있습니다. 이 속성의 기본 설정입니다.
- FifoOrder - 처음 받은 이벤트가 가장 먼저 폐기됩니다.
- Lifo Order - 마지막으로 받은 이벤트가 가장 먼저 버려집니다.
- 우선순위 순서 - 이벤트는 우선순위 순서대로 폐기되어야 하며, 낮은 우선순위 이벤트는 높은 우선순위 이벤트보다 먼저 폐기됩니다.
- 마감 순서 - 이벤트는 만료 시간이 가장 짧은 순서대로 먼저 폐기되어야 합니다.
RocketMQ에는 메모리 버퍼 개념이 없으며, 큐는 영구 디스크로 구성되어 데이터가 정기적으로 삭제됩니다.
이 문제에 대한 해결책으로, RocketMQ는 다른 MQ들과 매우 중요한 차이가 있습니다. RocketMQ의 메모리 버퍼는 무한 길이의 큐로 추상화되어 있으며, 데이터가 얼마나 들어와도 설치할 수 있습니다. 이 무한대는 브로커가 만료된 데이터를 정기적으로 삭제한다는 전제입니다. 예를 들어, 브로커는 3일치 메시지만 저장하고, 버퍼 길이가 무한하지만 3일 전 데이터는 큐 끝에서 삭제됩니다.
회고적 소비란 소비자가 성공적으로 소비한 메시지를 의미하며, 비즈니스 수요로 인해 그 메시지를 다시 소비해야 함을 의미합니다. 예를 들어, 소비자 시스템 고장으로 인해 복구 후 1시간 전 데이터를 재소비해야 하며, 브로커는 시간 차원에 따라 소비 진행 상황을 되돌릴 수 있는 메커니즘을 제공해야 합니다.
RocketMQ는 밀리초 단위로 정확한 시간 차원을 가진 시간 기반 소급 소비를 지원하며, 이를 앞으로 또는 뒤로 되돌릴 수 있습니다.
메시지 스태킹 메시지 미들웨어의 주요 기능은 비동기 분리이며, 또 다른 중요한 기능은 프론트엔드의 데이터 플러드 피크를 차단하고 백엔드 시스템의 안정성을 보장하는 것입니다. 이는 메시지 미들웨어가 일정한 메시지 스태킹 능력을 갖추어야 하며, 메시지 힙은 다음과 같은 두 가지 상황을 통합합니다:
- 메시지는 메모리 버퍼에 쌓이고, 메모리 버퍼를 초과하면 CORBA 알림 명세서에 설명된 특정 드롭 정책에 따라 메시지를 폐기할 수 있습니다. 이 방식은 메시지 폐기(discarding)를 허용할 수 있는 서비스에 적합하며, 이 경우 메시지의 축적 용량은 주로 메모리 버퍼 크기에 달려 있고, 메시지 중첩 후에는 메모리 내 데이터 양이 외부 세계에 제공하는 접근 능력에 제한적인 영향을 미치기 때문에 성능 저하가 크게 크지 않습니다.
- 메시지는 DB, KV 저장소, 파일 레코드 형식과 같은 영구 저장 시스템에 쌓여 있습니다. 메모리 캐시에서 메시지가 도달하지 못하면 디스크에 접근하는 것이 불가피하며, 이는 많은 읽기 IO를 생성하고, 읽기 IO의 처리량은 쌓인 메시지 접근 능력을 직접 결정합니다.
메시지 축적 능력을 평가하는 주요 포인트는 네 가지입니다:
- 몇 개의 메시지를 쌓을 수 있는지, 몇 바이트가 쌓일 수 있을까요? 즉, 메시지의 힙 용량입니다.
- 메시지가 쌓인 후, 스택이 메시지의 처리량에 영향을 미치나요?
- 메시지가 쌓인 후 소비자들의 정상적인 소비에 영향을 받을까요?
- 메시지가 쌓인 후, 디스크에 쌓인 메시지에 접근할 때 처리량은 얼마인가요?
분산 트랜잭션 XA, JTA 등 여러 알려진 분산 트랜잭션 명세가 있습니다. 그중 XA 사양은 Oracle, Mysql 등 주요 데이터베이스 벤더에서 널리 지원받고 있습니다. 그중 XA의 TM 구현 리더인 Oracle Tuxedo는 금융, 통신 및 기타 분야에서 널리 사용되고 있습니다.
분산 트랜잭션은 2단계 커밋 문제를 포함하며, 데이터 저장 측면에서 KV 저장소를 지원해야 합니다. 왜냐하면 커밋 롤백의 두 번째 단계는 메시지 상태를 수정해야 하며, 이는 키를 따라 메시지를 찾는 동작을 포함해야 하기 때문입니다. RocketMQ는 2단계에서 키를 따라 메시지를 찾는 문제를 우회합니다. 1단계에서 준비된 메시지를 보내고, 메시지의 오프셋을 얻으며, 2단계에서 오프셋을 통해 메시지에 접근해 상태를 수정합니다. 오프셋은 데이터의 주소입니다.
RocketMQ의 트랜잭션 구현 방식은 KV 저장소를 통해서가 아니라 오프셋 방식을 통해 이루어지는데, 이 방법은 큰 결함이 있는데, 오프셋을 통해 데이터를 변경하면 시스템에 너무 많은 더러운 페이지가 생겨 특별한 주의가 필요합니다.
예약된 메시지란, 브로커에게 전송된 직후 소비자가 메시지를 소비할 수 없으며, 특정 시점이나 특정 시간을 기다린 후에만 사용할 수 있음을 의미합니다.
브로커 수준에서 임의의 시간 정확성을 지원하려면 메시지 정렬을 해야 하며, 지속성이 관련되면 메시지 정렬은 필연적으로 큰 성능 오버헤드를 초래하게 됩니다.
RocketMQ는 타이밍 메시지를 지원하지만 임의의 시간 정확도는 지원하지 않으며, 5초, 10초, 1m 등 특정 타이밍 수준을 지원합니다.
메시지 재시도 소비자가 메시지를 소비하지 못하면, 메시지를 다시 소비하게 하는 재시도 메커니즘을 제공하세요. 소비자 소비 메시지 실패는 일반적으로 다음과 같은 상황에서 고려할 수 있습니다:
- 메시지 자체의 이유, 예를 들어 직렬 제거 실패 때문에 메시지 데이터 자체가 처리되지 않습니다(예: 전화 요금 충전, 현재 메시지의 휴대전화 번호가 로그아웃, 충전 불가 등). 이 오류는 보통 이 메시지를 건너뛰고 다른 메시지를 소비해야 하며, 이 실패 메시지는 소비를 즉시 재시도해도 99% 실패하므로 10초 후 재시도하는 타이머 리트리지 메커니즘을 제공하는 것이 가장 좋습니다.
- DB 연결이 불가능하거나 외부 시스템 네트워크에 접근할 수 없는 등 의존적인 하위 애플리케이션 서비스가 제공되지 않기 때문입니다. 이 오류가 발생하면, 현재 실패한 메시지가 건너뛰어도 다른 메시지들이 함께 소비됩니다. 이 경우 Sleep30을 적용하고 다음 메시지를 소비하는 것이 권장되며, 이는 중개인이 메시지를 다시 시도해야 한다는 압박을 줄일 수 있습니다.
RocketMQ 개요 위에서 언급한 메시지 미들웨어가 직면한 문제들을 RocketMQ가 해결하는지 확인해 봅시다.
RocketMQ란 무엇인가요?
위 그림은 메시지 미들웨어의 전형적인 메시지 송수신 모델이며, RocketMQ 역시 이렇게 설계되어 있습니다. 간단히 말해 RocketMQ는 다음과 같은 특징을 가지고 있습니다:
- 이는 고성능, 높은 신뢰성, 높은 실시간, 분산 특성을 가진 큐 모델 메시지 미들웨어입니다.
- 프로듀서, 컨슈머, 큐 모두 배포할 수 있습니다.
- 프로듀서는 차례로 몇몇 큐에 메시지를 보내며, 큐 컬렉션은 Topic, Consumer Broadcast consumption이라면 한 소비자 인스턴스가 해당 주제에 해당하는 모든 큐를 소비하고, 클러스터 소비 시에는 여러 컨슈머 인스턴스가 해당 큐 컬렉션을 고르게 소비합니다.
- 엄격한 메시지 순서는 보장할 수 있습니다
- 풍부한 메시지 풀 모드를 제공합니다
- 효율적인 수평 가입자 확장 기능
- 실시간 메시지 구독 메커니즘
- 수억 건의 메시지 축적 용량
- 의존도가 줄어듭니다
RocketMQ 물리적 배치 구조
위 그림에서 보듯이, RocketMQ의 배치 구조는 다음과 같은 특징을 가집니다:
- 네임 서버는 노드 간 정보 동기화 없이 클러스터에 배포할 수 있는 사실상 상태 없는 노드입니다.
- 브로커의 배포는 비교적 복잡하며, 브로커는 마스터와 슬레이브로 나뉩니다. 마스터는 여러 슬레이브에 대응할 수 있지만, 슬레이브는 한 마스터에만 대응할 수 있습니다. 마스터와 슬레이브 간의 대응은 동일한 브로커네임과 다른 브로커ID, 브로커리드는 마스터를 의미하는 0, 0이 아닌 경우 슬레이브를 의미합니다. 마스터는 여러 개로 배치될 수도 있습니다. 각 브로커는 이름 서버 클러스터 내 모든 노드와 긴 연결을 구축하고, 정기적으로 모든 이름 서버에 주제 정보를 등록합니다.
- 프로듀서는 이름 서버 클러스터 내 노드 중 하나와 긴 연결을 구축하고(무작위로 선택), 정기적으로 이름 서버에서 주제 라우팅 정보를 가져오고, 주제 서비스를 제공하는 마스터와 긴 연결을 구축하며, 정기적으로 하트비트를 마스터에 전송합니다. 프로듀서는 완전히 비상태이며 클러스터로 배포할 수 있습니다.
- 소비자는 이름 서버 클러스터 내 노드 중 하나와 긴 연결을 구축하고(무작위로 선택), 정기적으로 이름 서버에서 주제 라우팅 정보를 가져오며, 주제 서비스를 제공하는 마스터와 슬레이브와 긴 연결을 구축하고, 정기적으로 하트비트를 마스터와 슬레이브에게 전송합니다. 소비자는 마스터와 슬레이브 모두에서 메시지를 구독할 수 있으며, 구독 규칙은 브로커 설정에 의해 결정됩니다.
RocketMQ 논리적 배치 구조
위 그림에서 보듯, RocketMQ의 논리적 배포 구조는 두 가지 특징을 가집니다: 생산자와 소비자.
메시징 애플리케이션을 표현하는 데 사용되는 프로듀서 그룹은 여러 프로듀서 인스턴스를 포함하며, 이는 여러 대의 머신, 한 머신의 여러 프로세스, 또는 프로세스의 여러 프로듀서 객체일 수 있습니다. 프로듀서 그룹은 여러 개의 주제 메시지를 보낼 수 있으며, 프로듀서 그룹은 다음과 같이 기능합니다:
- 생산자 유형을 식별하세요
- O&M 도구를 통해 이 메시징 애플리케이션에 여러 Producer 인스턴스가 있는지 쿼리할 수 있습니다
- 분산 트랜잭션 메시지를 보낼 때, 프로듀서가 예기치 않게 다운되면, 브로커는 프로듀서 그룹 내 모든 머신을 적극적으로 호출하여 거래 상태를 확인합니다.
소비자 메시징 애플리케이션을 표현하는 데 사용되는 소비자 그룹은 여러 개의 소비자 인스턴스를 포함하며, 이는 여러 기계, 여러 프로세스 또는 프로세스의 여러 소비자 객체일 수 있습니다. 소비자 그룹 내 여러 소비자는 고르게 분포된 방식으로 메시지를 소비하며, 방송으로 설정되면 이 소비자 그룹 내 각 인스턴스가 전체 데이터를 소비합니다.
RocketMQ 데이터 저장 구조
위 그림에서 보듯이, RocketMQ는 데이터를 인덱스와 분리하는 저장 방식을 채택합니다. 파일 자원, IO 자원, 메모리 자원의 손실을 효과적으로 줄입니다. 알리바바와 같은 방대한 데이터도 고동시성 시나리오는 종단 간 지연을 효과적으로 줄이고 강력한 수평 확장 능력을 제공합니다.
|
게시됨 2017. 7. 28. 오후 8:26:52
|
|
|
|
게시됨 2017. 7. 29. 오전 8:09:37