1초에 수만 건의 트래픽이 몰리는 대형 서비스에서 RDBMS만으로 버티는 것은 불가능에 가깝습니다.
물리적인 디스크 I/O의 한계를 극복하고 쾌적한 사용자 경험을 제공하기 위해 Redis는 이제 선택이 아닌 '생존'을 위한 필수 인프라가 되었습니다.
오늘은 실무에서 Redis를 다룰 때 반드시 챙겨야 할 핵심 아키텍처와 전략을 정리.
1. Redis가 압도적으로 빠른 물리적 이유
기존 DB가 지하 서고에 있는 책을 가지러 가는 과정이라면, Redis는 책상 바로 위 '손 닿는 곳에 둔 책꽂이'와 같습니다.
- In-Memory의 위력: RAM은 전자의 이동만으로 데이터를 처리합니다.
메모리 접근 속도(약 120ns)는 아무리 빠른 SSD(약 50~150us)보다 최소 1,000배가량 빠릅니다. - 싱글 스레드와 이벤트 루프: 여러 일꾼이 복잡하게 락(Lock)을 걸고 싸우는 대신, 한 명의 초인적인 웨이터(이벤트 루프 다중화)가 모든 주문을 순차적으로, 하지만 미친 듯이 빠르게 처리하여 컨텍스트 스위칭 오버헤드를 없앴습니다.
2. 실무에서 가장 많이 쓰는 캐싱 전략
① Look-Aside (Cache-Aside)
가장 대중적인 방식으로 조회가 많은 서비스에 적합합니다.
앱이 캐시를 먼저 보고, 없으면 DB에서 가져와 캐시에 채워넣습니다.
장점은 Redis 장애 시에도 DB를 통해 서비스 유지가 가능하다는 안정성에 있습니다.
② Write-Back
모든 쓰기를 Redis에 먼저 하고 주기적으로 DB에 배치(Batch) 반영합니다.
좋아요 폭주나 실시간 이벤트 등 쓰기 트래픽이 몰릴 때 DB의 부하를 막아주는 강력한 무기이지만, DB 반영 전 Redis 장애 시 데이터 유실 위험이 있음을 인지해야 한다.
인기 상품 100개의 만료 시간을 똑같이 '정오 12시'로 설정하면 안 됩니다.
12시 정각에 캐시가 동시에 삭제되는 순간, 수만 명의 유저가 DB로 한꺼번에 몰려 서버가 다운된다
.해결책은 TTL 설정 시 1~5분 정도의 랜덤 난수(Jitter)를 더해 만료 시점을 분산해야 한다.
3. 현업 개발자가 반드시 추가로 알아야 할 운영 포인트
3.1 고가용성(HA) 구성 : Replication & Sentinel
실무에서 단일 Redis 인스턴스(Standalone)를 쓰는 것은 매우 위험합니다.
Master-Slave 복제를 통해 데이터를 실시간 백업하고, Master 서버가 죽었을 때 Sentinel이 이를 감지해 자동으로 Slave를 Master로 승격(Failover)시키는 구성이 필수이다.
3.2 메모리 정책 (Eviction Policy)
메모리는 한정된 자원입니다. 메모리가 가득 찼을 때 어떤 데이터를 지울지 결정해야 합니다.
- allkeys-lru: 가장 최근에 사용되지 않은 데이터를 삭제 (가장 추천되는 정책)
- volatile-ttl: 만료 시간이 설정된 키 중 수명이 가장 짧은 것부터 삭제
3.3 Big Keys & Hot Keys 피하기
싱글 스레드 특성상, 하나의 키에 너무 큰 데이터(Big Key)를 넣거나 특정 키 하나에만 트래픽이 몰리면(Hot Key) 전체 시스템이 멈춥니다.
대량의 데이터는 Hash나 여러 키로 쪼개어 저장하는 설계가 필요합니다.
DB 업데이트 시 캐시를 지울지, 아니면 새 값으로 바꿀지 고민되시나요?
실무에서는 'Active Invalidation', 즉 DB 수정 직후 캐시를 명시적으로 삭제(DEL)하는 방식을 기본으로 한다.
여기에 시스템 오류를 대비해 적절한 TTL을 이중 안전장치로 거는 것이 정석이라고 한다.
4. 마무리
단순 캐싱을 넘어 배달의민족 B마트 사례처럼 분산 락(Distributed Lock)을 통해 동시성을 제어하거나, Sorted Set을 활용한 실시간 랭킹 시스템을 구축하는 등 Redis는 활용도가 무궁무진합니다.
하지만 비싼 메모리 자원을 쓰는 만큼, 데이터의 수명(TTL)을 엄격히 관리하고 모니터링하는 습관을 가져야 한다.
참고 사이트
'인메모리 저장소 ,Redis 기초' 카테고리의 다른 글
| [Backend] 데이터 성능의 핵심, Redis 기초] (0) | 2026.05.11 |
|---|