[Server] Redis와 서버 성능 개선을 위한 몇 가지 캐싱 전략들

Youtube 강의를 시청하고 정리하였습니다.

redis란?

In-memory data structure store.
인 메모리 데이터 저장소이다. 즉 데이터를 메모리에 저장한다.
- Memory: 임시 저장소(휘발성), 빠른 속도, 적은 용량
- Storage: 장기 저장소(비휘발성), 느린 속도, 많은 용량
- 따라서 외부 DB나 스토리지와 비교할 때 훨씬 빠른 속도로 데이터를 가져올 수 있다.
용도
- Cache
  - 서버의 성능을 향상시키기 위해 사용되는 메모리
  - 앞으로 필요할 것이라 예상되는 데이터를 미리 가지고 있다가 빠르게 제공하는 것.
  - 서버가 클라이언트에 전달해주는 정적인 리소스들을 복사하여 미리 저장해놓는다. (Cache miss)
  - 그 후 클라이언트가 특정 리소스를 요청할 때 캐시에 저장된 리소스를 빠르게 반환한다.(Cache hit)
- DB
- Message Broker

정말 많은 캐싱 전략이 있지만, 이 글에선 local cache에 대해 다룬다.

Read-Through (Lazy-Loading)
- 클라이언트로부터 데이터 요청이 들어오면, 서버는 캐시에 데이터가 존재하는지 확인한다.
- 캐시에 데이터가 없다면(Cache Miss) 서버는 DB를 조회하여 필요한 데이터를 얻은 후 캐시에 저장하고 클라이언트에 응답한다.
- 캐시에 데이터가 존재한다면 캐시에서 데이터를 바로 반환한다. (Cache Hit)
- 데이터가 자주 변하지 않는 경우에 활용된다.
Write-Through
- 데이터를 데이터베이스에 작성할 때마다 캐시에 데이터를 추가하거나 업데이트하는 전략이다.
- 데이터가 자주 변하는 경우에 활용된다.
Cache-Aside
- 어플리케이션이 캐시를 옆에 따로 두고 필요할 때만 데이터를 캐시에 로드하는 전략이다.
Write-Back(Behind)
- 데이터를 먼저 캐시에 쓴 다음 비동기식으로 데이터를 데이터 저장소에 업데이트하여 쓰기 성능을 향상시키는 전략이다.

Postman 등을 활용하여 응답 소요 시간 체크해보자.

Read-through 활용 전략 (응답 지연 시간이 길고, 요청하는 정보가 자주 변하지 않는 페이지 로딩)
- 최초 요청 시 cache가 비어있기 때문에 DB로부터 필요한 데이터를 추출해서 cache에 저장한다.
- 두 번째 요청부터는 캐시에서 바로 응답이 가도록 한다.
- 캐싱 유효 시간을 두어 주기적으로 데이터가 캐시에 업데이트 될 수 있도록 설정할 수 있다.
Read-through + Write-through 활용 전략 (응답 지연 시간이 길고, 요청하는 정보가 자주 변하는 페이지 로딩)
- Read-through 전략을 통해 캐싱할 모든 데이터를 캐시에 저장해둔다.
- 일부가 변경될 때마다 Write-through 전략을 통해 수정한다.
- 이로써 캐시 데이터를 늘 최신 상태로 유지하고 메모리가 유실되더라도 DB를 통해 복구가 가능해진다.
- Sync + Async
  - 데이터를 쓰는 속도가 빠른 캐시에는 동기적으로 write
  - 데이터를 쓰는 속도가 느린 DB에는 비동기적으로 write (캐시에 데이터가 존재하고 클라이언트는 캐시로부터 데이터를 먼저 찾아가기 때문에 DB에 데이터를 쓰는 작업은 비동기적으로 처리해도 큰 문제가 없다.)