카프카 (Kafka)

데이터를 활요하기 위해서는, 데이터를 생성하는 소스 어플리케이션과 데이터가 최종 적재되는 타겟 어플리케이션을 연결해야하는데, 시간이 지날 수록 복잡도가 증가하면서, 소스 / 타겟 어플리케이션의 갯수가 점점 많아지고, 데이터 파이프라인 관리가 어려워짐

한 곳에 모아 처리할 수 있다.

  • fault tolerent (고가용성): 서버 장애 시 손실없이 복구
  • 낮은 지연(latency)과 높은 처리량(throughput)

카프카의 특징

  • 높은 처리량
    • 프로듀셔가 브로커로 데이터를 보낼 때, 브로커로부터 컨슈머가 데이터를 받을 때 배치 단위로 전송 가능, 네트워크 비용을 주림
    • 파티션 갯수 만큼 컨슈머 갯수를 늘려 데이터 처리량을 늘릴 수 있음
  • 확장성
    • 카프카 클러스터( = 여러개의 브로커)의 scale-out
  • 영속성
    • 전송받은 데이터를 파일 시스템에 저장
    • 운영체제 레벨에서 파일 I/O 성능 향상을 위해 페이지 캐시(page cache) 영역을 메모리에 따로 생성하여 사용
  • 고가용성
    • 카프카 클러스터는 3개 이상의 서버(브로커)로 운영
    • 다른 브로커에도 데이터 복제 (replication)

카프카의 스트림 데이터를 배치 데이터로 활용

  • 카프카의 레코드는 timestamp를 남김
  • 일종의 스냅샷 데이터 처럼 배치 데이터로 표현 가능

프로듀서

  • 토픽의 파티션으로 데이터를 보냄
  • 배치 형태로 보내어 네트워크 비용을 줄일 수 있음

토픽

카프카 클러스터 = 여러개의 브로커

  • 1개 이상의 파티션을 가질 수 있음
    • 여러개의 파티션은 데이터를 병렬 처리를 가능하게 함
    • 파티션 갯수만큼 컨슈머 개수를 늘려 데이터 처리량을 늘릴 수 있음
  • 파티션 (= 샤드의 개념): 일종의 queue 역할
  • 세그먼트 삭제 주기
    • retention.ms 세그먼트를 보유할 최대 기간. 기본값 7일
    • retention.bytes 파티션당 로그 적재 바이트 값. 기본값은 -1(지정하지 않음)
    • log.retention.check.interval.ms: 세그먼트가 삭제 영역에 들어왔는지 확인하는 간격. 기본 값은 5분
  • 세그먼트 삭제
    • 레코드 단위로는 개별 삭제 불가능
    • 세그먼트 단위로 삭제
    • 이미 적재된 데이터에 대해서 수정 불가능
  • 압축 정책
    • 일반적인 압축(compression)의 개념이라기 보다는 메시지 키 별로 해당 메시지 키의 레코드 중 오래된 데이터를 삭제하는 것
    • 키가 값을 경우, 같은 키를 가진 가장 최신의 데이터만 남김

브로커의 역할 - 복제(Replication)

  • 복제된 파티션은 리더와 팔로워로 구성
  • 보통 유실되면 안되는 데이터는 Replication 갯수를 3으로 씀 (리더 파티션 1개 + 팔로워 파티션 2개)
    • 토픽마다 Replication 갯수를 정할 수 있으뮤
    • 최대 브로커의 갯수만큼 Replcaiton 갯수를 늘릴 수 있음
  • 리더 파티션
    • 프로듀서 또는 컨슈머와 직접 통신
  • 리더 파티션의 오프셋과 팔로워 파티션의 오프셋을 비교하고 차이가 나는 경우 복제가 일어남

컨슈머

  • 토픽의 파티션으로 부터 데이터를 가저감
  • 토픽의 파티션으로 부터 데이터를 가져가도 데이터는 삭제되지 않음
  • subscribe(): 모든 파티션으로부터 데이터를 가저감
    • 파티션 갯수 만큼 컨슈머 갯수를 맞추는게 좋음
  • assign(): 특정 파티션으로부터 데이터를 가져감

컨슈머 그룹

  • 컨슈머 그룹으로 묶인 컨슈머들은 다른 컨슈머 그룹과 격리된 환경에서 운영 가능함
  • (데이터를 가져간다 해도 토픽의 데이터는 지워지지 않음)
  • 각각의 컨슈머 그룹은 서로 다른 목적을 가짐
    • 엘라스틱서치 컨슈머 그룹
    • 하둡 적재 컨슈머 그룹
  • 컨슈머 그룹 별로 리소스(= 컨슈머 갯수)를 다르게 가져갈 수 있음

메시지 브로커

데이터를 보내고, 처리하고, 삭제한다.

레디스 큐, 레빗엠큐

이벤트 브로커

  1. 이벤트 또느 메시지라 불리는 레코드를 딱 하나만 관리, 인덱스를 통해 개별 엑세스를 관리
  2. 업무상 필요한 시간동안 이벤트를 보전 할 수 있다.

이벤트 브로커의 큐에 저장 (마치 DB에 저장하듯이)

단일 진실 공급원 장애가 발생했을 때 장애가 일어난 지점부터 처리 가능 많은 양의 실시간 데이터를 효과적으로 처리할 수 있음 이벤트 기반 마이크로 서비스 아키텍쳐에서 중요한 역할

카프카. 키네시스