Consumer Error Handling Patterns

목차

 

Kafka의 에러 핸들링은 보통 Consumer단에서 처리한다고 한다.

이러한 에러를 핸들링하는 패턴들에 대해 정리.

 

[Poison Pill]

Poison Pill이란 Consumer가 처리하지 못하는 메시지가 왔을 때를 의미힌다. (Deserializer를 하지 못하는 메시지 형태)

M2가 비정상적 메시지라고 하면 M2를 처리하다가 오류가 나고 Consumer가 실패할 것이다.

 

Spring - ErrorHandlingDeserializer

스프링에서는 ErrorHandling Deserializer를 제공하고 있다고 한다. 그래서 이상한 데이터가 들어오면 ErrorHandling Logic의해 처리되고, 정상적인 데이터들만 Consumer로 넘어가게 하는 패턴을 권장한다고 한다.

 

[Error Handling Patterns]

패턴1. 일정시간(횟수)동안 재처리 시도 후 Consumer를 종료

가장 기본적인 패턴으로 일정 시간이나 횟수동안 재시도 해보고 실패하면 그냥 종료해버린다.

 

패턴2. Dead Letter Queue (DLQ)

실패 시 별도의 오류 토픽에 담는 방식. 오류 토픽에 담은것을 어떻게 처리할지 정해서 처리한다.

 

 

패턴3. DLQ with Retry

Retry토픽에는 처리를 지금 당장 못하는 메시지를 담는다. (ex: DB일시적 장애)

Retry Consumer는 성공할 때까지 Retry를 하고, 일반 Consumer는 Retry 토픽에 담거나 Error Topic에 담은 후 다음 메시지를 처리한다.

 

이 패턴의 문제는 만약 메시지의 순서를 지켜야할 때 메시지1은 일시적인 장애로 Retry Topic을 거쳐 처리되었지만 메시지2는 정상처리되었을 때 순서가 뒤바뀔 수 있다는 것이다.

순서가 중요하지 않으면 사용할 수 있는 패턴이다.

 

패턴4. DLQ with Retry의 문제를 해결 (순서보장)

메시지의 색깔이 동일한 키라고 가정한다.

 

이때 M1이 retry로 처리되어야할 때 local state에 M1 메시지를 내가 Retry Queue에 보냈다고 표시한다.

표시해놓으면 순서를 지켜야 하는, M2메시지가 왔을 때도 Retry Topic으로 전달되게 된다.

이를 통해 순서를 보장해야하는 경우 동일하게 Retry Topic으로 처리하도록 해서 순서를 보장한다.

반면 M3의 경우 다른키라서 순서보장이 필요없기 때문에 정상적으로 처리될 수 있다.

 

Retry Consumer가 이들을 처리하고 난 후에는 Redirect Topic에 툼스톤 메시지 (value: null)를 발급하는데, 토픽이 Compact 옵션으로 되어있기 때문에 해당 메시지는 삭제처리된다. 이후에 State Updater가 이 정보를 읽어서 local state에 업데이트 해준다.