책

카프카의 ‘정확히 한 번’ 의미 구조는 멱등적 프로듀서(idempotent producer)와 트랜잭션 의미 구조의 조합으로 이루어진다.멱등적 프로듀서: 프로듀서 재시도로 인해 발생하는 중복을 방지트랜잭션 의미 구조: 스트림 처리 애플리케이션에서 ‘정확히 한 번’ 처리를 보장 멱등적 프로듀서DB에서 아래 구문은 몇 번을 호출하든 간에 x는 18이기 때문에 멱등적이라고 할 수 있다.UPDATE t SET x=18 where y=5 가장 고전적인 카프카에서 재시도로 인한 메시지 중복 예시파티션 리더가 프로듀서로부터 레코드를 받아서 팔로워들에게 성공적으로 복제했지만 프로듀서에게 응답을 보내기 전, 파티션 리더가 있는 브로커에 크래시가 발생한 경우프로듀서 입장에서는 응답을 받지 못한 채 타임아웃이 발생하고, 메..

카프카는 어떻게 신뢰성을 보장할까? 1️⃣ 카프카는 파티션 안의 메시지들 간에 순서를 보장한다.메시지 A 다음에 B가 쓰여졌다면 동일한 프로듀서가 동일한 파티션에 썻을 경우 B의 오프셋이 A보다 큰 것을 보장한다. 2️⃣ 클라이언트가 쓴 메시지는 모든 in-sync replica의 파티션에 쓰여진 뒤에야 commit된 것으로 간주한다.굳이 디스크에 flush될 필요까지는 없으며 프로듀서의 commit 정책을 지정할 수 있다. (acks)완전히 commit된 다음 응답리더에게 쓰여진 다음 응답네트워크로 전송된 다음 바로 응답 3️⃣ commit된 메시지들은 최소 1개의 작동 가능한 replica가 남아 있는 한 유실되지 않는다. 4️⃣ 컨슈머는 commit된 메시지만 읽을 수 있다.메시지를 저장하는 데 있..

아파치 주키퍼를 사용하는 이유카프카는 현재 클러스터의 멤버인 브로커들의 목록을 유지하기 위해서다.각 브로커는 브로커 설정 파일에 정의되었거나 아니면 자동으로 생성된 고유한 식별자를 가진다.브로커 프로세스는 시작될 때마다 주키퍼 Ephemeral 노드의 형태로 ID를 등록한다.컨트롤러를 포함한 카프카 브로커들과 몇몇 생태계 툴들은 브로커가 등록되는 주키퍼의 /brokers/ids 경로를 구독함으로써 브로커가 추가/제거 될 때마다 알림을 받는다.ID는 중복되지 않으며, 중복된 값이 추가된다면 동일한 브로커 ID를 갖는 ZNode가 있기 때문에 실패하며 에러가 발생한다.더보기ZNode의 종류는 영속 종류에 따라 다음과 같이 구분된다. (참조)Persistent Nodes(영구 노드) : 명시적으로 삭제되기 전..

AdminClient 개요AdminClinet.createTopics메서드는 토픽이 생성될 때 까지 기다리거나, 생성 상태를 확인하거나 토픽이 생성된 뒤 토픽 설정을 가져올 수 있다.카프카의 각 메서드 요청을 컨트롤러로 전송한 뒤 바로 1개 이상의 Future 객체를 리턴한다. 카프카 컨트롤러부터 브로커로의 메타데이터 전파는 비동기적으로 이루어지기에 AdminClient가 전달하는 Future 객체들은 컨트롤러의 상태가 완전히 업데이트 된 시점에서 완료된 것으로 간주한다. 즉, 모든 브로커가 전부 다 새로운 상태에 대해 알고 있지 못할 수 있다.토픽에 최신 상태를 전달 받지 않은 브로커에 의해 처리될 수 있다.일관성을 지키기 위해 최종적으로 모든 브로커는 모든 토픽에 대해 알게 되어 동기화 처리가 되겠지..

카프카 컨슈머: 개념구독한 토픽들로부터 메시지를 받기 위해 KafkaConsumer를 사용하는데 해당 API 대해서 알아보기 전에 컨슈머와 컨슈머 그룹에 대해서 이해하자 컨슈머애플리케이션은 컨슈머 객체(KafkaConsumer) 인스턴스를 생성하고 해당 토픽을 구독하면서 메시지를 받게된다.컨슈머가 메시지를 읽는 속도보다 프로듀서가 더 빠르게 메시지를 쓰는 경우 처리가 계속 뒤로 밀리기 때문에 토픽으로부터 데이터를 읽어오는 작업을 확장할 수 있어야 한다. 컨슈머 그룹동일한 컨슈머 그룹에 속한 여러 개의 컨슈머들이 동일한 토픽을 구독할 경우 각각의 컨슈머는 해당 토픽에서 서로 다른 파티션의 메시지를 받게된다. 컨슈머를 추가함으로써 단위 컨슈머가 처리하는 파티션과 메시지의 수를 분산시키는 규모 확장 방식이다...