04 프로듀서: 데이터 공급

4.1 예제

• 웹사이트가 고객을 위해 어떻게 작동하는지에 대한 사용자 피드백을 받는 애플리케이션이 있다고 해보자.
• 현재 사용자는 지원 계정이나 챗봇에 이메일을 생성하는 양식을 웹사이트에 제출한다.
• 지원 담당자가 받은 편지함을 열어 고객이 어떤 제안이나 문제를 겪었는지 확인한다.
• 이 이메일 전송 대신 카픜카 토픽에 쓰는 것으로 변경하면, 중요한 정보를 필요한 형식으로 추출할 수 있으며 다양한 방식으로 활용할 수 있다.
  • 소비하는 애플리케이션은 단일 프로토콜 형식에 묶이지 않고 데이터 작업에 스키마를 사용할 수 있다.

4.1.1 프로듀서 설명

• 프로듀서 작업에는 클러스터에 대한 메타데이터 가져오기가 포함된다.
• 프로듀서는 할당된 파티션의 리더 레플리카에만 쓸 수 있다.
• 사용자는 토픽 이름만 알고 있으므로, 이 메타데이터는 프로듀서가 쓸 브로커를 결정하는 데 도움이 된다.
• 감사메시지와 같이 순서가 필수적인 경우 'retries' 숫자를 3으로 설정하고, 'in.flight.requests.per.connection' 값을 1로 설정하고 ack를 all로 설정해야 한다.
• 동일한 메시지를 여러 번 보내더라도 메시지가 한 번만 생산되는 특성인 멱등성을 보장하기 위해서 enable.idempotence=true로 설정할 수 있다.

4.2 프로듀서 옵션

• 프로듀서 옵션은 쉽게 설정할 수 있다.
• 프로듀서는 전체 카프카 목록과 같이 필요한 대부분의 정보를 자체적으로 조회하여 작업을 시작한다.

중요한 프로듀서 구성

• acks: 메시지 전달이 성공하기 위한 프로듀서가 요구하는 복제 확인
• boostrap.servers: 시작 시 연결할 하나 이상의 카프카 브로커
• value.serializer: 값의 직렬화에 사용되는 클래스
• key.serializer: 키의 직렬화에 사용되는 클래스

4.2.1 브로커 목록 구성

• 토픽은 파티션으로 구성되어 있는데, 카프카는 토픽과 파티션의 위치를 알 수 있는 방법은 boostrap.servers를 통해 알 수 있다.
• 프로듀서는 이 브로커에 연결하여 클러스터에 있는 다른 브로커에 대한 데이터도 포함하는 필요한 메타데이터를 발견할 수 있다.

4.2.2 더 빨리(또는 안전하게) 처리하기

• 비동기 메시지 패턴은 대기열 유형의 시스템을 사용하는 한 가지 이유이다.
• 'acknowledgements'를 나타내는 'acks'를 통하여 프로듀서가 완료된 요청을 반환하기 전에 파티션 리더의 팔로워로부터 얼마나 많은 수신확인을 받아야 하는지를 제어한다.
• 0으로 설정되면 가장 낮은 대기 시간을 얻을 수 있지만, 안전한 배달은 희생해야 한다.
• all 또는 -1로 설정되면 배달 보장에서 가장 강력하다. 파티션 리더의 레플리카가 ISR의 전체 목록에 대해 복제 완료를 확인하기를 기다린다는 의미이다.
• 1로 설정하였을 때, 리더가 메시지를 팔로워 레플리카에 복사할 시간을 갖기 전 리더가 실패하게 된다면, 메시지는 손실될 수 있다.

4.2.3 타임스템프

• ProducerRecord 자바 객체를 프로듀서에게 전달할 때 자바 long 데이터 유형으로 사용자가 직접 전달하거나 현재 시스템 시간으로 전달할 수 있다.
• 메시지에 사용된 실제 시간은 이 값으로 유지되거나 or 브로커 타임스탬프일 수도 있다.
• message.timestamp.type 토픽 구성을 CreateTime으로 하면 클라이언트에서 설정한 시간이 사용되는 반면, LogAppendTime으로 설정하면 브로커 시간이 사용된다.
• 데이터는 로그에서 타임스탬프가 아닌 오프셋을 기준으로 정렬되기 때문에, 이전의 레코드보다 더 빠른 타임스탬프를 가진 레코드를 얻을 수도 있다.
  • 이는 전송 실패가 발생하고 첫번째 레코드의 재시도가 완료되기 전 더 늦은 타임스탬프가 있던 다른 메시지가 커밋된 경우 발생할 수도 있다.

4.3 요구사항에 대한 코드 생성

직렬화/역직렬화

• 같은 메시지에서 다른 직렬 변환기로 키와 값을 직렬화할 수 있다.
• 프로듀서가 값을 직렬화한 방법과 관련하여 컨슈머가 값을 역직렬화하는 방법에도 영향을 미친다.

이벤트 그룹화

• 일반적으로 동일한 키는 동일한 파티션에 할당하므로 올바른 키를 사용하면 동일한 스테이지 ID로 그룹화된다.
• 카픜카는 특정 파티션에 메시지를 보내는 기본 방법을 제공한다.
• 키가 없는 메시지의 기본값은 라운드 로빈 할당 전략이다.(2.4 버전 이전)
• 2.4 버전 이후는 키가 없을 경우 고정 파티션 전략을 사용한다.
• 데이터를 분할하는 방법 중 하나는 고유한 파티셔너 클래스를 작성하는 것이다. 클라이언트는 고유한 파티셔너를 구성하여 데이터를 쓸 파티션을 제어할 수 있다.
• 예를 들어, Critical, Major, Minor, Warning 이라는 네 가지 얼럿 수준이 있을 때, 컨슈머는 다른 얼럿을 처리하기 전 항상 크리티컬 얼럿을 읽어야 할 때, Partitioner 인터페이스를 구현하여 프로듀서가 쓰기를 원하는 특정 파티션으로 메시지를 보내도록 만들 수 있다.
• 데이터를 특정 파티션에 저장하고, 컨슈머가 특정 파티션에서만 크리티컬 얼럿을 의도적으로 받을 수 있으며, 다른 얼럿은 다른 파티션에서 처리할 수 있다.

4.3.1 클라이언트와 브로커 버전

• 카프카 브로커와 클라이언트 버전이 항상 일치할 필요는 없다.