책/카프카 핵심 가이드

카프카는 어떻게 신뢰성을 보장할까? 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) 인스턴스를 생성하고 해당 토픽을 구독하면서 메시지를 받게된다.컨슈머가 메시지를 읽는 속도보다 프로듀서가 더 빠르게 메시지를 쓰는 경우 처리가 계속 뒤로 밀리기 때문에 토픽으로부터 데이터를 읽어오는 작업을 확장할 수 있어야 한다. 컨슈머 그룹동일한 컨슈머 그룹에 속한 여러 개의 컨슈머들이 동일한 토픽을 구독할 경우 각각의 컨슈머는 해당 토픽에서 서로 다른 파티션의 메시지를 받게된다. 컨슈머를 추가함으로써 단위 컨슈머가 처리하는 파티션과 메시지의 수를 분산시키는 규모 확장 방식이다...

프로서 개요애플리케이션이 카프카에 메시지를 써야하는 상황들감사 혹은 분석을 목적으로 하는 사용자 행동 기록성능 매트릭 기록로그 메시지 저장 (ELK 스택에서 Filebeat Kafka output 설정등)스마트 가전 정보 수집다른 애플리케이션과의 비동기적 통신 수행임의의 정보 데이터베이스 저장 전 버퍼링아래는 카프카에 데이터를 전송할 때 수행되는 주요 단계들이다.카프카에 메시지를 쓰는 작업은 ProducerRecord객체를 생성함으로써 시작되며 토픽과 밸류 지정은 필수 사항이지만, 키와 파티션 지정은 선택사항입니다. ProducerRecord를 전송하는 API를 호출했을 때(send 메서드)프로듀서는 가장 먼저 키와 값 객체가 네트워크 상에서 전송될 수 있도록 직렬화해서 바이트 배열로 변환합니다. @A..