게시글 조회수 설계 고민과 이 과정에서 Redis를 선택한 이유와 방식에 대해 작성해두려고 한다.
조회수 설계
- 어뷰징 방지 정책
- 사용자는 게시글당 10분에 1번만 조회수로 집계 / 10분 동안 같은 게시글을 100번 조회해도 조회수는 1번만 증가
- 데이터의 중요도와 일관성 - 조회수는 다른 데이터(댓글 수, 좋아요 수 등)처럼 정확해야 하는 데이터가 아니다. 즉, 약간의 불일치가 발생해도 사용자 경험에 큰 영향을 미치지 않는다.
- 게시글/댓글/좋아요 수 : 원본 데이터를 기반으로 개수가 파생되므로, 불일치가 발생하면 안 된다.
- 조회수 : 사용자가 직접 확인할 수 없으며, 정확한 개수보다 트래픽 분산이 중요하다.
- 데이터 저장 방식 - 조회수는 단순한 카운트 값이므로, 비정규화된 단일 레코드로 저장해도 충분하다.
- SQL에 정규화된 테이블로 저장할 필요 없이 단순한 키-값 저장소에 기록 가능
- 디스크 I/O 비용을 줄이기 위해 메모리 기반 저장소 활용
💡빠른 조회를 위해 in-memory database 사용
Redis
In-Memory Database로, 메모리에 데이터를 저장하여 빠른 읽기/쓰기가 가능하다.
조회수는 트래픽이 많고, 높은 처리량이 필요하기 때문에 Redis가 적합하다.
특징
- 고성능 : 디스크가 아닌 메모리에 저장되므로 빠른 속도 제공
- 키-값 저장소 : 간단한 조회수 데이터에 적합
- TTL(Time To Live) 지원 : 일정 시간이 지나면 자동 삭제 가능 (어뷰징 방지 적용 가능)
- 싱글 스레드 처리 : 동시성 제어가 간단
- 데이터 백업 지원 : AOF(Append Only File), RDB(Snapshot) 방식 제공
어뷰징 방지 적용
게시글 조회수의 어뷰징 방지가 필요하다.
- TTL 설정 : TTL을 10분으로 설정하여 같은 사용자가 같은 게시글을 여러 번 조회하는 것 방지
- 조회 요청 시 Redis 키 확인 : 조회 요청이 들어오면, Redis에서 해당 게시글에 대한 조회수 증가 여부를 확인, 이미 조회된 게시글이라면 조회수를 증가시키지 않으며, Redis에 키가 없을 경우에만 조회수 증가 진행
백업 설계
Redis는 휘발성이 있기 때문에 주기적인 백업이 필요하다. 이를 위해 MySQL에 일정 간격으로 백업하는 방식을 선택했다.
간단하게 개수 단위 백업 방식 적용
- 조회수 증가 시 특정 개수(100개)에 도달하면 MySQL로 백업 진행
- 성능 최적화를 위해 실시간 백업이 아닌 일정 간격으로 백업을 수행하는 방식
👉 조회수는 데이터 일관성이 비교적 덜 중요하고, 트래픽이 많아 성능 최적화가 필요했다. 이를 위해 Redis를 활용한 조회수 관리를 적용했고, 주기적인 MySQL 백업으로 데이터 유실을 최소화했다. 앞으로 프로젝트에서 조회수 외에도 Redis를 더 다양한 캐시 및 데이터 처리 방식에 활용해 볼 계획이다.
'프로젝트' 카테고리의 다른 글
[DB] 좋아요 수 설계 및 동시성 문제 해결 방법 (0) | 2025.03.04 |
---|---|
[DB] primary key 생성 전략 비교 (0) | 2025.02.27 |
[DB] 분산 처리를 위한 샤딩(Sharding) (0) | 2025.02.25 |
[MSA] 마이크로서비스 아키텍처(MSA)란? (0) | 2025.02.19 |