Spring Boot + MySQL로 구현한 선착순 이벤트 시스템 (1편)“매일 오후 1시에 선착순 100명에게 도서를 증정하는 이벤트 시스템”을 개발하게 되었습니다. 처음엔 단순해 보였지만, 높은 동시성과 정확성이 요구되는 이 과제는 생각보다 많은 도전 과제hyodeng.tistory.com 1편에서는 Spring Boot와 MySQL만으로 선착순 이벤트 시스템을 구현하고 그 한계점을 분석했습니다. 이번 글에서는 Redis Stream을 활용하여 시스템을 어떻게 개선했는지 그리고 그 결과로 성능이 어떻게 향상 되었는지 공유하고자 합니다. Spring + MySQL 구조에서의 문제점단일 서버 환경의 Spring Boot + MySQL 구조로 시스템을 구현했을 때 심각한 병목 현상들이 발견되었습니다.DB ..

“매일 오후 1시에 선착순 100명에게 도서를 증정하는 이벤트 시스템”을 개발하게 되었습니다. 처음엔 단순해 보였지만, 높은 동시성과 정확성이 요구되는 이 과제는 생각보다 많은 도전 과제를 안겨주었습니다.이 글에서는 Spring Boot와 MySQL만으로 시작해 어떤 문제에 직면했고, 어떻게 이를 분석하고 개선해 나갔는지 경험을 공유하고자 합니다. 요구사항 분석프로젝트 시작 시 다음과 같은 요구사항을 확인했습니다.매일 오후 1시에 선착순 100명 한정 이벤트 진행1분에 10만 건의 요청을 10분간 처리 (초당 약 1,666건)중복 응모 방지정확히 100명까지만 선발다음날 오후 1시에 당첨자 발표가장 핵심적인 요구사항은 초당 1,666건의 요청 중에서 정확히 100명만 선발하고, 동일 사용자의 중복 응모를..

현재 꾸미 서비스에는 좋아요/싫어요 기능의 동시성 제어를 위해 Redis를 사용하고 있었습니다.그러나 기능 분석 결과, Redis 사용이 오버 엔지니어링이라고 판단했습니다.Redis를 사용하지 않으려는 이유좋아요/싫어요 기능은 SNS 서비스와 달리 실시간성이 매우 중요한 기능이 아닙니다. 사용자들이 동시에 좋아요 버튼을 누르는 상황이 자주 발생하지 않으며, 초당 처리해야 할 트랜잭션 수가 많지 않습니다. 즉, 수 밀리초 단위의 즉각적인 반영보다는 좋아요 수의 정확성이 더 중요합니다. 추가적으로, Redis 사용으로 인한 여러 단점들이 존재했는데,추가 인프라 관리 오버헤드 발생Redis와 MySQL 간 데이터 동기화 로직 필요장애 상황에서 데이터 정합성 보장의 어려움시스템 복잡도 증가이번 기회에 JPA와 ..