RabbitMQ 비동기 처리와 데드레터 처리 적용기

문제 상황 & 접근

1. FCM 오류 처리

그룹 초대 , 친구 요청 서비스를 수행하는데 있어 FCM을 사용했다. FCM 자체의 성능 개선을 위해 RabbitMQ을 사용함. FCM 요청에 있어 오류가 발생할 경우 처리를 위해 데드레터 처리

1. 비동기 적용

FCM 자체는 동기방식이기 때문에 짧은 시간에 많은 요청이 수행되는 경우 성능상 개선 필요, 메시지 큐를 사용하여 비동기 방식으로 처리

적용

• queue 설정
  • 알림을 위한 RabbitMQ queue에서 발생한 오류는 데드레터로 메시지가 전달되도록 연결하였다.

• producer
  • 알림관련 정보 즉, rabbitmq로 발행할 메시지 정보들을 db에 저장한 이후 rabbitmq로 알림 발송을 위한 메시지를 발행한다.

• 알림 consumer
  
  1. FCM을 통해 알림을 발송한다.
  2. db에 저장된 알림 관련 Entity를 조회한다.
  3. 존재하는 id인 경우 complete() 메서드를 통해 완료된 상태로 업데이트한다.
  4. 존재하지 않은 경우 nack (requeue = false)를 통해 재시도하지 않는다.

• 재시도 consumer (첫 요청 시 사용될 기존 큐에서 재시도를 수행하면 다른 요청에 영향이 가기에 분리했다.)
  1. 알림 consumer와 다른 큐를 사용하지만 동일하게 동작하며, 지수 백오프 재시도를 수행한다.

•  deadletter
  • 데드레터가 발생한 경우 로그를 남기고 슬랙으로 예외상황 정보를 전송해 알린다.

 

데드레터 & 재시도 전략

• 여러 단계에 걸친 RabbitMQ를 통한 로직은 없었으며, 로깅을 수행한 이후 개발자의 Slack으로 알림을 전송한다.
• DB에 데드레터 처리 여부 및 요청 데이터를 갖는 테이블을 추가하여 상태 필드로 처리 여부 확인 및 RabbitMQ 장애를 파악한다.
  • RabbitMQ로 보내기 직전 DB에 데이터를 저장한다.
  • RabbitMQ로 처리 완료되면 해당 row의 상태를 업데이트한다.
• 10초 간격으로 지수 백오프 기반 재시도한다.
  • Firebase 관련 로직이기에 치명적으로 오랜 기간 장애가 발생할 가능성은 적다고 판단해 일시적 오류를 고려하여 재시도 하도록 설정했다.
  • FCM 공식 문서를 확인하면, 10초 동안은 FCM 서버에서 자체 재시도를 수행하므로 10초 이상으로 재시도 간격을 잡도록 권장하고 있다.
  • 부하를 고려하여 지수 백오프를 도입했다.

다른 에러 상황을 대비할 방법은? (+개선해볼 사항)

메시지가 유실되는 경우 고려

• 현재는 알림 Entity의 상태를 실패로 미리 저장해둔 다음 성공시 상태를 성공으로 업데이트 중이다.
• 실패 시 대처 방법
  
  • 관리자 권한의 API를 생성하여 알림을 다시 보내도록 구현했다.
    • 모든 실패 상태의 알림을 발송하기에는 현재진행 중인 알림이 있을 수 있기에 id를 직접 받아 처리한다.
• 직접 관리자가 확인하여 수동으로 처리해야하기에 이 부분에 대한 개선 방안이 있을지 고민 중이다.
  • 고민 중인 방향) 스케줄링을 통해 DB에서 실패한 부분을 읽어와 큐에 넣는 방법이 있을 것이다.
    • 스케줄링을 스프링 자체에서 실행하면 서버 확장 시 여러 서버가 동시에 같은 값을 읽어올 가능성이 있으므로 API를 열어두고 인프라를 활용하여 하나의 서버에서만 실행되도록 구성하는 방향이 좋을 것 같다.
    • 스케줄링을 당장 도입하기 어렵다면 슬랙을 사용 중이기 때문에 슬랙봇을 만들어 간단하게 API를 호출하도록 구성하여 불편함을 조금 덜어볼 수 있다.

컨트롤러 (role based 인가 처리)

알림 발송 로직 (sendToQueue는 위에서 확인한 메서드와 같다.)

결론

데드레터 발생시 슬랙 알림

RabbitMQ Management에서 확인한 데드레터 현황