Redis 도입 여부 결정하기

Redis 도입 배경 및 판단

선착순 이벤트 특성상 짧은 시간에 대량의 트래픽이 집중되며,
이 과정에서 동시성 제어 방식이 시스템 전체 안정성에 직접적인 영향을 준다고 판단했다.

초기에는 DB 비관적 락을 통해 동시성 문제를 해결할 수 있었으나,
비관적 락은 트랜잭션을 직렬화함으로써 DB를 단일 병목 지점으로 만들고,
특정 기능의 트래픽 증가가 다른 API의 응답 지연 및 장애로 전파될 위험이 있었다.

이에 따라 동시성 제어 책임을 DB에서 분리하고,
DB를 보호하는 방향의 구조가 필요하다고 판단했다.

⸻

Redis 도입 장점
1. DB 병목 제거 및 자원 보호

• Redis를 DB 앞단에 두어 애플리케이션 레벨에서 선제적으로 락을 관리
• 동시성 제어로 인한 DB 커넥션 점유를 최소화하여
이벤트 트래픽이 다른 서비스에 영향을 주지 않도록 분리

2. 확장성 있는 트래픽 처리 구조

• WAS Scale Out 시에도 DB 병목으로 처리량이 제한되는 구조를 제거
• Redis를 통한 분산 락으로 서버 확장 효과가 실제 처리량 증가로 이어지도록 설계

3. 분산 환경을 고려한 동시성 제어

• 단일 서버·단일 DB 환경에서는 비관적 락도 유효하지만
분산 환경에서는 중앙에서 락 상태를 관리할 수 있는 구조가 필요
• Redis 분산 락을 통해 여러 노드에서 발생하는 요청에 대해 일관된 동시성 제어 보장

4. 응답 속도 및 사용자 경험 고려

• 인메모리 기반 Redis를 활용해 선착순 이벤트와 같이 응답 지연에 민감한 기능을 빠르게 처리

• 병목 제거를 통해 메인페이지, 상품 목록 조회 등 선착순 이벤트 요청 이외 요청에 대한 응답 지연 가능성 제거

Redis 도입 VS 비관적락 + 커넥션 풀 조정

첫 번째 가설 실험
Redis를 DB 커넥션 요청을 줄이는 용도로 사용. 특정 API와 관련된 DB 커넥션 요청이 많을 경우 다른 API 요청이 지연되어 전체적인 서비스 성능이 나빠질 우려가 있기 때문에 Redis를 두어 이벤트 참여 요청으로 인한 동시성 제어는 Redis를 통해 DB 커넥션 요청을 줄이기 위한 목적으로 Redis 도입.
실제 Redis를 도입하였을 때 커넥션 요청이 어떻게 줄어드는지 실험



테스트를 하기전 평소 이벤트 참여 요청을 제외한 API 요청이 어느 정도 인지 가정을 하고, 선착순 이벤트 요청이 단시간에 얼마나 많은 요청이 올지를 계산하여 단시간 이벤트 요청에 부하를 주었을 때 서버가 감당 가능한 트래픽 수를 산정하고 그에따른 쓰레드 풀 조정으로 문제를 해결할 수 있다.
개인 프로젝트이기 때문에 가설을 설정하고 문제를 해결하는 과정이 중요하다. 여기서 가정은 요구사항이 될 것이고 내가 해결해야할 문제의 환경이 어떠한지를 나타내주는 지표일 것이다.

이를 통해 비관적 락의 한계를 인지하고 언제 Redis를 분산락을 도입하는게 효과적일지 결정할 수 있다.