실전 카프카 개발부터 운영까지 2

 

카프카 주요 구성요소

1. 카프카(또는 카프카 클러스터)

2. 브로커 

    카프카가 설치된 서버 또는 노드

3. 프로듀서

    카프카로 메세지를 보내는 역할을 하는 클라이언트

4. 컨슈머

    카프카에서 메세지를 꺼내가는 역할을 하는 클라이언트

    컨슈머는 특정 컨슈머 그룹에 속하며, 같은 그룹에 속한 컨슈머들은 토픽의 파티션을 분산 처리함

    기본적으로 컨슈머는 스티키 파티셔닝(Sticky Partitioning)을 사용.
    이는 특정 컨슈머가 특정 파티션에 붙어서 계속해서 데이터를 처리하는 방식으로, 데이터 지역성을 높여
    캐시 히트율을 증가시키고 전반적인 처리 성능을 향상시킴.

5. 토픽

    메시지를 저장하는 장소

6. 파티션

    병렬 처리 및 고성능을 위해 하나의 토픽을 여러개로 나눔

    파티션은 토픽을 물리적으로 나눈 단위로, 각 파티션은 독립적으로 메시지를 저장하고 관리

    각 파티션은 메시지를 순서대로 저장하며, 파티션 내의 메시지는 고유한 오프셋으로 식별

    파티션을 통해 데이터를 병렬로 처리할 수 있으며, 클러스터 내의 여러 브로커에 분산시켜 저장할 수 있다.

7. 세그먼트

    프로듀서가 전송한 실제 메세지가 브로커의 로컬 디스크에 저장되는 파일

 

 

replication을 하면 토픽이 replication 되는게 아니라 토픽의 파티션이 replication 된다.

레플리케이션 팩터 수가 커지면 안정성은 높아지지만 리소스를 많이 사용하게 되므로

복제에 대한 오버헤드를 줄이고 최대한 브로커를 효율적으로 사용해야한다.

 

기준을 세우자면

테스트나 개발환경에서는 팩터 1

운영환경에서 약간의 유실이 허용되는 경우  팩터2

유실을 허용하지 않는 운영환경  팩터3

 

경험에 비춰보자면 팩터 3에서도 충분히 메세지 안정성을 보장하며, 디스크 공간을 효율적으로 사용할 수 있었다.

그래서 그 이상으로 올리는 것은 고려해봐야할 사항

 

 

파티션

하나의 토픽을 여러개로 나눠 병렬 처리가 가능하게 함

이렇게 하나를 여러개로 나누면 분산처리도 가능하며,  이렇게 나눈 파티션 수만큼 컨슈머를 연결할 수 있다.

파티션은 초기 생성 후에 얼마든지 늘릴 수 있지만, 늘린 파티션을 다시 줄일수는없다.

 

줄이는게 가능 할 경우 기존 파티션에 저장된 데이터를 새 파티션으로 이동해야 하고,  이때 데이터 순서와 파티션 키 무결성을 보장할 수 없기 때문에 제약을 걸어둔 것

 

줄이고 싶다면 기존 토픽 데이터를 새 토픽으로 이동하면서 새 토픽에서 파티션 수를 기존보다 적게 만들면 된다.