Kafka

end-to-end 아키텍처의 문제점

 

1. 실시간 트랜잭션(OLTP) 처리와 비동기 처리가 동시에 이뤄지지만 통합된 전송 영역이 없어 복잡도 증가
• 문제 발견과 조치를 위해서는 이와 관련된 여러 데이터 시스템을 확인해야함
• 장애 / OS update / scale out 과 같은 작업을 위해 많은 준비 시간이 필요

 

1. 데이터 파이프라인 관리의 어려움
• 여러 시스템에 저장된 동일한 데이터를 개발자는 각기 다른 방법으로 파이프라인을 만들고 유지하게 된다.
• 각 파이프라인별로 데이터 포맷과 처리하는 방법들이 완전히 달라서 데이터 파이프라인의 확장이 어려움
• 데이터 파이프라인의 복잡성으로 인해 두 시스템 간의 데이터가 서로 달라져 데이터의 신뢰도 저하

 

Kafka의 등장

 

• 위와 같은 문제점을 해결하기 위해 모든 시스템으로 데이터 전송, 실시간 처리가 가능하며, 급속도로 성장하는 서비스를 위해 확장이 용이한 시스템을 만들게 되었다.
• 목표
• 프로듀서와 컨슈머의 분리
• 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지 최적화
• 데이터가 증가함에 따라 scale out이 가능한 시스템
• 링크드인의 데이터 처리 시스템

 

Kafka와 기존 메시지 큐 솔류션(RabbitMQ etc..)

 

• Kafka의 특징
1. 프로듀서와 컨슈머의 분리
1. 기존 polling 방식이었던 메트릭 수집 방식을 pub/sub 방식으로 변경
2. polling 방식의 경우 scale out 하고자 할 경우 연동해야 할 시스템이 많아지기 때문에 많은 어려움이 있다.

 

1. 멀티 프로듀서, 멀티 컨슈머
1. 하나의 토픽에 여러 프로듀서 또는 컨슈머들이 접근 가능하다.
2. 하나의 프로듀서가 하나 또는 하나 이상의 토픽으로 메시지 전송 가능
3. 하나의 컨슈머는 하나 이상의 토픽으로부터 메시지를 가져올 수 있다.

 

1. 디스크에 메시지 저장
1. 일반적인 메시징 시스템들은 컨슈머가 메시지를 읽으면 큐에서 바로 삭제된다,
2. 카프카는 컨슈머가 읽더라도 보관 주기 동안 디스크에 메시지를 저장해둔다.
3. 이는 멀티 컨슈머를 가능하게 하며, 손실 없이 작업이 가능하게 한다.

 

1. 확장성
1. 확장 작업은 카프카 서비스의 중단 없이 온라인 상태에서 작업이 가능하다.
2. 클러스터 확장하는 작업이 매우 간단하며 부담이 없다.

 

1. 높은 성능
1. 내부적으로 분산 처리, 배치 처리 등 다양한 기법을 사용하여 높은 성능을 보인다.

 

Kafka 용어 정리

 

• 브로커(Broker) : 카프카 어플리케이션이 설치되어 있는 서버 또는 노드
• 토픽(Topic) : 프로듀서와 컨슈머들이 카프카로 보낸 자신들의 메시지를 구분하기 위한 네임으로 메시지들이 서로 뒤섞여 각자 원하는 메시지를 얻기 어려워지는 것을 방지한다.
• 파티션(Partition) : 병렬처리가 가능하도록 토픽을 나눌 수 있고, 많은 양의 메시지 처리를 위해 파티션의 수를 늘려줄 수 있다.
• 프로듀서(Producer) : 메시지를 생산하여 브로커의 토픽 이름으로 보내는 서버 또는 어플리케이션

 

 

주키퍼(Zookeeper)

 

• 분산 애플리케이션을 위한 코디네이션 시스템 [ 분산 앱이 안정적인 서비스를 할 수 있도록 분산되어 있는 각 앱의 정보를 중앙에 집중하고 구성 관리, 그룹 관리 네이밍, 동기화 등의 서비스 제공 ]
• 카프카와 직접 통신을 하면서, 카프카의 메터데이터 정보를 주키퍼에 저장
• 카프카의 상태관리 등의 목적으로 이용된다.
• 주키퍼의 사용은 필수 조건이다.

 

• 분산 애플리케이션을 사용하게 되면, 분산 애플리케이션 관리를 위한 안정적인 코디네이션 애플리케이션이 필요하다.
• 분산 앱과 코디네이션 앱을 병렬적으로 개발하다 보면 코디네이션 앱을 위한 추가적인 개발 리소스가 필요하다.
• 이를 방지하기 위해 이미 안정적인 코디네이션 서비스로 검증된 주키퍼를 주로 사용

 

• 카프카 클라이언트들의 상태 정보들은 주키퍼의 지노드(znode)라 불리는 곳에 key-value 형태로 저장한다.
• 지노드에 key-value가 저장된 것을 이용하여 분산 앱들은 서로 데이터를 주고받게 된다.
• 지노드는 일반적인 디렉토리와 비슷한 형태로서 자식노드를 가지고 있는 계층형 구조로 구성되어 있다.
• 주키퍼에 저장되는 데이터는 모두 메모리에 저장되어 처리량이 매우 크고 속도 또한 뻐르다.

 

 

카프카 데이터 모델 ( 토픽 - 파티션 )

 

토픽

• 카프카 클러스터가 데이터를 저장하는 장소
• 메일 시스템의 메일주소라고 생각할 수 있다.
• 데이터를 구분하기 위한 단위

파티션

• 토픽을 분할한 것
• 분산 시스템의 기본 조건인 메시지 순서의 보장을 위해 사용된다.
• 빠른 전송을 위해서는 토픽의 파티션을 늘려주어야 하며, 그 수만큼 프로듀서 수도 늘려야 한다.
• 파티션의 조건
• 파일 핸들러의 낭비
• 각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터마다 2개의 파일(index & data)이 있다.
• 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 된다.
• 많은 파티션의 수는 많은 파일 핸들의 수를 야기하기 때문에 리소스를 낭비하게 된다.
• 장애 복구 시간 증가
• 각 파티션마다 리플리케이션이 동작하게 되며, 하나는 파티션의 리더 나머지는 팔로워가 된다.
• 브로커가 다운되면 해당 브로커에 리더가 있는 파티션은 일시적으로 사용할 수 없게 되므로, 컨트롤러(지정된 브로커)에 의해 리더를 팔로워 중 하나로 이동시켜 요청을 처리할 수 있다.
• 파티션이 너무 많은 경우 새로운 리더를 선출하는데 오랜 시간이 걸린다.
• 무작정 파티션 수를 늘리기보다는 적절한 값으로 설정해 운영하는 편이 좋다.

 

• 적절한 파티션 수
• 목표 처리량의 기준을 잡는다.
• 프로듀서와 컨슈머의 서버당 메시지 전송 수에 맞게 적절한 개수를 잡는다.

 

• 카프카는 파티션 수의 증가는 시스템 운영 중에 가능하지만 감소시키는 것은 불가능하다.

 

오프셋

• 각 파티션마다 메시지가 저장되는 위치
• 파티션 내에서 유일하고 순차적으로 증가하는 숫자(64비트) 형태로 되어 있다.
• 파티션마다 오프셋 값은 유니크한 값을 가진다.
• 컨슈머가 파티션에서 데이터를 가져가고자 할 떄 절대적으로 오프셋 순서에 따라야 한다.