kafka의 기본 개념 정리

카프카의 기본 개념

카프카 브로커란?

• 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자, 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 어플리케이션
• 보통 하나의 서버에 한 개의 카프카 브로커 프로세스가 실행되며 데이터를 안전하게 보관하기 위해 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영

데이터 저장, 전송

• 카프카 브로커는 프로듀서가 요청한 토픽의 파티션에 데이터를 저장하고 컨슈머가 요청하면 파티션에 저장된 데이터를 전달하는데 데이터는 파일 시스템에 저장된다.

파일 시스템으로 저장하다보면 다루기 편하긴 하지만 지속적으로 입출력할 경우 메모리에 올려 사용하는 것보다 속도가 현저히 느린데 카프카는 여기서 페이지 캐시를 사용하여 디스크 입출력 속도를 높여 이 문제를 해결했다.

** 페이지 캐시란 os에서 파일 입출력의 성능 향상을 위해 만들어 놓은 메모리 영역을 뜻함.

데이터 복제, 싱크

• 데이터의 복제는 주로 클러스터로 묶인 브로커 중 일부에 장애가 발생하더라도 데이터를 유실하지 않고 안전하게 사용할 수 있도록 하기 위해 사용된다.
• 데이터의 복제는 주로 파티션 단위로 이루어지고 topic을 처음 생성할 때 파티션의 복제 개수(replication factor)도 같이 설정되며 default로는 브로커에 설정된 옵션값을 따라간다.
• 복제 개수의 최솟값은 1(복제를 안함)이고 최대로 브로커의 개수만큼 설정할 수 있다.
• 팔로워 파티션들은 리더 파티션의 오프셋을 확인하여 현재 자신이 가지고 있는 오프셋과 차이가 나는 경우 리더 파티션으로부터 데이터를 가져와서 자신의 파티션에 저장 ⇒ 복제과정
• 보통 topic마다 복제 개수를 다르게 설정하고 데이터의 처리 속도가 중요하면 적게 설정하기도 한다.

컨트롤러

• 컨트롤러는 다른 브로커들의 상태를 체크하고 브로커가 클러스터에서 빠지는 경우 해당 브로커에 존재하는 리더 파티션을 재분배하는 역할을 하며 클러스터의 다수 브로커 중 한대가 컨트롤러의 역할을 한다.
• 컨트롤러 브로커는 브로커의 상태가 비정상이라면 빠르게 클러스터에서 빼내기도 한다.

데이터의 삭제

• 데이터의 삭제는 오직 브로커만이 할 수 있으며 삭제는 파일 단위로 이루어지며 이 단위를 로그 세그먼트라고 부른다. 세그먼트에는 다수의 데이터가 들어있기 때문에 특정 데이터만 삭제할 수는 없다.
• 세그먼트는 데이터가 쌓이는 동안에는 파일 시스템으로 열려 있으며 카프카 브로커에 log.segment.bytes or log.segment.ms옵션에 값이 설정되면 세그먼트 파일이 닫힌다.(주로 기본값이 1GB이나 설정가능)
• 닫힌 세그먼트 파일은 log.retention.bytes or log.retention.ms옵션에 설정값이 넘으면 삭제된다. 닫힌 세그먼트 파일 체크 간격은 log.retention.check.interval.ms에 따른다.

컨슈머 오프셋 저장

• 컨슈머 그룹은 파티션의 어느 레코드까지 가져갔는지 확인하기 위해 오프셋을 커밋하는데 커밋한 오프셋은 __consumer_offsets 토픽에 저장된다. 여기에 저장된 오프셋을 토대로 컨슈머 그룹은 다음 레코드를 가져가서 처리한다

코디네이터

• 코디네이터는 컨슈머 그룹의 상태를 체크하고 파티션을 컨슈머와 매칭되도록 분해하는 역할을 하며 클러스터 내의 하나의 브로커가 이 역할을 한다. 컨슈머가 컨슈머 그룹에서 빠지면 그로 인해 매칭되지 않은 파티션을 다른 컨슈머로 할당하여 데이터를 끊임없이 처리하도록 도와준다. 이러한 과정을 rebalance라고 한다.

(이미지 출처 :  https://1.bp.blogspot.com/-1-rnz3NXpbQ/YOOmr5OJ57I/AAAAAAABBpM/KbmAkGDUvOs02WAygSFAeY_CGqMJ_2tMACLcBGAsYHQ/w640-h348/1.JPG )

주키퍼란?

• 주키퍼는 카프카의 메타데이터를 관리하는데 사용되며 카프카 클러스터로 묶인 브로커들은 동일한 경로의 주키퍼 경로로 선언해야 같은 카프카 브로커 묶음이 된다.
• 주키퍼의 root znode아래엔 여러 개의 znode가 있다. (znode란 주키퍼에서 사용되는 데이터 저장 단위이며 파일 시스템처럼 계층 구조를 가진다.) 보통 2개 이상의 카프카 클러스터를 구축할 때는 root znode보다 한 단계 아래인 znode를 카프카 브로커 옵션으로 지정하도록 한다.

이미지 출처:  https://moonsupport.oopy.io/post/22

토픽과 파티션

토픽은 카프카에서 데이터를 구분하기 위한 단위로서 1개 이상의 파티션으로 구성되어 있다. 데이터는 파티션의 레코드 단위로 데이터가 저장된다. 파티션은 카프카의 병렬처리의 핵심으로써 컨슈머 그룹이 레코드를 병렬로 처리할 수 있도록 매칭된다. 파티션은 자료구조의 큐와 동일하며 FIFO 방식을 따른다. 하지만 카프카에서는 데이터가 삭제되지 않으며 그래서 같은 데이터를 여러번 가져갈 수 있다.

토픽의 네임은 .과_ , - , 숫자, 대소문자로 조합이 가능하며 보통 팀명에 맞춰서 토픽의 네임을 추후에 알아볼 수 있게 설정한다.(카프카에서 토픽 리네임을 제공하지 않기 때문)

레코드

레코는드 타임스탬프, 메시지 키 , 메시지 값, 오프셋, 헤더로 구성되어 있다.

타임스탬프 - 프로듀서에서 해당 레코드가 생성된 시점의 유닉스 타임이 설정되며 타임스탬프를 통해 언제 생성되었는지 알 수 있다 .(하지만 토픽 설정에 따라 브로커에 적재된 시간으로 설정될 수도 있음!!)

메시지 키 - 메시지 값을 순서대로 처리하거나 값의 종류를 나타내기 위해 사용되며 주로 메시지 키의 해시값을 토대로 파티션에 저장하게 된다. 즉, 동일한 키라면 같은 파티션에 들어가게 된다.(다만 파티션 개수가 변경되면 매칭이 달라질 수 있다.) 메시지 키를 null로도 설정할 수 있으며 해당 레코드는 기본 설정 파티셔너에 따라 파티션에 분배되어 적재된다.

메시지 값 - 실제로 데이터가 들어가는 부분으로서 메시지 키와 값은 직렬화되어 브로커에 전송되기 때문에 컨슈머에서도 동일한 형태로 역직렬화를 해서 처리해야한다.(string직렬화이면 string으로 역직렬화 해야함을 의미)

오프셋 - 0이상의 숫자로 이루어져 있으며 레코드가 브로커에 저장될 때 이전에 전송된 레코드의 오프셋+1 값으로 생성된다.

헤더 - 레코드의 추가적인 정보를 담는 메타데이터 저장소 용도로 사용된다.