[Kafka] 기초1 - 기본 구성과 핵심 개념(토픽, 파티션, 리플리케이션 등)

 

❑ 카프카 구성 Overview

 

카프카 기본 구성

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

 

❑ 카프카의 핵심 개념

다음에 소개되는 개념들은 카프카의 최대 장점인 높은 처리량, 빠른 응답 속도, 안정성을 가질 수 있도록하는 특징들이다.

1) 토픽, 파티션, 오프셋, 세그먼트

• 토픽과 파티션
  • 토픽은 카프카가 데이터를 저장하는 공간이다. 토픽에 프로듀서가 데이터를 넣고, 컨슈머가 데이터를 가져가게 된다
  • 토픽 내에는 파티션이라는 여러 개의 구역으로 나눠져 있어 프로듀서로부터 받은 데이터는 각 파티션에 저장된다. 여러 개로 나눠진 파티션 덕분에 데이터를 분산하여 쌓고, 병렬 처리를 할 수 있다.
  • 토픽 생성시 --partition N 이라는 옵션으로 파티션의 수를 지정할 수 있다. 파티션은 0번부터 시작하며 파티션의 수만큼 컨슈머를 연결할 수 있다.
  • 파티션 개수는 생성 후 언제든지 늘릴 수 있지만, 다시 줄일 수는 없다. 따라서 초기 토픽 생성시 파티션 수를 2~4정도로 작게 생성 후 메시지 처리량, 컨슈머 LAG 등을 모니터링하며 늘려나가는 방법이 좋다.
  • [참고] 컨슈머 LAG
    (프로듀서가 마지막으로 넣은 오프셋) - (컨슈머가 마지막으로 읽은 오프셋) 값이다. LAG은 컨슈머에 지연이 없는지 확인할 수 있는 지표로 사용된다. 

• 오프셋(Offset)
  • 파티션의 메시지가 저장되는 위치를 오프셋이라 한다. 각 파티션에서 오프셋은 Unique number이며, 순차적으로 증가하는 숫자로 되어 있다.
  • 오프셋을 통해 메시지의 순서를 보장하고, 컨슈머에서 마지막까지 읽은 위치를 확인하는데 사용된다
• 세그먼트
  • 세그먼트는 파티션의 메시지(레코드)가 실제 카프카 로컬 디스크에 저장된 로그 파일.
  • 세그먼트의 위치는 카프카 서버의 /data/kafka-logs/{토픽 이름-파티션 번호} 디렉토리에 위치한다.
    예) /data/kafka-logs/Topic01-0 (파티션 번호 = 0)

 

2) 리플리케이션과 고가용성 보장

• 리플리케이션 기능은 리더 토픽의 파티션을 복제해서 카프카 클러스터 내 다른 팔로워 브로커에게 저장하는 것이다.
• 리플리케이션 기능 덕분에 하나의 브로커가 종료되더라도 다른 브로커가 리더 역할을 승계하기 때문에 안정적인 서비스가 가능하고, 고가용성이 보장된다.

• 리더는 원본으로서 프로듀서, 컨슈머로부터 오는 모든 읽기와 쓰기 요청을 처리하며, 리플리케이션인 팔로워는 오직 리더의 데이터를 복제만 한다.

리플리케이션 팩터 숫자	리더 수	팔로워 수
1	1	0
2	1	1
3	1	2
4	1	3

• 토픽 생성시 --replication-factor N 이라는 옵션으로 리플리케이션의 개수를 지정할 수 있다.

환경	권장 리플리케이션 팩터
테스트, 개발 환경	1
운영 환경(로그성 메시지로서 약간의 유실 허용)	2
운영 환경(유실 불허)	3

• 리플리케이션 팩터 숫자를 높일 수록 리더 외 팔로워의 수를 더 확보할 수 있으므로 안정적이지만, 디스크 공간도 비례해 소비되므로 리플리케이션 팩터 숫자를 3으로 권장하고 있다.

 

3) 분산 시스템

• 분산 시스템은 네트워크상 연결된 컴퓨터들의 그룹을 말함
• Scale-out 구조
  브로커를 추가하는 방식으로 확장이 용이해 단일 시스템이 갖는 성능 한계를 극복할 수 있음
• 탁월한 장애 대응
  하나의 서버 또는 노드 등에 장애가 발생했을 때 다른 서버 또는 노드가 대신 처리하므로 장애 대응에 탁월함

 

4) 페이지 캐시(Page cache)

• 높은 처리량을 얻기 위한 기능으로 OS의 페이지 캐시를 활용하는 방식으로 설계됨
• 페이지 캐시는 직접 디스크에 읽고 쓰지 않고 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용함
• 디스크에 읽고 쓰지 않으므로 디스크 I/O가 줄어 들어 성능을 높일 수 있음

 

5) 배치 전송 처리

• 카프카는 프로듀서, 컨슈머와 통신하며 수 많은 메시지(레코드)를 주고 받는데, 이 메시지들을 묶어서 처리하는 것을 배치 전송이라 한다.
• 배치 전송을 할 경우 네트워크 부하를 줄일 수 있어 빠르게 처리할 수 있다

 

6) 압축 전송

• 메시지의 크기를 줄이면 전송해야할 크기가 작아지므로 네트워크 속도와 비용 측면에서 효과적이다. 따라서 메시지 전송 시 압축 전송하는 것을 권장한다.
• 카프카에서 지원하는 압축 타입은 gzip, snappy, lz4, zstd 등이 있다
  • gzip, zstd: 높은 압축률이 필요할 경우 권장
  • lz4, snappy: 빠른 응답 속도가 필요할 경우 권장

 

7) 주키퍼

• 주키퍼는 하둡(Hadoop)의 서브 프로젝트 중 하나로 시작해 2011년 아파치 탑레벨 프로젝트로 승격됨. 하둡, HBase 등 많은 분산 애플리케이션의 코디네이터 역할로 사용되고 있음
• 주키퍼는 여러 대의 서버를 클러스터로 구성하고, 살아 있는 노드 수가 관수 이상 유지될 때 지속적인 서비스가 가능하다. 따라서 주키퍼 서버 대수는 반드시 홀수로 구성해야 한다.
• 지노드(znode)를 이용해 카프카의 메타 정보가 주키퍼에 기록되며, 주키퍼는 지노드를 이용해 브로커의 노드, 토픽, 컨트롤러 등을 관리하는 매우 중요한 역할을 한다.
• 참고로, 주키퍼가 카프카의 성능을 제한하는 요소로 작용함에 따라 주키퍼에 대한 지속적인 의존성 제거 작업이 이뤄졌고, 최근 주키퍼를 선택적으로 사용할 수 있는 카프카 버전(3.3)이 릴리즈 되었으며, 4.0 버전 부터는 정식 제거되어 배포될 예정이다. 다만 2022년 8월 현재까지는 안정성을 이유로 대부분의 현업에선 주키퍼를 사용하고 있다.

 

❑ REFERENCE

실전 카프카 개발부터 운영까지 | 고승범 | 책만