락 대신 MQ로 동시성을 해결하고자하는데 성능이 안좋습니다.

Question

안녕하세요. 현재 쿠폰과 비슷한 선착순 이벤트 기능을 구현하고, 계속 성능 고도화를 하고있습니다.처음에는 락을 사용하다가 RabbitMQ를 도입하여 구현하였습니다.우선 반드시 데이터 정합성이 보장되어야 하는 임계구역에 총 4번의 SQL 연산이 있고(멤버 조회, 이벤트 조회, 멤버 업데이트, 이벤트 업데이트) 이후 후처리로 (내역 인서트, 이벤트 종료 여부 판단 -> 판단 후 종료 시 SQL 업데이트, SQL 인서트)로,하나의 요청에 적으면 총 5번의 DB 연산, 많으면 7번의 DB 연산이 일어납니다.현재 하나의 API 요청에 대해 임계구역은 RabbitMQ를 통해 직렬 처리하고, 후처리는 응답 이후 비동기로 분리하는 구조로 구현을 하였습니다.[1] 사용자 요청 → Controller 도착 → RabbitMQ Producer.publish() → 메시지 MQ에 보냄 → HTTP 200 OK 응답 반환 [2] Consumer → 임계구역 처리 (멤버/이벤트 조회 & 업데이트) → 후처리 Async로 호출 [3] 후처리 Async → 참여 내역 저장, 종료 여부 확인 후 종료 시 (1)이벤트 업데이트 및 (2)이벤트 인서트 RabbitMQ를 도입한 뒤에 당연히 비관적 락을 사용했을 때 보다 성능은 좋아졌지만, 제가 설정한 목표치에 도달하지는 못해서 도움을 좀 얻고자 이렇게 글을 작성하게 되었습니다.어떤 방법을 쓰면 순차성을 유지하면서, 동시성문제도 해결하면서, 성능도 좋아질 수 있을까요?현재는 Producer를 호출하고 바로 응답을 줘서 마지막 사용자가 당첨인데 사용자가 당첨됐는지 안됐는지 여부를 바로 응답을 주지 못하고, 응모 완료되었습니다 라는 답밖에 주지 못하고있습니다.RPC방식으로 RabbitMQ의 convertSendAndReceive() 같은 동기 요청-응답 구조를 쓴다면 당첨 미당첨 여부로 응답을 줄 수 있다고 하는데, 그럼 동기 요청을 사용하다보니 성능 저하가 또 우려되는데 다른 좋은 방법이 있을까요?코린이 도와주시면 감사하겠습니다.. 밤낮없이 고민 고민 고민 하는데도 어렵네요..ㅠㅠ

yeori · Accepted Answer

응모 및 당첨여부 절차를 살짝 바꿔서 구현 난이도를 낮추는 것도 한 가지 방법입니다.응모하자마자 바로 응답에 당첨 또는 종료여부를 반환하기보다는,응모 요청은 접수됐다고 응답을 보내고, 여기에 접수 uuid를 보내줌.그리고나서 곧바로 프론트엔드에서 1~2초 단위로 uuid를 보내서 결과 조회 요청을 보냅니다. 보통 2번, 3번이면 충분하고 사용자 입장에서 잠깐동안 두근두근 기다리는 맛이 있음.보통 2~3초 정도면 충분합니다.백엔드에서는 100ms 마다 접수된 응모 요청을 가져다가 처리해 줌. 쌓여있는 요청을 전부 가져올 필요는 없습니다. 1000개 중에 현재 350개 처리됐으면 최대 650개만 가져오고, 전부 당첨 처리함.이렇게 1000개가 다 찼으면 이벤트 자체를 종료시킵니다. 그래야 뒤에 들어오는 요청들을 막을 수 있습니다.그리고 후처리 task로 넘겨서 나머지 쌓여있는 요청들 취소 처리하고, 로그 남기고 업체에 아벤트 결과 보내고, 당첨자한테 메일 보내는 등의 잡다한 일을 처리함.한 방 쿼리처럼 한 방 메소드도 가급적 피하는 게 좋습니다.메소드 한 곳에서 이벤트 재고 확인하고, 참여자 등급 조회하고, 중복있는지 체크하고, 당첨됐으면 재고 줄이고, 재고 오링나면 이벤트 종료 처리하고, 무시기 온갖 작업을 전부 처리하면 메소드가 엄청나게 두꺼워집니다.우리는 이벤트같은 거 별로 안 한다면 상관없는데, 매월 매 분기 매 주 이런 행사가 있다면 주파수를 쪼개듯이 task 별로 나누는 게 유지보수하기 좋습니다.

캐티 · Answer

FIFO 1:1로 하였음 긍정에 여지가 없었쩌. 위에서 분산처리기를 목적으로 하여요.Reliability Guide | RabbitMQ원자적 프로세스는 일반적으로 작은 블록을 처리하여야 지대한 성능을 이루어내는 여지가 있어요. 위에 서술에서 큰 블록을 처리하려고 하였다는 부분에서 터져버린거 아니나요.빈 MQ 서버를 구축하고 부하 테스트를 쳐보아요. 이렇게 하면 어디어디서 병목이 나는 거인지 정밀한 판단에 여지가 나요.

더미 · Answer

원하는게 실시간 응답이라면 동기로 가야되는겁니다.

CooH · Answer

AI에 물어봤습니다.임계구역(정합성이 꼭 맞아야 하는 핵심 연산)은 큐로 쪼개지 말고 한 트랜잭션으로 짧고 굵게 처리하세요. 그 바깥의 것들만(로그, 알림, 통계, 후처리) MQ 같은 걸로 비동기화하는 게 맞습니다.이벤트 단위 공정성이 필요하면 MQ에서 이벤트ID 기반 샤딩을 하세요. 샤드 내부는 컨슈머 1개로 유지(순서 보장), 샤드 간엔 병렬이니 샤드 수만 늘리면 병렬도도 같이 오릅니다.즉시 응답이 꼭 필요하면 Redis 임시예약(토큰)을 얹어 ms급 판정을 주고, 컨슈머가 DB 트랜잭션으로 최종 확정 + 보상(INCR)을 수행하게 하세요.API: DECR remaining_cache가 0 이상이면 즉시 ‘당첨’ 응답 + 토큰 발급 → 컨슈머가 토큰 검증 후 DB 확정.음수면 즉시 ‘매진’ 응답.단, DB와 Redis 이중원장 복잡도가 생기니 필요할 때만.

락 대신 MQ로 동시성을 해결하고자하는데 성능이 안좋습니다.

4개의 답변

#rabbitmq 목록