메시지 큐 방식을 이용한 비동기 프로세스 개발

회사에서 다양한 B2B, B2C 서비스를 운영하고 있는데 모두 고객 문의 기능을 통해 운영팀이 CS 대응하게 된다.
사용자가 고객 문의를 접수하면 해당 API가 호출되고, 젠데스크라는 외부 API를 호출하여 운영팀이 사용하는 툴에 고객 문의를 등록하는 기능이다.

하지만 간헐적으로 외부 API 호출 실패로 문의 내용이 누락되면서 고객 불만이 커지고 있어 빠른 개선이 필요한 상황이었다.
개선 요구 사항으로는 간헐적으로 누락되는 티켓에 대해 재등록 되어야하며 API 호출에 대한 모니터링과 오류에 대한 원인 파악이 필요했다.

처음 기존대로 고객문의가 인입되면 req/res에 대한 로그성 데이터를 쌓고, 젠데스크 API를 호출했을 때 실패나는 건들을 모아 백그라운드에서 비동기로 처리하는 방향으로 설계했다.
하지만 이 방식은 젠데스크 API 호출부가 두 곳으로 늘어나기 때문에 유지, 보수에 비효율적이라고 판단했다.

그래서 메시지 큐 방식과 비슷하게 인입되는 고객 문의를 DB에 바로 쌓고, 일정주기마다 비동기로 N개씩 처리하는 방식으로 결정했다. 메시지 큐를 직접 사용해보진 않아서 같이 공부하고, 개발하면서 배운 내용들을 정리하면 좋을 것 같았다.

위에서 말한대로 비동기 방식으로 구현했을 때 어떤 장점이 있을까?

• 큐에 넣어 나중에 처리가 가능하다.
  • 내가 구현한 방식에서는 고객문의 요청 데이터를 저장하는 DB가 큐 역할을 한다.
• application과 분리할 수 있다.
  • 고객 문의를 해당 application가 아닌 다른 서비스를 통해 처리할 수 있다.
• 여러 개의 서비스들이 큐에 메시지를 보낼 수 있다.
  • 고객 문의 기능을 여러 서비스에서 사용하고 있고, 사용될 수 있으므로 모든 고객 문의 요청을 한 번에 쌓아 처리가 가능하다.
• API 호출이 실패해도 기존 서비스에는 영향을 주지 않는다.
• 요청이 실패할 경우 재실행이 가능하다.
  • 나는 API 요청 상태 값을 관리하여 미호출/호출 실패된 상태인 경우 재실행되도록 구현했다.

다음과 같은 작업에서 구현하기 적합할 것 같다.

1. 대용량으로 데이터를 처리해야 하는 작업
2. 서버 부하가 많은 작업
3. 필요에 따라 재실행이 필요한 작업