카프카 기본 구조 정리

카프카

카프카는 링크드인 에서 만들어진 고성능 분산 이벤트 스트리밍 플랫폼`

 

도입이전

• 파편화된 데이터 수집 및 분배 아키텍처를 운영하는데 큰 어려움을 겪음
• 타킷 애플리케이션 장애 발생시 소스 애플리케이션에 직접적으로 영향을 줌
• 카프카 등장

 

도입후

• 카프카를 중앙 배치함으로써 소스/타킷 애플리케이션 간 의존도 완화
• 기존 1:1 매칭 파이프라인의 의존도 타파

구성요소

• 주키퍼
  • 카프카의 메타데이터 관리, 브로커의 health check 담당

 

• 카프카 또는 카프카 클러스터
  • 아파치 프로젝트 애플리케이션으로 여러대의 브로커를 구성한 클러스터를 의미

 

• 브로커
  • 카프카 애플리케이션이 설치된 서버 또는 노드

 

• 프로듀서
  • 카프카로 메시지를 pub 하는 클라이언트

 

• 컨슈머
  • 카프카로부터 메시지를 consume 하는 클라이언트

 

• 토픽
  • 카프카는 메시지 피드를 토픽으로 구분하고, 각 토픽의 이름은 카프카 내에서 고유

 

• 파티션
  • 병렬 처리 및 고성능을 위해 하나의 토픽을 여러개로 나눈 것

 

• 세그먼트
  • 프로듀서 가 전송한 실제 메세지가 브로커의 로컬 디스크에 저장되는파일을 의미

 

• 메세지, 레코드
  • 프로듀서가 브로커로 전송하거나 컨슈머가 읽어가는 데이터 조각

Replication

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

때문에 카프카는 하나의 브로커가 다운되더라도 안정성을 유지할 수 있다.

카프카 클러스터 설치 후 토픽 생성시, 아래와 같은 옵션을 생성하였다.

--partition 1, --replication-factor 3

replication-factor 옵션은 몇개의 replication을 유지하는지 설정하는 옵션이다.

위 그림에서 replication-factor 3 으로 생성했기 때문에 3개의 replication이 있음을 의미한다.

그리고 test 1 이라는 topic의 파티션들이 3개로 복제됬다고 표현할 수 있다.

 

replication-factor 의 값이 높아지면 안정성이 증가하지만, 그만큼 브로커의 리소스 비용증가, 오버헤드가 발생하여 적절한 팩터수의 설정이 필요하다.

• 테스트 또는 개발환경: replication-factor 1
• 운영(약간의 유실 가능): replication-factor 2
• 운영(유실 불가능): replication-factor 3

파티션

하나의 토픽이 한번에 처리할 수 있는 성능을 높이기 위해 여러개로 나누어 병렬처리 할 수 있도록 한 것이 파티션이다.

파티션의 개수만큼 컨슈머를 연결할 수 있게 되어 consume 성능도 증가한다.

토픽 1은 1개의 파티션, 토픽 2는 3개의 파티션으로 구성되어 있다.

파티션의 개수는 초기 생성 후에 언제든지 늘릴 수 있지만, 줄이는 것은 불가능하다. 때문에 메시지 처리량인 컨슈머의 LAG 수치 등을 모니터링 하면서 적절하게 늘려나가는 것이 권장되는 방법이다.

세그먼트

프로듀서를 통해 보낸 메세지는 어디 저장될까?

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

각 파티션 마다 N개의 세그먼트 로그 파일들이 존재한다.

핵심 기능

• 높은 처리량
  • 일반적으로 많은 양의 데이터 송수신시 많은 네트워크 비용 발생
  • 그러나 카프카는 동일한 양 데이터 송신에서의 최소한의 네트워크 통신 횟수(메세지 압축 전송)
  • 동일 시간 내 많은 데이터 전송가능
  • 많은 양의 데이터를 배치(묶음단위)로 처리
  • 파티션을 통한 데이터 병렬처리 -> 파티션 개수를 늘리면 데이터 처리량 증가

​

• 확장성
  • 클러스터의 브로커 개수를 자연스럽게 조절하여 스케일 아웃/스케일 인 가능
  • 무중단 운영 지원으로 인한 안정적 운영 가능

​

• 영속성
  • 전송받은 데이터를 메모리에 저장하지 않고 파일 시스템에 저장
  • 파일 시스템은 보편적으로 느리지만 카프카는 페이지 캐시영역을 메모리에 따로 생성하여 사용하기 때문에 처리량이 높음
  *페이지캐시
• 한번 읽은 파일 내용은 메모리에 저장시켰다가 다시 사용하는 방식(OS에서 사용됨)

​

• 고가용성
  • 3개 이상의 서버들로 운영되는 카프카 클러스터는 일부 서버 장애가 발생하더라고 무중단으로 안전하고 지속적인 데이터 처리 가능
  • 온프레미스/퍼블릭 클라우드 환경에서도 데이터를 안전히 복제할 수 있는 옵션 제공

프로듀서 모델

ProducerRecord 는 카프카로 전송하기 위한 실제 데이터이며, 토픽, 파티션, 키, 벨류로 구성되어 있다.

 

프로듀서가 카프카로 메세지를 전송할 때, 특정 토픽으로 메세지를 전송하며,

레코드에서 토픽,벨류는 필수, 파티션, 키 는 optional 이다.

 

레코드는 Send() 메서드를 통해서 Serializer, Partitioner를 거친다.

 

만약 파티션을 지정했다면 Partitioner는 아무 동작도 하지 않고 지정된 파티션으로 레코드를 전달한다.

파티션을 지정하지 않은 경우 Partitioner가 동작하여 각 파티션에 분배한다.

 

Partitioner 동작시 ProducerRecord에 키가 있다면, partition = key.hashCode() % numPartitions 키의 해시 값을 계산해서 파티션에 분배된다.

키가 없다면, 라운드 로빈 방식으로 각 파티션들에게 균등히 분배한다.

 

Send() 동작 이후 레코드들을 파티션 별로 잠시 모아두었다가 카프카 브로커로 배치 전송 한다.

 

컨슈머 모델

보통 하나의 컨슈머 그룹 안에 여러개의 컨슈머가 구성될 수 있다.

같은 그룹 내의 컨슈머들은 서로의 정보를 공유한다. 때문에 예를 들어 컨슈머 1이 다운되는 경우 컨슈머 2 가 대체하여 파티션 1을 컨슘한다.

참고:

https://hoing.io/archives/5108