개발/이론 고찰
Redis 저장소 [왜 Redis여야 하니?]
1223v
2025. 2. 3. 23:38
고민의 시작
- 저번 내용에서는 토큰인지 세션인지에 대한 문제는 다루었다.
- 그래서 여러 부분을 고려해 토큰을 채택했다.
- 토큰을 채택하며, 보안을 위해 AT, RT를 분리하게 되었다.
💡 이부분에서 RT를 어디에 보관해야 하는가? 로 했을때, 인메모리 스토리지로 여러가지 선택지가 존재했다.
왜 이 고민이 필요해?
- 항상 관리 포인트를 늘리면서 기술을 도입하는 행위는 늘 아쉬움이 남았다.
- 무엇보다도 인메모리 스토리지를 도입했을 때 기술 및 관리 포인트를 늘리 면서까지 기술을 도입했을때의 압도적인 강점이 존재해야 한다.
- 그러기 위해서는 유사한 스펙을 가진 두 기술의 각 장점과 단점을 명확히 파악하고 현재 우리 서비스에 적합한 기술을 도입하는 것이 중요하다고 판단했다.
Redis vs Memcached
Redis의 장 / 단점
장점
- 디스크에 데이터를 기록하고 있기 때문에, Redis 메모리가 날라가도 데이터를 복구할 수 있다.
- → 스냅샷 (RDB) 방식 | Write / Update Event 로그(AOF) 방식
- 다양한 포멧 지원 (String, List, Set, Sorted Sets, Hash) ⇒ 애플리케이션 단에서 데이터 저장 편함
- 데이터 삭제 정책이 다양하다 (이유: 단순한 캐시 시스템이 아닌 데이터 저장소라는 목적성 존재)
삭제 방식 | Redis | Memcached |
---|---|---|
수동 삭제 (Manual Deletion) | 지원 (DEL , UNLINK , FLUSHALL , FLUSHDB ) |
지원 (delete , flush_all ) |
TTL(만료 시간)에 따른 자동 삭제 | 지원 (EXPIRE , TTL , PTTL ) |
지원 (set key value expiration_time ) |
LRU(Least Recently Used) 삭제 | 지원 (다양한 eviction 정책) | 지원 (기본 LRU) |
LFU(Least Frequently Used) 삭제 | 지원 (Redis 4.0부터) | 미지원 |
Lazy Deletion (요청 시 삭제) | 지원 | 지원 |
Active Expiration (백그라운드 삭제) | 지원 (주기적으로 만료된 키 삭제) | 미지원 |
result.
메모리 제한이 있는 환경에서 데이터 제거 정책으로 데이터 관리 효율 가능케 한다.
데이터 제거 정책에 대해 이야기하면 너무 길어지므로 따로 나중에 작성해 올리겠습니담..
단점
- 메모리를 2배로 사용한다.
- 레디스는 싱글스레드로 스냅샷을 뜰 때, 자식프로세스를 하나 만들고 새로 변경된 메모리 페이지를 복사해서 사용한다. (Copy-on-write 방식)memcached는 내부적으로 slab 할당자를 사용하고 있어 메모리 파편화 문제가 덜하다.
- But, 데이터 변경이 잦은 경우 메모리 파편화가 발생하기 쉬움.
- 즉, memcached는 한번 입력 후, 변경되지 않은 정보를 저장할 때 유용
- 레디스에 비하면 메타 데이터를 적게 사용하기 때문에 메모리 사용량이 상대적으로 낮다.
- ⇒ 레디스는 메모리를 직접 처리할 수 없어 메모리 파편화가 발생하기 쉬움
결론
위에서 볼 수 있듯이 redis의 장점을 간단하게 요약하면 아래와 같다.
- TTL 관리와 유연한 데이터 삭제 옵션 제공 (allkeys-lru, allkeys-lfu, volatile-lru 등)
- 데이터 영속성 제공(AOF, 스냅샷)
- 잦은 데이터 변경으로 인한 memcached , redis 모두 메모리 파편화 발생
- 클러스터링과 확장성 제공 (자동 데이터 샤딩, master-slave, 복제 지원[읽기부하분산], Sentinel[자동 장애 조치])
왜 우린 Redis 인가?
- 우선, 데이터 제거 옵션이 여러가지여서 관리의 효율성이 높은점과 클러스터링이 가능하여 안정적인 인증 시스템으로 관리가 가능하다는 점이다.
Memcached는 주로 단순 캐싱으로 사용하며, 인증 데이터 관리에는 데이터 영속성, 확장성, TTL 관리, 고성능을 제공하는 Redis가 더 적합하다고 판단했다.
고찰
비슷한 스펙을 지닌 기술들 중 하나를 선택하는 기준이 그저 좋아서면 안된다고 생각한다. 비슷한 스펙을 가진 기술일수록 우리 서비스와 얼마나 적합한 기술인지 우리가 풀고자 하는 문제외에도 더 많은 확장성을 고려할 수 있는지를 항상 고민해야겠다고 생각했다.
특히 예를 들어, memcached에 TTL이 존재함을 알았으나 자동 만료키 처리는 안된다는 부분과 memcached는 AOF, 스냅샷과 같은 데이터 영속성을 지원하지 않는다는 부분이 비교하는 중에 알게 됐다. 만약 영속성을 지원하지 않는 Memcached를 사용했다면, 다운되었을때에 대한 복구비용이 많이 소요되었을 것이다
728x90