Cache vs MQ 성능 개선을 위해 무엇을 도입해야 할까??

최근 성능 개선을 위해 Redis(캐시)나 Kafka(메시지 큐)를 가장 먼저 떠올리곤 합니다. 결론부터 말하면 성능 저하의 정확한 원인을 파악하여 읽기 성능의 병목을 해결하기 위한 캐시 도입인지, 혹은 쓰기 및 데이터 저장이나 복잡한 로직 처리의 부하를 분산하기 위한 메시지 큐 도입인지를 명확히 결정하는 것입니다.

 

 

캐시(Cache)

캐시는 자주 사용하는 데이터나 복잡한 계산 결과를 메모리에 미리 저장해 두었다가 필요할 때 즉시 재사용함으로써, 데이터 접근 시간을 단축하고 데이터베이스의 읽기 부하를 효과적으로 줄여주는 기술입니다.

 

 

좋은 상황

• 반복되는 데이터 조회: 동일한 데이터(예: 공지사항, 베스트 상품 목록)를 반복해서 조회하는 경우
• 계산 비용이 큰 작업: 복잡한 쿼리나 통계 작업 결과를 매번 계산하기 부담스러울 때
• 읽기 처리: 읽기 관련 로직인 경우

성능 개선 부분

• 응답 속도 향상: DB 대신 메모리에서 데이터를 가져오므로 응답이 향상됩니다.
• DB 부하 분산: 캐시에서 요청을 처리(Cache Hit)하면 DB까지 요청이 가지 않아 DB 자원을 아낄 수 있습니다.

 

메시지 큐(Message Queue)

메시지 큐는 시스템 간의 요청을 즉시 처리하지 않고 대기열(Queue)에 담아 비동기 방식으로 처리함으로써, 시스템 간의 결합도를 낮추는 역할을 합니다.

 

 

좋은 상황

• 비동기 처리가 가능한 작업: 눈앞에서 바로 보여줄 필요 없이 뒤에서 몰래 처리할 수 있는 작업 (회원가입 후 환영 이메일 발송)
• 트래픽 서지(Traffic Surge) 발생: 이벤트 오픈 등으로 갑자기 쓰기 요청이 폭주하여 DB가 버티지 못할 때.
• 시스템 간 통신: 서비스 간의 직접적인 연결을 피하고 독립적인 확장을 원하는 경

성능 개선 부분

• 사용자 체감 속도 개선: 무거운 작업을 백그라운드로 돌리고 사용자에게는 즉시 응답을 반환합니다.
• 시스템 안정성(Throttling): 폭주하는 요청을 큐에 쌓아두고, 서버가 처리할 수 있는 속도만큼만 가져와 처리하여 시스템 붕괴를 막습니다.

 

결론

성능 저하의 근본적인 원인이 잦은 조회나 반복되는 계산 결과로 인한 읽기 병목이라면 캐시를 통해 응답 속도를 높이고 DB 부하를 줄여야 하며, 반대로 특정 이벤트 시점의 쓰기 요청 폭주로 인한 시스템 마비가 우려되거나 즉각적인 처리가 필요 없는 비동기 작업이 주를 이룬다면 메시지 큐를 도입하여 시스템 안정성과 처리 효율을 확보하는 것이 올바른 방법입니다.

 

 

문제: 대기열 작업에 알맞은 해결책은?

일반적으로 메시지 큐가 요청을 대기열에 쌓아 시스템 안정성을 높이는 최선의 방법이라 생각하기 쉽지만, 일반적으로  Redis(ZSET)를 사용하는 것이 더 좋은 해결책이 될 수 있습니다.

 

그 이유는 첫째, UI/UX 때문입니다. 사용자에게 실시간으로 대기 순번을 안내해야 하는 환경에서 내부 상태 확인이 어려운 메시지 큐와 달리, Redis(ZSET)는 실시간 순위 조회가 가능하여 사용자에게 명확한 정보를 제공할 수 있습니다. 둘째는 중복 요청 처리의 효율성입니다. 메시지 큐는 중복된 요청도 개별적으로 처리하는 경향이 있는 반면, Redis(ZSET)는 동일한 Key 값을 가질 경우 자동으로 중복을 방지해주어 데이터 관리의 번거로움을 덜어줍니다. 마지막으로, 서비스 이용 도중 발생하는 사용자 이탈 대응에 있어서도 메시지 큐는 특정 작업을 중간에 취소하기 까다롭지만, Redis(ZSET)는 이탈한 유저를 즉각적으로 관리하고 제거할 수 있어 시스템 자원을 훨씬 효율적으로 운용할 수 있게 해줍니다. 실제로 ZSET는 랭킹 시스템에 사용하라고 만든 자료구조인 만큼 대기열 작업에 알맞는 솔루션입니다.

 

 

이상적인 아키텍트 구조

 

 

조회 및 관리 (Redis ZSET)

• 사용자의 진입 순서와 실시간 대기 순번을 관리합니다.
• 중복 진입 방지 및 이탈 자 관리를 실시간으로 처리하여 UI/UX를 개선합니다.

API 

• 사용자가 자신의 순례가 되었는지 확인하거나, 대기열 진입/이탈 요청을 처리

추가 비동기 작업 (Message Queue) 

• 대기열을 통과한 이후 비동기 처리가 가능한 결제, 데이터 생성, 알림 발송과 같은 무거운 로직들은 메시지 큐에 담아 시스템 부하를 효과적으로 분산함으로써 대량의 작업도 안정적으로 처리할 수 있습니다.