개요
티켓팅 프로젝트를 진행하며, 성능 개선을 목표로 프로젝트를 보완하고 있습니다.
티켓팅은 특정 예매 시간에 많은 사용자가 몰릴 것으로 예상되기 때문에, 성능 개선이 필요했습니다.
프로젝트의 메인 페이지에는 아래 인터파크 티켓 웹사이트와 같이 공연 요약 정보들이 출력되어야 합니다.
메인 페이지는 트래픽이 많고 조회해야 할 데이터도 많기 때문에, 조회 성능이 개선되어야 할 우선순위라고 생각했습니다.
성능을 개선하기 위한 방법으로 Redis의 캐싱을 적용하여 콘서트 요약 정보 조회 성능을 개선해보고자 합니다.
이번 게시글에서는 간단하게 Redis(레디스)란 무엇인지, Redis 캐시 전략을 선택하게 된 과정을 간단히 소개하겠습니다.
다음 게시글에서는 Redis를 활용해 실제로 조회 성능을 개선하는 과정을 다뤄보고자 합니다.
Redis란?
Redis는 오픈 소스 기반의 고성능 키-값 저장소이며, 메모리 내 데이터 구조 저장 및 검색을 위한 데이터베이스로 사용됩니다.
Redis는 NoSQL 데이터베이스 중 하나로, 주로 캐싱, 세션 관리, 메시지 큐, 대기열 처리 등 다양한 용도로 활용됩니다.
MySQL과 같은 RDBMS는 대부분 데이터를 디스크에 저장하고,
Redis는 메모리(RAM)에 데이터를 저장하는 인메모리 데이터 저장소입니다.
메모리가 디스크보다 데이터 처리속도가 빠르기 때문에 Redis를 사용하면 RDBMS를 사용할 때보다 데이터 처리속도가 빠릅니다.
저는 Redis의 기능 중 캐싱을 활용하여 데이터 조회 성능을 향상해보려고 합니다.
캐시/캐싱이란?
캐시(Cache)란 데이터나 값을 미리 복사해 놓는 임시 저장소를 의미합니다.
캐싱(Caching)이란 캐시에 접근해서 데이터를 빠르게 가져오는 행위를 의미합니다.
자주 사용되는 데이터나 반복적으로 조회되는 데이터를 캐시에 저장하면, 데이터베이스를 호출하지 않고도 데이터를 빠르게 반환하여,
조회 속도가 빨라지고 데이터베이스 부하가 감소합니다.
어떤 캐싱 전략을 선택할까?
- 캐시 읽기 전략
- Look Aside 패턴 : 데이터를 찾을 때 캐시를 먼저 조회하고, 캐시에 데이터가 없다면 DB에서 데이터를 조회한다.
- Read Through 패턴 : 캐시에서만 데이터를 읽어오는 전략이다. 데이터 동기화를 라이브러리 또는 캐시 제공자에게 위임한다.
- 캐시 쓰기 전략
- Write Back 패턴 : 데이터 저장 시 DB에 바로 쓰지 않고, 캐시에 모아서 일정 주기 배치 작업을 통해 DB에 반영한다.
- Write Through 패턴 : 데이터를 데이터베이스와 Cache에 동시에 저장한다.
- Write Around 패턴 : 모든 데이터를 DB에 저장한다. Cache miss가 발생하는 경우에만 캐시에도 데이터를 저장한다.
자세한 내용은 아래의 캐시 전략에 관련하여 깔끔하게 정리되어 있는 글을 읽어 보시면 좋을 것 같습니다.
Look Aside + Write Around
저는 Look Aside 패턴과 Write Around 패턴을 조합하여 캐싱 전략을 구성했습니다.
공연 요약 정보에는 (공연 이미지, 공연 제목, 공연장 정보)등이 포함됩니다.
또한 해당 정보는 메인 페이지에서 자주 호출되고 데이터 수정이 빈번하지 않을 것으로 예상하고 있습니다.
따라서, 조회 성능을 극대화하면서 일관성 관리 비용이 낮은 Look Aside + Write Around 패턴을 사용하기로 결정했습니다.
한계점
해당 전략을 사용하는 경우 캐시 된 데이터와 DB 데이터가 일치하지 않을 수 있다는 한계점이 존재합니다.
Write Around 패턴에서는 데이터 수정 시 캐시에 반영하지 않기 때문에,
데이터 수정이 발생하면 기존에 캐시에 저장한 데이터 값과 수정된 DB의 데이터 값이 다를 것입니다.
예시를 들어볼까요?
DB에 "홍길동"이라는 데이터가 저장되어 있다고 가정하겠습니다.
1. Look Aside 패턴에 의해 캐시에 데이터가 있는지 요청합니다.
2. 캐시에 데이터가 없기 때문에(Cache Miss) DB에서 데이터를 요청했습니다.
3. "홍길동"이라는 데이터를 응답받습니다.
4. Cache Miss가 발생했기 때문에 Cache에 "홍길동"을 저장합니다.
이번에는 DB의 데이터를 수정해 보겠습니다.
1. Write Around 패턴에 의해 "홍길동"을 "홍대입구"로 수정하면 DB에만 반영합니다.
2. 캐시에 데이터를 요청합니다. 여전히 캐시에는 "홍길동"이라는 데이터가 저장되어 있습니다.
3. "홍길동"이 응답됩니다.
TTL을 사용하여 한계점을 극복하기
캐시와 DB의 불일치가 오래 지속되면 문제가 될 수 있습니다.
이를 방지하기 위해 TTL을 설정하여 일정 시간이 지나면 캐시 데이터를 자동으로 만료시키도록 할 수 있습니다.
일정 시간이 지나 데이터가 캐시에서 삭제되고, 이후 사용자가 조회하면 Cache Miss가 발생하여 DB의 데이터를 새로 조회하고 캐시에 저장합니다. 그렇다면 데이터가 자연스럽게 갱신되는 효과가 있습니다.
참고
https://www.youtube.com/watch?v=ZLrVjeSNLQw&list=PLtUgHNmvcs6qoVrxB5jzZ4meINz_KL-Bl&index=10
'Teck Stack > Redis' 카테고리의 다른 글
| [Cache] 서버 캐시란? (0) | 2025.12.13 |
|---|---|
| Refresh Token을 Redis에 저장한 이유 (0) | 2025.11.04 |