Chapter 03. 카프카 기본 개념과 구조

[minkukjo]

카프카 기초 다지기

• 모르는 내용 위주로 빠르게 훑어보는걸로

Replication

• 각 메시지를 여러 개로 복제하여 카프카 클러스터 내 브로커들에 분산시키는 동작
• 정확히는 토픽이 레플리케이션되는게 아닌, 토픽의 파티션이 레플리케이션 된다고 한다.

Partition

• 하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나뉘어 병렬 처리가 가능하게 만든 것이 Partition
• Partition 수를 정확하게 예측하기는 어렵다. 늘리긴 쉬우나 줄이는건 안되니까 조심!

Segment

• 프로듀서에 의해 브로커로 전송된 메시지는 토픽의 파티션에 저장되며, 각 메시지들은 Segment라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장된다.
• 파티션 마다 N개의 세그먼트 로그 파일들이 존재한다.

카프카 핵심 개념

• 카프카는 어떻게 높은 처리량과 안정성을 구현해냈을까!?

분산 시스템

• 최초 구성된 클러스터의 리소스가 한계치에 도달하면 새로운 브로커를 추가하는 방식으로 Scale-out이 가능

페이지 캐시

• 카프카는 높은 처리량을 얻기 위해 OS 페이지 캐시를 활용하는 방식을 사용함
• 페이지 캐시를 통해 디스크 I/O를 최소화하여 성능을 높임

배치 전송 처리

• 단위 시간 대비 처리량을 높이기 위해 카프카는 기본적으로 여러 개의 요청을 묶어서 전송하는 배치 전송 처리 방식을 사용한다.

압축 전송

• 카프카에서는 메시지 전송 시 성능이 높은 압축 전송을 사용함
• 대표적으로 gzip, snappy, lz4, zstd
• zstd는 페이스북에서 만든 압축 알고리즘인데, 압축하고 또 압축하고 또 압축하는 (...) 그런 방식임

Topic, Partition, Offset

• 카프카는 파티션의 메시지가 저장되는 위치를 offset이라 부른다.
• offset은 순차적으로 증가하는 64비트 정수 형태이다.

고가용성 보장

• 카프카는 Raft 알고리즘을 사용해서 고가용성을 보장한다.

주키퍼의 의존성

• 카프카는 주키퍼의 성능적 한계를 느끼고 탈주키퍼(?)를 하기 위한 노력을 진행하여 3.0 버전에서는 KRaft를 사용한다. (이름만 봐도 알겠지만 Kafka + Raft 알고리즘의 결합인 듯.)

[LOG-INFO]

요약

(요약 중 밑줄로 표기된 것은 사견 또는 개인 경험입니다)

• Partition
  • Topic을 여러 개로 나누어서 Broker들에 분산시켜 저장함
  • 병렬 처리를 가능하게 하여 성능을 높임
    • Partition 수만큼 Consumer를 늘려야 병렬처리가 됨
    • Partition 수보다 Consumer 수가 많으면 노는 Consumer가 발생함
    • Partition 수 >= Consumer 수 로 설정하자
  • 늘리는건 가능하지만 줄이는건 불가능
    • 줄일 때 삭제되는 Partition의 Message를 어디로 보낼지 결정하거나 전송중인 Message들 동시성 처리하기가 힘들긴 할 듯
    • 초기엔 작게(2 or 4?) 생성한 후 LAG 등을 모니터링하며 조금씩 늘려가는게 좋음 (물론 Consumer 수도 같이)
  • Leader 와 Follower로 나뉨
    • Leader에 메시지를 쓰면, 각 Follower가 Consuming
• Replication
  • 각 Message들을 여러 개로 복제해서 Broker들에 분산시키는 동작
  • 특정 Broker가 죽는다고 해도 가용성 보장
  • 하지만 많다고 좋기만 한 것은 아님. 성능과 trade-off(그만큼 복제를 많이 해야 하므로)
  • 관련 설정: replication-factor: 해당 토픽의 replication factor 값 설정
• Segment
  • 실제 Message는 해당 Partition을 보유한 Broker 내 로컬 스토리지의 Segment 파일에 저장됨
• 성능 개선
  • Page Cache
  • 직접 디스크에 읽고 쓰는 대신 물리 메모리 중 애플리케이션이 사용하지 않는 일부 잔여 메모리를 활용
  • Batch 전송 처리
  • 메시지들을 하나씩 보내지 않고 묶어서 전송
  • 압축 전송
  • 메시지 전송 시 압축 전송을 하여 네트워크 대역폭을 줄임
    • 또, 압축 전송하면 메시지 처리량도 같이 올라갈 듯 (CPU IO 속도 > 네트워크 IO 속도, feat. 가상 면접 사례...시스템 설계)
  • 배치 전송과 같이 사용하면 더 효율 좋음
    • 데이터 하나만 압축하기보단, 비슷한 데이터들을 압축하는 것이 압축 효율 좋음
    • 높은 압축률: gzip, zstd
    • 빠른 응답속도: lz4, snappy
• Producer
  • producer record -> send() -> serializer -> partitioner -> topic&partition
  • send() 후에 레코드들을 partition별로 잠시 모아둔 후 batch 전송
  • producer에서 partition을 지정했다면 partitioner는 아무 역할 하지 않고 지정된 partition으로 message 전달
  • producer에서 partition을 지정하지 않았다면 partitioner가 message key를 가지고 partition을 선택해 message 전달
  • 주요 옵션
  • bootstrap.servers
  • 가용성 관련
    • acks (0, 1, all)
    • max.in.flight.requests.per.connection
  • 배치 관련
    • buffer.memeory
    • batch.size
    • linger.ms
  • ...
• Consumer
  • 각 Consumer는 반드시 Consumer Group에 속하게 됨
  • group.id 설정해주지 않으면 임의의 anonymous group에 속하게 됨 (ex.
  • partition 수와 consumer group 내의 consumer 수는 1:1 매핑되는 것이 이상적임
    • 4 partition & 3 consumer: 특정 consumer는 2 partition에서 메시지를 가져오게 됨
    • 특정 파티션만 lag이 생기거나 부하가 높아질 수 있음
    • 3 partition & 4 consumer: 노는 consumer가 생김
    • consumer 장애를 위해 active/stand by 개념으로 하나 더 둘 수는 있지만, 어차피 consumer 장애나면 리밸런싱 되면서 재할당 됨
      • 그런데 그러면 위에 언급한 것처럼 특정 파티션은 부하가 높아질 수는 있음
  • 주요 옵션
  • bootstrap.servers
  • group.id
  • group.instance.id: 설정하면 static 멤버로 간주되어 불필요한 리밸런싱 방지 (p.187 스태틱 멤버십에 자세히 나옴)
  • session.timeout.ms
  • max.poll.records + max.poll.interval
  • enable.auto.commit auto.commit.interval.ms
  • auto.offset.reset
  • isolation.level: transactional producer인 경우 transaction처리를 하는데, consumer 단에서 어떤 상태의 메시지를 읽을지 설정
    • read_uncommitted, read_committed

궁금한 점

• Broker가 죽는다면 새로운 Replication이 다른 브로커로 복제되는건가?
  • ex) Broker1, Broker2, Broker3이 있을 때 특정 토픽의 replication-factor가 2고, Broker1, Broker2에 저장이 되고 있을 때
  • Broker1이 죽는다면 일단 Broker2를 조회하면 되긴 하는데, 그 즉시 Broker2의 파티션 내 메시지들이 Broker3으로 복제되는건가?
• '페이지 캐시'를 사용할 때 모든 데이터를 메모리에 올리진 않을텐데, 캐싱하는 데이터의 기준(캐싱 알고리즘)이 무엇일까?
  • 그냥 최근에 전송된 메시지는 곧 컨슈머가 읽어갈 확률이 높으니 최신 메시지를 캐싱하려나? Write-through + LRU or FIFO?
  • 생각해보니 Kafka는 단순히 OS File system의 page cache 기능을 사용하는 것이니 OS에서 사용하는 page cache replacement algorithm을 그대로 사용할 것임. 즉, 서버컴퓨터 OS의 page cache replacement algorithm을 확인하면 됨.
• Producer의 설정 중에는 bootstrap.servers가 있어서 브로커 목록을 전달받는데, 그럼 실제 전송은 어디로 하는거지? 라운드로빈?
  • 브로커가 100대가 있더라도 하나만 입력해도 된다고 한다. 그 브로커에서 메타데이터 가져와서 내가 어떤 브로커로 보내야하는지 알아냄
  • https://always-kimkim.tistory.com/entry/kafka101-configuration-bootstrap-servers

느낀점

• 동작방식이 되게 자세하게 쓰여있고, 예제도 적절하여서 좋았음!
  • 프로그래밍 예제들도 동기, 비동기 등 여러 예제들과 그에 대한 자세한 설명이 있음 👍

[MinJunKweon]

카프카 주요 컴포넌트

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

카프카 구성

리플리케이션(Replication)

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

• 카프카에 전송된 메시지를 여러 대의 서버에 저장하여 하나의 서버가 비정상 종료되더라도 문제없이 메시지를 복원할 수 있음 ⇒ 안정성 향상
• 리플리케이션 팩터(Replication factor) : 메시지를 복제할 서버 개수
• 테스트나 개발환경 : 리플리케이션 팩터 수 1
• 운영 환경(로그성 메시지로서 약간의 유실 허용) : 리플리케이션 팩터 수 2
• 운영 환경(유실 허용하지 않음) : 리플리케이션 팩터 수 3

파티션(Partition)

• 하나의 토픽이 한 번에 처리할 수 있는 한계를 높이기 위해 토픽 하나를 여러 개로 나눠 병렬처리가 가능하도록 만듦.
• 토픽마다 파티션 개수를 따로 설정할 수 있으며, 모든 토픽은 1개 이상의 파티션을 가지고 있음.
• 파티션 번호는 0부터 시작함
• 토픽을 생성할 때, 파티션 개수를 지정할 수 있음
• 이미 생성된 토픽의 파티션 수를 늘릴 수 있지만, 한번 늘린 파티션 수는 절대로 줄일 수 없음.

세그먼트(Segment)

• 프로듀서에 의해 브로커로 전송된 메시지는 토픽의 파티션에 저장되며, 메시지들은 세그먼트라는 로그 파일의 형태로 브로커의 로컬 디스크에 저장됨
• 파티션마다 N개의 세그먼트 로드 파일들이 존재함
• /data/kafka-logs 경로를 확인하면 각 파티션마다 로그 세그먼트가 저장된 것을 확인할 수 있음

카프카의 핵심 개념

분산 시스템

• 네트워크 상에서 연결된 컴퓨터들의 그룹으로 단일 시스템이 갖지 못하는 높은 성능을 낼 수 있음
• 하나의 서버 또는 노드 등에 장애가 발생할 때 다른 서버 또는 노드가 대신 처리해서 장애 대응이 탁월함
• 부하가 높은 경우 시슽메 확장이 용이하다

페이지 캐시

• 운영체제(Operating System) 성능을 향사하기 위해 페이지 캐시를 활용함
• 카프카 역시 OS의 페이지 캐시를 활용하는 방식으로 설계되어 직접 디스크에 읽고 쓰는 대신 메모리를 사용하도록 함
• 페이지 캐시를 사용하면 디스크 I/O에 대한 접근이 줄어드므로 성능을 높일 수 있음

배치 전송 처리

• 수많은 통신들을 묶어서 처리할 수 있다면 단건으로 통신할 때에 비해 네트워크 오버헤드를 줄일 수 있음
• 장기적으로는 더욱 빠르고 효율적인 처리가 가능

압축 전송

• 메시지 전송 시 좀 더 성능이 높은 압축 전송을 사용하는 것을 권장함
• 높은 압축률이 필요하다면 gzip, zstd 사용
• 빠른 속도가 필요하다면 lz4, snappy 사용

토픽(Topic), 파티션(Partition), 오프셋(Offset)

• 토픽 별로 여러 개의 파티션으로 메시지를 저장함.
• 파티션의 메시지가 저장되는 위치를 오프셋(Offset)이라고 부르며, 오프셋은 순차적으로 증가하는 숫자 형태로 되어있음
• 오프셋을 통해 메시지의 순서를 보장하고 컨슈머에서는 마지막까지 읽은 위치를 알 수도 있음

고가용성 보장

• 분산 시스템이기 때문에 리플리케이션(Replication)으로 하나의 서버나 노드가 다운되어도 다른 서버 또는 노드가 장애가 발생한 서버의 역할을 대신해 안정적인 서비스가 가능
• 토픽 자체를 복제하는 것이 아니라 토픽의 파티션을 복제하는 것
• 카프카에서는 Leader와 Follower라고 부름
• Leader 수는 1로 고정. 리플리케이션 팩터 수에 따라 Follower 수가 증가함

주키퍼 의존성

• 여러 대의 서버를 앙상블(클러스터)로 구성하고, 살아 있는 노드 수가 과반수 이상 유지된다면 지속적인 서비스가 가능한 구조
• 주키퍼는 반드시 홀수로 구성해야함
• 지노드(znode)를 이용해 카프카의 메타 정보가 주키퍼에 기록되며, 주키퍼는 지노드를 이용해 브로커의 노드 관리, 토픽 관리, 컨트롤러 관리 등 매우 중요한 역할을 함
• 주키퍼 성능의 한계가 드러나기 시작하여 신규 버전의 카프카에서는 주키퍼 의존성이 제거될 예정