5. Kafka 메시지 처리 실패 시 대처 방법 (feat. Spring) (DLT, 재시도) (+실습)

서론

• Kafka를 이용하여 비동기 통신을 할 경우 사용자에게는 성공 여부와 상관없이 바로 성공이라고 보내지기 때문에 실패할 시 서버에서 처리를 해주어야한다.
  • 이를 위해 재시도, DLT 등의 방식이 쓰인다
• 본 실습을 하기 전 EC2에 kafka가 설치 되어야하며 Producer와 Consumer가 구축된 로컬 스프링 서버가 필요하다. 만약 구축이 안되어 있거나 관련 이론을 먼저 공부하고 싶다면 아래의 링크를 참고하자

[환경 세팅]

2. Kafka 간단히 설치해보기 (feat. EC2) (+ 실습)

4. Kafka의 Producer, Consumer 서버 만들기 (feat. Spring) (+ 실습)

 

[관련 이론]

1. Kafka와 메시지큐 (정의, 형태)

3-1. Kafka의 핵심 요소와 작동 (Topic, Consumer, Producer, Consumer Group, OffSet, CURRENT OFFSET) (+ 실습)

 

Kafka에서 처리에 실패한 메시지를 재시도(Retry)하도록 만들기

1. 의도적으로 실패하는 상황을 만들기 위해 Consumer 코드 수정하기

EmailSendConsumer

@Service
public class EmailSendConsumer
{

    @KafkaListener(
            topics = "email.send",
            groupId = "email-send-group" // 컨슈머 그룹 이름
    )
    public void consume(String message) {
        System.out.println("Kafka로부터 받아온 메시지: " + message);

        EmailSendMessage emailSendMessage = EmailSendMessage.fromJson(message);

        if (emailSendMessage.getTo().equals("fail@naver.com")) {
            System.out.println("잘못된 이메일 주소");
            throw new RuntimeException("잘못된 이메일 주소");
        }

        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }

        System.out.println("이메일 발송 완료");
    }
}

2. Postman으로 실패 조건에 해당하는 API 요청 보내기

• 실패해도 성공이라고 뜸

3. Consumer 서버에 찍힌 로그 확인하기

• 요청을 보냈더니 Consumer 서버에서 재시도(Retry)에 대해서 아무런 코드를 작성하지 않았는데도 여러 번 재시도를 한 흔적이 로그로 남았다. 그리고 에러 메시지 바로 직전의 로그를 살펴보면 "Backoff FixedBackOff{interval=0, currentAttempts=10, maxAttempts=9} exhausted for email.send-0@5"라고 작성되어 있다.
  • 기본적으로 10번 바로 재시도가 기본값이기에 아무것도 설정하지 않았다면 그렇게 작동하는 것이다.
• 로그에 찍힌 각 용어의 의미는 다음과 같다.
  • interval : 재시도를 하는 시간 간격 (ms)
    • interval=0일 경우 실패하자마자 즉시 재시도 한다는 뜻이다.
  • maxAttempts : 최대 재시도 횟수
    • maxAttempts=9인걸로 봐서 재시도를 9번까지 했다는 뜻이다.
  • currentAttempts : 지금까지 시도한 횟수 (최초 시도 횟수 + 재시도 횟수)
    • currentAttmpes=10인 이유는 최초 시도를 1번 하고 재시도를 9번 했기 때문이다.

재시도(Retry) 정책 변경하기

1. Consumer 코드 수정하기

EmailSendConsumer

@Service
public class EmailSendConsumer
{

    @KafkaListener(
            topics = "email.send",
            groupId = "email-send-group" // 컨슈머 그룹 이름
    )
    @RetryableTopic(
            attempts = "5", // 시도 횟수
            backoff = @Backoff(delay = 1000, multiplier = 2) // 재시도 간격 (1초, 2배씩 늘려나감) 1초.. 2초.. 4초..
    )
    public void consume(String message) {
        System.out.println("Kafka로부터 받아온 메시지: " + message);

        EmailSendMessage emailSendMessage = EmailSendMessage.fromJson(message);

        if (emailSendMessage.getTo().equals("fail@naver.com")) {
            System.out.println("잘못된 이메일 주소");
            throw new RuntimeException("잘못된 이메일 주소");
        }

        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }

        System.out.println("이메일 발송 완료");
    }
}

• 현업에서 보통 재시도 횟수는 3~5회 사이로 정하는 편이다. 왜냐하면 재시도를 너무 많이 할 경우 시스템 부하가 커질 수 있고, 너무 적으면 일시적인 장애에 대응하기 어렵기 때문이다.
• 첫 재시도 간격은 짧게 설정하는 편이고, 그 이후 재시도 간격은 지수적(exponential)으로 증가하도록 설정하는 편이다. 그래야 일시적인 장애에 대해서는 첫 빠른 재시도로 대응이 가능하고, 장애가 조금 길어지는 경우라도 무의미하게 재시도하는 걸 방지하기 위함이다.

2. 테스트해보기

• 로그를 보면 횟수가 5회이며 계속 시간이 증가하는 것을 볼 수 있음

 

Spring Boot로 Kafka에서 재시도조차 실패한 메시지를 따로 보관하기 (DLT, Dead Letter Topic)

• DLT(Dead Letter Topic)는 오류로 인해 처리할 수 없는 메시지를 임시로 저장하는 토픽이다. Kafka에서는 재시도까지 실패한 메시지를 다른 토픽에 따로 저장해서 유실을 방지하고 후속 조치를 가능하게 만든다.

그럼 DLT는 왜 사용하는 걸까?

1. 실패한 메시지를 DLT 토픽에 저장해놓기 때문에, 실패한 메시지가 유실되는 걸 방지할 수 있다.
2. DLT 토픽에 실패한 메시지가 저장되어 있기 때문에, 사후에 실패 원인을 분석할 수 있다.
3. DLT 토픽에 실패한 메시지가 저장되어 있기 때문에, 처리되지 못한 메시지를 수동으로 처리할 수 있다.

DLT를 활용해 재시도에 실패한 메시지 따로 보관하기

사실 Spring Kafka는 @RetryableTopic을 사용하면 자동으로 DLT 토픽을 생성하고 메시지를 전송해준다. 기본적으로 만드는 DLT 토픽 이름은 {기존 토픽명}-dlt 형태로 지어진다. 일관적인 DLT 토픽 이름을 위해 직접 DLT 토픽명을 별도로 다시 설정해주자.

1. Consumer 코드 수정하기

EmailSendConsumer

@Service
public class EmailSendConsumer
{

    @KafkaListener(
            topics = "email.send",
            groupId = "email-send-group" // 컨슈머 그룹 이름
    )
    @RetryableTopic(
            attempts = "5", // 시도 횟수
            backoff = @Backoff(delay = 1000, multiplier = 2), // 재시도 간격 (1초, 2배씩 늘려나감) 1초.. 2초.. 4초..
            dltTopicSuffix = ".dlt" // email.send.dlt로 저장이 됨
    )
    public void consume(String message) {
        System.out.println("Kafka로부터 받아온 메시지: " + message);

        EmailSendMessage emailSendMessage = EmailSendMessage.fromJson(message);

        if (emailSendMessage.getTo().equals("fail@naver.com")) {
            System.out.println("잘못된 이메일 주소");
            throw new RuntimeException("잘못된 이메일 주소");
        }

        try {
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }

        System.out.println("이메일 발송 완료");
    }
}

2. 서버 실행 후 API 요청 보내기

• 실패한 후 dlt 토픽으로 잘 가는 모습을 볼 수 있음

3. CLI로 정말 DLT 토픽이 잘 생성됐는 지 확인해보기

# 토픽 전체 조회
bin/kafka-topics.sh \
	--bootstrap-server localhost:9092 \
	--list

• email.send.dlt가 잘 저장된 모습을 볼 수 있다
• email.send-retry-…은 재시도시에 저장된 토픽이다.

# 토픽 내부 메시지 전체 조회
bin/kafka-console-consumer.sh \
	--bootstrap-server localhost:9092 \
	--topic email.send.dlt \
	--from-beginning

• 잘 저장된 것을 볼 수 있다.

그림으로 이해하기

• Conusmer 서버가 메시지를 처리하다가 실패하면 정해진 횟수까지 재시도를 한다. 여기서 끝까지 재시도 처리에 실패한 메시지는 DLT 토픽으로 옮겨서 보관하게 된다.

 

Spring Boot로 재시도조차 실패한 메시지 사후 처리하기

DLT에 저장된 메시지를 사후 처리하는 방식

DLT에 저장된 메시지는 여러 번의 재시도를 거쳤음에도 불구하고 실패한 메시지이기 때문에 분명 문제가 있는 메시지이다. 따라서 이 메시지는 수동으로 체크하고 조치를 취해야 한다. 따라서 현업에서는 DLT에 저장된 메시지를 아래와 같은 방식으로 주로 처리한다.

1. DLT에 저장된 실패 메시지를 로그 시스템에 전송해 장애 원인을 추적할 수 있도록 한다.
2. DLT에 메시지가 저장되자마자 수동으로 대처할 수 있게 알림을 설정한다.
3. 알림을 받은 관리자는 로그에 쌓인 내용을 보고 장애 원인을 분석하고, 그에 맞게 메시지를 수동으로 처리한다.

여기서 3번째 내용 중에 ‘메시지를 수동으로 처리한다’라는 부분을 더 자세히 살펴보자. 도대체 메시지를 수동으로 어떻게 처리한다는 걸까? 대표적인 수동으로 처리하는 방식의 예시를 알아보자.

DLT에 저장된 메시지 처리하기

1. DLT에 저장된 메시지 처리하는 Consumer 로직 작성하기

EmailSendDltConsumer

@Service
public class EmailSendDltConsumer {
  @KafkaListener(
      topics = "email.send.dlt",
      groupId = "email-send-dlt-group"
  )
  public void consume(String message) {

    // ...로그 시스템에 전송하는 로직은 생략...
    System.out.println("로그 시스템에 전송 : " + message);
    
    // ...Slack에 알림 발송하는 로직은 생략...
    System.out.println("Slack에 알림 발송");
  }
}

• Slack과 같이 알림을 발송하게 만들어놓으면 DLT로 빠진 메시지를 바로 인식할 수 있게 된다. 그러고 로그 시스템에 저장된 로그를 확인하면서 문제의 원인을 파악해 그에 맞게 메시지를 처리하면 된다.

2. 서버 재시작해서 테스트해보기

• Slack에 정상적으로 보내지는 모습을 볼 수 있다.

출처: https://inf.run/qzJua