카프카

메시지 발행과 구독 

 메시지 발생/구독 시스템에서는 데이터(메시지)를 발행자(전송자)가 직접 구독자(수신자)에게 보내지 않는다.
 

 

카프카 살펴보기

분산 커밋 로그(distributed commit log) 또는 분산 스트리밍 플랫폼(distributed streaming platform) 이라고 한다. 
모든 트랜잭션을 지속적으로 기록
  - 파일 시스템이나 데이터베이스의 커밋 로그는 시스템의 상태를 일관성 있게 유지할 수 있다.
데이터 분산 처리 
 - 시스템 장애에 대비하고 확장에 따른 성능 저하 방지

메시지와 배치 

 메시지(message) : 데이터의 기본 단위 
   데이터베이스의 행(row)이나 레코드(recode)에 비유된다.
   메시지는 바이트 배열의 데이터로 간주
   키(key)라는 메타데이터가 포함될 수 있다. 키도 바이트 배열
   토픽(topic)으로 분류된 파티션(partition)에 수록된다. 이때 데이터를 수록할 파티션을 결정하기 위해 일관된 해시 값으로 키를 생성한다. 같은 키 값을 갖는 메시지는 항상 같은 파티션에 수록된다.

배치(batch)
  효율성을 위해 여러 개 메시지를 모아 배치 형태로 파티션에 수록. 매번 각 메시지를 받아서 처리하는데 따른 부담 감소
  대기시간(latency)과 처리량(throughput) 간의 트레이드오프가 생길 수 있다. 
  배치의 크기가 크면 > 단위 시간당 처리 메시지 많음 > 전송 시간 증가 
  데이터 압축 적용되어 전송 저장시 효율적이다.

스키마

스키마(schema) : 메시지의 구조 
 JSON이나 XML 형식 : 데이터 타입에 대한 지원이 부족 스키마 버전 간 호환성이 떨어진다.
 아파치 Avro : 하둡을 위해 개발된 직렬화 프레임워크. 데이터 직렬화 형식 제공 
                       메시지와 별도로 스키마 유지 관리하므로 스키마가 변경되어도 애플리케이션의 코드를 추가 하거나 변경할 필요가 없다.
                       신구버전간 호환성도 제공
일관된 데이터 형식이 중요하다. 메시지 쓰기와 읽기 작업을 분리해서 할 수 있기 때문에 
읽기 쓰기가 분리가 되지 않는 다면 데이터 형식 변경 시 읽기 애플리케이션이 먼저 업데이트 후 쓰기가 변경 되어야 한다.
카프카에서는 스키마를 공유 리포지터리(reepository)에 저장하여 사용할 수 있으므로 애플리케이션 변경 없이 메시지를 처리할 수 있다.

 

토픽과 파티션

토픽(topic)
 메시지 분류 기준(?)
 데이터베이스의 테이블, 파일 시스템의 폴더의 개념과 유사
 하나의 토픽은 여러개의 파티션으로 구성됨

파티션(partition)
 파티션은 하나의 로그에 해당 
 메시지는 파티션에 추가되는 형태로 수록
 맨 앞에서 맨 뒤까지 순서대로 읽힌다.

 하나의 토픽은 여러개의 파티션을 가진다. 토픽 : 파티션 = 1 : n
 메시지 처리 순서는 파티션 별로 유지 관리된다.
 추가되는 메시지는 파티션의 맨 끝에 수록된다.
 각 파티션은 서로 다른 서버에 분산 될 수 있다. > 하나의 토픽이 여러 서버에 걸처서 수평적으로 확장 될 수 있다.

 프로듀서(producer) : 데이터를 쓰는 것(?)
 컨슈머(consumer) : 데이터를 읽는 것
 스트림(stream) : 데이터를 프로듀서로부터 컨슈머로 이동되는 연속적인 데이터. 오프라인으로 처리하는 하둡과 대비된다.

프로듀서와 컨슈머

프로듀서(producer) : 메시지를 생성(쓴다). 다른 발행/구독 시스템에서는 발행자 또는 작성자라고도 한다.
 데이터가 어느 파티션에 쓰여지는지 관여하지 않는다. *특정 파티션에 쓸 경우 메시지 키와 파티셔너(partitioner)를 사용

 컨슈머(consumer) : 메시지를 읽는다. 다른 발행/구독 시스템에서는 구독자 또는 독자라고도 한다.
  하나 이상의 토픽을 구독하여 메시지가 생성된 순서로 읽는다.
  메시지의 오프셋을 유지하여 읽는 메시지의 위치를 알 수 있다. 

 오프셋 : 메시지 읽는 위치를 가지고 있는 메타데이터. 메시지가 생성될 때 카프카가 추가해준다.
  각 파티션 별로 오프셋을 가지고 있다. 마지막에 읽은 위치를 가지고 있으므로 컨슈머가 읽기를 중단 했어도 언제든 다음 메시지 부터 읽을 수 있다. 

 컨슈머 그룹 : 한 토픽을 소비하기 위해 같은 그룹의 여러 컨슈머가 동작한다. 한 토픽은 하나의 컨슈머만 소비할 수 있다.
 각 컨슈머가 특정 파티션에 대응되는 것을 소유권(ownership) 이라 한다.

 이를 이용해 대량의 메시지를 갖는 토픽을 소비하기 위해 컨슈머를 수평적으로 확장 할 수 있다.
 한 컨슈머가 자신의 파티션 메시지를 읽는데 실패 하더라도 소유권 재조정으로 다른 컨슈머가 해당 파티션을 읽을 수 있다.

브로커와 클러스터

브로커 : 하나의 카프카 서버 
 브로커는 프로듀서로부터 메시지를 수신하고 / 오프셋을 지정한 후 / 메시지를 디스크에 저장한다.
 브로커는 컨슈머로의 파티션 읽기 요청에 응답하고 / 디스크에 수록된 메시지를 전송한다.
 브로커는 초당 수천개의 토픽과 수백만 개의 메시지를 처리할 수 있다.

브로커는 클러스터(cluster)의 일부 
 여러개의 브로커가 클러스터 하나.
 그중 하나의 브로커가 컨트롤러의 역할을 수행한다.
 컨트롤러는 다른 브로커에게 담당할 파티션을 할당과 정상 동작 하는지 모니터링 한다.

 각 파티션은 클러스트의 한 브로커가 소유. 그 브로커를 리더(leader)라고 한다.
 파티션이 여러개의 브로커가 동시에 소유할 수 있는데 이 때는 파티션이 복제(replication)된다. 
 이 경우 파티션의 메시지는 중복으로 저정되고, 관련 브로커가 장애가 나면 다른 브로커가 소유권을 넘겨 받아 처리 할 수 있다.

각 파티션을 사용하는 모든 컨슈머와 프로듀서는 파티션 리더에 연결해야 한다.

보존(retention) : 일정 기간 메시지를 보전하는 것. 카프카의 핵심 기능 중 하나.
 카프카 브로커는 일정 기간 또는 토픽 크기를 설정하여 메시지를 보존 할 수 있다.
 설정한 한도 값에 도달하면 최소한의 데이터가 유지되도록 만료 메시지들이 삭제된다.
 각 토픽 별로 보존 설정을 다르게 할 수 있다. 예를들어 A 토픽은 7일 , B 토픽은 10시간 보존으로 설정.

다중 클러스터

 카프카를 여러개 설치하여 다중 클러스터 이용할 수 있다.
 장점으로는 
  데이터 타입에 따라 구분해서 처리할 수 있음
  보안 요구사항을 분리해서 처리할 수 있음
  재해 복구를 대비한 다중 데이터센터를 유지할 수 있음
카프카 클러스터의 복제 메커니즘은 다중 클러스터가 아닌 단일 클러스터에만 동작하도록 설계되었다.
따라서 다중 클러스터를 지원하기 위해 카프카에는 미러메이커(MirrorMaker)라는 도구가 포함되어 있다.
미러메이커는 컨슈머와 프로듀서이며 각 미러 메이커는 큐로 연결된다.

카프카를 사용하는 이유 

1. 다중 프로듀서 
 여러 클라이언트가 많은 토픽을 사용하거나 같은 토픽을 사용해도 메시지를 처리 할 수 있다. 따라서 여러 프론트엔드 시스템으로부터 데이터를 수집하고 메시지 일관성을 유지하는데 이상적이다.

2. 다중 컨슈머
 많은 컨슈머가 상호 간섭 없이 어던 메시지 스트림도 읽을 수 있게 지원한다.

3. 디스크 기반의 보존
 카프마 보존 옵션에 다라 디스크에 보존된다. 따라서 읽기 실패하더라도 데이터 유실에 위험이 없다. 

4. 확장성 
 확장성이 좋아 어떤 크기의 데이터도 쉽게 처리할 수 있다.

5. 고성능
 프로듀서, 컨슈머, 브로커 모두 대용량 메시지 스트림을 쉽게 처리할 수 있도록 확장될 수 있다.

이용사례
 활동 추적 
   사용자 활동추적을 위해 링크드인에서 최초 설계된 것이 카프카다.
   해당 사이트의 페이지 뷰와 클릭 기록 될 수있다. 
  하다 이상의 토픽으로 생성되어 카프카에 저장된 후 백엔드 애플리케이션에서 소비된다. 

메시지 전송