ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 카프카 프로듀서
    카테고리 없음 2024. 2. 26. 21:35

    [ 목차 ]

      acks 옵션 

      프로듀서가 전송한 데이터가 카프카 클러스터에 얼마나 신뢰성 높게 저장할지 지정할 수 있다.

      0, 1, all(-1) 값을 가질  수있다. 

      복제 개수가 1인 경우 acks 옵션에 따른 성능 변화는 크지 않다. 

      그러나 안정적 운영을 위해 대부분 복제 개수가 2 이상인 경우가 많다.

       

      acks=0

      프로듀서가 리더 파티션으로 데이터를 전송했을 때 리더 파티션으로 데이터가 저장되었는지 확인하지 않는다는 뜻이다. 

      리더 파티션은 데이터가 저장된 이후에 데이터가 몇 번째 오프셋에 저장되었는지 리턴하는데,

      acks가 0으로 설정되어 있다면 프로듀서는 리더 파티션에 데이터가 저장되었는지 여부에 대한 응답 값을 받지 않는다. 

      retries 설정을 해도 전송하자마자 성공으로 간주해 재전송할 일이 없다. 

      네트오크 오류, 브로커 이슈 등으로 데이터 유실되더라도 지속적으로 데이터를 보내기 때문에 전송 속도는 1, all 로 설정했을 때보다 빠르다. 데이터 유실보다 전송 속도가 중요한 경우 사용할 수 있는 옵션이다. 

       

      acks=1 

      프로듀서가 리더 파티션에만 정상적으로 적재되었는지 확인한다. 

      리더 파티션에 저장되었더라고 복제 개수가 2 이상인 경우 팔로워 파티션에 동기화되지 않을 수 있는데, 팔로워 파티션이 복제하기 전에 리터 파티션이 있는 브로커에 장애가 발생하면 동기화되지 못한 일부 데이터가 유실될 수 있기 때문이다. 

       

      acks=all or asks=-1

      프로듀서가 리터 파티션, 팔로워 파티션에 모두 정상 적재되었는지 확인한다. 0또는 1보다 속도가 느리다. 

      acks 로 all로 설정할 경우에는 토픽 단위로 설정 가능한 min.insync.replicas 옵션값에 따라 데이터 안정성이 달라진다. 

      all 옵션은 모든 파티션이 아닌 ISR 에 속한 파티션을 의미한다, min.insync.replicas 은 프로듀서가 리더/팔로워 파티션에 데이터가 적재되었는지 확인하기 위한 최소 ISR 그룹의 파티션 개수이다. min.insync.replicas 을 1로 하면 처음 적재되는 파티션이 리더 파티션이기 때문에 acks 1과 동일하게 동작한다. 

      min.insync.replicas 은 복제 개수를 고려해 설정해야 한다. 브로커 개수가 설정값보다 작은 경우 프로듀서가 더는 데이터를 전송할 수 없기 때문이다. NotEnoughReplicasException, NotEnoughReplicasAfterAppendException 이 발생해 더는 토픽으로 데이터를 전송할 수 없다. 

      브로커와 같은 수를 설정할 경우에도, 카프카 클러스터 버전 업그레이드와 같은 상황이 발생하면 브로커는 롤링 다운 타임이 생기는데, 브로커 1대라도 중산되면 프로듀서가 데이터를 추가할 수다 없다. 

      상용에서 브로커 3대 이상을 묶어 클러스터를 이용하는데, 프로듀서가 데이터를 가장 안정적으로 보내려면 토픽의 복제 개수는 3, min.insync.replicas 는 2로 설정하고 프로듀서는 acks 를 all 로 설정하는 것을 추천한다. 

       

       

       

      멱등성(Idempotence) 프로듀서 

      동일 데이터를 여러 번 전송해도 카프카 클러스터에 단 한 번만 저장한다.

      기본 프로듀서는 at least once 로 유실은 없지만 중복 저장이 발생할 수 있다.

      프로듀서가 보내는 데이터 중복 적재를 막기 위해 0.11.0 이후 버전부터는 enable.idempotence=true 로 하면 멱등성 프로듀서로 동작하며 단 한 번만 전달된다. 기본값은 false 이다. 

       

      데이터를 브로커로 전달할 때 pid, sequence number 가 추가된다.  그럼 이 정보들을 확인해 동일한 메세지는 다시 적재하지 않는다.

      주의할 점은 동일한 세션에 대해서만 정확히 한 번 전달을 보장한다. 동일한 세션이란 pid 의 생명주기를 의미한다. 

      애플리션이션을 재시작할 때 pid 가 달라지므로, 브로커 입장에서 다른 데이터를 보냈다고 판단하고 저장하기 때문에 

      장애가 발생하지 않는다는 것을 전제로 1번만 저장하는 것을 보장 한다.

      idempotence 설정을 하면 관련있는 retries 나 ack 가 Integer.Max_Value, all 로 자동 설정된다. 적어도 한 번 이상 브로커에 보내고 단 한번만 저장되는 것을 보장하기 위해서다. 

      seq 가 다르게 되면 OutOfSequenceException 에러가 발생할 수 있다. 이. 오류는 브로커가 예상한 시퀀스 넘버와 다른 번호의 데이터의 적재 요청이 왔을 . 때발생한다. 이 에러가 발생했을 경우 시퀀스 넘버의 역전현상이 발행할 수 있기 때문에 순서가 중요한 데이터를 전송하는 프로듀서는 해당 exeption 발생했을 경우 대배 방안을 고려해야한다.

       

      트랜잭션 프로듀서 

      다수의 파티션에 데이터 저장 시 모든 데이터의 원자성을 보장하기 위함이다. all or nothing.

      원자성을 만족한다는 것은 다수의 데이터를 동일 트랜잭션으로 묶어 전체 데이터를 처리하거나 하지 않는다는 것이다.

      기본적으로 컨슈머는 프로듀서가 보내는 데이터가 파티션에 쌓이는 대로 모두 가져가 처리하는데, 트랜잭션으로 묶인 데이터를 브로커에서 가져갈 때는 다르게 동작하도록 설정할  수있다.

      enable.idempotence=true 와 transactional.id='string' 을 설정하면 트랜잭션 프로듀서로 동작한다.

      consumer 쪽에서는 isolation.level=read_commited 를 설정하면 트랜잭션으로 처리 완료된 데이터만 읽고 쓴다. 

       

      트랜잭션은 파티션의 레코드로 구분한다.

      트랜잭션 프로듀서는 사용자가 보낸 데이터를 레코드로 파티션에 저장할 뿐만 아니라 트랜잭션의 시작과 끝을 표현하기 위해 트랜잭션 레코드를 하나 더 보낸다. 

      트랜잭션 컨슈머는 파티션에 저장된 트랜잭션 레코드를 보고 트랜잭션이 완료되었음을 확인하고 데이터를 가져간다. 

       

      출처: 아파치 카프카 애플리케이션 프로그래밍 with 자바 

      반응형
    Designed by Tistory.