Kafka 좀 더 알아보기

카프카가 자꾸 말썽을 부리고 있다.

왜일까...

공식 홈페이지의 기본 개념을 살짝 정리해보자.

https://kafka.apache.org/090/documentation.html#gettingStarted

잘못된 정보 수정은 환영입니다.

​

 

카프카는 topic을 통해 메시지 피드를 유지 관리한다.

topic producer를 통해 kafka cluster에 메시지를 적재한다.

consumer를 통해 kafka cluster에서 topic을 감지하고 메시지를 가져온다.

그림의 kafka cluster는 1개지만 그 이상의 서버로 구성될 수 있다.

​

 

cluster에 1개의 토픽에 관한 파티션을 살펴보면 위의 그림과 같다.

파티션을 1개로 놓는것도 가능하지만,
나눠 놓는것으로 메시지의 read와 write의 부하 분산을 줄여 성능 개선을 할 수 있다.
​

각 파티션의 메시지는 지속적으로 추가되고, 정렬 또는 변경이 불가능하다.

파티션 별로 메시지에 오프셋이라는 순차 ID가 부여된다.

​

메시지 유지 기간

cluster는 구성 가능 기간 동안 소비 여부에 관계없이 모든 메시지를 유지한다.

(보존 기간이 2일로 설정된 경우 메시지가 게시된 후 2일 동안 사용할 수 있고, 그 후에는 공간 확보를 위해 삭제한다.)

​

offset

각각의 consumer는 오프셋 번호를 가지고 있다.

오프셋은 소비자 마음대로 왔다 갔다 할 수 있으며,

그로 인해 처리했던 메시지를 다시 처리할 수 있다.

consumer의 오프셋 변화는 cluster 또는 producer에 영향을 미치지 않는다.

​

파티션

파티션은 1개의 topic에 대해 많은 양의 파티션으로 구성할 수 있고, 이것은 병렬 처리가 가능하다.

주의할 점은

kafka를 사용하면서 파티션을 늘릴 수는 있지만 줄일 수는 없다.

파티션을 줄이고 싶다면 토픽을 삭제하고 다시 만들어야 한다.

​

복사 전략

replication-factor 옵션에 따라 여러 cluster 서버에 데이터를 복제하여 안전하게 관리할 수 있다.

2로 설정한다면 원본과 복사본의 갯수를 합쳐서 2개의 데이터가 존재한다.

전략은 leader - follwers 방식으로 아래 사진을 참고할 수 있다.

 

leader-follwers 방식

클러스터하나의 클러스터 안에는 여러개의 브로커가 존재한다.
각 파티션에서 리더를 선출하여 팔로워들은 리더의 데이터를 복사한다.
리더가 죽게 되면 팔로워 중 하나를 리더로 선출한다.

앞에서 파티션을 늘려 부하 분산을 할 수 있다고 언급했는데,

무분별한 파티션 증설은 안 좋은 영향을 줄 수 있다.

이유는 위의 리더 선출과 복사 전략 때문인데,만약 Brooker101 이 다운된다면 Broker 102의 partition 0 은 일시적으로 사용할 수 없게 된다.
(새로운 리더 선출로부터 영향)

또한 다운된 브로커가 컨트롤러 역할을 수행하고 있었다면, 새로운 컨트롤러 선출을 위해서 모든 파티션의 데이터를 읽어야하기 때문에 더 큰 지연을 불러올 수 있다.

​

메시지 적제

producer는 topic 내의 어떤 파티션에 메시지를 할당할지 선택해야 한다.

방식은 메시지의 key 기반으로 분할되거나,(따로 공부하자)

key 값이 없다면 기본적으로 라운드 로빈 방식으로 분할된다.

메시지를 컨슘 할 때, 파티션 내부에서는 순서를 보장한다.

하지만 토픽 단위로 봤을 때 라운드로빈 기반으로 메시지를 저장했다면,

각각의 파티션끼리는 순서를 보장하지 않으니 주의하자.

​

메시지 소비

kafka는 소비자 그룹을 제공한다.

 

consumer에 group-id를 지정한다.

(C1과 C2는 A라는 group-id를 지정하여 하나의 그룹으로 본다.)

동일한 group-id를 가진 consumer 중 하나라도 메시지를 소비하면,

같은 그룹 내의 consumer들은 메시지를 소비하지 않고 넘어간다.

(C1과 C2는 1개의 topic에 대한 파티션처럼 동작한다)