[Kafka] 카프카 에러 핸들링 패턴

Pattern 1: Stop on error (에러시 중지)

모든 이벤트들이 순서 보장과 함께 에러 없이 처리 되어야 하는 경우에 사용함. (예를 들어, CDC)
처리 도중 에러가 발생한다면 어플리케이션은 중단되며 수동 개입이 필수적이다. Source 토픽의 이벤트는 다른 경로를 사용하지 않는다.

Pattern 2: Dead letter queue (실패 대기열 큐)

일반적인 시나리오로 메인 스트림이 계속되는 동안 어플리케이션에서 처리가 불가하다면 Error 토픽으로 향하도록 함.
이 방식에서는 재시도를 위한 프로세스를 요구하거나 지원하지 않는다.

즉, 이벤트는 성공적으로 처리되거나 Error 토픽이다.

1. 일반적인 상황에서 어플리케이션은 Source 토픽의 각 이벤트를 처리하고 Target 토픽으로 생성한다. 
2. 이벤트 처리가 불가하다면, Error 토픽으로 향한다. (잘못된 포맷 혹은 부족한 데이터 등)

 

Pattern 3: Add a retry topic and retry application
(재시도 토픽과 재시도 어플리케이션 추가)

Retry 토픽을 추가하는 것은 대부분의 이벤트를 즉시 처리하면서 실패한 이벤트를 지연할 수 있다.
예를 들어, 상품 가격을 지금은 조회할 수 없지만 조회 가능한 시점이라면 Retry 토픽으로 향한 이벤트들을 상황이 해소 된다면 처리가 될 것이다.

컨테이너 환경에서는 한개 혹은 두 개의 인스턴스로 재시도 처리 구조로 사용할 수 있다.

1. 일반적인 상황에서 Source 토픽의 각 이벤트를 처리하고 Target 토픽으로 생성한다.
2. 이벤트 처리가 불가하다면, Error 토픽으로 향한다. (잘못된 포맷 혹은 부족한 데이터 등)
3. 현재 시점에서는 이벤트 처리가 불가하지만, 상황이 해소된다면 처리가 가능한 이벤트 경우 Retry 토픽으로 향하여 주기적으로 재시도를 할 수 있도록 한다.

이 패턴은 관계된 이벤트들의 순서 보장의 문제가 있을 수 있다.

Retry 토픽을 사용한다는 것은  더 적은 수의 인스턴스와 지연된 재시도를 한다는 건데, 이는 Source 토픽의 이벤트가 순차대로 처리 될 것을 보장하지 못한다.

첫 번째 이벤트의 경우 두 번째 이벤트보다 늦게 처리가 될 것이다. 이 패턴 구조를 가져가는 경우는 순서가 보장되지 않아도 상관없는 경우에 주의할 것.

 

Pattern 4: Maintain order of redirected events (재전송된 이벤트의 순서 보장)

이전 패턴들은 Retry 토픽과 연관 프로세스를 추가함으로 몇가지 이점들을 가져가는데 순서에서 문제가 발생할 수 있다.

이벤트 순서보장이 필수인 경우가 있을 것이다. 예를 들어, 상품 재고를 증가 혹은 감소시키는 등의 경우가 있을 것이다.
만약 구매 이벤트로 현재 10개의 재고를 가진 상품 재고를 10개 감소 시켜야 하는 상황이라면 추가적인 구매 이벤트로 재고량이 0 이하로 떨어지는 상황을 막아야 할 것이다.

이 패턴에서는 Retry 토픽으로 향하는 모든 이벤트들을 Unique 식별자를 통해 저장 및 추적하고 있어야 한다.
구매 이벤트가 발생하여 상품 A의 재고를 감소 시키는 이벤트가 실패하여 Retry 토픽으로 처리되고 있다면, 
구매 이벤트로 생성된 상품 재고 감소 이벤트의 후속 이벤트들을 모두 Retry 토픽으로 향해야 한다.

1. 이벤트 메시지의 유니크 식별자를 생성  (UID: 1)
2. Retry 토픽으로 향할 때, 메시지의 UID를 헤더에 추가하여 보낸다. Retry 어플리케이션이 처리 성공한다면 적절한 삭제(tombstone) 이벤트를 생성한다.
3. 이벤트 메시지의 UID를 Redirected 토픽으로 생성한다.

다음 메시지 이벤트를 받을때 어플리케이션은 이 상품의 이벤트가 있는지 확인한다. 만약 한 개 이상의 이벤트가 있다면, 어플리케이션은 신규 이벤트들을 Retry 토픽으로 보낸다.

예를 들어, 어플리케이션은 상품 A의 이벤트를 받았고 이 이벤트는 현재 재시도 중이다. 어플리케이션은 상품 A의 새로운 이벤트는 처리하지 않고 Retry 토픽으로 보낸다. 이 방법을 통해 상품 A의 이벤트들을 순서 보장하여 처리를 할 수 있도록 해준다. 어플리케이션은 새로운 이벤트 메시지가 생성될 때마다 유니크 식별자를 생성해서 가지고 있어야 한다.

 

재시도 어플리케이션은 받은 이벤트 메시지들을 순서 보장하여 처리하여야 한다. 재시도한 이벤트 처리 성공 했고 Target 토픽으로 생성 했다면, 재시도 어플리케이션은 Redirected 토픽으로 삭제(tombstone) 이벤트 형식으로 보낸다. 각 성공된 재시도 이벤트들은 삭제(tombstone) 이벤트를 생성한다.  

메인 어플리케이션은 성공적으로 재시도되었다는 신호를 알기 위해서 Redirected 토픽으로 생성된 삭제(tombstone) 이벤트들을 Listens 하고 있는다. 이 방법은 동일한 상품에 대해서 메인 Flow로 처리되어질 수 있도록 해준다.

최종적으로 이벤트에 대해서 필요로 하는 구조 종속성과 정상적인 흐름을 따를 수 있도록 해주는 순서이다.
정리해서 메인 어플리케이션은 다음 행동을 수행한다.

1. Source 토픽의 이벤트를 읽는다.
2. Retry 토픽으로 보내야 하는지 확인.
3. 이벤트를 성공적으로 처리하고 Target 토픽으로 이벤트 생성