Message Queue 그리고 Kafka

조만간 Kafka를 쓸 일이 생길 것 같아 MQ(Message Queue)와 Kafka에 대해 간단히 정리하고자 한다.

 

1️⃣ MQ

MQ는 어떤 프로세스에 대한 메시지를 저장하는 큐를 말한다.

windows 시스템의 모든 스레드에 메시지 큐가 있다고 한다.

예를 들어서 사용자가 마우스를 움직이면 WM_MOUSEMOVE라는 이벤트가 메시지 큐에 저장되어서 프로그램이 메시지 루프를 통해서 이 이벤트/명령을 수행하게 된다고 한다. [1]

보통 분산환경일 때 Kafka 등으로 MQ를 구현하는 경우가 많다고 들었다. 

지금 하고 있는 프로젝트에서 실시간성으로 대규모 데이터 업데이트가 많이 생길 예정인데 그 데이터를 우리 쪽 엔진과 WEB/APP 쪽에 모두 흘려보내 줘야 하는 이슈가 있어서 Kafka를 고려하게 되었다.

---

2️⃣ Kafka

Kafka는 아파치에서 스칼라로 개발한 오픈소스 메시지 브로커 프로젝트라고 한다.  

메시지 브로커(message broker), 다른 말로 인터페이스 엔진(interface engine)은 송신자의 메시지 프로토콜 형식으로부터의 메시지를 수신자의 메시지 프로토콜 형식으로 변환하는 중간 컴퓨터 모듈이라고 한다.

메시지 브로커는 MOM(메시지 지향 미들웨어)의 빌딩 블록이지만 완전히 대체하는 개념은 아니라고 한다.

비슷한 소프트웨어로 AWS의 SQS(Simple Queue Service)가 있다고 한다. [2]

 

Kafka는 대규모 데이터 스트리밍 플랫폼으로 어떤 한 포인트에서 여러 개의 포인트로 대규모 데이터를 흘려보낼 수 있는 분산 환경을 구축하는데 용이하다.

Kafka는 포인트 투 포인트로 데이터 통합의 필요성을 최소화해서 지연시간을 밀리 세컨드 단위로 줄임으로써 실시간성 데이터 가용성이 중요할 때 유용하게 쓰인다고 한다. [3] 

 

Kafka는 Pub/Sub (Publish/Subscribe) 모델이라는 데이터 분포 모델이다.

우리나라 말로는 발행-구독 모델인데 비동기 메시징 패러다임으로써, 발신자 메시지의 수신자는 특별히 정해져 있지 않다.

하지만 발행된 메시지는 정해진 범주에 따라, 각 범주를 구독한 수신자에게 전달된다.

수신자는 발행자에 대한 지식이 없이도 원하는 메시지를 수신할 수 있으며,

발행자와 구독자의 디커플링은 더 다이내믹한 네트워크 토폴로지와 높은 확장성을 허용한다. [5]

 

또, Kafka에는 이벤트를 생성하는/요청하는 Producer가 있고, 그 이벤트를 처리하는 Consumer가 있다.

즉, producer는 이벤트를 post 하고, consumer가 그 이벤트를 pull 해서 처리한다.

이벤트는 topic에 작성되며 이 topic은 여러 개의 broker에 분산되어 저장되는데, 이때 분산된 topic을 partition이라고 한다.

partition에 어떤 이벤트가 저장될 지는 이벤트 key에 의해 정해지며, 한번 정해지면 바뀌지 않는다.

그리고 consumer는 이 partition의 이벤트를 정확히 동일한 순서로 읽을 것을 보장한다. [6]

---

3️⃣ Kafka 활용 예시

LINE에서도 메시지 처리할 때 대용량 데이터 허브의 역할로 Kafka를 쓴다고 한다.

너무 좋은 예시를 들어준 아티클이 있어서 내용을 간단히 공유하자면,

LINE Kafka 활용 예시 [4] (그대로 펌해왔는데 문제 시 삭제하겠습니다 😥)

상기 그림은 어떤 사용자 A가 B를 친구 추가한 이벤트를 처리할 때 Kafka를 어떻게 활용하는지에 대해서 보여주고 있다.

A가 B를 친구 추가하겠다는 이벤트를 main app을 통해서 내부적으로 처리를 하고,

또 그 이벤트 내용 ADD_CONTACT를 파라미터와 함께 Kafka에 전달하게 된다.

그 이벤트는 user-activity-log-v1 이라는 topic에 게시가 되면서

이를 구독하는 hadoop 기반의 통계 처리 시스템과 사용자 간의 관계성 graph를 관리하는 그래프 시스템, 그리고 abnormal behaviour를 탐지하는 위협 탐지 시스템에서 이 이벤트를 처리하게 되는 구조다.

 

LINE에서는 여러 개의 플랫폼이 하나의 중앙화된 Kafka 클러스터를 사용하는 즉, multitenancy 클러스터를 사용하도록 구성하였다고 한다.

그 이유로는 데이터 허브라는 콘셉트, 그리고 클라이언트 각각의 kafka 클러스터를 따로 관리할 필요가 없어지면서 운영 효율이 높아지는 점 때문이라고 한다.

현재 LINE Kafka 클러스터에는 매일 2,500억 건의 메시지가 생성되고 데이터 양은 일일 210TB에 달한다고 한다. 😮👍

반대급부로 클러스터에 부하가 심하게 걸리는 경우를 대비해 Kafka의 request quota 기능으로 클라이언트 별 요청 수를 제한하고 있다고 한다. [4]

 

나중에 간단한 예제 같은걸 찾아서 Kafka 실습을 해봐야겠다.

---

출처

[1] 위키백과 

메시지 큐 - 위키백과, 우리 모두의 백과사전

[2] 위키백과 

메시지 브로커 - 위키백과, 우리 모두의 백과사전

[3] 레드햇 

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

[4] LINE engineering 블로그

LINE에서 Kafka를 사용하는 방법 - 1편 - LINE ENGINEERING

[5] 위키백과

발행-구독 모델 - 위키백과, 우리 모두의 백과사전

[6] 블로그

Kafka - Kafka란? (Kafka의 구조와, 주요개념)