메세지 큐와 MOM
카프카를 이해하기 위해서는 먼저 메세지 큐와 MOM을 알아야한다. 메시지 큐는 분산화된 환경에서 발신자와 수신자 사이에서 메세지를 전송하고, 수신하는 기술을 의미한다. MOM(message oriented middleware)를 통해서 구현된다.
메세지 큐를 왜 사용할까?
메세지 큐를 사용하면 발신자와 수신자가 서로를 직접 알 필요가 없으므로 느슨한 결합(loose coupling)을 만들 수 있다. 발신자, 수신자 서로가 서로에게 의존하지 않으므로, 각자는 독립적으로 확장될(scale out) 수 있다. N(Producer):1(Message queue):M(Consumer)의 형태로 발신자, 수신자 사이에서 메세지 큐가 베세지를 중계한다.
또한 수신자 서비스가 장애 상황이어서 메세지를 받을 수 없어도 발행된 메세지는 메세지 큐에 남아있으므로 결국 발신자가 발행한 메세지는 소비자 서비스에게 전달된다는 보장성(guarantees)를 갖는다. 이러한 여러 특성으로 메세지 큐는 여러 마이크로 서비스가 서로 협력하는 MSA 환경에서 좋다.
메세지 큐를 사용하면 비동기 통신(asynchronous)을 구현할 수 있다. A 서비스와 B 서비스가 서로 통신을 한다고 가정해보자. A가 B를 HTTP 통신을 통해 request한다면, A는 B로부터 동기적으로 response를 기다릴 것이다. 반면 A가 메세지를 메세지 큐에 발행하고, B가 그 메세지를 가져가는 방식이라면 비동기적으로 통신이 이루어질 수 있다. 이런 특성으로 메세지 큐는 이미지 프로세싱같이 무거운 작업을 요청하거나, 혹은 IoT 환경같은 이벤트 드리븐 아키텍처에서 이벤트가 발생했음을 알리기 위한 용도로 적합하다.
Point to Point와 Pub/Sub
메세지 큐는 Point to Point와 Pub/Sub 모델로 구분할 수 있다. P2P 모델은 한 대의 발신자가 한 대의 수신자에게 메세지를 보내는 방식이다. 즉 메세지 전송 대상이 한 대로 고정되어 있다.
반면 Pub/Sub 모델은 발신자가 토픽이라고 불리는 공간에 메세지를 전송하면, 그 토픽을 구독하고 있는 수신자 모두 모두 메세지를 수신하는 방식이다. 즉 전송 대상이 다수이다.
MOM이라고 하면 흔히 RabbitMQ, ActiveMQ, Kafka를 이야기한다. Kafka는 Pub/Sub 모델만을 지원한다.
Kafka
카프카는 RabbitMQ, ActiveMQ와 비교했을 때, 높은 확장성과 내결함성, 대용량 데이터 처리, 실시간 데이터 처리에 특화되어 있는 오픈소스 메세징 시스템이다. 카프카는 링크드인에서 최초로 개발되었으며, 현재는 아파치 재단에서 오픈소스로 관리하고 있다.
Before Kafka
카프카가 등장하기 이전의 링크드인의 아키텍처이다. 각 서비스 혹은 데이터 저장소가 End-To-End로 연결되어 복잡한 구조를 가지고 있다. 이런 아키텍처는 시스템을 확장하기 어렵다.
After Kafka
Kafka 등장 이후 아키텍처이다. 모든 이벤트와 데이터의 흐름이 카프카를 중심으로 모이고 퍼진다. 이벤트가 발생하면 발생 주체가 카프카로 해당 이벤트를 전달한다. 그리고 해당 이벤트(데이터)가 필요한 곳에서 가져다 사용한다.
예를 들어 회원 서비스에서 새로운 회원이 가입되었다는 메시지를 카프카로 전달한다. 이 메시지를 멤버십 서비스가 컨슘하여 새로운 회원에게 가입 축하 멤버십 포인트를 생성해 부여한다. 동시에 하둡은 이 메시지를 컨슘하여 해당 유저에 대한 데이터를 빅데이터에 저장해 분석한다. 또한 동시에 로그 스태시(로그 수집 시스템)는 이 메시지를 컨슘하여 개발자가 디버깅할 때 사용할 수 있도록 로그를 생성한다.
카프카가 없었다면 회원 서비스가 멤버십 서비스, 하둡, 로그 스태시로 각각 다른 데이터 파이프라인을 통해 데이터를 전송해야 했을 것이다. 이에 반해 카프카를 사용하여 데이터 흐름을 중앙화한다면, 복잡도가 드라마틱하게 낮아지는 것을 확인할 수 있다.
카프카 아키텍처
kafka cluster: 하나 이상의 카프카 브로커들의 집합이다. 특징에서 알아보았듯 카프카는 확장성과 내결함성을 위해 브로커들을 클러스터로 구성한다.
broker: 브로커는 개별 카프카 서버로 보면 된다. 브로커는 프로듀서로부터 메시지를 전달받아, 토픽에 저장하고, 컨슈머에 전달하는 역할을 한다. 브로커는 여러개의 토픽을 가질 수 있다.
topic: 토픽을 데이터가 저장되는 단위라고 할 수 있다. 토픽은 이름으로 식별된다. 토픽에 한번 추가된 데이터는 수정될 수 없다.
partition: 카프카의 확장성을 위해 토픽은 1개 이상의 파티션으로 나뉠 수 있다. 레코드에 키가 없다면 라운드 로빈으로 파티션에 나뉘어 저장되고, 같은 키를 가진 레코드는 같은 파티션에 저장된다.
offset(key): 파티션에 저장된 레코드가 가지는 정수 ID. 오프셋은 0부터 시작하며, 파티션에 레코드가 저장될 때 마다 시퀀셜하게 증가한다. 특정 파티션의 각 레코드는 고유한 오프셋을 갖지만, 서로 다른 파티션 간에는 고유하지 않다. 파티션에서 데이터를 읽을 때 작은 것부터 큰 순서대로 읽는다.
record(value): 파티션에 저장되는 데이터이다. Key, Value, Timestamp, Compression Type, Optional Headers, Partition and Offset id 로 구성된다.
producer: 카프카에 요청하여 토픽에 레코드를 추가하는 클라이언트이다. 카프카의 구성 요소가 아니며, 카프카 외부에서 카프카에 요청하는 애플리케이션이다.
consumer: 하나 이상의 파티션과 토픽으로부터 레코드를 읽어오는 클라이언트이다. 기본적으로 사용 가능한 가장 낮은 오프셋부터 높은 오프셋까지 순서대로 레코드를 읽어온다. 하나의 토픽의 여러 파티션으로부터 레코드를 읽어올 때는 순서가 보장되지 않는다. 파티션 0, 1, 2 로부터 레코드를 읽어올 때 파티션 0의 레코드만 바라봤을 때는 순서가 보장되지만, 읽어온 전체 레코드를 바라볼대는 파티션 0 ~ 2의 레코드가 순서와 상관없이 섞여있을 수 있다.
컨슈머 그룹 (consumer group): 동일한 컨슈머 인스턴스를 여러개 생성하여 컨슈머 그룹을 구성할 수 있다. 컨슈머 그룹을 구성하는 여러 컨슈머는 동일한 토픽의 각자 다른 파티션을 도맡아 메시지를 컨슘할 수 있다. 예를 들어 토픽 A에 파티션이 0, 1, 2 가 생성되어 있고, 컨슈머 그룹 A에 컨슈머 a, b, c가 있다고 가정하자. 이 경우 컨슈머 a는 파티션 0을, 컨슈머 b는 파티션 1을, 컨슈머 c는 파티션 2를 컨슘한다.
출처:
https://hudi.blog/what-is-kafka/
https://tecoble.techcourse.co.kr/post/2021-09-19-message-queue/
