일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
- java
- 정처기
- groupby
- 혼공파
- select
- 오블완
- Android
- 혼공챌린지
- SQL
- 인프런
- CS
- 티스토리챌린지
- 카카오코테
- 자료구조
- Til
- 코틀린
- MySQL
- Kotlin
- 안드로이드스튜디오
- 정보처리기사
- 프로그래머스
- 자바
- join
- 스터디
- 코테
- doitandroid
- 혼공단
- 알고리즘
- 안드로이드
- 기술면접
- Today
- Total
Welcome! Everything is fine.
캐싱(caching)이란? / Redis(Remote Dictionary Server)란? / 데이터 캐싱 전략 정리 본문
캐싱(caching)이란?
Redis에 대해 알아보기 전, 먼저 캐시 & 캐싱이 무엇인지 알아보자! 파레토의 법칙에 따라 자주 사용되는 20%의 데이터를 미리 캐싱해둔다면 효과적인 성능 향상을 기대할 수 있다.
- 캐시(Cache) : 원본 저장소보다 데이터를 더 빠르고 효율적으로 가져올 수 있는 임시 데이터 저장소.
- 캐싱(Caching) : 캐시에 접근해 데이터를 빠르게 가져오는 방식.
- 캐시 사용 시 주의사항
- 자주 사용되면서 변경이 적은 데이터에 적합하다.
- 유실되어도 크게 문제가 없는 데이터에 적합하다.
- DB와 함께 사용 시 데이터 정합성 문제를 고려해야한다.
데이터 캐싱 전략
단순히 "캐싱"만 한다고 성능이 무조건 보장되는 것은 아니다. 어떻게 캐싱하느냐가 중요하다.
대표적인 데이터 캐싱 전략을 알아보자.
Cache Aside(=Look Aside, Lazy Loading)
캐시에서 데이터를 확인하고, 없다면 DB를 통해 조회해오는 방식.
- Cache Aside는 Redis를 캐시로 쓸 때 가장 일반적으로 사용하는 방법으로, 데이터에 대한 요청이 들어오면 먼저 캐시를 확인한다.
- 캐시에 데이터가 있으면(cache hit) 캐시에서 데이터를 가져온다.
- 캐시에 데이터가 없으면(cache miss) DB에서 데이터를 가져와 캐시에 저장 후, 반환한다.
- 장점
- 캐시에 문제가 생기면 Db로 요청을 위임할 수 있어 캐시 미스 제어가 쉽다.
- 단점
- 데이터 불일치 가능성 : 캐시된 후 DB의 데이터가 변경되면 캐시는 오래된 데이터를 반환할 수 있다.
Write Around
데이터를 쓸 때 DB에만 저장하고 캐시에는 반영하지 않는 방식.
- Write Around는 한 번 쓰고 자주 읽지는 않는 경우에 적합하다.
- 장점
- DB에 바로 쓰기 때문에 성능이 좋다.
- 불필요한 데이터를 캐시에 올리지 않고 바로 쓰기 때문에 리소스를 아낄 수 있다.
- 단점
- 캐시와 DB의 정합성 유지가 어렵다.
Write Through
데이터를 쓸 때 DB와 캐시 둘 다 동시에 갱신하는 방식.
- Write Through는 데이터에 대한 요청이 들어오면 캐시와 DB에 모두 기록된다. 따라서 캐시에는 항상 최신 데이터가 저장된다. 데이터의 일관성이 중요할 때 사용한다.
- 장점
- 캐시가 항상 최신 정보를 가진다.
- 캐시와 DB가 항상 동기화 되어서 데이터 일관성을 보장한다.
- 단점
- 항상 두 번의 쓰기가 발생하므로 성능 문제에 유의해야 한다.
Write Back(=Write Behind)
데이터를 먼저 캐시에 저장하고, 이후 비동기로 DB에 반영하는 방식.
- Write Back은 캐시에 한꺼번에 기록 후, 나중에 DB에 한꺼번에 저장한다. 이때 스케줄링을 사용한다.
- 장점
- DB에 대한 쓰기 작업 수를 줄여(한 번의 쿼리로 삽입) 성능이 좋다.
- 단점
-DB에 저장되기 전에 캐시에 오류가 나면 데이터 손실이 발생할 수 있다.
성능 개선을 한다고 꼭 바로 캐시를 적용하려고 하지 않아도 된다. 우선 SQL 튜닝을 통해 기본적으로 성능을 향상시킬 수 있다. 또한 SQL 튜닝은 추가적인 시스템 구축 없이도 적용할 수 있기 때문에 가장 먼저 고려해보도록 하자!
Redis(Remote Dictionary Server)
Redis는 데이터 처리 속도가 매우 빠른 Key-Value 기반의 NoSQL 데이터베이스이다.
- 특징
- Redis는 인메모리(in-memory)에 모든 데이터를 저장하므로 데이터의 처리 성능이 매우 빠르다.
- 다양한 자료구조를 제공한다.
- 싱글 스레드로 동작해 한 번에 하나의 명령만을 처리하기 때문에 Race Condition이 거의 발생하지 않는다.
- 메모리에 저장된 데이터를 디스크에 영속화하는 기능을 제공한다.(RDB, AOF)
Redis는 주로 캐싱에 사용된다는 것만 알고 있었는데, 검색해보니 아주 많은 사용 사례가 있었다.
- 캐싱
- 세션 관리
- 실시간 분석 및 통계
- 메시지 큐
- 지리공간 인덱싱
- 속도 제한
- 실시간 채팅 및 메시징
가장 먼저 캐싱을 통한 데이터 조회 성능 향상에 대해 학습하면서 자연스럽게 다른 기능을 익혀보는 것이 좋다. 또한 채용 공고에 자주 등장하는 ‘대용량 트래픽 처리 경험’을 위해 필수적인 것이 바로 Redis의 캐싱 기능이다!
Redis 기본 명령어
데이터 (Key-Value) 저장하기
# set [key 이름] [value]
$ set gom:name "gom gom"
Key로 Value 조회하기
# get [key 이름]
$ get gom:name
저장된 모든 Key 조회하기
$ keys *
단, Redis는 싱글 스레드로 동작하기 때문에 keys *와 같이 모든 키를 탐색하는 O(N) 복잡도의 작업은 성능에 큰 영향을 줄 수 있다.
key로 데이터 삭제하기
# del [key 이름]
$ del gom:name
데이터 저장 시 만료시간(TTL) 정하기
# set [key 이름] [value] ex [만료 시간(초)]
$ set gom:pet dog ex 30
데이터 저장 시 만료시간(TTL) 정하기
# ttl [key 이름]
$ ttl gom:pet

- 만료 시간이 몇 초 남았는지 반환
- -2 : TTL이 만료된 경우
- -1 : 키 값은 존재하지만, TTL이 설정되어있지 않은 경우
Redis Key 네이밍 컨벤션
보통 콜론(:)을 활용해 계층적으로 의미를 구분해 사용 → 가독성, 일관성, 검색 및 필터링 용이성, 확장
예를 들면 다음과 같이 사용할 수 있다.
- users:100:profile : 사용자들 중에서 아이디가 100인 사용자의 프로필
- products:123:details : 상품들 중에서 아이디가 123인 상품의 세부사항
🔖 참고 자료
'TIL' 카테고리의 다른 글
QueryDSL 사용하기(with JPA) (0) | 2025.03.22 |
---|---|
[AWS] 🪣S3 시작하기 - bucket 만들기, bucket policy 설정, 정적 웹 사이트 호스팅, EC2에 S3 권한 주기 (0) | 2025.03.21 |
[Java/Spring] 인터페이스 vs enum 클래스 vs final 클래스 - 상수 관리하는 법 (0) | 2025.03.19 |
[AWS] RDS 가볍게 시작해보기! (0) | 2025.03.18 |
[Spring] Spring Security 도입 후 NullPointException 해결(@AuthenticationPrincipal) (3) | 2025.03.14 |