신뢰성 있는 시스템에서 프로듀서/컨슈머 사용하기

이 글은 전의 신뢰성 있는 데이터 전달 방법에 이어지는 글이다.

신뢰성 있는 데이터 전달 방법

 

글을 시작하기 전에 카프카의 시스템에 대해서 잠시 공부해보자.

아주 간단히 다룰 예정이니, 자세히 알고 싶은 분들에게는 적합하지 않음을 밝힌다.

 

카프카는 크게 프로듀서, 컨슈머, 브로커들이 있는 클러스터로 나눌 수 있다.

 

브로커는 일종의 서버로, 데이터를 저장하고, 처리하는 공간이다.

이 브로커들이 여러 개가 묶여 구성되어 있는 것이 카프카 클러스터이다.

 

이런 카프카 클러스터에 있는 브로커에 데이터(메세지, 이벤트)를 넣어주는 역할이 프로듀서

브로커에서 데이터(메세지, 이벤트)를 읽어주는 역할이 컨슈머이다.

 

그림으로 간단히 표현해보면 아래와 같다.

브로커들이 모여있는 가운데가 카프카 클러스터

그렇다면, 신뢰성 있는 시스템에서 프로듀서와 컨슈머를 어떻게 사용하는지 알아보자.

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

• 신뢰성 요구사항에 맞게 acks 구성 매개변수 올바르게 설정 해야 한다.
• 구성 매개변수와 코드 모두에서 에러처리를 올바르게 해야 한다.

1-1. 확인 응답 전송(acks 설정하기)

acks=0 : 수신응답을 기다리지 않음

• 장점
  • 실행속도가 빨라 처리량이 많다. → 네트워크 성능을 잘 활용할 수 있다.
• 단점
  • 데이터 유실이 생길 수 있다.
    
    < 프로듀서가 알 수 없는 경우>
    • 파티션이 오프라인인 경우
    • 카프카 클러스터의 처리 지연이 생긴 경우
    • 새로운 리더 선출 중인 경우

 

acks=1 : 리더만 받으면 성공

• 장점
  • 데이터가 유실될 수 있으나, 수신응답을 기다리지 않는 것보다 그 확률이 적다.
    < 데이터 유실 예시 >
    리더가 성공적으로 쓰고 확인 응답한 일부 메세지가 리더 중단 시점에도 팔로어에 복제되지 않았다면 데이터가 유실된다.

acks=all : 모든 동기화 레플리카에 복제될 때까지 기다림

• 장점
  • 리더 브로커가 죽어도 모든 레플리카에 모두 복제되어 있으므로 데이터 유실이 전혀 없다 → 가장 안전
• 단점
  • 복제할 때까지 기다려야 한다. : 네트워크에서 기다림 지연시간이 발생한다 → 처리속도가 매우 느림
    < 소소한 해결법 >
    용량이 큰 배치 사용하기
    → 하지만 이 친구도 처리속도는 줄여주지만, 처리량도 같이 준다는 단점을 가진다.

1-2 . 프로듀서의 재시도 구성하기

재시도가 가능하도록(retriable) 에러 처리하기 → 시간이 해결할 수 있는 문제라면!

< 예시 >

• LEADER_NOT_AVAILABLE : 리더 선출 중인 경우
• 네트워크 연결 문제

1-3. 추가적인 에러 처리 → 개발자가 해야하는 일

• 메세지 크기 설정하기
• 인증에러 피하기
• 직렬화 에러
• 메모리 관리

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

• 일관성이 보장된 데이터를 읽어오기
  • 읽은 메세지와 읽지 않은 메세지를 파악만 하면 된다
    (자신의 오프셋을 컨슈머가 커밋해야하는 이유)
    **어떻게? → 오프셋을 기준으로!**
  • 이미 읽었지만 아직 완전히 처리되지 않은 메시지의 오프셋을 커밋할때 누락이 발생할 수 있다.
    • 언제 어떻게 오프셋을 커밋하는지가 중요하다.

2-1. 신뢰성 있는 처리에 중요한 컨슈머 구성

group.id

컨슈머는 할당받은 group.id에 대한 메세지를 읽어 온다

같은 토픽을 구독하는 같은 group.id를 가진 컨슈머는 해당 토픽의 일부 파티션을 분담하여 할당받은 메세지만 읽게 된다.

auto.offset.reset

• earlist : 맨 처음부터
  • 장) 데이터 누락 최소화
  • 단) 2번 메세지를 읽어올 수 있음
• latest : 가장 최근에 추가된 데이터(파티션의 제일 끝)부터
  • 장) 중복을 최소화
  • 단) 다만 일부 메세지 누락될 수 있음

enalbe.auto.commit

• 자동
  • 처리한 메세지의 오프셋만 커밋되도록 보장
  • poll() 메서드 호출 시 자동 commit
  • 속도가 빠름
  • 중복되는 메세지 처리를 제어할 수 없음
• 수동
  • 언제 어떻게 커밋할지 사용자가 지정

auto.commit.intervals.ms(5s)

• 자동으로 오프셋을 커밋하는 시간 간격을 제어
• 자주하도록 설정하면, 중단으로 인해 초래될 수 있는 중복의 메세지 수를 줄이지만, 약간의 성능 부담이 될 수 있다.

2-2. 신뢰성 있는 컨슈머 개발하기

• 오프셋 커밋은 항상 메세지가 처리된 후에 할 것
  • 오프셋 커밋 빈도는 성능과 중복 메세지 개수간의 trade-off
• 어떤 오프셋을 커밋하는지 정확하게 알 것!
  • 처리된 메세지의 오프셋인지 꼭 확인
• 리밸런싱이 수행될 수 있음을 인지할 것!

---

리밸런싱이란?

* 파티션 소유권(ownership)

: 각 컨슈머가 특정 파티션에 대응되는 것
→ 컨슈머 그룹의 컨슈머들은 자신들이 읽는 토픽 파티션의 소유권을 공유한다

 

리밸런싱(rebalancing)

: 한 컨슈머부터 다른 컨슈머로 파티션 소유권을 이전하는 것

< 장점 >

• 컨슈머 그룹의 가용성과 확장성을 높여주므로 중요하다
• 쉽고 안전하게 컨슈머를 추가하고, 삭제할 수 있다.

< 단점 >

• 리밸런싱은 정상적인 처리에서 바람직하지 않다
• 리밸런싱을 하는 동안 컨슈머들은 메세지를 읽을 수 없어 해당 컨슈머 그룹 전체가 사용 불가 상태가 된다.
• 한 컨슈머로부터 다른 컨슈머로 파티션이 이전될 때, 핻당 컨슈머의 이전 파티션에 대한 정보가 삭제된다.

---

• 컨슈머는 상태 데이터를 유지할 것
• 긴 처리 시간에 대처할 것