카프카 개요

1. 카프카 디자인의 특징

• 분산시스템 : 동일한 역할을 하는 서버를 추가하여 부하를 분산할 수 있다.
• 페이지 캐시를 이용한다
  • 카프카 - 페이지캐시 - 디스크
• 작은 단위의 I/O를 묶어서 배치로 처리

2. 카프카 데이타 모델

2.1 토픽(Topic)

카프카 클러스터는 토픽에 데이타를 저장한다.

2.2 파티션(Partition)

토픽을 분할한 단위이다. 파티셔닝을 통하여 병렬처리가 가능하다. 단, 메시지의 순서는 각 파티션 내에서만 보장되며 파티션 사이의 순서는 보장하지 않는다.

파티션 수가 많으면 좋은가 ?

당연히 무조건 많다고 좋은 것은 아니다. 파티션 수가 많아짐에 따라 생기는 문제점이 있다.

• 파일 핸들러가 낭비될 수 있다.
• 장애 복구시간 증가
  • 나중에 다루겠지만, 미리 언급하자면 카프카는 고가용성을 위한 Replication을 지원한다. Replication은 토픽의 파티션 마다 적용되며, Leader 와 Follower(s)로 구분된다. 한 브로커가 죽었을 때, 이 브로커에 Leader가 있는 파티션은 일시적으로 사용할 수 없다. 그리고 Leader Election 과정에서 죽은 Leader 파티션이 많으면 오래걸리게 된다.

카프카에서는 파티션을 늘리는 것은 가능하지만 줄이는 것은 불가능하다. 따라서, 처음엔 너무 높게 설정하기 보다는 운영하며 차차 높여가는 것이 좋겠다.

참고로 카프카 팀에서는 한 브로커에 최대 2000개 이하로 운영할 것을 권장한다.

2.3 오프셋(Offset)

각 파티션마다 메시지가 저장되는 위치를 말한다. 파티션 내에서 고유하며 순차적으로 증가하는 값이다. 이 오프셋 값을 통해 파티션 내의 메시지 순서를 보장할 수 있다. 반드시 컨슈머는 오프셋 순서대로만 메시지를 가져 갈 수 있다.

3. 카프카 HA

default.replication.factor 옵션을 이용하여 토픽의 default replication 값을 지정 할 수있다. 클러스터 내의 모든 브로커들이 동일해야 한다.

이 레플리케이션은 토픽이 아니라, 토픽을 이루는 각각의 파티션을 레플리케이션 한다.

ex. topic-test 가 partition=2, replication.factor=2 라면, 총 4개의 파티션이 존재하게 되는 것이다

Replicatoin을 하면 Leader와 Follower(s) 가 생긴다.

• 모든 Read, Write 는 Leader에만 일어나며, Follower는 데이타를 복제만 하고 standby 상태로 있는 것이다.

만약 Leader가 있는 브로커가 다운될 시 Follower 중 하나가 해당 Partition의 Leader로 승격되어 서비스에 참여한다.