[주저리] 개념으로 이해하는 메세지 큐(Message Queue)와 카프카(Kafka)

🧐 개요

이번 포스트에서는 일전의 제가 카프카의 개념을 이해하는 과정에서 배우고 적었던 내용들을 설명하고자 합니다.

주니어 개발자로서 '메세지 큐(Message Queue)와 카프카(Kafka)'에 대한 개념을 이해하게 된 것은 최근의 일이었습니다. 컴퓨터 분야에 입문한지 이제 막 1년이 된 저에게 있어 사뭇 낯설게 느껴지는 개념들이었던 것 같습니다.

 

그간 제 머릿속에서 카프카의 개념은 아래와 같았습니다.

"다양한 데이터 원천에서 수집된 데이터는 빅 데이터 아키텍처 기반으로 구성된 DataLake 환경에 저장된다. Apache Kafka는 이렇게 DataLake 환경에 모인 빅 데이터를 서빙하는 통합 메세지 브로커로서, 각 서비스 및 어플리케이션에서 특정 데이터에 빠르게 접근할 수 있도록 도와준다.”

 

컴퓨터를 다루는 개발자가 추상적인 표현을 사용하면 안 되지만, 부끄럽게도 내용이 상당히 추상적이었군요.

당시에 처음으로 했던 일은, GPT의 도움을 받아서 개념을 구체화 해 보는 것이었습니다.

 

GPT가 추가로 설명해주었듯, 카프카가 가진 핵심 역할 및 기능 중 ‘실시간 스트리밍 데이터 처리’ 가 있습니다.

 

CPU 리소스 환경은 제한적이기 때문에, 생성된 데이터는 영구적으로 보관하지 않는 한 휘발성을 가지고 있을 것입니다. 데이터가 유실되지 않도록 스토리지 환경 등에 데이터를 보관할 수 있지만, 대부분의 스토리지는 대용량의 데이터를 빠르게 처리하기엔 속도가 너무 느립니다. 서비스 가능한 수준의 rw 속도를 구현하기 위해서는 추가적인 장치가 필요합니다.

 

이런 상황에서 클라이언트가 필요로 하는 데이터를 빠르게 가져올 수 있도록 도와주는 브로커가 있다면, 클라이언트는 원하는 기능을 즉각적으로 빠르게 구현할 수 있겠죠.

 

🔎 기술 블로그에서의 소개

OS 종류로 유명한 Redhat 사의 기술 블로그에 재미있는 글이 있어서 읽어 보았습니다.

Apache Kafka(아파치 카프카)란? 소개, 생성, 설치 및 성능

제공하는 서비스의 폭이 넓은 대기업에서 주로 채용하는 마이크로서비스 아키텍처의 경우, 저장된 데이터 중 일부분을 다수의 서비스가 공유하는 일이 종종 발생할 것입니다. 카프카는 빅 데이터 아키텍처에 저장된 데이터를 어플리케이션에 제공하기 쉬운 형태로 가공 및 복제하고, 해당 데이터를 ‘구독’ 한 어플리케이션 측의 요청에 대한 응답으로 데이터를 전달하는 방식을 사용합니다. 이러한 데이터가 모여 있는 곳을 ‘데이터 스토어’ 라고 부르며, 데이터 가공 및 복제의 과정은 비동기식으로 진행된다고 합니다.

 

🔎 Message Queue 에 대하여

카프카 및 메세지 큐에 대한 상세한 설명을 정리한 분이 계셔서 해당 글을 읽어 보았습니다.

[Apache Kafka] 카프카란 무엇인가?

메세지 큐는 프로세스 사이에서 데이터를 주고 받는 과정에서 사용하는 미들웨어 입니다.

(미들웨어는 데이터가 생성 및 가공되어 클라이언트에게 전달되는 과정에서 중간 결과물을 가로채 특정 로직을 수행하는 장치입니다. 메세지 큐는 프로세스들이 주고 받는 데이터를 임시로 보관하고 추가적인 기능을 수행해주는 미들웨어 역할을 수행합니다)

 

🏷️ 메세지 큐의 구성 요소

메세지 큐는 아래와 같은 구성 요소들로 이루어져 있습니다.

  1. producer: 데이터 송신
  2. consumer: 데이터 수신
  3. broker: 데이터 전달 (큐에 저장, 큐로부터 전송)
  4. queue: producer 데이터 임시 저장

메시지 큐는 큐(queue) 라는 데이터 임시 저장 공간을 통해 데이터를 공유합니다. 즉 엔드포인트에서 동기적으로 데이터를 직접 교환하는 방식이 아닌 것이죠. 비동기식인 만큼 데이터가 임시 저장되어 있는 동안 만큼은 언제든 데이터를 호출할 수 있습니다.

 

메세지를 전달하는 역할은 브로커가 담당하게 되고, 이러한 브로커의 구조를 pub/sub 이라고 부릅니다. 직역하면 발행/구독 시스템이라고 이야기할 수 있습니다.

 

👨‍🏫 왜 redis 는 사용하지 못하는 걸까?

메세지 큐의 여러가지 예시들 중, standalone 서비스에서 자주 사용되는 redis도 있습니다. 가장 단순하게 구현할 수 있는 메세지 큐인 redis로 kafka 등의 서비스를 대체할 수는 없을까요?

 

안타깝게도 redis는 메모리 환경에서 단일 thread로 동작합니다. 즉, 들어오는 데이터 요청을 순차 처리하게 되므로 아무리 병렬로 커넥션을 구성해도 작업 수행이 병렬로 진행되지 않습니다. 수 많은 컨슈머가 동시에 데이터를 요청할 때, 이를 병렬로 처리하기 위해서는 분산 환경을 고려한 고성능의 시스템이 필요합니다.

 

🔎 RabbitMQ vs Apache Kafka

통용적으로 사용되는 메세지 큐는 Apache Kafka와 RabbitMQ 가 있습니다. 둘 사이에는 어떠한 차이점들이 있을까요?

RabbitMQ와 Kafka의 차이점을 정리한 AWS 문서가 있어서 읽어 보았습니다. 이해하기 쉽게 상당히 잘 정리되어 있습니다.

 

RabbitMQ와 Kafka - 메시지 대기열 시스템 간의 차이점 - AWS

간단하게 차이점을 요약하면, RabbitMQ와 Kafka에서 생산자와 소비자가 상호 작용하는 방식이 서로 다르다고 합니다.

 

- RabbitMQ는 엔드투엔드 메시지 전달의 우선 순위를 지정하는 범용 메시지 브로커입니다.

- RabbitMQ의 생산자는 메시지를 보내고, 메시지가 의도한 소비자에게 도착하는지 모니터링합니다.

- Apache Kafka는 지속적인 빅 데이터의 실시간 교환을 지원하는 분산 이벤트 스트리밍 플랫폼입니다.

- Kafka의 생산자는 소비자가 메시지를 검색했는지 여부에 관계없이 메시지를 대기열에 게시합니다.

 

이 밖의 구체적인 차이점들도 상세하게 기록되어 있습니다.

 

메시지 우선순위

• RabbitMQ 브로커를 사용하면 생산자 소프트웨어는 우선 순위 대기열을 사용하여 특정 메시지를 에스컬레이션할 수 있습니다. 브로커는 선입선출 순서로 메시지를 보내는 대신 우선 순위가 높은 메시지를 일반 메시지보다 먼저 처리합니다.
• Apache Kafka는 우선 순위 대기열을 지원하지 않습니다. Apache Kafka는 메시지를 해당 파티션에 분산할 때 모든 메시지를 동등하게 취급합니다.

메시지 정렬

• RabbitMQ는 메시지를 특정 순서로 보내고 대기열에 추가합니다. 우선 순위가 더 높은 메시지가 시스템 대기열에 추가되지 않는 한 소비자는 전송된 순서대로 메시지를 받습니다.
• Kafka는 토픽과 파티션을 사용하여 메시지를 대기열에 추가합니다. 생산자가 메시지를 보내면 해당 메시지는 특정 토픽과 파티션으로 들어갑니다. Kafka는 생산자-소비자 직접 교환을 지원하지 않기 때문에 소비자는 다른 순서로 파티션에서 메시지를 끌어옵니다.

메시지 삭제

• RabbitMQ 브로커는 메시지를 대상 대기열로 라우팅합니다. 소비자는 메시지를 읽으면 브로커에 확인(ACK) 응답을 보내고, 그러면 브로커가 대기열에서 해당 메시지를 삭제합니다.
• Apache Kafka는 메시지를 로그 파일에 추가하며, 메시지는 보존 기간이 만료될 때까지 보관됩니다. 따라서 소비자는 규정된 기간 내에 언제든지 스트리밍된 데이터를 다시 처리할 수 있습니다.

정리하자면, 마이크로서비스 아키텍처를 구성하는 회사의 경우 데이터의 보존 시기를 지정하고 토픽과 파티션을 통해 데이터를 정렬해 전달하기 위해 Kafka를 사용하는 것임을 알 수 있습니다. 클라이언트를 일일히 지정해서 데이터를 전송하는 과정은 매우 번거롭고, 데이터를 재요청하는 경우 다시 생성해주어야 하니까요.

 

📝 요약하기

앞에서 학습한 내용들을 간단하게 요약한다면, Kafka로 대표되는 pub/sub 시스템은 데이터를 다양한 환경에 산재하여 수집하고 일일히 전달하는 대신, 메세지를 임시로 보관하고 적재 적소에 빠르게 전달할 수 있는 아키텍처를 통해 데이터를 전달하는 방식인 것입니다. 

 

해당 학습을 통해 메세지 큐와 pub/sub, 그리고 Kafka의 개념에 대해 대략적으로나마 이해할 수 있게 되었습니다.