카프카 기본 개념

출저 : 네하 나크헤데, 그웬 샤피라, 토드 팔리노. "카프카 핵심가이드" .제이펍.2018년 

 

Chapter1

카프카란?

• 분산 커밋 로그
• 분산 스트리밍 플랫폼
• 데이터를 지속해서 저장하고 읽을 수 있음
• 파일 시스템이나 데이터베이스 커밋 로그는 시스템의 상태를 일관성 있게 유지할 수 있도록 모든 트랜잭션을 지속적으로 기록하는 기능
• 데이터 분산처리
• for 시스템 장애에 대비, 확장성에 대한 성능 저하 방지

+) 매트릭(metric)

• 시스템이나 애플리케이션의 성능이나 상태를 모니터링 하기 위한 측정 지표이며 측정치

 

메시지와 배치

메시지

• 메시지 : 데이터의 기본 단위 (.= db의 행이나 레코드)
• 키 : 메타데이터 
• 둘다 바이트 배열의 데이터로 간주해 특정 형식이나 의미를 가지지 않음
• +) 메타데이터 
• 데이터에 대한 데이터
• 어떤 목적을 가지고 만들어진 데이터
• 메시지 데이터는 ‘토픽’으로 분류된 ‘파티션’에 수록
• 이때 데이터를 수록할 파티션을 결정하기 위해 일정한 해시 값으로 키를 생성
• 같은 키값을 가진 메시지는 같은 파티션에 수록

배치(batch)

• 효율성을 위해 여러개의 메시지를 모아 배치 형태로 파티션에 수록
  • 어떤것을 얻으려면 다른걸 잃게됨
• 네트워크로부터 매번 각 메시지를 받아서 처리 하는 부담을 줄임
• 단점 : 대기 시간(latency)과 처리량(throughput) 간의 트레이드오프 생김
• +) 트레이드오프? 
• 배치의 크기가 클수록 단위 시간당 처리 될 수 있는 메시지는 많아지지만 각 메시지의 전송시간은 더 길어짐
• 데이터 압축이 적용 됨으로 더 효율적인 데이터 전송과 저장 능력을 제공 

 

스키마

• 메시지의 구조를 나타냄
• 메시지의 스키마로 사용가능한 표준 형식
• Json, XML
• 단점 : 강력한 데이터 타입에 대한 지원 부족, 스키마 버전 간의 호완성 떨어짐
• => 아파치 Avro 
  • 스키마가 변경되더라도 애플리케이션의 코드를 추가하거나 변경할 필요 없음
• 하둡을 위해 개발된 직렬화(serialization) 프레임 워크
• 데이터를 직렬화 하는 형식 제공
• 메시지와는 별도로 스키마를 유지 관리
• 강력한 데이터 타입을 지원하며 스키마 신구버전 간의 호환성도 제공
• 메세지 쓰기와 읽기 작업을 분리해서 할 수 있기 때문에 일관된 데이터 형식이 중요
• 잘 정의된 스키마를 공유 repository에 저장하여 사용할 수 있음으로 애플리케이션 변경없이 메시지를 처리할 수 있음

 

토픽과 파티션

 토픽

• .= db의 테이블이나 파일 시스템의 폴더
• 하나의 토픽은 여러개의 파티션으로 구성

 파티션 

• ‘커밋 로그’ 데이터의 관점으로 보면 하나의 로그에 해당
• 메시지는 파티션에 추가되는 형태로만 수록되며, 맨 앞부터 제일 끝까지의 순서로 읽힘
• 하나의 토픽은 여러개의 파티션을 갖지만, 메시지 처리 순서는 파티션별로 유지 관리
• 각 파티션은 서로 다른 서버에 분산 가능 
• 하나의 토픽이 여러 서버에 걸쳐 수평적으로 확장 가능
• 단일 서버로 처리 할때 보다 성능 우수

 스트림

• 파티션의 개수와 상관없이 하나의 토픽 데이터로 간주
• 프로듀서(데이터를 씀)에서 컨슈머(데이터를 읽음)로 이동되는 연속적인 데이터
• 실시간으로 메세지를 처리할때 주로 사용
• <-> 하둡 (실시간이 아닌 오프라인으로 대량 데이터 처리)

 

프로듀서와 컨슈머

프로듀서

• 새로운 메세지를 생성 (.=발행자 / 작성자) 라고 부름
• 메세지는 특정 토픽으로 생성됨
• default : 프로듀서는 메세지가 어느 파티션에 수록되는지 관여하지 않음
• 프로듀서가 특정 파티션에 ‘메세지키’와 ‘파티셔너’를 사용해 메시지를 직접 쓰기 가능
• 파티셔너? 
  • 키의 해시 값을 생성하고 그것을 특정 파티션에 대응시킴으로서 지정된 키를 갖는 메시지가 항상 같은 파티션에 수록되게 함
• 프로듀서는 나름의 커스텀 파티셔너를 갖고 다른 규칙 / 알고리즘에 따라 메시지가 파티션에 대응되게 할 수도 있음

컨슈머

• 메세지를 읽음 ( .= 구독자 / 독자)
• 하나이상의 토픽을 구독하여 메시지가 생성된 순서로 읽음 
• 메시지의 오프셋(offset)을 유지하여 메시지의 위치를 알 수 있음
• 오프셋?
• 메타데이터
• 지속적으로 증가하는 정수값으로 메시지 생성시 카프카에서 추가해줌
• 파티션에 수록된 각 메시지는 고유한 정수값을 가짐
• 각 파티션에서 마지막에 읽은 메시지의 오프셋을 주키퍼나 카프카에서는 저장하고 있으므로 컨슈머가 메시지 읽기를 중단했다가 다시 시작하더라도 언제든 그다음 메시지부터 읽기 가능
• 컨슈머 그룹
• 컨슈머는 컨슈머 그룹의 멤버로 동작 
• 하나이상의 컨슈머로 구성되며 한 토픽을 소비(읽고 처리)하기 위해 같은 그룹의 여러 컨슈머가 함께 동작
• 한 토픽의 각 파티션은 하나의 컨슈머만 소비 가능 / 하나의 컨슈머는 다수의 파티션을 소비 할 수 있음
• 파티션 소유권(ownership)
  • 각 컨슈머가 특정 파티션에 대응되는 것
• 다량의 메시지를 갖는 토픽을 소비하기 위해 컨슈머를 수평적으로 확장 가능
• 한 컨슈머가 자신의 파티션 메시지를 읽는데 실패하더라도 같은 그룹의 다른 컨슈머가 파티션 소유권을 재조정받은 후 실패한 컨슈퍼의 파티션 메시지를 대신 읽을 수 있음

 

브로커와 클러스터

브로커

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

클러스터

• 브로커는 클러스터의 일부로 동작하도록 설계
• 클러스터 컨트롤러
• 클러스터에 속한 여러개의 브로커 중 하나는 자동으로 선정
• 클러스내의 각 브로커에게 담당 파티션을 할당
• 브로커들이 정상적으로 동작하는지 모니터링 하는 관리 기능
• 파티션 리더
• 각 파티션은 클러스터의 한 브로커가 소유
• 이때, 해당 브로커를 이르는말
• 같은 파티션이 여러 브로커에 할당 되는것도 가능하며 이는 해당 파티션이 복제됨 
• 해당 파티션의 메세지는 중복으로 저장
• 관련 브로커 장애시 다른 브로커가 소유권을 인계 받아 그 파티션 처리
• 각 파티션을 사용하는 모든 컨슈머와 프로듀서는 파티션 리더에 연결해야함

 

보존

• 일정 기간 메시지를 보존
• 지정된 토픽 크기가 될때가지 보존
• => 지정한 기간, 크기에 도달하면 expire
• 토픽마다 보존 설정 다르게 지정 가능
• for 메시지가 유용할때만 보존되도록 
• ex ) 지속적인 메시지 유지가 필요한 토픽은 7일 애플리케이션 성능 관련 메트릭으로 저장한 토픽은 수시간만
• 토픽은 압축 로그(log compacted) 설정으로 구성 
• 같은 키를 갖는 메시지들은 가장 최신 것만 보존 
• 마지막으로 변경된 것이 중요한 로그 데이터에 유용

 

다중 클러스터

• 장점
• 이때는 메시지가 데이터 센터간 복제되어 온라인 애플리케이션에서는 사용자의 처리 결과를 양쪽 사이트 모두에서 사용가능 
• 데이터 타입에 따라 구분해서 처리
• 보안 요구사항을 분리해서 처리 
• 재해 복구를 대비한 다중 데이터센터 유지
• 여러 사이트에서 수집된 모니터링 데이터를 분석/보안 시스템이 운영되는 센터로 집중시켜 처리
• 미러메이커
• 카프카 클러스터의 복제 메커니즘은 다중 클러스터가 아닌 단일 클러스터에만 동작
• 다중 클러스터를 지원하는 도구
• 근본적으로 카프카의 컨슈머와 프로듀서이며 각 미러메이커는 큐로 상호 연결
• 하나의 카프카 클러스터에서 소비된 메시지를 다른 클러스터에서 사용 할 수 있도록 생성 
• 두 개의 로컬 클러스터에서 집중(aggregate) 클러스터로 메시지를 모은 후 다른 데이터센터로 복사

카프카를 사용하는 이유 

 

다중프로듀서 

• 여러 클라이언트가 많은 토픽을 사용하거나 같은