개발블로그임다

컨슈머 주요 옵션 bootstrap.servers 카프카 클러스터의 주소 fetch.min.bytes (df: 1 bytes) 한번에 가져올 수 있는 최소 사이즈로, 만약 가져오는 데이터가 지정한 사이즈보다 작으면 요청에 응답하지 않고, 데이터가 누적될 때 까지 기다린다. fetch.max.wait.ms(df: 500sec = 0.5sec) : fetch.min.bytes에 설정된 데이터보다 데이터 양이 적은 경우 요청에 응답을 기다리는 최대시간을 설정 group.id: 컨슈머가 속한 컨슈머 그룹의 id enable.auto.commit (df: true) 백그라운드로 주기적으로 오프셋을 커밋할지 안할지 설정하는 옵션 auto.commit.interval.ms (df: 5000ms = 5sec) : 주기..

프로듀서 주요 옵션 bootstrap.servers 카프카 클러스터는 기본적으로 마스터가 없는 구조이므로 클러스터 내 모든 서버가 클라이언트의 요청을 처리 할 수 있다. 그러므로, 하나의 서버가 장애가 나도 클라이언트는 자동으로 다른 서버로 재접속 한다. acks(default: 1) 프로듀서가 토픽 혹은 파티션의 리더에게 메시지를 보낸 후 요청을 완료하기 전 ack의 수. 0인 경우 : 서버로부터 완료됬다는 ack를 기다리지 않음 1인 경우 : 리더에 데이터가 기록되었는지만 확인 all 또는 -1 인 경우 :: 리더 뿐만 아니라 모든 팔로워로부터 데이터 기록 응답을 기다림. buffer.memory(default: 33554432 byte) : 프로듀서가 카프카 서버로 데이터를 보내기 전, 잠시 대기하..

카프카 디자인의 특징 확장이 쉬운 분산 시스템 페이지 캐시 페이지 캐시는 메모리에 있고, 공유할 수 있기 때문에, 카프카 클러스터를 같은 시스템, 서버에 구축하는것이 좋다. 배치 전송 처리 카프카에서는 작은 I/O가 빈번하게 일어나기 때문에 이러한 I/O들을 묶어 배치로 처리하는 방식을 취한다.(ex: 메시지 4개를 모은 후 한번만 I/O 작업을 한다.) 카프카 데이터 모델 토픽의 이해 파티션의 이해 토픽을 분할한 것 EX) 4개의 토픽을 보내는 상황에서 파티션이 1개라면, A->B->C->D 순서로 보내기 때문에 총 4초가 걸리는 반면, 프로듀서와 파티션을 늘려서 4개의 프로듀서가 각각 1개의 파티션에 메시지를 보내면, 4개의 메시지가 보내진다고 해도 1초밖에 안걸리게 된다. 파티션 확장의 단점 파일 ..

카프카 관리를 위한 주키퍼 분산 시스템을 설계 하다보면, 가장 문제점 중의 하나가 분산된 시스템간의 정보를 어떻게 공유할것이고, 클러스터에 있는 서버들의 상태를 체크할 필요가 있으며 또한, 분산된 서버들간에 동기화를 위한 락(lock)을 처리하는 것들이 문제로 부딪힌다. 이러한 문제를 해결하는 시스템을 코디네이션 서비스 시스템 (coordination service)라고 하는데, Apache Zookeeper가 대표적이다. 이 코디네이션 서비스는 분산 시스템 내에서 중요한 상태 정보나 설정 정보등을 유지하기 때문에, 코디네이션 서비스의 장애는 전체 시스템의 장애를 유발하기 때문에, 이중화등을 통하여 고가용성을 제공해야 한다. ZooKeeper는 이러한 특성을 잘 제공하고 있는데, 그런 이유로 이미 유명한..

카프카의 탄생배경 기존 end-to-end 연결 방식의 아키텍처의 문제점 통합, 중앙화된 전송 영역이 없어 end-to-end 연결이 갈수록 복잡해지므로 하나의 프로세스에 여러 데이터 시스템을 확인 해야 한다. 데이터 파이프라인 관리의 어려움, end-to-end를 연결하는 연결선 마저도 end-to-end 마다 제각기 다른 방식으로 구현될 수 있어 복잡도가 증가, 추후에 통합데이터 분석을위해 파이프라인들이 연결되어야 할 때 문제 발생. 이러한 배경에서 카프카는 다음과 같은 목표를 달성하기 위해 탄생하였다. 프로듀서와 컨슈머의 분리 메시징 시스템과 같이 영구 메시지 데이터를 여러 컨슈머에게 허용 높은 처리량을 위한 메시지 최적화 데이터가 증가함에 따라 스케일 아웃이 가능하도록 한다. 카프카의 동작 방식과..