📕 개요
처음 MSA 아키텍처와 Kafka 를 접했을 당시, 관련 문서를 찾아보며 “MSA 아키텍처를 활용하면, Kafka 를 함께 사용해야 한다” 는 느낌의 글을 많이 접하게 되었다.
하지만 대부분의 글에서는 Kafka 를 활용하는 이유를 “고가용성” 정도만 설명하고 있어, 기초 지식이 부족했던 당시에는 그 이유를 명확히 이해하기 어려웠던 기억이 있다.
때문에 이번 글에서는, 직접 MSA 아키텍처와 Kafka를 활용해본 경험을 바탕으로,
왜 Kafka 가 MSA 환경에서 사용되는지에 관해 정리해보고자 한다.
🔍 MSA(Microservice Architecture)
우선 이를 위해서는, MSA 아키텍처에 관해 알아야할 필요가 있다.
MSA 는 간단히 말해, 하나의 어플리케이션을 위해 다수의 서비스가 동작하는 방식이다.
이해를 위해 배달의민족 어플리케이션을 예시로 들어보자.
배달의민족 서비스에서 우리가 음식을 주문하기 위해서는 대략적으로 아래와 같은 과정을 거쳐야한다.
[ 음식 검색 → 매장 조회 → 음식 조회 → 주문 → 결제 ]
이때, 위의 과정을 하나의 서비스에서 처리하는 것이 아니라 음식 서비스, 매장 서비스, 주문 서비스, 결제 서비스와 같이 역할을 나누어 이를 분산 시켜 처리하도록 하는것이 MSA 아키텍처이다.
이러한 MSA 아키텍처는, 서비스 간 독립적으로 관리가 가능해 많은 이점을 얻을 수 있다.
하지만, 이때문에 서비스 간 주기적인 통신이 필요하고 이를 위해 활용하는 것이 메세지 큐, 즉 Kafka 이다.
MSA 에서는, “장애 전파 방지” 라는 중요한 포인트가 있다.
예를 들어, 음식 서비스에 장애가 발생하여도 이는 주문 서비스로 전파가 되지 않게 하는 것이다.
하지만, 일반적으로 HTTP 와 같은 방식으로 서비스 간 직접 통신하게 되면 서비스 간 결합도가 증가하여 장애가 전파될 수 있다.
이러한 결합도를 낮추기 위해, MSA 에서는 메세지 큐를 통해 각 서비스 간 통신을 진행하는 것이고, 이러한 방식을 EDA(Event-Driven Architecture) , 이벤트 기반 아키텍쳐라고도 한다.
또한, 메세지 큐를 활용하게 되면 메세지가 유실되지 않고 안전하게 처리하기 위한 “재처리” 기능을 기본적으로 지원하기에 안정성 또한 보장할 수 있다.
🔍 Kafka, RabbitMQ, Redis Streams
그래서, 메세지 큐 중 왜 Kafka 를 활용하는 것일까?
결론부터 말하자면, 꼭 Kafka 여야하는 것은 아니다.
다른 메세지 큐도, 큐 라는 특징을 공유하는 만큼 활용 방법이나 방식 등은 비슷하기 때문이다.
때문에 상황과 목적에 맞는 메세지 큐를 선택하는 것이 중요하고, 이를 위해서는 각 메세지 큐의 특징을 알아야 할 필요가 있다.
- Kafka
Kafka 는 메세지를 파티션이라는 곳에 담고, 이를 컨슈머(어플리케이션) 로 전달하는 동작 원리를 하고 있다.
이러한 파티션의 갯수는 자유롭게 추가 할 수 있으며 ( 제거는 불가 ), 어떤 파티션에 메세지를 저장할 것인지 설정할 수 있기 때문에, 특정 메세지 간 처리 순서를 보장할 수 있다.
또, Kafka 는 클러스터 구성으로 메세지를 복제 및 분산 시킬 수 있고, 모든 메세지는 오프셋 기반의 로그 형태로 저장되어, 메세지 추적이나 재처리가 용이하다는 장점이 있다.
즉, 다른 메세지 큐에 비해 높은 확장성과 트래픽 처리에 대한 유연성을 갖추고 있기 때문에, 일반적인 MSA 환경에서 보편적으로 활용 되곤 한다.
2. RabbitMQ
RabbitMQ 에서는 메세지가 Exchange 에 전달되고, 이를 어떤 Queue 에 전달할 것인지 결정하게 된다.
이 구조 덕분에, 하나의 메세지를 여러 Queue 에 동시에 전달하거나, 조건에 따라 다른 Queue로 분기 처리하는 등의 유연한 설정이 가능해, 메세지 활용도가 높다는 이점이 있다.
또한, RabbitMQ 는 Kafka 와 비교해 구조가 비교적 단순하고 가벼워서, 낮은 지연이 중요한 상황에서 빠른 응답성을 제공할 수 있다는 강점도 있다.
때문에, 모놀리식 아키텍처나 규모가 크지 않은 서비스에서 단독으로 활용되기도 하며, Kafka 와 함께 병행하여 알림과 같이 빠른 처리가 요구되는 기능에 RabbitMQ 를 사용하는 방식으로도 활용된다.
3. Redis Streams
Redis Streams 는 기본적으로, 위에서 설명했던 RabbitMQ 의 장점을 모두 갖고 있다고 생각하면 편하다.
이중, Redis Streams 는 RabbitMQ 와 달리 메모리 단에서 처리를 하기 때문에 메세지 처리 속도가 매우 빠르며 지연이 거의 없다는 강점이 존재한다.
또, Redis 내부에서 구동하기 때문에 추가적인 인프라를 구축하지 않아도 된다는 점 또한 큰 강점이 될 수 있을 것이라 생각한다.