[실전 카프카 개발부터 운영까지 정리] 3장. 카프카 기본 개념과 구조

http://www.yes24.com/Product/Goods/104410708

해당 책을 공부하며 정리한 내용입니다.

실전 카프카 개발부터 운영까지 - YES24

 

Replication

• 안정성을 높이기 위해 각 메시지들을 여러 개로 복제하여 카프카 클러스터 내 브로커들에 분산시키는 동작

--replication-factor 3 # 3개의 리플케이션

• 리플리케이션의 수가 증가할 수록 안정성은 높아지지만, 브로커 리소스를 많이 사용하게 되는 트레이드오프가 존재.
  • 테스트나 개발 환경: Replication Factor 1
  • 운영 환경 (로그성 메시지로 약간의 유실을 허용): Replication Factor 2
  • 운영 환경 (유실 허용 X): Replication Factor 3

다음과 같이 리플리케이션 팩터 수를 설정해서 사용하는 것을 권장한다고 한다. (4이상으로 설정하는 것은 브로커 리소스 사용량에 비해 크게 효율적이지 않음)

파티션

• 하나의 토픽을 여러 개의 논리적인 개념인 파티션으로 나누어 병렬 처리가 가능하도록 함.
• 이러한 파티션을 이용해 분산 처리를 할 수 있음. (나뉜 파티션만큼 컨슈머를 연결)

파티션 수 적정 값

• 파티션 수는 초기 생성 후 언제든지 늘릴 수 있지만, 한 번 늘린 파티션 수는 절대로 줄일 수 없다.
• 따라서 초기에 토픽을 생성할 때 파티션 수를 2, 4 정도로 작게 생성한 후, 메시지 처리량이나 컨슈머의 LAG 등을 모니터링하면서 조금씩 늘려가는 방법이 좋다. (컨슈머의 LAG란 프로듀서가 보낸 메시지 수 - 컨슈머가 가져간 메시지 수 ⇒ 즉, 컨슈머가 처리해야 하는 메시지 수라고 할 수 있다)
• LAG 지표를 통해 컨슈머의 지연 여부를 확인한 후 파티션 수를 늘려가는 방법이 좋다.

세그먼트

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

카프카의 핵심 개념

---

분산 시스템

• 카프카는 분산 시스템으로 구성되어 있어 성능이 높으며 고가용성 처리 가능 및 시스템 확장 용이.

페이지 캐시

• 카프카는 OS의 페이지 캐시를 활용하는 방식으로 설계되어 있어서, 직접 디스크를 읽고 쓰는 대신 물리 메모리 중 일부 잔여 메모리를 페이지로 캐시로 사용함으로써, 디스크 I/O에 대한 접근이 줄어들어 성능을 높임.

토픽, 파티션, 오프셋

• 카프카는 토픽이라는 곳에 데이터를 저장하는데, 이 토픽은 파티션으로 나뉘어 병렬 처리를 수행.
  • 이와 같은 파티셔닝을 통해 높은 처리량을 수행할 수 있음.
• 파티션의 메시지가 저장되는 위치를 오프셋이라고 한다.
  • 카프카에서는 오프셋을 통해 메시지의 순서를 보장하고 컨슈머에서는 마지막까지 읽은 위치를 알 수 있음.

고가용성 보장

• 카프카에서는 고가용성을 보장하기 위해 리플레케이션 기능을 제공.
• 카프카에서 제공하는 리플리케이션은 토픽 자체를 복제하는 것이 아니라, 토픽의 파티션을 복제.
• 원본과 복제본을 리더와 팔로우라고 부른다.
  • 리더는 프로듀서, 컨슈머로부터 오는 모든 읽기와 쓰기 요청을 처리
  • 팔로워는 오직 리더로부터 리플리케이션 수행.

주키퍼의 의존성

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

프로듀서

---

프로듀서는 카프카의 토픽으로 메시지를 전송하는 역할을 담당.

• KafkaRecord는 카프카로 전송하기 위한 실제 데이터로
  • 토픽, 파티션, Key, Value로 구성되어있음.
  • 토픽, Value(메시지 내용)은 필수 값
  • 특정 파티션을 지정하기 위한 레코드의 파티션과 특정 파티션에 레코드들을 정렬하기 위한 레코드의 키는 필숫값이 아닌 옵션 값.

각 레코드들은 프로듀서의 send() 메소드를 통해 Serializer, Partitioner를 거치게 된다.

• 만약 프로듀서 레코드의 선택사항인 파티션을 지정했다면, 파티셔너는 아무 동작도 하지 않고 지정된 파티션으로 레코드를 전달함.
• 파티션을 지정하지 않은 경우에는 키를 가지고 파티션을 선택해 레코드를 전달하는데, 기본적으로 라운드 로빈 방식으로 동작한다

프로듀서 내부에서는 send() 메서드 동작 이후 레코드들을 파티션 별로 잠시 모아두었다가 전송한다. (배치 전송을 위해)

프로듀서의 주요 옵션

• acks
  • 프로듀서가 카프카 토픽의 리더 측에 메시지를 전송한 후 요청을 완료하기를 결정하는 옵션.
  • 0은 빠른 전송, 일부 메시지 손실 가능성 존재
  • 1: 리더가 메시지를 받았는지 확인하지만, 모든 팔로우를 전부 확인하지는 않음.
  • all(-1): 팔로우도 메시지를 받았는지 여부를 확인
  대부분 기본값으로 1을 사용한다.
• transaction.id
  • 정확히 한 번 전송을 위해 사용하는 옵션, 동일한 TransationId에 한해 정확히 한 번을 보장함.
  • enable.idempotence를 true로 설정해야 한다.
• enable.idempotence
  • true 하면 중복 없는 전송이 가능하며, 동시에 max.in.flight.requests.per.connection은 5 이하, retries는 0 이상, acks는 all로 설정해야 한다.
• max.in.flight.requests.per.connection
  • 하나의 커넥션에서 프로듀서가 최대한 ACK 없이 전송할 수 있는 요청 수.
  • 메시지의 순서가 중요하다면 1로 설정할 것을 권장하지만, 성능은 다소 떨어진다.

컨슈머

---

• 카프카의 토픽에 저장되어 있는 메시지를 가져오는 역할 담당.
• 추가로 내부적으로 컨슈머 그룹, 리밸런싱 등 여러 동작을 수행한다.

기본 동작 방식

프로듀서가 토픽으로 메시지를 전송하면 해당 메시지들은 로컬 디스크에 저장된다. 그리고 컨슈머를 이용해 토픽에 저장된 메시지를 가져올 수 있다.

컨슈머 그룹은 하나 이상의 컨슈머들이 모여 있는 그룹으로, 컨슈머는 반드시 컨슈머 그룹에 속하게 된다.

• 컨슈머 그룹은 각 파티션의 리더에게 카프카 토픽에 저장된 메시지를 가져오기 위한 요청을 보낸다.
• 이때 파티션 수와 컨슈머 수는 1:1로 매핑되는 것이 이상적이지만 반드시 1:1로 매핑해야 하는 것은 아님.
  • 단 파티션 수보다 컨슈머 수가 많게 구현하는 것은 올바르지 않음.

컨슈머의 주요 옵션

• group.id
  • 컨슈머가 속하는 컨슈머 그룹을 식별하는 식별자
  • 동일한 그룹 내의 컨슈머 정보는 모두 공유된다.
• enable.auto.commit
  • 백그라운드로 주기적으로 오프셋을 커밋.
• auto.offset.reset
  • 카프카에서 초기 오프셋이 없거나 현재 오프셋이 더 이상 존재하지 않는 경우 다음 옵션으로 reset 수행.
  • earliest: 가장 초기의 오프셋 값으로 설정
  • lateest: 가장 마지막의 오프셋값으로 설정
  • none: 이전 오프셋 값을 차지 못하면 에러

컨슈머 그룹

• 컨슈머는 컨슈머 그룹 안에 속한 것이 일반적인 구조로, 하나의 컨슈머 그룹 안에 여러 개의 컨슈머가 구성될 수 있음.
• 컨슈머들은 토픽의 파티션과 1:1로 매핑되어 메시지를 가져오게 된다.