Redis 기초 정리 — 왜 쓰는가, 어디에 두는가, 누가 쓰는가

Об этом предложении

강의 1~4강 내용을 요약하고, 따로 알아두면 좋을 내용을 덧붙인 정리입니다. 1. Redis를 쓰는 이유: Disk vs Memory RDB가 느려지는 지점 MySQL, PostgreSQL 같은 RDB는 데이터를 디스크(SSD/HDD) 에 저장한다. 장점: 전원이 꺼져도 데이터가 남고(영속성), 용량 대비 저렴하다. 단점: 읽기/쓰기마다 Disk I/O 가 발생하고, 트래픽이 늘면 대부분 여기서 병목이 생긴다. 속도 차이 (대략적인 수치) 저장 위치 조회 시간 L1 Cache ~0.5 ns RAM ~100 ns SSD 100 150 μs HDD 5 10 ms RAM은 SSD보다 약 1,000배 이상 빠르다. 트래픽이 늘 때 DB 서버 사양만 올리는 것(Scale-up)은 비용 효율이 나쁘다. Redis는 데이터를 메모리에 두는 In-Memory 데이터 구조 저장소 여서 디스크 접근을 줄이고 응답을 빠르게 만든다. ✍️ 추가로 기억할 점 위 수치는 저장 매체 자체 의 차이다. 애플리케이션에서 Redis를 호출하면 네트워크 왕복(보통 수백 μs ~ 1ms 안팎) 이 붙기 때문에, 체감 차이가 1,000배까지 나지는 않는다. 그래도 DB 쿼리(인덱스 탐색, 락, 디스크 읽기)에 비하면 훨씬 빠르고 DB 부하를 줄인다 는 효과가 더 크다. Redis가 빠른 이유는 메모리뿐이 아니다. 명령을 싱글 스레드로 처리 해서 락 경쟁과 컨텍스트 스위칭이 없고, I/O 멀티플렉싱으로 많은 연결을 동시에 받는다. (6.0부터 네트워크 I/O는 멀티스레드 옵션이 있지만 명령 실행은 여전히 싱글 스레드) 그래서 KEYS * , 큰 컬렉션 전체 조회 같은 O(N) 명령 하나가 전체를 막을 수 있다. 운영에서는 SCAN 을 사용한다. 2. 로컬 캐시 vs 글로벌 캐시(Redis) 모든 데이터를 Redis에 넣으면 안 될까? 비용 : RAM은 디스크보다 훨씬 비싸다. 휘발성 : 메모리는 전원이 꺼지면 사라진다. 백업 기능이 있어도 영구 보관은 디스크 기반 RDB가 유리하다. 로컬 캐시 애플리케이션 내부 메모리( HashMap , ConcurrentHashMap 등)에 데이터를 담는 방식이다. 네트워크를 타지 않아서 가장 빠르다. 대신 서버가 꺼지면 사라지고, 해당 서버에서만 볼 수 있다. 분산 환경에서 생기는 문제: 데이터 부정합 서버가 여러 대(Scale-out)일 때 로컬 캐시만 쓰면 이런 일이 생긴다. 1번 서버가 "홍길동"을 로컬 캐시에 저장한다. 이름 수정 요청이 2번 서버로 가서 DB는 "고길동"으로 바뀐다. 다음 조회가 1번 서버로 가면 캐시에 남은 옛 값 "홍길동" 을 보여준다. → 요청이 어느 서버로 가느냐에 따라 데이터가 달라 보인다. Redis = 모든 서버가 함께 보는 중앙 저장소 어느 서버가 수정하든 하나의 저장소 를 보므로 정합성을 맞추기 쉽다. 캐시/세션을 서버 밖에 두니 서버를 Stateless 하게 만들 수 있어 확장이 쉬워진다. 구분 로컬 캐시 글로벌 캐시(Redis) 속도 가장 빠름 (네트워크 X) 빠름 (네트워크 O) 일관성 서버 간 공유 불가 모든 서버가 같은 데이터 적합한 데이터 변경 적은 데이터(국가코드, 설정값) 공유·자주 바뀌는 데이터(세션, 재고, 이벤트) ✍️ 추가로 기억할 점 실무에서는 둘 중 하나만 고르기보다 2단계 캐시(Local → Redis → DB) 를 쓰는 경우도 많다. (Java에서는 Caffeine + Redis 조합이 흔함). 이때 로컬 캐시 무효화는 Redis Pub/Sub 등으로 서버들에 알려준다. Spring에서는 spring-session-data-redis 로 세션을 Redis에 두면 Sticky Session 없이 서버를 늘릴 수 있다. HashMap 을 캐시로 쓸 때는 만료(TTL)와 최대 크기 제한이 없어서 메모리가 계속 늘 수 있다. 직접 구현하기보다는 캐시 라이브러리를 쓰는 편이 안전하다. 3. Redis의 위치: RDB와 함께 쓰는 하이브리드 구조 역할 분담 RDB : 신뢰성이 우선. 최종적으로 정확하다고 보는 원본 저장소(Source of Truth) Redis : 속도가 우선. 자주 쓰는 데이터의 임시 보관소 + 빠른 연산소 Redis는 RDB를 대체하지 않고 보완 한다. Cache-Aside (Look-aside) — 가장 많이 쓰는 읽기 전략 애플리케이션이 먼저 Redis를 조회한다. Cache Hit → 바로 반환한다. Cache Miss → DB에서 조회한다. 조회한 값을 Redis에 저장한 뒤 응답한다. Client → Web Server → Redis (Hit이면 바로 반환) ↘ DB (Miss일 때 조회 후 Redis에 저장) 쓰기 전략 Write-Through : 쓸 때 Redis와 DB를 함께 갱신한다. 최신 상태를 유지하지만 쓰기가 느려진다. Write-Back (Write-Behind) : Redis에 먼저 쓰고, 나중에 DB에 모아서 반영한다. 쓰기 성능은 좋지만 반영 전에 Redis가 죽으면 유실 될 수 있다. (조회수, 좋아요 집계, 로그 등에 사용) 왜 섞어 쓰는가 유실 위험 : 중요한 데이터는 RDB에 남아 있어야 한다. 비용 효율 : 자주 쓰는 일부 데이터만 RAM에 두고 나머지는 디스크에 둔다. (파레토 법칙) ✍️ 추가로 기억할 점 TTL은 거의 필수다. 만료 시간 없이 캐싱하면 DB와 값이 어긋난 채로 계속 남을 수 있다. 수정 시에는 캐시를 갱신하기보다 삭제(Evict)하는 편이 안전한 경우가 많다. 두 요청이 동시에 갱신하면 순서가 꼬여 옛 값이 남을 수 있기 때문이다. (DB 수정 → 캐시 삭제 → 다음 조회 때 다시 채움) Cache Stampede (Thundering Herd) : 인기 키가 만료되는 순간 많은 요청이 동시에 DB로 몰리는 현상이다. 락, 만료 전 미리 갱신, TTL에 랜덤값(jitter) 추가 등으로 완화한다. Cache Penetration : DB에도 없는 키를 계속 조회하면 매번 DB로 간다. "없음" 결과도 짧은 TTL로 캐싱하는 방법이 있다. 메모리가 가득 차면? maxmemory 와 maxmemory-policy 로 동작을 정한다. 캐시 용도라면 보통 allkeys-lru 나 allkeys-lfu 를 쓴다. 기본값 noeviction 은 가득 차면 쓰기가 에러 난다. 용어 주의 : Redis의 영속성 옵션인 RDB(스냅샷 파일) 와 관계형 DB를 뜻하는 RDB 는 다른 개념이다. Redis 영속성은 RDB(주기적 스냅샷) 와 AOF(명령 로그 기록) 두 가지다. 4. 글로벌 기업의 Redis 활용 사례 서비스 문제 Redis 활용 주로 쓰는 자료구조 Twitter(X) 팔로워 수천만 명의 타임라인을 즉시 보여줘야 함 유저별 타임라인을 미리 만들어 저장 List Netflix 이어보기·추천을 빠르게 보여줘야 함 시청 기록, 찜 목록 등 개인화 데이터 캐싱 Hash, Set 등 쿠팡 등 이커머스 선착순 이벤트에 요청이 몰리면 DB 락 병목 DB 부하 차단 + 원자적 연산 으로 재고 처리 String( DECR ), Lua 온라인 게임 실시간 순위를 매번 ORDER BY 로 계산하면 부하 점수 기반 정렬 저장 Sorted Set Redis를 많이 쓰는 3대 영역 Caching : 반복 조회를 빠르게 Real-time Stats : 순위, 조회수, 재고 같은 실시간 계산 Session Management : 여러 서버가 인증 정보를 공유 ✍️ 추가로 기억할 점 Twitter의 타임라인 방식은 Fan-out on Write 다. 글을 쓸 때 팔로워 타임라인에 미리 넣어둔다. 다만 팔로워가 너무 많은 계정은 쓰기 비용이 커서, 이런 계정은 읽을 때 합치는 방식(Fan-out on Read) 을 섞는다. 선착순 재고가 Redis에서 안전한 이유 : 명령이 싱글 스레드로 하나씩 실행되므로 DECR , INCR 하나하나는 원자적이다. 하지만 "조회 후 차감"처럼 명령 여러 개를 이어 붙이면 원자성이 깨진다. 이 경우 Lua 스크립트 나 MULTI/EXEC 로 묶어야 한다. Sorted Set 순위 조회 ( ZRANK , ZREVRANK )는 O(log N)이다. 데이터가 많아도 빠른 이유가 여기에 있다. 분산 락이 필요하면 SET key value NX PX <ms> 나 Redisson 같은 라이브러리를 쓴다. 라이선스 이슈 : 2024년 Redis가 라이선스를 변경하면서 Linux Foundation 쪽에서 Valkey 라는 포크가 나왔다. 이후 Redis 8에서 AGPL 옵션이 추가됐다. AWS ElastiCache 등 클라우드 서비스를 고를 때 한 번쯤 확인할 만하다. 📌 한 줄 요약 디스크는 안전하지만 느리고, 메모리는 빠르지만 비싸고 휘발성이다. 서버가 여러 대라면 로컬 캐시만으로는 데이터가 어긋나므로 중앙 저장소로 Redis 를 둔다. Redis는 RDB를 대체하지 않고, Cache-Aside 로 앞단에서 DB 부하를 막는다. 캐싱할 때는 TTL, 무효화 방식, Stampede, 메모리 정책 을 함께 설계해야 한다.