Distributed Message Queue

김기현·2023년 4월 23일

분산 메세지 큐

요약

최근 몇 년 동안 MSA 아키텍처이 일반화되면서 분산 시스템이 일반적인 상황이 되었으며 서버간의 통신이 잦아지게 되었습니다. 또한 대용량의 데이터를 처리하고 실시간 처리를 지원하고 서버 간의 통신의 신뢰성이 보장될 필요가 생겼습니다. 이 블로그 포스팅에서는 이러한 분산 시스템 상황에서 필수적으로 사용 되는 컴포넌트인 MQ(Message Queue)에 대해서 설명하고자합니다. Single Message Queue의 한계, 그로 인해 등장한 Distributed MQ의 장점과 단점에 대해 설명하려고합니다. 추가적으로 모니터링 해야하는 요소를 간략하게 다뤄보겠습니다.

Single Message Queue

Limitation

RabbitMQ, Redis와 같은 Single Message Queue는 단일 시스템의 용량 제한으로 인해 제한된 양의 데이터를 처리할 수 있습니다. Single MQ의 한계는 다음과 같습니다.

Fault Tolerance 및 HA(High Availability) 능력이 부족하여 서버 다운에 취약
- Queue Mirroring같은 기술로 등 방식을 통해 stand-by를 구현하여 장애시간을 최소화 할 수 있지만 설계 상으로 원래 clustering을 지원하지 않기 때문에 부족합니다.
성능 증가를 위해 Scale-Up을 해야하는데 비용이 많이 듦
- 단일 서버기 때문에 단일 서버의 메모리와 I/O Disk 처리량은 한계가 있기 때문이다.
단일 서버의 성능 한계가 있음
- MQ는 빠른 처리를 위해 Memory 사용, down 시 복구를 위한 event(task)를 파일로 기록(Disk I/O)
- 하는데 결국 단일 서버의 리소스를 가지고 하기에 단일 서버의 리소스의 한계와 MQ의 한계는 직결된다.

이러한 Single MQ의 한계를 극복하고 고가용성의 서비스와 지속적으로 확장 가능한 서비스를 만들기 위해서는 Distributed MQ가 필수입니다. 따라서 대용량의 데이터 처리의 필수 요소인 EDA에서는 Fault Tolerance, HA, High Scalability이 보장되는 Distributed MQ가 필요합니다.

Usage

Single MQ는 높은 Throughput 이나 Fault Tolerance가 필요하지 않은 소규모 애플리케이션에 적합합니다.

이러한 기능이 필요가 없는 서비스 규모가 작은 회사에서 무리하게 Distributed MQ를 쓴다면 이는 Over-Engineering이고 소프트웨어의 복잡성이 올라갈 뿐만아니라 값비싼 하드웨어가 필요합니다. 이는 어마어마한 비용이 필요하므로 개인의 개발 커리어 욕심 때문에 무리하게 도입하지 않도록 주의가 필요합니다.

Type of Single MQ

Rocket MQ, ActiveMQ, Redis, RabbitMQ와 같은 다양한 MQ가 존재합니다. 이 중에서 많이 화두가 되는 Redis와 RabbitMQ에 대해 설명을 하겠습니다.

결론부터 말씀드리면 단일 MQ로써 선택지는 RabbitMQ 밖에 없습니다.

Redis는 MQ의 기능을 하기 부족한 것이 때문인데 가장 큰 문제는 Message가 도착지에 도착한 것을 보장할 수 없습니다. Redis는 기본적으로 Queue에 들어온 event를 Disk에 저장하지 않기 때문에 message의 손실과 복구 기능이 부족합니다. 물론 최근들어 영속성 기능이 추가 되었지만 성능이 좋지 않아 사용하기에는 무리가 있습니다.

Distributed Message Queue

Benefits

Apache Kafka와 같은 분산 MQ는 Single MQ의 한계를 해결할 수 있습니다. 대표적인 분산 큐인 Kafka를 통해 설명하겠습니다. Single MQ가 제공하지 못하는 HA(고가용성), Scalability(확장성), Durability(내결함성)을 제공하기 위해 클러스터를 형성하는 여러 broker 서버로 구성된 분산 아키텍처를 사용합니다. Distributed MQ의 Benifit은 다음과 같습니다.

Scalability: 분산 메시지 큐는 대량의 데이터를 처리할 수 있고 확장성이 높기 때문에 대량의 데이터를 실시간으로 처리하는 데 적합합니다. 여러 분산 대기열을 사용한 확장을 통해 증가하는 트래픽, 데이터 및 클라이언트에 대응할 수 있습니다.
Fault Tolerance: 클러스터의 여러 노드에서 데이터를 복제하여 고가용성과 내결함성을 제공하여 한 노드에 장애가 발생해도 다른 노드에서 데이터를 계속 사용할 수 있습니다. 이렇게 하면 데이터를 항상 사용할 수 있고 내구성이 있으며 데이터 손실 및 다운타임 가능성이 줄어듭니다.
Durability: Kafka는 들어온 모든 메시지를 메시지를 segment에 저장하기 때문에 broker에 장애가 나더라도 데이터가 손실되지 않습니다.
Resilience: 오류로부터 자동으로 복구할 수 있습니다. 복원력이 뛰어나도록 설계되었으며 장애로부터 신속하게 복구하여 가동 중지 시간을 줄이고 가용성을 향상시킬 수 있습니다.
- replica: 각topic의 파티션은 replica를 가지기 때문에 현재 리더에 장애가 나더라도 다른 리더를 자동으로 선출한다.
- 분산 설계: 일부 broker가 죽어도 독립적으로 작동한다.
- 내결함성 설계: Producer와 Consumer는 실패한 작업을 자동으로 재시도하게 설계 되었으며 파티션을 새 브로커에 re-assign 시킬 수 있도록 설계 됨
- broker 확장: borker를 수평적 확장이 가능하도록 설계 됨
분리: 분산 메시지 대기열은 Pub/Sub 모델을 채택하여 Producer와 Consumser의 분리를 허용하여 시스템간의 결합도를 낮춰 비동기 처리를 가능하게 하고 시스템 복원력을 높입니다.

Disadvantages

Apache Kafka는 많은 이점을 제공하지만 다음과 같은 몇 가지 단점도 있습니다.

복잡성 증가: Kafka의 분산 아키텍처를 효과적으로 설정하고 운영하려면 모든 개발자가 kafka에 대한 전문 지식이 있어야합니다.
운영 오버헤드:
- Kafka 클러스터를 관리하려면 비용이 많이 들 수 있는 서버 및 storage와 같은 추가 리소스가 필요합니다.
- 시스템을 모니터링하고 유지 및 관리가 필요하므로 운영 오버헤드가 추가됩니다.
데이터 순서 제약:
- Kafka의 분산 아키텍처는 메시지가 여러 노드에 복제되므로 메시지 순서를 보장하기 어려움
- Kafka는 주문 관리를 위한 도구와 기술을 제공하지만 메시지가 올바르게 처리되도록 하려면 신중한 계획과 설계가 필요함
구성 복잡성: Kafka의 구성은 복잡할 수 있으며 최적의 성능을 보장하려면 신중한 조정이 필요
추가 종속성: Kafka에는 시스템에 복잡성을 추가하고 운영 오버헤드를 증가시킬 수 있는 ZooKeeper와 같은 추가 종속성이 필요합니다. - 최근에는 zookeeper 없이 동작하는 버전이 나오기도 함
러닝커브: Kafka는 러닝 커브가 높으며 개발자는 Kafka를 효과적으로 사용하기 위해 지속적인 공부가 필요함

분산 메시지 대기열 모니터링

최적의 성능을 보장하고 서버의 Down Time을 방지하려면 Kafka를 모니터링하는 것이 필수적입니다. 모니터링할 몇 가지 주요 지표는 다음과 같습니다.

Latency :
- 메시지가 허용 가능한 시간 내에 처리되도록 메시지가 전달되고 처리되는 데 걸리는 시간을 모니터링
Throughput:
- 시스템이 예상되는 데이터 및 트래픽 양을 처리할 수 있도록 메시지가 처리되는 속도를 모니터링
Availability:
- 시스템이 항상 사용 가능하고 액세스 가능한지 확인하기 위해 메시지 대기열의 가동 시간과 가용성을 모니터링
Replication:
- 장애가 발생한 경우에도 데이터를 항상 사용할 수 있도록 노드 간 데이터 복제를 모니터링
Consumer Lag:
- Consumer가 메시지를 처리하는 데 걸리는 시간을 모니터링
- lag이 넘처서 consumer가 중요한 데이터를 놓치지 않도록 해야함
- Skew 현상이 발생하지 않는지 잘 확인하고 해소 하도록 해야함