1. 문제 발견

kafka 토픽으로 부터 이벤트가 수신될 때 실행되는 컨슈머 로직의 오류가 발생 시, 지수 백오프를 통한 재시도 전략과 실패 메시지는 DLT에 넣는 작업을 진행하여 안정성을 확보했습니다.

시스템은 Kafka Consumer가 이벤트를 수신하면 1차적으로 위험도를 판단하고, 2차적으로 LLM에 분석을 요청하는 구조였습니다. LLM 요청은 응답 시간이 존재하기 때문에 @Async를 활용한 비동기 방식으로 구현했습니다.

하지만 메인 Kafka Consumer 로직과 비동기 로직의 트랜잭션 범위가 분리되면서 문제가 발생했습니다.

• 문제점: 메인 스레드는 비동기 메서드를 호출한 직후, 작업 성공으로 간주하고 Kafka Offset을 Commit
• 결과: LLM 서비스에서 다양한 예외처리가 발생하여 결과가 증발해도, 메인 로직은 이미 커밋된 상태이므로 DLT(Dead Letter Topic)로 재처리가 불가능
• 현상: 로그상으로는 모든 이벤트 처리가 성공했지만, LLM 분석 결과가 이루어지지 않은 Silent Failure(조용한 실패) 발생
  • 즉 DLT를 통해 관리하려고 했던 유실된 메시지를 관리하지 못하게됨

2. 부하테스트를 통한 데이터 유실률 확인 방안

이 문제가 단순한 설정 오류가 아닌, 아키텍처의 구조적 결함임을 증명하기 위해 JMeter를 활용한 부하 테스트를 설계했습니다.

실험 환경 및 전제 조건

운영 환경의 트래픽 폭주 상황을 로컬 환경에서 효율적으로 재현하기 위해, 의도적으로 리소스를 극한으로 제한하는 제약 테스트 방식을 채택했습니다.

• 스레드 풀 설정: Core 1 / Max 1 / Queue 1 (조기 실패 유도)
• 부하 조건: 100개의 이벤트를 동시 발행
• 검증 지표: 데이터 보존율 (LLM 분석 완료 수 / 메인 이벤트 처리 수)

3. ThreadPool 정책의 딜레마