문제 상황
게시물 조회수와 포인트 랭킹 등과 같은, 데이터를 실시간으로 정확하게 처리해야 하는 것이 중요한 상황에서, 기존 시스템은 다음과 같은 문제(한계)를 가지고 있었습니다:
- DB 부하 및 응답 지연
- 게시물 조회수와 포인트 랭킹(예: 실시간 유저 랭킹, 지난달 유저 랭킹 등) 등을 조회할 때 데이터베이스 조회가 느려졌습니다. 조회수가 많은 인기 게시물에서는 동시 조회 요청이 많이 쏟아지면서 DB에 과도한 부하가 발생했습니다.
- 실시간 데이터 처리의 한계
- 조회수를 DB에 저장하는 방식으로는 비정상적인 조회수 증가(어뷰징)를 실시간으로 확인하거나 조치하는 것이 어려웠습니다.
- Refresh Token 관리의 비효율성
- DB로 관리할 경우, 불필요한 부하와 비효율성이 발생하는, 사용자 인증을 위한 Refresh Token을 효율적으로 관리하려면, 일정 시간이 지나면 자동 삭제되는, 단기 데이터를 처리할 메커니즘이 필요했습니다.
도입 이유 및 해결 방안
Redis는 데이터를 인메모리 방식으로 빠르게 처리할 수 있어, 실시간 데이터 처리의 요구를 충족시키기에 적합했습니다.
'PORTFOLIO > TECHNICAL DECISION-MAKING' 카테고리의 다른 글
[ACE Hand Wash - 기술적 의사 결정]코드 정리 대작전: 권한 확인 로직, 어디까지 분리해봤니? (0) | 2025.01.08 |
---|---|
[CodeChef - 기술적 의사 결정] Redis Sentinel 도입이 필요한 이유 (0) | 2025.01.06 |
[CodeChef - 기술적 의사 결정] Docker Hub? AWS ECR? (0) | 2025.01.06 |
[CodeChef - 기술적 의사 결정] CI/CD 툴, Jenkins? Github Actions? (0) | 2025.01.06 |
[CodeChef - 기술적 의사 결정]이벤트 동시성 제어 (0) | 2025.01.06 |