Before 카프카

• 엔드투엔드(end-to-end) 연결 방식의 아키텍쳐.
• 데이터 연동의 복잡성 증가(HW, OS, System, ...).
• 각기 다른 데이터 파이프라인 연결 구조.
• 확장에 엉청난 노력 필요.

모든 시스템으로 데이터를 전송 실시간 처리도 가능한 것 데이터가 갑자기 많아지더라도 확장이 용이한 시스템이 필요.

After 카프카

• 프로듀서/컨슈머 분리
• 메시지 데이터를 여러 컨슈머에게 허용
• 높은 처리량을 위한 메시지 최적화
• 스케일 아웃 가능
• 관련 생태계 제공

카프카 브로커

실행된 카프카 어플리케이션 서버(프로세스) 중 1대. n 개 이상 사용할 수 있지만 그렇게 운영하는 경우는 없음. 3대 이상의 브로커로 클러스터 구성 가능. 카프카 클러스터에서 1대는 컨트롤러 기능 수행. 각 브로커에게 담당파티션 할당 수행. 브로커 정상 동작 모니터링 관리.

주키퍼와 연동(~2.5.0 버전) 필요.

• 주키퍼의 역할 : 메타 데이터(브로커 id, 컨트롤러 id, ...) 저장. 누가 컨트롤러인지는 주키퍼에 저장.
• 카프카에서는 주키퍼를 걷어 내려는 시도가 있다는 말도 있음.

토픽 & 파티션

• 토픽이란 카프카에서 메시지 분류하는 단위이다.
• 토픽마다 파티션은 반드시 한개 이상 존재 해야함.
• 각 토픽마다 n개의 파티션 할당 가능하다.
• 각 파티션마다 고유한 offset을 가지며 0 번부터 가장 오래된 offset이고 FIFO 형태의 데이터 구조이지만 큐처럼 아이템을 읽은 후 바로 큐에서 제거하지 않는다.
• 메시지 처리는 각 파티션 별로 관리된다.

프로듀서 & 컨슈머

카프카에서 전달되는 데이터를 메시지 또는 레코드라고 한다. 이 메시지를 생성하는 역할을 프로듀서, 메시지를 가져가서 처리하는 역할을 컨슈머라고 한다. 파티션에 여러 컨슈머가 붙어서 메시지를 가져갈 수 있으며 별도로 offset을 유지 한다.

1. 프로듀서는 메시지를 생성하여 브로커로 전송한다.

2. 전송된 메시지는 파티션에 신규 오프셋과 함께 기록된다.

3. 컨슈머는 브로커로 부터 메시지를 요청(polling)하여 가져간다.

카프카가 전달하는 메시지 : topic, key, message.

프로듀서의 데이터

ProducerRecord 객체를 생성하여 전달해야 한다.

new ProducerRecord<String, String>("topic", "key", "message");

컨슈머의 데이터

ConsumerRecord<String, String> records = consumer.poll(1000);
for (ConsumerRecord<String, String,> record : records) {
}

직렬화

객체를 프로듀서에서 컨슈머로로 전달하기 위해 카프카 내부에 byte 형태로 저장할 수 있도록 직렬화/역직렬화하여 사용.

• 기본 제공 직렬화 class : StringSerializer, ShortSerializer 등.
• 커스텀 직렬화 class를 통해 Custom Object Serialize/Deserialize 가능.

카프카 로그 & 세그먼트

브로커로 전달된 메시지는 DB에 저장하지 않고 로컬 파일 시스템에 저장한다. 즉 파일로 저장 한다는 의미다.

• 

카프카는 메시지를 세그먼트 파일로 저장한다. 세그먼트 파일은 로그 파일과 같이 일정 시간이나 용량이 임계점에 도달하면 저장하고 다른 세그먼트 파일에 저장한다.

생성된 세그먼트 파일은 일정 시간(또는 용량)에 따라 삭제(delete) 또는 압축(compact)하여 파일 시스템 저장 공간을 관리한다.

• 

싱글 컨슈머 그룹 동작 방식

3 파티션 + 1 컨슈머 : 1개의 컨슈머가 3개의 파티션 메시지를 처리.

3 파티션 + 3 컨슈머(스케일 아웃) : 컨슈머가 파티션을 1:1 대응하여 메시지 처리. 컨슈머의 병렬처리

3 파티션 + 4 컨슈머 : 남는 컨슈머는 idle이 되기에 (파티션 갯수 >= 컨슈머 갯수) 원칙을 지키는 것을 권고 한다(! 주의할 것은 컨슈머가 같은 그룹에 있다는 전제이다)

리밸런스

리밸런스는 파티션 컨슈머 할당을 재조정 하는 것이다. 컨슈머 중 한개가 장애가 난 경우 다른 컨슈머가 대신 처리 할 수 있도록 리밸런스 한다.

리밸런스가 발생하면 파티션 할당이 중단된다. 따라서 리밸런스가 언제 멈추었는지를 확인하여 언제부터 장애가 발생 하였는지 파악 하기도 한다.

멀티 컨슈머 그룹 동작 방식

목적에 따라 컨슈머 그룹을 분리할 수 있다. 장애에 대응하기 위해 재입수(또는 재처리) 목적으로 임시 신규 컨슈머 그룹을 생성하여 사용하기도 한다.

EX) 엘라스틱서치와 하둡으로 각자 별개의 컨슈머를 만들어 처리.

이런 구조의 장점은 장애 격리 이다. 하둡에 이슈가 발생하여 컨슈머 적재지연이 발생하여도 엘라스틱서치에 적재하는 컨슈머의 동작에는 이슈가 없음.

문제가 발생한 하둡도 복구가 되면 문제가 발생한 시점부터의 메시지를 다시 polling 하여 처리를 이어나갈 수 있다.

레플리케이션

만약 파티션 3개 생성한 후 잘 사용하고 있는 상황에서

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic topic_name --partitions 3

--bootstrap-server : 로컬에 있는 카프카 브로커에
--topic : 토픽 이름 지정

Brocker 1이 문제가 발생한다면 Broker 1이 복구 될때까지 사용할 수 없다.

Broker 1을 복구하기 전까지 Broker 1의 파티션을 사용하고 싶다면 레플리케이션 기능을 사용할 수 있다.

레플리케이션 : 파티션을 다른 브로커에 복제.

kafka-topics.sh --bootstrap-server localhost:9092 --create --topic topic_name --partitions 3 
\ --replication-factor 3

--replication-factor : 레플리케이션 갯수 지정

리더 파티션 : 카프카 클라이언트와 데이터를 주고 받는 역할.

팔로워 파티션 : 리더 파티션으로 부터 레코드를 지속 복제(복제하는데 시간이 걸림). 리더 파티션의 동작이 불가능할 경우 나머지 팔로워 중 1개가 리더로 선출됨.

EX) 파티션 3개 + 레플리케이션 3개

ISR(In-Sync Replica) : 특정 파티션의 리더, 팔로워가 레코드가 모두 복제되어 sync가 맞는 상태. 이 상태에서는 장애가 발생 하여도 문제없이 처리 가능

ISR이 아닌 상태에서 장애가 발생하면 복제 완료 될때까지 대기해야 한다.

unclean.leader.election.enable 옵션 : 기본은 false. true 하면 팔로워 파티션이 복제 완료 안되어도 처리 진행.

EX) Broker 1 장애 발생할 경우 파티션 1의 리더가 브로커 1 또는 2 중에 새로 할당되고 카프카 클라이언트는 새로운ㅇ 파티션 리더와 연동 된다.

카프카 클러스터의 서버 장애 대응

서비스 운영에 있어 장애 허용(Fault-tolerant)은 아주 중요
서버 중단(이슈 발생, 재시작) 언제든 발생할 수 있음.

일부 서버가 중단되더라도 데이터가 유실되면 안됨. 안정성이 보장되지 않으면 신뢰도가 하락

카프카 핵심 요소

카프카 클라이언트

카프카와 데이터를 주고받기 위해 다양한 라이브러리, 3rd party 라이브러리 존재. 단 카프카 브로커 버전과 클라이언트 버전 하위호환 확인 필요

카프카 스트림즈

데이터를 변환(Transformation)하기 위한 목적으로 사용하는 API
스트림 프로세싱을 지원하기 위한 다양한 기능을 제공

• Stategul 또는 Stateless 와 같이 상태기반 스트림 처리 가능
• Stream api와 DSL(Domain Sepecific Language)를 동시 지원
• Exactly-once 처리, 고 가용성 특징
  • 장애가 발생 하여도 각 offset을 한번만 처리
• Kafka security(acl, sasl 등) 완벽 지원
• 스트림 처리를 위한 별도 클러스터(ex: yarn 등) 불필요

카프카 커넥트

많은 경우 Kafka client로 Kafka로 데이터를 넣는 코드를 작성할때도 있지만, Kafka connect를 통해 data를 Import/Export 할 수 있음.

코드 없이 configuraion으로 데이터를 이동시키는 것이 목적

• Standalone mode, distribution mode 지원
• REST api interface를 통해 제어
• Stream 또는 Batch 형태로 데이터 전송 가능
• 커스텀 connector을 통한 다양한 plugin 제공(File, S3, Hive, MySql, ...)

카프카 미러 메이커

특정 카프카 클러스터에서 다른 카프카 클러스터로 토픽 및 메시지를 복제하는 Standalone tool

클러스터간 토픽에 대한 모든 것을 복제하는 것이 목적

• 신규 토픽, 파티션 감지기능 및 토픽 설정 자동 Sync 기능
• 양방향 클러스터 토픽 복제
• 미러링 모니터링을 위한 다양한 metric(latency, count 등) 제공

기타

카프카 reack-awareness 옵션 : 서버 랙이 내려가면 같이 내려감. 1개의 랙에 다수의 브로커를 몰아 넣는 것은 위험. 다수의 랙에 분산하여 브로커 옵션 설정 및 배치

카프카 application

브로커 갯수 이상으로 레플리케이션 설정 불가.

레블리케이션이 많은게 무조건 좋은게 아님. 싱크 과정에서 네트워크 패킷 발생.

카프카가 기본 힙메모리 설정이 1G로 설정되어 있을 경우 EC2에서 메모리 제한으로 실행되지 않을 수 있음. 이때 환경 변수로 카프카의 힙메모리 설정을 변경 가능.

export KAFKA_HEAP_OPTS="-Xmx400m -Xms400m"

링크드인 java option 추천값

• 

서비스간 인터페이스

성능, 장애 처리 이외에 카프카는 서비스간 통신을 위한 인터페이스로도 사용될 수 있다. 카프카를 지원하는 여러 서드파티들이 존재하기에 카프카를 사용한다면 여러 서비스를 쉽게 추가할 수 있다는 장점이 있다.