Kafka

Kafka Introduction

1. LinkedIn의 Kafka 개발 배경

카프카 개발 전 링크드인의 데이터 처리 시스템

기존 링크드인의 데이터 처리 시스템은 각 파이프라인이 파편화되고 시스템 복잡도가 높아 새로운 시스템을 확장하기 어려운 상황이였음
기존 메시징 큐 시스템인 ActiveMQ를 사용했지만, 링크드인의 수많은 트래픽과 데이터를 처리하기에는 한계가 있었음
이로 인해 새로운 시스템의 개발 필요성이 높아졌고, 링크드인의 몇몇 개발자가 다음과 같은 목표를 가지고 새로운 시스템을 개발
- 프로듀서와 컨슈머의 분리
- 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
- 높은 처리량을 위한 메시지 최적화
- 데이터가 증가함에 따라 스케일아웃이 가능한 시스템

카프카를 개발 후 링크드인의 데이터 처리 시스템

카프카를 적용함으로써 모든 이벤트/데이터의 흐름을 중앙에서 관리할 수 있게 되었으며,
서비스 아키텍처가 기존에 비해 관리하기 심플해졌음

2. 메시징 시스템

Publisher와 Subscriber로 이루어진 비동기 메시징 전송 방식
메시지라고 불리는 데이터 단위를 보내는 측(Publisher/Producer)에서 메시지 시스템에 메시지를 저장하면 가져가는 측(Subscriber/Consumer)는 데이터를 수신
발신자의 메시지에는 수신자가 정해져 있지 않은 상태로 발행(Publish)
구독(Subscribe)을 신청한 수신자만이 정해진 메시지를 받음
수신자는 발신자 정보가 없어도 메시지 수신이 가능

일반적인 형태의 네트워크 통신의 문제점

N:N연결이므로 클라이언트 갑자기 많아질 경우 느려질 수 있고 이를 대응하기 위한 확장성이 떨어짐
특정 클라이언트가 다운되서 메시지를 받지 못하게 될 경우 메시지가 유실될 수 있음

Pub/Sub 모델

작동방식
- 프로듀서가 메시지를 컨슈머에게 직접 전달하는 것이 아니라, 중간의 메시징 시스템에 전달 (수신처 ID포함)
- 메시징 시스템의 교환기가 메시지의 수신처 ID값을 통해 컨슈머들의 큐에 메시지를 전달 (push)
- 컨슈머는 큐를 모니터링하다가 큐에 메시지가 있을 경우 값을 회수
장점
- 특정 개체가 수신불능 상태가 되더라도 메시징 시스템만 살아있다면 메시지가 유실되지 않음
- 메시징 시스템으로 연결되어있기 때문에 확장성이 용이
단점
- 직접 통신하지 않기 때문에 메시지가 잘 전달되었는지 파악하기 힘듬
- 중간에 메시징 시스템을 거치기 때문에 메시지 전달 속도가 빠르지 않음

3. 그래서 카프카(Kafka)는 무어냐 ?

카프카 아키텍처

프로듀서(Producer)
- 메시지를 생산하여 브로커의 토픽으로 전달하는 역할
브로커(Broker)
- 카프카 애플리케이션이 설치되어 있는 서버 또는 노드를 지칭
컨슈머(Consumer)
- 브로커의 토픽으로부터 저장된 메시지를 전달받는 역할
주키퍼(Zookeeper)
- 분산 애플리케이션 관리를 위한 코디네이션 시스템
- 분산된 노드의 정보를 중앙에 집중하고 구성관리, 그룹 네이밍, 동기화 등의 서비스 수행

작동방식

프로듀서는 새 메시지를 카프카에 전달
전달된 메시지는 브로커의 토픽이라는 메시지 구분자에 저장
컨슈머는 구독한 토픽에 접근하여 메시지를 가져옴 (pull 방식)

기존 메시징 시스템과 다른 점

디스크에 메시지 저장
- 기존 메시징 시스템과 가장 큰 특징
- 기존 메시징 시스템은 컨슈머가 메시지를 소비하면 큐에서 바로 메시지를 삭제
- 하지만, 카프카는 컨슈머가 메시지를 소비하더라도 디스크에 메시지를 일정기간 보관하기 때문에 메시지의 손실이 없음 (영속성)
멀티 프로듀서, 멀티 컨슈머
- 카프카의 경우 디스크에 메시지를 저장하는 특징으로 인해,
- 프로듀서와 컨슈머 모두 하나 이상의 메시지를 주고 받을 수 있음
분산형 스트리밍 플랫폼
- 단일 시스템 대비 성능이 우수하며, 시스템 확장이 용이함
- 일부 노드가 죽더라도 다른 노드가 해당 일을 지속 (고가용성)
페이지 캐시
- 카프카는 잔여 메모리를 이용해 디스크 Read/Write 를 하지 않고 페이지 캐시를 통한 Read/Write으로 인해 처리속도가 매우 빠름
배치 전송 처리
- 서버와 클라이언트 사이에서 빈번하게 발생하는 메시지 통신을 하나씩 처리할 경우 그만큼 네트워크 왕복의 오버헤드가 발생
- 이로인해, 메시지를 작은 단위로 묶어 배치 처리를 함으로써 속도 향상에 큰 도움을 줌

4. 카프카 데이터 모델

카프카는 기본적으로 토픽과 파티션이라는 데이터 모델이 존재

토픽(Topic)

메시지를 논리적으로 묶은 개념 (데이터베이스의 테이블 / 파일시스템의 폴더와 유사한 개념)
프로듀서가 메시지를 보낼경우 토픽에 메시지가 저장됨.

파티션(Partition)

토픽을 구성하는 데이터 저장소이며 메시지가 저장되는 위치

여러개의 프로듀서에서 한개의 파티션으로 메시지를 보낼 경우 병목이 생기고, 메시지의 순서를 보장할 수 없게 됨
그렇기에, 파티션을 여러개로 늘리고 그 수만큼 프로듀서도 늘려 하나의 파티션마다 하나의 프로듀서 메시지를 받으면 훨씬 빠름
그렇다면 파티션은 많을 수록 좋은가?
- 파일 핸들러의 낭비가 존재
  - 각 파티션은 브로커의 디렉토리와 매핑되고 저장되는 데이터마다 2개의 파일(인덱스, 실제 파일)이 있기 때문에 너무 많은 파일 핸들이 생길 경우 리소스 낭비가 생김
- 장애 복구 시간이 증가할 수 있음
  - 카프카는 리플리케이션(Replication)을 지원하고, 이를 통해 지속적으로 리더 파티션을 팔로워 파티션으로 리플리케이션을 하게됨
  - 하지만 파티션 수가 너무 많을 경우 리플리케이션 수행이 느려져 장애복구시간이 증가할 수 있음
- 추후 파티션 수를 줄이는 것이 불가능
  - 카프카에서 파티션 수를 늘리는 것은 아무때나 가능하지만 파티션 수를 줄이는 방법은 제공하지 않음. 만약 줄이고 싶다면 토픽 자체를 삭제하는 것 말고는 방법이 없음

오프셋과 메시지순서

오프셋(offset)
- 파티션마다 메시지가 저장되는 위치
- 파티션 내에서 순차적으로 유니크하게 증가하는 숫자 형태로서 동일 파티션 내 메시지의 순서를 보장해줌
- 컨슈머는 메시지를 가져올 때마다 오프셋 정보를 커밋(commit)함으로써 기존에 어디 위치까지 가져왔는지 알 수 있게 됨

파티션과 메시지순서

파티션을 여러개 지정할 경우
- 프로슈머가 메시지를 보낼 때, 파티션이 여러개인 경우 메시지는 각각의 파티션으로 순차적으로 배분 (Round-robin 방식)
- 메시지의 순서는 오로지 동일 파티션 내 오프셋을 기준으로만 보장되기 때문에,
- 여러개의 파티션을 사용할 경우 동일 파티션 내에서는 순서가 보장되지만, 파티션과 파티션 사이에서는 순서를 보장하지 못하기 때문에 전체 메시지를 출력할 경우 순서가 섞일 수 있음
- 전체 메시지의 순서를 보장하고 싶은 경우 partition을 1개로만 설정해야 함
  - 하지만 파티션이 하나이므로 분산 처리가 불가능

리플리케이션

고가용성 및 데이터 유실을 막기 위해 replication을 수행
원본 파티션의 경우 '리더'가 되고, 복제 파티션의 경우 '팔로워'가 됨
만약 리더 파티션이 있는 브로커가 다운될 경우, 복제 파티션을 가진 브로커의 팔로워 파티션이 새로운 리더가 되어 정상적으로 프로듀서의 요청을 처리

ISR(In Sync Replica)

리더와 팔로워로 이루어진 리플리케이션 그룹
리플리케이션 그룹 내 동기화 및 신뢰성 유지
팔로워는 Read/Write 권한이 없고 오로지 리더로부터 데이터를 복제하기 때문에 특정 팔로워가 다운되서 리플리케이션을 못할 경우 동기화 문제 발생
이러한 문제로 인해, 문제가 감지된 팔로워(설정된 일정주기(replica.lag.time.max.ms)만큼 요청이 오지 않는 팔로워)는 ISR 그룹에서 추방됨

Consumer 그룹

컨슈머가 메시지를 소비하는 시간보다 프로듀서가 메시지를 전달하는 속도가 더 빨라서 메시지가 점점 쌓일 경우를 대비하여
동일 토픽에 대해 여러 컨슈머가 메시지를 가져갈 수 있도록 컨슈머 그룹이라는 기능을 제공
아래와 같이 하나의 consumer가 프로듀서의 메시지 전송 속도를 따라가지 못할 경우
아래와 같이 컨슈머를 확장하여 하나의 파티션 당 하나의 컨슈머가 연결되도록 할 수 있음 (리밸런스, rebalance)
하나의 파티션 당 하나의 컨슈머가 1:1 연결되어야 하므로 아래와 같이 확장할 수는 없음
컨슈머 그룹은 컨슈머가 일정한 주기로 하는 하트비트(컨슈머가 poll()하거나 메시지의 오프셋을 커밋할때 보냄)를 통해 컨슈머가 메시지를 처리하고 있다는 것을 인지하며, 만약 오랫동안 하트비트가 없다면 해당 컨슈머의 세션이 타임아웃되고 리밸런스를 수행
카프카의 메시지 큐 시스템은 큐에서 메시지를 가져가도 사라지지 않기 때문에 여러 컨슈머 그룹이 동일 토픽에 붙을 수 있음

5. 카프카는 어떤 경우 필요한가?

Kafka vs RabbitMQ vs Google Cloud Pub/Sub

모두 비동기 통신을 제공하며, 프로듀서와 컨슈머가 분리되어 있음

RabbitMQ

AMQP(Advanced Message Queuing Protocol, 클라이언트와 미들웨어간 메시지 교환 개방형 표준 프로토콜)을 위해 개발 되어 다른 AMQP 프로토콜 기반 MQ(ex. RabbitMQ, ActiveMQ, ZeroMQ)등과 데이터 교환이 수월
필요에 따라 동기/비동기 구현 가능
유연한 라우팅이 가능(exchanger가 메시지를 적절히 각각의 queue에 분배)하여 관리가 쉽고, 관리UI가 직관적이고 편리
broker 중심적이며, producer와 consumer간 메시지 전달 보장에 초점을 맞추어 신뢰성이 높음
20k+/sec 처리 보장

Kafka

고성능, 고가용성, 확장성
분산 처리 시스템으로서, 확장성(scalability) 및 고가용성(high available)이 높음
따라서, 노드 장애에 대한 대응성이 높음
배치 처리가 가능해 네트워크 왕복 오버헤드를 줄일 수 있음
디스크 파일 시스템에 데이터를 저장함으로써 영속성(persistency)을 보장 (즉, 오류 시 복구가 가능)
Producer 중심적이며, 메시지 전달 보장이 optional
- 메시지 전달 보장을 할 경우 처리속도가 느려져(리더와 팔로워 모두에게 ack(응답 승인)을 받야아 하므로) 카프카의 처리속도 측면의 장점이 상쇄
라우팅 기능이 없음 (producer가 직접 적절한 topic과 partion으로 보내줘야 함)
100k+/sec 처리 보장

처리속도 비교

Producer의 메시지 배치 처리 성능 비교
Consumer 메시지 수신 처리 성능 비교

Kafka

높은 처리량 및 고성능/분산/스케일 아웃이 중요한 경우
가용성(장애 대응)이 높아야 하는 경우
메시지 전달 보장이 필수적이지 않은 경우
메시지 처리 순서가 보장되어야 하는 경우
스트리밍 데이터 처리가 필요한 경우
메시지 영속성이 필요한 경우

RabbitMQ

빠르고 쉽게 메시지 큐 시스템을 구축하고자 하는 경우 (라우팅 기능이 유연함)
메시지 전달 보장이 필수적인 경우
메시치 처리 순서가 보장되지 않아도 되는 경우
메시지 영속성 X

Google Pub/Sub

Kafka와 유사한 아키텍처 (topic 개념)
클라우드 서비스로서 별도의 설치나 운영이 필요없음
메시지 처리 순서 보장이 안됨(분산형 아키텍처)
메시지 영속성 X (저장기간 최대 7일)

References

PreviousMongoDB NextSpring Webflux + Reactive Kafka

Last updated 3 years ago