hyunjuuun.dev

Topic replication factor 토픽은 replication factor를 가진다. 보통 2와 3 정도로 설정하며 3으로 설정하는 경우가 가장 흔하다. 이를 통해 카프카 서버(브로커)가 다운되었을 때 또 다른 브로커에 있는 데이터 사본을 통해 작업을 수행할 수 있게 된다. ex) Topic-A, 2개의 파티션, 복제 계수 2의 브로커 리더 파티션 1개의 브로커가 파티션 리더 역할을 수행한다. 프로듀서는 파티션의 리더인 브로커에만 데이터를 전송할 수 있다. 리더 브로커가 아닌 브로커들은 리더 브로커의 데이터를 복제한다. 이 때 리더 브로커의 데이터를 복제한 레플리카를 ISR이라 한다. (in-sync replica) (반대로는 out-of-sync replica) 리더 파티션의 기본 동작 기본..

Kafka Broker 카프카 클러스터는 다수의 카프카 브로커로 구성된다. 브로커는 서버를 의미한다. 카프카 브로커는 Integer 타입의 ID로 식별된다. 각각의 브로커는 특정한 토픽 파티션을 가진다. 데이터가 모든 브로커에 걸쳐 분산된다. 클러스터에 있는 모든 브로커를 미리 알고 있을 필요는 없다. 하나의 브로커에 연결하면 클라이언트가 자동으로 나머지에 연결된다. 브로커 개수는 3개 정도로 시작하는 것이 좋으며 여러 개로 설정 가능하다. 예시를 통해 브로커와 토픽의 관계를 이해해보자. 3개의 파티션으로 이루어진 토픽 A와 2개의 파티션으로 이루어진 토픽 B가 있다. 토픽 파티션은 순서에 상관 없이 모든 브로커에 걸쳐 분산되었다. (수평적 스케일링) 파티션과 브로커를 더 추가하면 더 많은 데이터가 전체..

앞서 토픽에 데이터를 보내는 프로듀서에 대해 알아보았으니 이제 토픽으로부터 데이터를 읽는 역할을 수행하는 컨슈머에 대해 알아보자. 카프카 브로커가 컨슈머에 데이터를 push 하는 것이 아니라 컨슈머가 데이터를 pull 해온다. 하나 이상의 파티션으로부터 데이터를 읽어오는 것도 가능하다. 위처럼 파티션으로부터 데이터를 읽어와야 하는 컨슈머들은 자동적으로 어떤 카프카 브로커(서버)로부터 데이터를 읽을지 알고 있다. 파티션으로부터 오프셋에 따라 데이터를 순차적으로 읽어온다. Consumer Deserializer 컨슈머는 메시지를 읽고 Kafka로부터 받은 바이트를 객체나 데이터로 역직렬화한다. 컨슈머에서 역직렬화하기 위해서는 프로듀서에서 해당 토픽을 저장할 때 어떠한 형식의 Serializer인지에 따라 알..

Producer 카프카 토픽 내 파티션으로 데이터를 전송하는 역할을 수행한다. 프로듀서는 토픽 내 어떤 파티션으로 데이터가 전송될 지를 미리 알고 있다. 장애가 발생했을 경우 자동적으로 대응한다. (추후 학습) Message key 프로듀서는 생성하는 카프카 메시지에 메시지 키를 설정 할 수 있다. (optional) 메시지 키가 존재하지 않는 경우(null인 경우) 라운드 로빈 방식으로 파티션에 데이터를 전달한다. 키가 존재하는 경우 같은 키를 가진 데이터들은 같은 파티션으로의 전달을 보장받는다. (hashing) Kafka Message 카프카 메시지는 아래와 같은 정보들로 구성된다. Kafka Message Serializer 프로듀서로부터 입력값으로 직렬화 된 바이트만을 받고 컨슈머에게 출력값으로..

Topic Topic은 카프카 클러스터 내의 특정한 데이터 스트림을 의미한다. 하나의 Kafka cluster가 다수의 토픽을 가질 수 있다. ex)로그 토픽, 구매 토픽, 댓글 토픽 비유하자면 DB의 테이블이라고 할 수 있다. 테이블과 다르게 constraint은 존재하지 않는다. 카프카 토픽으로 무엇을 보내더라도 데이터에 대한 검증은 이루어지지 않는다. 클러스터 내의 토픽 간의 구분은 name을 통해 이루어진다. 다양한 메시지 포맷을 지원한다. Partition 토픽은 파티션으로 나뉜다. ex) 특정한 토픽이 [파티션 0, 파티션 1, 파티션 2] 3개의 파티션을 가질 수 있다. 토픽으로 보내진 메시지는 이러한 파티션들에게로 순차적으로 전달된다. 한 번 파티션에 저장된 메시지는 immutable하다...