Kafka 요약 정리

Topic

- 메시지는 Topic에 분류된다.

Partition

- Topic은 partition으로 구분된다.

- 파티션에 쌓이는 데이터는 로그라고 부르고 각 파티션에 나눠서 저장된다.

Topic이 파티션으로 나뉘는 이유

- Topic 내부에 파티션이 없을경우 메시지를 보내는 대상이 많아질경우 append 속도가 버거워진다. 

- 병렬로 분산저장하고자 Partition 개념 생성

- 한번 생성한 파티션은 운영중에 줄일 수 없기 때문에 설계시 조심

Consumer

- Topic에 있는 데이터를 읽는 대상

Consumer Group

- Consumer를 여러개 묶어놓은 것.

Consumer Group이 필요한 이유.

- 소비를 진행 하던 Consumer가 죽어버릴 경우를 Rebalance 상황이라고 하는데 이럴경우 파티션 재 조정을 통해서 다른 컨슈머가 이어서 진행한다.

- 파티션이 많아서 데이터를 처리해야하는 경우 Consumer Group내에서 파티션을 나눠서 읽을 수 있기에 속도가 좋다.

- 무조건 늘리는게 아니라 적절하게 속도 조절 필요.(읽는 속도가 더 빠르다면 굳이 늘리지말고 Consumer 하나당 담당하는 Partition을 늘려라.)

- 그리고 핵심적인 이유가 만약 그룹이 없이 Consumer 여러개가 같은 topic에서 데이터를 읽을 때 offset이 공유가 되기 때문에 마지막 Consumer가 읽어간 부분부터 읽게되기 때문에 데이터가 신뢰도가 부족해진다. 하지만 Group을 사용하게 되면 Group마다 offset을 다르게 쓰기 때문에 그럴 염려가 없다.

Broker

- 카프카 서버

Zookeeper

- kafka를 실행시키기고 관리하는 주최

Replication

- kafka 서버를 여러개 띄울 경우 하나만 leader고 나머지는 follower가 됨.

- 리더가 읽고 쓰고를 주관하고 나머지는 대기 (리더가 죽으면 나머지들 중 하나가 리더가 됨)

파티션이 구분되면 메시지 순서는 보장될까?

- 파티션이 생기고 Consumer Group에서 Topic에 데이터를 읽으면 순서가 보장되지 않는다. Round robin 처럼 파티션을 돌아다니면서 데이터를 읽는 구조로 기본적으로 되어있지만 한쪽 파티션이 느려지거나 문제가 생기면 정상적인 파티션을 먼저 읽게된다. 그래서 중요한건 같은 파티션 내에서는 순서가 보장되지만 같은 토픽내에 다른 파티션들끼리는 순서가 보장되지 않는다.

공부는 했지만 정리가 되지 않았던걸 정리해봤다. 이제는 이해가 잘되는 것 같다.