[Web] RabbitMQ가 필요한 이유 (feat. MSA)

📍 RabbitMQ 적용 계기

 

현재 진행중인 빅데이터 프로젝트에서 Message Queue를 적용할 일이 생겼다.

 

사용자 유입 & 데이터 보정을 통한 빅데이터 추천 시스템 성능 개선을 위해

MBTI 테스트를 오마주한 'JUBTI(酒비티아이)'를 개발했는데,

 

한 사용자가 테스트를 마칠 때마다

결과 데이터를 SpringBoot API로 받아 Flask 서버에 보내서 데이터 보정 작업을 진행해야 했다.

(API 서버는 Spring Rest API, Analysis 서버는 Flask로 구성)

 

그런데 해당 테스트는 비회원으로 진행할 수 있는 서비스이며,

카카오톡 공유하기 기능까지 추가하여 최대한 많은 사용자가 쉽게 테스트 할 수 있도록 했기에

동시에 많은 사용자가 몰릴 때의 성능상 문제점이 예상되었다.

 

 

💡 우리는 첫 번째 해결 방안으로 스케줄러를 생각했다.

테스트 결과를 받으면 우선 DB에 저장하고, 스케줄러를 이용하여
정해진 주기마다 한 번씩 Flask 서버에 요청을 보내서 쌓인 데이터만큼 데이터 보정을 진행하는 방식!

 

위와 같이 진행하면 문제는 없지만, 계속해서 새로운 데이터를 기반으로 보정을 진행하는 것 보다

추천 시스템 성능 개선의 정도가 아쉽다는 결론을 도출했다.

 

 

💡 새로운 개선 방법이 바로 MQ를 적용하여 MSA를 구축하자는 것!

더욱 정교한 데이터 보정 및 빅데이터 추천 성능 개선을 위해

실시간으로 테스트 결과 데이터를 Flask로 보내고 계속해서 데이터를 보정하는 방식을 지키고자 했다.

 

따라서 많은 사용자가 동시에 접속했을 때도, API 서버가 앞에서 어떻게 작동하고 있든 관계없이

Flask 서버는 API에서 요청받은 데이터들을 쌓아두고 계속해서 처리하는 방식을 목표로 했다.

 

그리고 아래와 같은 이유로 RabbitMQ 적용을 결정했다.

1️⃣ 데이터를 쌓아둘 곳 필요 -> Message Queue 이용하자.

2️⃣ Spring 서버와 Flask 서버의 통신이 필요 -> AMQP를 지원하는 RabbitMQ 이용하자.

 

---

📍 RabbitMQ의 쓰임

 

RabbitMQ는 AMQP를 구현한 미들웨어로,

서비스와 서비스 사이에 존재하며 메시지를 전달하는 역할을 한다.

 

백엔드 안에서도 프론트와 백으로 나눌 수 있는데, 보통 프론트는 API, 백은 Analysis 서버로 본다.

이 때, 백엔드의 프론트, 백을 한 서버에서 돌리는 것은 위험할 수 있다.

 

그 이유는 사용자가 많아질 경우 분석 서버가 사망하거나,

반대로 분석의 양이 많아져서 분석 서버가 사망하게 될 시 API까지 함께 사망할 수 있기 때문이다.

👉 의존성이 너무 높아서 생기는 문제 !

따라서 서버는 분할해주고, 분할된 서버들은 메시지를 큐에 적재하여 소통하도록 하는 것이

가용성과 확장성 측면에서 좋다. 이게 바로 MSA(마이크로 서비스 아키텍처) 💥

 

이 때 RabbitMQ를 사용하면 메시지 큐를 쉽게 구현할 수 있도록 해준다.

RabbitMQ는 AMQP를 구현했기 때문에 서로 다른 시스템간에 효율적인 메시지 교환을 돕기 때문이다.

AMQP 이전 상용화된  MQ들은 플랫폼 종속적인 제품이 많아서 메시지 브릿지가 따로 필요했고,

그로 인한 속도 저하가 발생했다.

 

---

📍 RabbitMQ 적용 방안

 

0️⃣ Spring 서버는 하나, Flask 서버는 두 개를 띄움

1️⃣ 사용자가 테스트를 진행

2️⃣ 해당 결과를 Spring API로 받음

3️⃣ 받은 결과를 RabbitMQ로 적재 (Spring에 Producer 구현)

4️⃣ 적재된 내용을 두개의 Flask 서버가 차례대로 가져감 (Flask에 Consumer 구현, prefetch count 1로 설정)

https://velog.io/@sdb016/RabbitMQ-%EA%B8%B0%EC%B4%88-%EA%B0%9C%EB%85%90

 

결과

Spring API에서는 계속해서 사용자의 테스트 결과를 RabbitMQ로 적재하고,

API의 동작 여부와 관계 없이 Flask에서는 계속해서 Queue를 지켜보며 적재된 메시지가 있으면 가져온다.

적재된 메시지가 여러 개 있을 경우에는 Flask 서버 두 개가 메시지를 나눠가진다.

ex) 1번, 2번, 3번 메시지가 있다고 할 때
1번을 Flask1이 받고, 2번은 Flask2가 받는데, 1번이 오래걸려서 2번이 먼저 끝난다고 가정하면
3번 메시지는 분석이 끝난 Flask2이 받아 분석을 시작한다.

 

👉 MQ를 통해 MSA를 구축함 (각 서버의 의존성 줄임)

👉 계속해서 실시간으로 데이터 보정을 진행함으로써 추천 시스템의 정확성 높임

 

---

📌 RabbitMQ의 자세한 구현 방식은 아래 글을 참고해주세요!

https://seolhee2750.tistory.com/267

[Web] 로컬 환경에서 SpringBoot와 Flask에 RabbitMQ 적용하기

 

---

참고

• https://kamang-it.tistory.com/entry/AMQPRabbitMQRabbitMQ%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0%EC%99%80-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95-1
• https://xzio.tistory.com/2024