📘Redis 도입 이유 및 장단점, 설계 방식
이전 프로젝트 내용 정리
배경
- 우리 서비스는 하루 약 50,000건의 예약 알림 트리거가 발생
- 기존 메시지 허브 구조에서는 메시지 유실과 중복 발송 위험이 존재
- 이에 따라, 발송 예약 정보와 플래그 관리를 Redis에서 처리하는 방식을 시도
- 이를 통해 데이터 유실 위험을 줄이고 추후 대량 트래픽에 대한 대응 점검
Redis 도입 이유
1. 실시간성 및 고성능 처리
- Redis는 메모리 기반 구조로 읽기/쓰기가 매우 빠름
- 하루 50,000건 수준의 알림 트리거나 플래그 처리는 Redis에서 부하가 거의 없음
- 스케줄러, 트리거 등 알림 관련 실시간 처리가 가능
2. TTL(만료) 및 데이터 관리의 용이함
- Redis는 key 별로 TTL(만료시간) 설정이 가능
- 알림 예약·중복 체크 등 단기성 데이터의 자동 삭제가 매우 간단
- 불필요한 데이터가 장기간 쌓이는 문제 없이 운영 부담을 최소화
3. 구조 단순화 및 유실 방지 보조 역할
- 중복 체크, 예약, 만료, 삭제 등 상태 관리를 간결하게 구현
- 장애나 일시적 서버 이슈로 인한 메시지 유실 가능성에 대비해 Redis에 예약 정보를 저장함으로써 메시지 유실 방지의 보조 역할도 수행할 수 있다.
- 전체적으로 운영 및 코드 복잡도가 크게 줄어들고, 신뢰성까지 함께 확보할 수 있다.
Redis 처리량과 서비스의 예상 처리량 비교
1. Redis 성능 여유
- Redis는 인메모리 데이터베이스 → 단일 노드 기준으로도 초당 수만~수십만 건의 읽기/쓰기 처리(QPS)가 가능
- 하루 50,000건 → 트래픽이 몰리는 시간(하루 5시간 정도)에도 초당 수~수십 건 수준
2. 메모리 사용량
- 알림 데이터 1건이 1KB라고 가정해도 하루 50,000건 × 14일 = 700,000건 → 700MB 미만 (실제는 더 적음)
- Redis 서버가 1~2GB 메모리만 있어도 충분히 감당가능
3. TTL 적용으로 데이터 자동정리
- 데이터가 쌓여도 만료(TTL)로 계속 자동 삭제 → 누적/성능 저하 우려 거의 없음
4. 실제 기업 사례
- 카카오, 쿠팡, 배민 등에서 하루 수백만~수천만 건을 Redis 단일/클러스터로 처리
- 서비스 초기, 중견 규모(수만~수십만 건/일)는 Redis로 충분히 운영 가능
Redis 설계 방식
- 알림 예약 정보
- ZSet(정렬된 집합)에 알림 식별자(unique key)를 score(알림 예정 시각)와 함께 저장
- Hash에는 고유키로 전체 객체를 저장 (상세 데이터 관리)
- 수정, 삭제 시 성능 이점 및 관리 용이
- 저장을 두번씩 하기때문에 데이터 사용량 증가
- “하루 전 알림” 발송
- 스케줄러 30분마다 발동
- score(알림 예정 시각) 로 조회 후 발송
- 발송된 알림은 “발송된 키” 로 별도 보관 → “30분 전 알림” 에 영향 없도록 설계
- “30분 전 알림” 발송
- 스케줄러 1분마다 발동
- 30분 전 알림은 Notification 도메인으로 발송 성공 시 즉시 삭제.
- 발송 실패 시 미 삭제. 다음 스케줄러에 재시도
Redis의 장점
- 빠른 처리 속도: 5,000건/일 기준 Redis는 병목 없이 빠르게 동작한다.
- 자동 만료: TTL로 인한 자동 데이터 정리가 강점.
- 운영 단순화: 추가적인 배치, 데이터 클린업 코드가 최소화된다.
- 분산 환경 적합성: 여러 서버가 동시에 동일한 상태 정보를 쉽게 공유한다.
- 유연한 구조: 알림 상태, 플래그 등 비정형 데이터 관리가 자유롭다.
Redis의 단점 및 유의점
- 데이터 영속성: 메모리 기반이므로 장애/재시작 시 데이터 유실 위험이 있다.
- 장기/영구 데이터 관리에는 부적합(단기 데이터에는 문제 없음)
- TTL만으로 의존 시 남아있는 데이터:
- 스케줄러/로직 누락 등으로 TTL/삭제가 실패하면 “좀비 데이터”가 남을 수 있다.
- 주기적 Clean-up(스케줄러) 또는 TTL 재확인 필요
- 복잡한 쿼리 부적합:
- 복합 검색/조인은 어렵다. 단순한 키/값, set/zset/hash 구조에 적합
도입 결론
- 일일 50,000건 예약 트리거, 한 달 이내 단기 데이터라는 조건에서 Redis 최적
- 실시간 처리, TTL 기반 자동 만료, 분산 환경 지원, 운영 구조 단순화 효과
- TTL 누락, 장애 상황, 대량 트래픽 등 보완 필요 시 추가 구조 적용
- 단기 데이터 처리 중심, 빠른 대응력, 추후 확장성 증가
기어 올라가는 개발