Chapter 7. 신뢰성 있는 데이터 전달

[hubtwork]

Chapter 7 Ownership : @kimsunhak

[iamzin]

신뢰성 있는 시스템을 구축하기 위해서는 트레이드 오프가 필요하다. 카프카는 트레이드 오프를 할 수 있도록 설정을 세밀하게 조절하여 신뢰성을 필요한 만큼 지정할 수 있도록 되어 있다.

• 같은 프로듀서가 쓴 동일 파티션 내의 메세지 순서
• 메세지가 in-sync replica의 파티션에 쓰인 후 커밋되었음을 판단
• 최소 1개의 replica가 살아있는 동안에는 커밋된 메세지들이 유실되지 않음
• 컨슈머는 커밋된 메세지들만 읽음

---

unclean.leader.election.enable 설정을 통해 out-of-sync 상태에서 Leader를 선출할 수도 있고, replica를 항상 in-sync 상태로 유지할 수도 있다. 앞에서 나왔던 auto.offset.reset 설정이 earliest이냐, latest이냐에 따라 중복 가능성이 달라지고 신뢰성을 보장하는 정도가 다르다. 여기에 더해서 enable.auto.commit와 auto.commit.interval.ms로 오프셋 커밋 설정을 조정할 수 있기도 하다. 신뢰성이 중요한 경우 모든 설정값에 대해 이해하고 이를 세밀하게 조정할 필요가 있는 것 같다. 하지만 이 때문에 생기는 중복 읽기라던지 유실이라던지 성능 저하라던지.. 적절한 비즈니스 상황에 맞게 선택해야 하는 점이 중요하다. Producer 같은 경우는 앞에서도 강조한 것처럼 acks 설정을 통해 조정한다. acks=0이라고 무조건 latency가 높다고 볼 순 없다. produce latency는 낮출 수 있지만, consumer가 놓칠 수 있으니 end to end latency가 좋아지지 않기 때문이다. DB에러 등으로 처리를 못하는 상황 같으면 pause()해서 추가 polling을 막거나 retry할 것을 다른 retry topic을 만들어서 거기에 쓰고 그것도 구독하는 등으로 해결할 수도 있다.

[kimsunhak]

Chapter 7. 신뢰성 있는 데이터 전달

7.1 신뢰성 보장 (카프카)

• 파티션 안의 메세지들 간 순서를 보장
  • 순차적으로 A, B 메세지가 쓰여지면, 동일한 파티션에 썻을 경우 B 오프셋이 A 보다 크다는걸 보장하게 되며, 컨슈머 역시 A를 읽고 B를 읽게 된다.
• 클라이언트가 쓴 메세지는 모든 in-sync replica 의 파티셔에 쓰여진 뒤 커밋 된 것으로 간주된다.
  • 메시지가 완전히 커밋된 후 응답이 올지, 리더에게 쓰여진 후 응답이 올지 아니면 네트워크로 전송된 후 바로 응답이 올지를 선택 가능하다.
• 커밋된 메세지들은 최소 1개의 작동 가능한 레플리카가 남아 있어야 유실되지 않는다.
• 컨슈머는 커밋된 메세지만 읽을 수 있다.

기본적으로 위에 나열된 방법으로 신뢰성을 보장 할 수 있지만 시스템 전체를 완전하게 신뢰성 있게 만들어 주지 못하여 트레이드 오프가 있고, 카프카는 트레이드 오프를 조정할 수 있도록 개발자 혹은 운영자가 설정 매개변수를 조절함으로써 어느 정도의 신뢰성이 필요한지를 결정 할 수 있도록 되어 있다.

7.2 복제

카프카의 복제 메커니즘은 파티션별로 다수의 레플리카를 유지한다는 특성과 함께 신뢰성 보장의 핵심이다.

복제 중요 부분

• Topic은 데이터 구성 요소인 파티션으로 이루어진다.
• 하나의 파티션은 하나의 디스크에 저장된다.
• 파티션에 저장된 이벤트들의 순서를 보장하며, 파티션은 온라인 상태거나 오프라인 상태일 수 있다.
• 각 파티션은 다수의 레플리카를 가질 수 있고, 그중 하나가 리더가 된다.
• 모든 이벤트들은 리더 레플리카에 쓰여지며, 리더 레플리카에서 읽혀진다.
• 리더가 동작 불가능 상태면 in-sync replica 중 하나가 새 리더가 된다.
• 레플리카는 파티션의 리더 레플리카이거나 아니면 다음 조건을 만족하는 팔로워 레플리카인 경우 in-sync replica 로 간주한다.
  • 주키퍼와 활성 세션이 있다.
  • 최근 10초 사이 리더로부터 메세지를 읽어왔다.
  • 최근 10초 사이에 리더로부터 읽어온 메세지들이 가장 최근 메세지이다. (랙이 없었던 적이 최소 한번은 있어햐 함)
• out-of-sync replica 상태가 되면, 리더 파티션의 최근 메세지까지 따라 잡으면 다시 in-sync replica가 된다.

❌주의 : in-sync replica 수가 줄어들면 파티션의 실질적인 복제 팩터가 줄어들면서 중단 시간이 길어지거나 데이터가 유실될 위험성이 높아진다.

7.3 브로커 설정

• 모든 토픽들을 제어할 수도 있고 토픽 단위에서 적용되어 특정 토픽의 작동을 제어 가능하다.

• 토픽 단위에서 신뢰성 트레이드 오프를 제어 할 수 있다는 것은 신뢰성이 필요한 토픽과 아닌 토픽을 같은 클러스터에 저장할 수 있음을 의미한다.

7.3.1 복제 팩터

중요하지 않은 데이터에 대해서는 복제 팩터를 3 미만으로 잡아 줘야한다.

토픽 단위 설정은 replication.factor, 자동으로 생선된 토픽들에 적용되는 브로커 단위 설정은 default.replication.factor

• 이미 존재하는 토픽일지라도 레플리카 재할당 툴을 사용해 레플리카를 추가 삭제할 수 있다. (복제 팩터 역시 변경 가능)
• 복제 팩터가 N이라고 할때 N-1개의 브로커가 중단되더라도 데이터를 읽고 쓰기가 가능하다.
  • 복제 팩터가 N이라는 것은 최소한 N개의 브로커가 필요할 뿐더러 N개의 복사본을 저장해야 하므로 트레이드 오프가 있다.
• 레플리카 위치가 중요하고, 랙 스위치 오작동으로 인한 사고를 방지하기 위해 브로커들을 서로 다른 랙에 배치한 뒤 broker.rack을 통해 랙 이름을 잡아 줄 것을 권장한다.

가용성 : 레플리카가 하나뿐인 파티션은 브로커를 재시작하면 작동 불능에 빠진다.

지속성 : 레플리카는 파티션 안의 모든 데이터의 복사본, 레플리카가 하나 뿐이고 디스크가 사용 불가능하면 파티션의 모든 데이터는 유실된다. (복사본이 많을수록 데이터 유실 가능성이 줄어든다.)

처리량 : 레플리카가 추가될 때마다 브로커간 트래픽이 증가한다. (처리량 감소)

종단 지연 : 레플리카가 많을수록 이들 중 하나가 느려짐으로써 컨슈머까지 느려질 가능성이 높아진다.

비용 : 레플리카가 많을수록 저장소와 네트워크에 들어가는 비용이 증가한다. (복제 팩터를 보통 2로 잡는데 3인 경우에 비해 가용성이 줄어듬)

7.3.2 언클린 리더 선출

해당 설정은 브로커 단위에서만 가능하고 매개변수 이름은 unclean.leader.election.enable 이고 기본값은 false 이다.

클린 리더 선출 : 파티션의 리더가 더 이상 사용 가능하지 않을 경우 in-sync replica 중 하나가 새 리더가 된다.

언클린 리더 선출 : out-of-sync replica 중 하나가 새 리더가 된다.

• out-of-sync replica 가 리더가 될 수 있도록 허용할 경우 데이터 유실과 일관성 깨짐의 위험성이 있다.
  • unclean.leader.election.enable = false 는 데이터 유실에 있어 가장 좋은 보장을 제공하는 만큼 가장 안전한 옵션

7.3.3 최소 인-싱크 레플리카

Topic, Broker 단위 모두 min.insync.replicas 설정에서 잡을 수 있다.

• 가용성과 일관성 둘 중에 하나를 골라야 할 수 있다.
• 커밋된 데이터를 레플리카에 쓰고자 한다면, in-sync-replica 최소값을 던 높게 잡아야 한다.
  • 만약 토픽당 3개의 레플리카가 있고 min.insync.replicas = 2 라면 producer 들은 3개의 레플리카 중 최소 2개가 in-sync 상태여야 파티션에 쓸 수 있다.
• Replica 3개 중 2 개의 레플리카가 작동 불능에 빠질 경우 브로커는 더이상 쓰기 요청을 받을 수 없어 NotEnoughReplicasException 을 발생한다.
  • 결론 : 읽기만 가능하다.
  • 해결방법 : 두 개의 사용 불능 레플리카 중 하나를 복구시킨 뒤 리더 레플리카의 상태를 따라잡아 in-sync 상태로 들어갈 때까지 기다려야 한다.

7.3.4 레플리카를 인-싱크 상태로 유지하기

클러스터의 민감도를 조절할 수 있는 브로커 설정을 가지고 있다.

• zookeeper.session.timeout.ms 를 통해 zookeeper와의 세션 타임아웃을 설정 가능하다.
• Replica.lag.time.max.ms 에 설정된 값을 통해 in-sync-replica의 레플리카가 리더로부터 데이터를 받지 않은 시간을 설정 가능하다.

7.3.5 디스크에 저장하기

세그먼트를 교체할 때, 재시작 직전에만 메세지를 디스크로 플러시하며, 그 외의 리눅스의 페이지 캐시 기능에 의존

• flush.messages 매개변수는 디스크에 저장되지 않은 최대 메세지 수 조절
• flush.ms 매개변수는 얼마나 자주 디스크에 메세지를 저장하는지 조절

7.4 신뢰성 있는 시스템에서 프로듀서 사용하기

가장 높은 신뢰성 설정을 브로커에 적용하더라도, 프로듀서 역시 신뢰성이 있도록 설정을 잡아주어야 한다. (데이터 유실 가능)

• 애플리케이션 개발자들이 신경써야 할 것
  • 신뢰성 요구 조건에 맞는 올바른 acks 설정
  • 설정과 코드 모두에서 에러를 올바르게 처리

7.4.1 응답 보내기

Producer 는 세 가지 응답 acknowledgement 모드 중 하나를 선택 가능하다.

• acks = 0
  • Producer가 네트워크로 메세지를 전송한 시점에서 메세지가 카프카에 성공적으로 쓰여진 것으로 간주
  • 직렬화될 수 없거나 네트워크 카드가 오작동할 경우 에러를 발겠지만, 파티션이 오프라인이거나, 리더 선출이 진행중이거나, 전체 카프카 클러스터가 작동 불능인 경우 에러가 발생하지 않는다.
  • 지연은 낮지만, 종단 지연이 개선되지는 않는다.
• acks = 1
  • 리더가 메세지를 받아서 파티션 데이터 파일에 쓴 직후 응답 또는 에러를 보낸다는 것을 의미
  • 클라이언트 응답이 간 상태에서 팔로워로 복제가 완료되기 전에 리더가 정지 또는 크래쉬 날 경우 데이터가 유실 될 수 있다.
  • 메세지를 복제하는 속도보다 리더에 쓸 수 있기 때문에 불완전 복제 파티션 이 발생할 수 있다.
• acks = all
  • 리더가 모든 in-sync replica가 메세지를 받아갈 때까지 기다렸다가 응답 또는 에러를 보낸다는 것을 의미
  • 브로커의 min.insync.replicas 설정과 함께, 이 설정은 응답이 오기 전까지 얼마나 많은 레플리카에 복제될 것인지를 조절
  • 가장 안전한 옵션이지만, 메세지가 완전히 커밋될 때까지 계속 메세지를 전송
  • Producer 지연이 가장 길어지는 옵션이기도 해서, in-sync replica가 메세지를 받을 때까지 기다린 뒤에야 해당 배치에 완료 표시를 하고 작업을 진행

7.4.2 프로듀서 재시도 설정하기

프로듀서 에러는 자동으로 처리해주는 에러, 라이브러리 사용하는 개발자들이 처리해야하는 에러 두개로 나뉜다.

• 메세지가 유실되지 않는 것이 목표일 경우
  • 프로듀서가 계속해서 메세지 전송을 재시도 하도록 설정
  • 재시도 수 = MAX_INT, delivery.timeout.ms 설정값을 최대로 잡아 준다.
  • ❌주의 : 메세지가 중복될 위험을 내포 (최소 한 번 저장되도록 보장할 수는 있지만, 정확히 한 번은 보장할 수 없다.)

7.4.3 추가적인 에러 처리

• 개발자들이 처리해야하는 에러
  • 메세지 크기에 관련되었거나 인가 관련 에러와 같이 재시도가 불가능한 브로커 에러
  • 메세지가 브로커에 전송되기 전에 발생한 에러 ( ex: 직렬화 과정에서 발생한 에러 )
  • 프로듀서가 모든 재전송 시도를 소진했거나, 재시도 과정에서 프로듀서가 사용하는 가용 메모리가 메세지로 가득 차서 발생하는 에러
  • 타임아웃
• ❌주의 : 만약 메세지 재전송이 에러 핸들러가 하는 일의 전부라면, 프로듀서의 재전송 기능을 사용하는 편이 낫다.

7.5 신뢰성 있는 시스템에서 컨슈머 사용하기

• 컨슈머는 일관성이 보장되는 데이터만 읽는다.

• 파티션으로부터 데이터를 읽어 올 때, 컨슈머는 메세지를 배치 단위로 읽어온 뒤 배치별로 마지막 오프셋을 확인한 뒤 브로커로부터 받은 마지막 오프셋 값에서 시작하는 다른 메세지 배치를 요청한다. (데이터를 올바른 순서로 읽어온다.)

• 읽고 있는 각 파티션에 대해 어디까지 읽었는지 저장해 둬야 해당 컨슈머나 다른 컨슈머가 재시작한 뒤에도 어디서 작업을 계속 해야할지 알 수 있다.

• 필수 : 오프셋이 언제 어떻게 커밋되는지에 대해 신경써야 한다

7.5.1 신뢰성 있는 처리를 위해 중요한 컨슈머 설정

신뢰성을 갖는 컨슈머를 설정하기 위한 속성은 네 개가 있다.

• group.id
  • 같은 그룹 내의 컨슈머들은 서로 다른 메세지를 읽는다.
• auto.offset.reset
  • 브로커에 없는 오프셋을 요청할 어떻게 해야 할지를 결정한다.
  • earliest : 파티션 맨 앞에서부터 읽기
  • latest : 파티션의 끝에서부터 읽기, 중복 처리는 최소화 하지만 메세지 누락 발생
• enable.auto.commit
  • 일정 시간에 맞춰서 커밋, 직접 커밋
  • 단점 : 메세지 중복 처리를 우리가 제얼할 수 없다는 점
• auto.commit.interval.ms
  • 오프셋을 자동으로 커밋할 경우 커밋되는 주기를 설정 가능
  • 5초마다 커밋하는 것이 기본값

7.5.2 컨슈머에게 명시적으로 오프셋 커밋하기

세밀한 제어가 필요한 경우 정확성과 성능에 미치는 영향에도 신경써야한다.

• 메세지 처리 먼저, 오프셋 커밋은 나중에 : 아래에 세 가지로 오버헤드와 중복 처리 회피 사이의 요구 조건 균형을 맞춘다.

  • 자동 오프셋 설정 사용
  • 폴링 루프 끝에서 오프셋 커밋
  • 루프 안에서 일정 주기로 오프셋 커밋

• 커밋 빈도는 성능과 크래시 발생시 중복 개수 사이의 트레이드 오프다 :

  • 커밋 작업은 상당한 오버헤드를 수반한다.
  • 커밋 주기는 성능과 중복 발생의 요구 조건 사이에서 저울질을 잘 해야한다.

• 정확한 시점에 정확한 오프셋을 커밋 :

  • 언제나 처리가 완료된 메세지의 오프셋을 커밋하는 것이 중요
  • 읽기는 했지만 처리가 안된 오프셋을 커밋할 경우 컨슈머에서 메세지가 누락될 수 있다.

• 리밸런스 :

  • 컨슈머 리밸런스가 발생할 것이라는 것과 이것을 적절히 처리해 줄 필요가 있다는 점을 기억해야 한다.
  • Tip : max.poll.records 를 조정하여 리밸런싱 시간 단축, poll 지연에 의한 리밸런싱 발생 가능성 감소, 메세지 중복 컨슈밍 가능성을 감소 시키자.

• 컨슈머는 재시도를 해야 할 수도 있다 :

  • 재시도 가능 에러가 발생했을 경우
  • 마지막으로 처리에 성공한 레코드의 오프셋을 커밋하는 것
    • 나중에 처리해야 할 레코드들을 버퍼에 저장하고, 컨슈머의 pause 를 호출해서 추가적인 poll 호출이 데이터를 리턴하지 않도록 한 뒤, 레코드 처리를 계속
  • 별도의 토픽에 쓴 뒤 계속 진행
    • 별도의 컨슈머 그룹을 사용해서 재시도 토픽에 저장된 레코드들을 처리, 주 토픽과 재시도 토픽을 모두 구독하는 컨슈머를 하나 둬서 재시도시 재시도 토픽 구독을 잠시 멈추도록 할 수 있다.
    • 대표 시스템 : 데드 레터 큐 (dead letter queue)

• 컨슈머가 상태를 유지해야 할 수도 있다 :

  • 애플리케이션에 따라서 poll 메서드 호출 간 상태를 유지해야 할 수도 있다.
  • 단일 트랜잭션 내에서 결과를 쓰는 작업은 카프카 스트림즈나 플링크와 같이 직접, 조인 등의 복잡한 분석 작업을 위한 고수준의 DSL 형식 API를 제공하는 라이브러리를 살펴볼 것을 권한다.

7.6 시스템 신뢰성 검증하기

세 개의 계층에 걸쳐서 검증을 수행할 것을 제안한다고 한다.

• 설정 검증
• 애플리케이션 검증
• 프로덕션 환경에 배포된 애플리케이션 모니터링

7.6.1 설정 검증하기

애플리케이션 로직과 격리된 브로커와 클라이언트 설정 검증

• 설정 검증 권장

  • 선택한 구상이 요구 조건을 충족시킬 수 있는지 확인

  • 시스템의 예상 작동을 추론해 보기 위한 좋은 방법

  • org.apache.kafka.tools 패키지에 해당 클래스로 검증 VerifiableProducer, VerifiableConsumer

  VerifiableProducer에는 acks, retries, delivery.tiomeout.ms 등의 설정값을 잡아줄 수 있고 메세지를 쓰는 속도 역시 정해줄 수 있다.

• 테스트 고려 사항

  • 리더 선출 : 리더를 정지시키면 어떻게 될지? 프로듀서와 컨슈머가 평상시처럼 작동을 재개하는데까지 얼마나 걸릴지?
  • 컨트롤러 선출 : 컨트롤러가 재시작한 뒤 시스템이 재개되는 데 얼마나 걸릴지?
  • 롤링 재시작 : 메세지 유실 없이 브로커들을 하나씩 재시작시킬 수 있을지?
  • 언클린 리더 선출 테스트 : out-of-sync 상태가 된 브로커를 시작시키면 어떻게 될지? 등

7.6.2 애플리케이션 검증하기

• 테스트 권장 상황
  • 클라이언트가 브로커 중 하나와 연결이 끊어짐
  • 클라이언트와 브로커 사이의 긴 지연
  • 디스크 꽉 참
  • 디스크 멈춤
  • 리더 선출
  • 브로커 롤링 재시작
  • 컨슈머 롤링 재시작
  • 프로듀서 롤링 재시작

테스트를 할때는 자제적인 프레임워크인 Trogdor(트록도르) 테스트 프레임워크를 포함

책에 나온 링크는 이전 링크라 아래에 남겨놓음 link : https://github.com/apache/kafka/tree/trunk/trogdor

7.6.3 프로덕션 환경에서 신뢰성 모니터링하기

클러스터의 상태를 모니터링 하는것 외에 클라이언트와 전체 데이터 흐름 역시 모니터링하는 것이 중요!!

• 컨슈머의 가장 중요한 지표는 컨슈머 랙이다.

  • 컨슈머가 브로커 내 파티션에 커밋된 가장 최신 메세지에서 알마나 뒤떨어져 있는지를 가리킨다.

• 버전 0.10.0 부터 모든 메세지는 이벤트가 생성된 시점을 가리키는 타임스탬프를 포함

[hubtwork]

소감

신뢰성 있는 컨슈머, 프로듀서를 적절하게 시나리오에 따라 설정하는 것은 실제로 백엔드 현업자에게 매우 중요한 역량이다. 이번에 회사에서 랭킹시스템을 만들 때, 카프카를 극한으로 잘 활용할 수 있도록 각 퍼널을 설계하고, 기능에 대해 고려하는 것이 중요했는데 이미 현업의 다양한 Usecase 에서 카프카를 활용하고 있는 능력있는 미들 체급 개발자들 임에도 이 부분에서 많은 조언을 구해왔다. 예를 들면, 각 퍼널의 Throughput 이나 각 요인에 따른 Latency Delay 에 따라 메세지들을 적절하게 잘 제어할 수 있도록 설정하는 것, 처리 효율을 높이기 위해 이전 장에서 보았던 Compression 같은 테크닉을 컨슈머의 처리방식 설계를 통해 제어하는 것과 같은 데에서 알맞은 프로듀서/컨슈머 설계는 수십배에 달하는 성능 차이를 낼 수 있다. 보통은 컨슈머의 애플리케이션 처리 목적, 방식을 이해하고 이에 대해 신뢰성과 오프셋 관리, 이에 따른 하트비트 레이턴시 관리 등 성능에 직결되는 요인들을 튜닝하는 데에 집중하는 것을 매우 경시하는 경향이 있는데 이런 부분을 좀 잘 고려했으면 좋겠다.

특히, 프로덕션 환경의 신뢰성 모니터링 파트에서 나온 컨슈머 랙에 대한 이해도는 정말 중요하다. 컨슈머의 랙을 해소하기 위한 컨슈밍 동작 전략이라던지, 파티션 개수라던지 컨슈머가 도출해낼 RESULT 에 대한 신뢰도 및 실시간 성을 어떻게 보장할 것인지 등은 정말 개발자 순수 역량에 따라 달려있다. 단순히 랙을 해소하기 위해서 파티션을 늘린다? 그럼 뺨 맞아야지. 그럼 처리하려는 메세지에서 실제로 "처리가 필요하지 않은 것" 들을 스킵할 수 있도록 애플리케이션들을 어떻게 설계할 수 있을까? 등을 고려하는 개발자가 되길 바란다.

[zinokim]

소감

카프카와 함께 통합되는 시스템이 중요한 이유를 알 수 있는 챕터였다. 이전 챕터들에서도 알 수 있었지만, 카프카가 얼마나 분산, 분할, 복제를 신경쓰고 이를 통해 신뢰성을 얻고자 했는지 알 수 있었다. 우리가 트레이드 오프를 할 때 어떤 점을 고려해야 하는지 생각해보게 되었다.

유연성이 높은 만큼, 카프카를 사용하다 실수로 문제를 초래하기도 쉽다. 시스템의 신뢰성이 높다고 착각하기 때문이다.

착각하지 않도록 경계해야겠다.

이전 Consumer 챕터에서 언급했던 현재 회사에서 사용 중인 컨슈머 설정인데, 데이터를 유실하지 않기 위해 earliest 설정을 사용 중이다.

auto.offset.reset=earliest

메시지를 읽어올 때마다 커밋하는 방식은 매우 낮은 빈도로 메시지가 들어오는 토픽에나 사용할 수 있다.

아 이거 우리회사에서 딱이겠다 싶었다. 매우 낮은 빈도로 메시지가 들어오는 토픽... 카프카를 잘 사용 중이지만, 과연 카프카가 꼭 필요했는지 의문에 이르렀다.

[KangHun-Lee]

소감

이번 챕터를 읽으면서 느낀 것은 내용에 나와 있는 설정과 그 동작들에 대해 제대로 이해를 하지 못한 상태로 사용을 하게 된다면 얼마나 끔찍한 일이 벌어질 지 상상이 됐다. 사실 카프카에 대해 나 뿐만 아니라 주변 동료들에 대한 실력이 뒷밤침 되지 않으면 오히려 시스템 복잡도만 심해지고 오히려 기술 부채만 더 심해지는게 아닌가 하는 생각들이 맴돌았다. 이상.

[CHOICORE]

~저는 사람이 아닙니다. 죄송합니다.~ 허재 : 그럴 수 있죠.