[요약] Part 3. 실무에서 가장 많이 쓰는 Redis 사용 패턴

실무 핵심 패턴 총정리

• 보안과 세션 관리 패턴
• 중앙 세션 저장소: 서버가 여러 대(스케일 아웃)로 늘어나더라도 로그인 상태가 풀리지 않도록, 모든 서버가 공통으로 바라보는 세션 공간으로 Redis를 활용합니다.
• 수명이 짧은 데이터 최적화: 이메일이나 SMS 6자리 인증 코드 등 단 몇 분만 필요한 데이터는 메인 DB에 넣지 않습니다.
• TTL 자동화: 만료 시간(TTL)을 지정하면 불필요한 데이터를 직접 지우는 로직을 작성할 필요가 없어 보안과 성능을 모두 챙길 수 있습니다.

• API 방어와 트래픽 제어 패턴
• Rate Limiting(처리율 제한): 초당 수백 번의 무차별 로그인 시도나 과도한 API 호출로부터 시스템을 보호하는 방패 역할을 합니다.
• 메모리 카운터: 매 요청마다 IP별 접근 횟수를 더해야 하므로 압도적으로 빠른 인메모리 구조가 필수적입니다.
• 자동 초기화: 카운터 키에 TTL을 설정해 특정 주기(예: 1분)가 지나면 카운터가 메모리에서 자연스럽게 지워지도록 설계해야 합니다.

• 일시적 상태와 무거운 통계 단기 캐싱
• 빈번한 상태 업데이트: 대용량 파일 인코딩 0%~100% 진행률처럼 디스크 I/O를 발생시키기엔 아까운 임시 상태 값을 저장합니다.
• 무거운 쿼리 방어: 수백만 건을 그룹핑하는 랭킹 등 무거운 쿼리 결과를 1분~5분간 캐싱해두어 메인 DB의 부하를 획기적으로 낮춥니다.
• 캐시 스탬피드 주의: 단기 캐시가 일시적으로 만료되는 그 짧은 순간, 수백 개의 요청이 동시에 메인 DB로 돌진하는 현상에 대비해야 합니다.

• 빠른 중계소: Pub/Sub 메세징
• 실시간 통신 연결: 채팅 서버가 여러 개일 때 서버들끼리 이벤트를 주고받는 고속 도로 역할을 합니다.
• 저장하지 않는 가벼움: 보낸 메시지를 영구히 보관하지 않고 현재 구독 중인 사람에게만 "발송 후 망각(Fire and Forget)" 합니다.
• 수신 보장 불가: 결제 완료 알림처럼 반드시 도달해야 하는 핵심 비즈니스 로직에는 순수 Pub/Sub만을 의존해서는 안 됩니다.

1. 로그인 유지(세션) -> (읽기/쓰기가 빈번, TTL 며칠) -> Redis 적합
2. 비밀번호 찾기 인증 코드 -> (초단기 생존, TTL 3분) -> Redis 적합
3. 무차별 로그인 차단(Rate Limit) -> (초당 수십 번 증가) -> Redis 적합
4. 무거운 통계 캐시 -> (캐시 미스 대비 필요, TTL 분 단위) -> Redis 적합
5. 결제/주문 내역 -> (절대 날아가면 안 됨) -> PostgreSQL 필수

반드시 기억해야 할 원칙 3가지

• "이 데이터가 내일 아침에도 의미가 있는가?" 고민하기 (아니라면 Redis 고려)
• "과도한 I/O가 메인 DB를 뻗게 만들 수 있는가?" 방어하기 (맞다면 Redis 방패 세우기)
• "모든 임시 데이터에는 수명(TTL)이 있는가?" 확인하기 (메모리 폭발 방지)