[Kafka] Kafka에서의 에러 핸들링에 대한 생각정리 (2024.02.22)

0. Table Of Contents

• 1. 서론
• 2. Dead Queue의 사용
• 3. 문제가 생긴 offset과 error type을 기록
• 4. offset을 기록 하고, retention기간이 지나면 데이터를 archiving 한다.

 

 

1. 서론

현재 백엔드 팀 일부 프로젝트에서는 message를 관리하고 이를 적절한 곳에서 consume하기 위해 kafka를 사용하지만, 이에 대해서 exception handling이 잘 되고 있지 않으며 각 프로젝트 별로도 다르게 설계 중인 것으로 파악이 되었다.

따라서 kafka exception handling 어떻게 하면 잘 했다고 소문이 날지 생각해보게 되었으며, 내가 고민한 방법들을 적어보았다.

 

2. Dead Queue의 사용

처리가 되지 않은 message에 대해서 나중에 메시지를 처리할 수 있도록 다른 별도의 topic에 쌓아놓는 기법이다. 이 기법을 사용 할 경우 아래와 같은 장단점이 있을 수 있다.

• 장점
  • 각 토픽별로 메시지를 보관 할 수 있으며, 작업시 자연스럽게 dead queue에 연결하여 하나씩 메시지를 까볼 수 있다.
• 단점
  • [개인적인 생각] kafka는 데이터의 위치를 알려주는 offset이라는 강력한 기능을 제공하는데, 이를 적절하게 활용하지 못하는 느낌이다.
  • topic이 많아지면 그만큼의 배수의 데이터가 중복으로 kafka에 생성되기 떄문에 스토리지 관점에서 비효율적이라고 생각된다.

 

 

3. 문제가 생긴 offset과 error type을 기록

kafka의 장점을 적극적으로 사용하여 offset기반으로 모든 데이터를 참조할 수 있다. 이 기법을 사용 할 경우 아래와 같은 장단점이 있을 수 있다.

• 장점
  • kafka의 offset을 활용해 문제가 되는 데이터만 받아 볼 수 있다.
  • 데이터의 복제본을 만들지 않아도 되므로 dataio를 최소화 할 수 있다.
• 단점
  • retention 기간이 지나버리면, kafka에 있는 데이터가 삭제되므로 디버깅을 할 수 없다.

 

 

4. offset을 기록 하고, retention기간이 지나면 데이터를 archiving 한다.

위 2가지 방법을 하나로 합친 방법으로 자세한 설명은 아래와 같다.

• retention기간 동안에는 데이터베이스에 기록 된 offset과 exception 타입을 보고 문제를 처리한다.
  • database connection 문제 등 배치로 해결 할 수 있는 문제의 경우, 일괄처리 한다.
  • 배치로 처리 할 수 없는 경우는 개발자가 직접 해당 데이터를 디버깅하여 해결한 다음, 다시 처리할 수 있도록 해당 topic에 produce한다.
• retention기간이 지났을 경우, 배치를 이용하여 database에 기록된 offset에 해당하는 데이터를 압축하여 minio등 storage에 저장한다.
  • 추후 이 문제에 대해 개발자들이 언제든 해결할 수 있도록 조치가 가능하다.
  • 중복을 kafka에 데이터를 저장하지 않기 때문에 안정적인 kafka 운영을 기대할 수 있다.