[Kafka 이론] 4. Kafka Producers

Kafka Producers

데이터를 담는 토픽이 있다. 토픽에 데이터를 기록하기 위해서는 Kafka 프로듀서를 작성해야 한다. 그렇게 되면 프로듀서가 토픽과 파티션에 데이터를 기록하게 된다.

• 프로듀서는 토픽과 파티션에 데이터를 전송하고 자기가 어떤 파티션에 기록하는지 미리 알고 있다. 그리고 카프카 브로커, 즉 카프카 서버가 그걸 갖고 있게 된다.

• 서버 끝에 있는 카프카가 결정하는것 아니다. 고로 기록할 파티션을 미리 결정하는건 프로듀서다.

• 카프카 서버의 어떤 파티션이 고정일 경우에는 어떻게 복구할지 프로듀서가 알게되고 프로듀서의 배후에서 많은 복구작업이 일어난다.

  

카프카 내부에서 일어나는 일들

• 로드 밸런싱

  • 프로듀서의 어떤 매커니즘에 따라 모든 파티션에 걸쳐 데이터를 전송하기 때문이다.

  • 토픽 안에 많은 파티션을 갖고 있고 각각의 파티션이 하나 또는 다수의 프로듀서로부터 메시지를 받게 되기 때문이며, 프로듀서는 메세지 안에 키를 갖고 있다.

    • 키를 추가하는건 선택사항이다.
    • 키는 원하는 형태로 지정할 수 있다. (문자열, 숫자, 바이너리 등등)
    • 만일 키가 null이라면 데이터가 라운드 로빈(프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위(Time Quantum)로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘) 방식으로 전송된다.

  • 동일한 키를 공유하는 모든 메세지들은 해싱 전략(어떤 키값으로 데이터의 저장위치를 직접 계산해 빠르게 탐색, 삭제, 저장하는 방법) 덕분에 항상 결국 동일한 파티션에 기록이 된다.

    

프로듀서가 생성한 카프카 메세지 형태

• 키 타입
• 값 타입
• 압축 타입
• 선택사항인 헤더 추가
• 메세지를 전송할 대상인 파티션과 오프셋
• 타임 스탬프가 있는데 시스템 또는 사용자가 설정한다.

카프카의 기술이 좋은 이유 (Kafka Message Serializer)

• 프로듀서로부터 입력값으로 직렬된 바이트만을 받고 출력값으로서 바이트를 컨슈머에게 전송

• 사용자가 메세지를 구성할 때 바이트형식이 아니기 때문에 메세지를 직렬화 해야한다. 바이트 형태로 변환해서 처리해야한다. 하지만 Kafka 프로듀서는 스마트하게 그 키 객체를 Serializer를 통해 직렬 바이트로 변환한다. 그러면 그 키의 바이너리 표현이 나오게 된다.

• 값 객체에 대해 StringSerializer를 지정하게 된다. 인스턴스에 표현된 Key와 Value의 직렬화가 다르게 표현되는데 이러한 바이너리로 표현된 키와 값으로 이루어진 메세지를 카프카로 전송할 수 있게 된다.

• 카프카 프로듀서에는 이런 변환을 도와주는 공통된 Serializer를 갖고 있다.

  String은 문자열의 JSON 표현도 포함하고, Int, Float, Avro, Protobuf 등 많은 메시지 Serializer를 찾아볼 수 있다.

  

아파치 카프카가 해싱하는 방법

• 아파치 카프카는 파티셔너라는게 있다. 해당 파티셔너는 코드에 대한 로직이고, 레코드 즉, 메세지를 받아서 그걸 전송할 대상인 파티션을 경정하는 코드다.

• send()를 하면 프로듀서 파티셔너 로직이 레코드를 확인하고 그걸 파티션에 지정한다.

• 키 해싱 프로세스는 파티션에 대한 키 매핑을 결정하는데 사용된다.

• 카프카 파티셔너에서 키들은 murmur2 알고리즘을 이용해서 해싱된다.

  

  • 키 바이트를 확인하고 mulmul2 알고리즘을 적용해서 타깃 파티션이 어떤 파티션인지 알아내게 된다.