[DB] Redis Cache 🔥

Cache란

• 많은 시간이나 연산이 필요한 일에 대한 결과를 저장해 두는 것
• 한번 읽은 데이터를 임시 저장, 필요에 따라 전송, 갱신, 삭제하는 기술
• 임시로 저장해 두고 같은 데이터를 불러올 때 빠르게 불러옴

Cache의 문제점

캐시를 사용하게 된다면 데이터 정합성 문제가 발생할 수 있습니다.

데이터 정합성문제란 간단하게 말하면 캐시에 있는 데이터의 값과 데이터베이스에 있는 데이터의 값이 다른다는 것을 의미합니다.

캐시를 사용하지 않았을 때는 그냥 데이터베이스에서 값을 가져오면 되기 때문에 정합성 문제가 발생하지 않았지만 캐시에 데이터가 있다면 캐시에서 데이터를 가져오기 때문에 캐시와 데이터베이스에 값이 다르다면 데이터 정합성 문제가 발생할 수 있습니다.

Cache 전략

캐싱 전략은 웹 서비스 환경에서 시스템 성능 향상을 기대할 수 있는 중요한 기술입니다.

일반적으로 캐시는 데이터베이스가 아니라 메모리를 사용하기 때문에 데이터베이스보다 데이터를 응답하는 속도가 빠릅니다. 

 

그러나 캐시는 메모리이기 때문에 용량이 크지 않습니다. 그렇기 때문에 모든 데이터를 다 캐시에 저장하게 된다면 용량 부족 현상이 일어나 시스템이 다운될 수 있습니다.

그렇기 때문에 어떤 데이터를 캐시에 저장할지, 얼마동안 캐시에 저장할지 전략이 필요합니다.

 

Cache hit : 캐시에 데이터가 있는 경우 바로 가져올 수 있다 (빠르다)

Cache miss : 캐시에 데이터가 존재하지 않아 어쩔 수 없이 데이터베이스에서 데이터를 가져옴 (느리다)

Cache 읽기 전략

Look Aside 패턴

• 데이터를 조회할 때 우선적으로 캐시에 데이터가 있는지 먼저 확인하는 전략. 만약에 캐시에 데이터가 존재하지 않는다면 데이터베이스를 통해 데이터를 조회한다.
• 반복적으로 읽기 작업이 많은 경우에 유리하다.
• 캐시와 데이터베이스가 분리되어 있기 때문에 만약에 캐시가 다운되더라도 데이터베이스를 통해 데이터 조회가 가능하기 때문에 서비스 자체에는 큰 문제가 되지 않는다.

Read Through 패턴

• 캐시에서만 데이터를 조회하는 전략
• 데이터를 조회하는데 전체적으로 속도가 느림
• 데이터를 조회하는데 캐시에만 의존하므로, 캐시 서버가 다운되면 서비스 이용에 차질이 생길 수 있음

Read Through 흐름

1. 요청이 오면 캐시에 데이터가 존재한 지 확인한다.
2. 캐시에 데이터가 존재하지 않는다면 데이터베이스를 통해서 캐시를 업데이트한다.
3. 업데이트된 캐시를 통해서 데이터를 조회한다.

Cache 쓰기 전략

Write Through 패턴

• 데이터베이스와 캐시에 동시에 데이터를 저장하는 전략
• 데이터베이스와 캐시가 항상 동기화되어 있어, 캐시의 데이터는 항상 최신 상태로 유지
• 매 요청마다 두 번의 쓰기 작업이 발생하게 됨으로써 빈번한 생성, 수정이 발생하는 서비스에서는 적합하지 않다.

Write Around 패턴

• Write Through 패턴보다 빠르다.
• 모든 데이터를 데이터베이스에만 저장
• Cache miss가 발생하는 상황에만 데이터베이스에 있는 데이터를 캐시에도 저장
• 데이터베이스와 캐시에 존재하는 데이터가 다를 수 있다.

저는 프로젝트를 진행하면서 메인페이지 공지사항과 회원가입 후 쉽게 변경되지 않는 회원정보를 캐싱하는 것을 목표로 하였습니다.
반복적으로 메인페이지에서 조회되면서 변경이 적은 공지사항과 처음에 회원가입을 하면 쉽게 바뀌지 않는 학생정보 등을 캐싱처리하여 캐시의 주된 목적인 데이터에 접근하는 데 걸리는 시간을 줄임으로써 시스템의 성능을 향상할 수 있습니다.

읽기 전략은 Look Aside 패턴을 적용시켜서 캐시를 먼저 조회하고 캐시에 데이터가 존재하지 않으면 데이터베이스로 접근하도록 설계하였습니다. 쓰기 전략은 Write Through 패턴을 적용시켜서 항상 Cache와 DB의 데이터를 동시화 해놓고, 캐시의 데이터를 최신 상태로 유지할 수 있도록 한다. 쓰기 작업의 빈도가 극도로 적고 읽기 작업의 빈도가 극도로 많은 상황에서 Write Through 전략의 단점인 쓰기 작업이 느린 속도는 큰 문제가 되지 않는다는 점에서 Write Through 전략을 적용시켰습니다.

캐싱 성능 확인

redis-cli에서 현재 캐시에 저장된 데이터를 확인할 수 있습니다. 현재 아무 캐시도 존재하지 않습니다.

이런 상황에서 서버에 공지글를 조회하는 API를 요청해 보겠습니다. 126ms가 소요되었고, Redis에 캐시도 잘 저장됩니다.

그럼 이제 Redis에 캐시가 저장돼 있기 때문에 공지글 조회 요청을 하게 되면 데이터베이스로부터 데이터를 가져오는 것이 아니라 Redis에 저장된 캐시를 통해서 데이터를 가져오게 될 것입니다.

처음 조회 했을 때보다 126ms -> 24ms로 80% 이상 응답 시간이 개선된 점을 볼 수 있습니다.