[싹틔움] 메인 서버측 에러로 인한 Kafka Message 전송 실패 시나리오 대비 안전 장치 고민

 

💡 개요

 

아웃박스 패턴 구현

 

고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?

고민1 해결: 아웃박스 패턴 변형 구조 구현

 

고민2 : 재전송을 시도해도 계속해서 Sent 값이 False 인 경우는 어떻게 처리하면 좋을까?

고민2 해결: Redis 도입을 통해 각 데이터별 Count 및 Webhook 연결을 통한 운영 처리

 

고민3 : DLQ Topic 도입을 하는 것이 좋을까?

---

이전 글:

[싹틔움] API Gateway 도입을 통한 인증 역할 분담

 

 

 

현재 구조에서 메인서버와 알림서버 사이에서 Kafka 를 사용해 메세지를 전달하는데, 단순한 메세지 전달 구현뿐만 아니라 시스템 안정을 위해 실패할 시나리오를 대비할 필요가 있고 그 방법이 많이 있다는 것을 알았다. 그 중 Outbox 패턴, retry 시도, DLQ 로직을 고려하면서 했던 고민을 기록하고자 했다.

 

💡 실패 시나리오

- Kafka 브로커 또는 컨슈머가 실행 중인 서버 간 네트워크 연결이 끊기거나 지연이 발생할 경우, 메시지가 전달되지 않을 수 있음

- Kafka 브로커가 다운되거나 일시적으로 응답하지 않는 경우

- 컨슈머가 메시지를 처리하는 과정에서 예외가 발생하여 메시지를 정상적으로 처리하지 못하는 경우

- 프로듀서와 컨슈머 간 메시지 포맷이 일치하지 않아 역직렬화에 실패하는 경우

등 등

 

💡 아웃박스 패턴 구현

🌱 아웃박스 패턴이란?

- 아웃박스 패턴은 분산 시스템에서 데이터베이스 트랜잭션과 메시지 전송을 일관성 있게 처리하기 위한 패턴이다. 이 패턴은 메시지를 Kafka와 같은 메시지 브로커로 직접 전송하지 않고, 먼저 로컬 데이터베이스에 저장한 후 별도의 프로세스가 해당 메시지를 읽어 브로커로 전송하는 방식으로 동작한다.

 

🌱 구현

- 필자는 기존에 kafka 로 메세지를 생성해서 topic 에 넣는 로직 대신에 notification Entity 에 sent Column 을 Flag 변수로 추가해서 kafka 메세지 전송 여부를 체크했다. 기존에 객체 생성시에는 false 값으로 넣어서 우선 DB 에 저장시켰다.

- 이후 Scheduler 를 활용해서 일괄적으로 sent Column 값이 false 인 데이터들의 kafka 메세지를 생성해 topic 으로 전달시킨다.

- 전달이 완료된 데이터의 sent 값을 true 로 변경시켜주면 된다.

---

🌱고민1 : 아웃박스 패턴을 적용하면 Kafka 메세지 전송 전에 무조건 DB 로 부터 조회를 해서 불러오다보니 리소스가 낭비되지 않을까?

- 1차적으로 DB 에 메세지를 저장시키고 이후 스케줄러를 통해 주기적으로 일괄 Kafka 메세지를 전송하다보니 아래 두 경우에서 한계가 있지 않을까 생각이 들었다.

• 서버 및 DB 부하
• 실시간 메세지 전송 불가

---

💡 고민1 해결: 아웃박스 패턴 변형 구조 구현

- 그래서 필자는 아웃박스 패턴에서 조금 변형해 최초 Kafka 메세지 생성 시 바로 전송시킴과 동시에 Outbox Table 에도 저장시킨다. 이 때 Sent Flag 변수는 true 값으로 저장한다.

- 혹시 Kafka 메세지 전송에 실패한다면 Sent 변수 값을 false 값으로 변경하고 이후 스케줄러를 통해 재처리를 시켰다.

- 또한 DB 과부하를 막기 위해 생성시간 기준 오름차순 상위 50 개의 데이터씩 재전송을 시도하도록 설정을 했다.

 

- 1차적으로 Kafka 메세지 전송에 성공한 데이터들은 걸러지기 때문에 이후 스케줄러를 통해 조회 후 처리할 때에도 DB 부하가 줄고, 최초 Kafka 메세지 생성 시 바로 전송시키기 때문에 빠른 메세지 전송이 가능하다.

---

🌱고민2 : 재전송을 시도해도 계속해서 Sent 값이 False 인 경우는 어떻게 처리하면 좋을까?

- 일시적인 네트워크 오류 등으로 Kafka 메세지 전송에 실패했을 때를 대비해 아웃박스 패턴을 필자의 서비스에 맞게 수정을 했다.

- 하지만 일시적인 네트워크가 아니라 Kafka 연결이 끊어졌든 어떠한 치명적인 상황 때문에 지속적으로 재전송을 시도해도 Kafka 메세지 전송에 실패를 하는 경우, Outbox DB 에는 데이터가 계속 쌓일 것이다.

List<NotificationOutbox> findTop50BySentFalseAndDlqFalseOrderByCreatedAtAsc();

 

- 또한 위처럼 생성시간 기준 오름차순으로 상위 50개를 가져오다보니, 계속 같은 데이터만 반복적으로 Kafka 메세지 전송 시도를 하게 될 것이다.

---

💡 고민2 해결: Redis 도입을 통해 각 데이터별 Count 및 Webhook 연결을 통한 운영 처리

- 때문에 각 데이터별 재전송 횟수의 한계를 두었어야했고, 단순 카운트이기 때문에 DB 부하를 줄이고 TTL 등 설정을 통해 관리하기 용이한 redis 를 이용해 count 를 했다.

 

- 각 Outbox Id 별 재전송 3회 제한을 걸고, 만약 3회 초과로 재전송 실패 시 이를 치명적인 에러 발생으로 분류한다.

 

- 이를 운영적인 측면에서 개발자가 조치를 할 수 있도록 해당 Outbox 데이터의 errored Column 값을 true 로 변경하고,

데이터 정보와 함께 Discord Webhook 를 연결해 공유 가능하도록 했다.

 

🚨 테스트

try {
    if (true) {
        throw new RuntimeException("💥 고의로 발생시킨 Kafka 예외");
    }
    kafkaTemplate.send("notifications", message);
    log.info("✅ Kafka 전송 성공");
}

 

의도적으로 Error 에 걸리게 하기 위해서 Kafka message 를 생성하는 try 문에 RuntimeException 에러가 나오게 했다.

 

반복문을 3번 돌면서 Redis 에서 count 를 하고 count 제한이 끝나면 해당 log 와 함께 Discord 알림 전송을 보내며 errored 값을 true 로 수정한다.

---

🌱고민3 : DLQ Topic 도입을 하는 것이 좋을까?

- Kafka 의 DLQ 기능을 고민해보았다. 

 

DLQ ( Dead Letter Queue ) 란 ?

메시지 소비(Consumer) 중 처리에 실패한 메시지를 따로 저장하는 Kafka의 특수한 토픽(Queue)

 

- 다양한 문제로 Kafka Message 생성의 실패 케이스가 있겠지만, 그 중 Kafka 서버 자체에 문제가 있는 시나리오를 대비해보자면 결국 Kafka 서버에 문제가 있기 때문에 Kafka DLQ Topic 에 저장을 시도해도 똑같이 문제가 생길 것으로 판단했다.

 

- 현재 Redis 를 활용한 3회 재시도 및 Discord 알림 전송을 통해 운영적인 측면에서 대응이 가능하도록 설계를 했기 때문에, DLQ 로 메세지 전송은 Producer 측이 아닌 이미 Kafka 로 메세지가 저장이 되었지만 Consumer 측인 알림서버에서 이 메세지를 수신하지 못한 시나리오를 대비해 알림서버에서 DLQ 로 전송하는 구조를 선택해보았다.

(https://hanstory33.tistory.com/321)