카프카 기본 개념과 구조

카프카 기초 다지기

카프카를 구성하는 주요 요소

요소	설명
주키퍼	아파치 프로젝트 어플리케이션 이름. 카프카의 메타데이터 관리 및 브로커의 정상상태 점검을 담당
카프카 / 카프카 클러스터	아파치 프로젝트 어플리케이션 이름. 여러대의 브로커를 구성한 클러스터를 의미
브로커	카프카 어플리케이션이 설치된 서버 또는 노드
프로듀서	카프카로 메세지를 보내는 역할을 하는 클라이언트
컨슈머	카프카에서 메세지를 꺼내가는(수신하는) 역할을 하는 클라이언트
토픽	카프카 메세지 피드들을 토픽으로 구분, 각 토픽의 이름은 카프카 내에서 유니크
파티션	병렬 처리 및 고성능을 얻기 위해 하나의 토픽을 여러 개로 나눈 것
세그먼트	프로듀서가 전송한 실제 메세지가 브로커의 로컬 디스크에 저장되는 파일
메세지 / 레코드	프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각

---

리플리케이션

리플리케이션이란?

메세지들을 여러 개로 복제해서 카프카 클러스터내 브로커들에게 분산시키는 동작을 의미

• 리플리케이션으로 인해 하나의 브로커가 종료되더라도 카프카는 안정성을 유지할 수 있다.
• 토픽생성시 --replication-factor 옵션은 카프카 내 리플리케이션 유지 개수를 의미한다.
• 토픽이 리플리케이션 되는 것이 아니라, 파티션이 리플리케이션 된다.
• replication-facotr 의 수가 많아지면 안정성은 높아지지만, 리소스를 많이 사용하게 된다.

  일반적으로 replication-factor 수는
  개발환경 : 1
  운영환경 (약간의 유실 허용) : 2
  운영환경 (유실 허용하지 않음) :3

---

파티션

파티션이란?

하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬 처리가 가능하게 만든 것

• 하나를 여러개로 나누면 분산처리도 가능하다
• 파티션 번호는 0부터 가능
• 파티션 수를 정하는 기준은 다소 모호한 경우가 많다
• 구하는 공식이 있지만, 각 메세지 크기나 초당 메세지 건수 등에 따라 달라지므로 정확하게 예측 불가
• 파티션 수는 초기 생성 후 늘릴 수 있다
• 한 번 늘린 파티션 수는 절대로 줄일 수 없다
• 초기의 파티션 수를 작게 2 or 4 정도로 생성한 후, 처리량이나 컨슈머의 LAG등을 분석하여 조금씩 늘려가는 방법이 좋다
  * LAG : 프로듀서가 보낸 메세지수(카프카에 남아있는 메세지 수) - 컨슈머가 가져간 메세지 수 (지연없이 가져갔다면 0이 나오게 된다)

• 토픽1은 파티션0 이라는 1개의 파티션으로 구성
• 토픽3은 파티션0, 파티션1, 파티션2의 총 3개의 파티션으로 구성

---

세그먼트

세그먼트란?

프로듀서에 의해 브로커로 전송된 메세지는 토픽의 파티션에 저장되며, 각 메세지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장된다

• 각 파티션 마다 N개의 세그먼트 존재
• /data/kafka-logs/ 에서 전송된 메세지 확인 가능
• 저장되는 디렉토리 명 규칙 : 토픽명-파티션번호 (ex) woorung-topic-0 (woorung-topic이란 토픽의 0번째 파티션)
• xxd 명령어로 세그먼트 메세지 로그 확인 가능 (ex) xxd 0000000.log