[Redis] 캐시(Cache)와 Redis

[Redis] 캐시(Cache)와 Redis
[Redis] Redis의 기본 명령어
[Java + Redis] Spring Data Redis로 Redis와 연동하기 - RedisTemplate 편
[Java + Redis] Spring Data Redis로 Redis와 연동하기 - RedisRepository 편

안녕하세요. 현대의 웹 서비스에서는 Cache가 정말 중요한 역할을 합니다. 서비스의 규모가 커져감에 따라 모든 요청을 DB 직접 참조 또는 API 호출로 처리한다면 성능과 에러 등과 같은 이슈가 발생할 수 밖에 없습니다. 과도한 요청이 문제가 되기 시작하면 캐시(Cache)에 대해서 고려할 수 밖에 없습니다.

오늘은 캐시(Cache)와 Redis의 특징에 대해서 여러분과 이야기해보고자 합니다.

오늘 내용은 강대명님의 우아한 테크 강의를 토대로 정리하였습니다.

Cache의 정의

Cache란 나중에 요청할 결과를 미리 저장해둔 후 빠르게 서비스 해주는 것을 의미합니다. 즉, 미리 결과를 저장하고 나중에 요청이 오면 그 요청에 대해서 DB 또는 API를 참조하지 않고 Cache를 접근하여 오청을 처리하게 됩니다. 이러한 cache가 동작 할 수 있는 철학에는 파레토 법칙이 있습니다.

파레토 법칙이란 80퍼센트의 결과는 20퍼센트의 원인으로 인해 발생한다는 말입니다.

즉, 이것은 Cache가 효율적일 수 있는 이유가 될 수 있습니다. 모든 결과를 캐싱할 필요는 없으며, 우리는 서비스를 할 때 많이 사용되는 20%를 캐싱한다면 전체적으로 영향을 주어 효율을 극대화 할 수 있다는 말입니다.

Cache 사용 구조

application logic using cache

1. Client로 부터 요청을 받는다.
2. Cache와 작업을 한다.
3. 실제 DB와 작업한다
4. 다시 Cache와 작업한다.

cache는 일반적으로 위의 이미지와 같은 flow로 사용됩니다. 동일한 flow에서 어떻게 사용하냐에 따라서 look aside cache(Lazy Loading)와 write back으로 나뉩니다.

• look aside cache (Lazy Loading)
  1. Cache에 Data 존재 유무 확인
  2. Data가 있다면 cache의 Data 사용
  3. Data가 없다면 cache의 실제 DB Data 사용
  4. DB에서 가져온 Data를 Cache에 저장

look aside cache는 캐시를 한번 접근하여 데이터가 있는지 판단한 후, 있다면 cache의 데이터를 사용하며 없다면 실제 DB 또는 API를 호출하는 로직으로 구현됩니다. 대부분의 cache를 사용한 개발이 해당 프로세스를 따르고 있습니다.

• write back
  1. Data를 Cache에 저장
  2. Cache에 있는 Data를 일정 기간동안 Check
  3. 모여있는 Data를 DB에 저장
  4. Cache에 있는 Data 삭제

write back은 cache를 다르게 이용하는 방법입니다. DB는 접근 횟수가 적을수록 전체 시스템의 퍼포먼스는 좋아집니다. 데이터를 쓰거나 많은 데이터를 읽게되면 DB에서 Disk를 접근하게 됩니다. 이렇게 되면 Application의 속도 저하가 일어날 수 있습니다. 따라서 write back은 데이터를 cache에 모으고 일정한 주기 또는 일정한 크기가 되면 한번에 처리하는 것입니다.

Redis 특징

Redis가 타 캐시 시스템(ex. MemCache 등)과 다른 특징은 아래와 같습니다.

• Redis는 List, Set, Sorted Set, Hash 등과 같은 Collection을 지원합니다.
• Race condition에 빠질 수 있는 것을 방지함
  • Redis는 Single Thread
  • 따라서 Atomic 보장
• persistence를 지원하여 서버가 꺼지더라도 다시 데이터를 불러들일 수 있습니다.

Redis의 주요 사용처

• Remote Data Store
  • 여러 서버의 Data 공유를 위해 사용될 수 있음.
  • 특히, Redis의 경우 Single Thread 이므로 Race Condition 발생 가능성이 낮다는 것을 활용할 필요가 있을 경우
• 인증 토큰 개발
• Ranking Board (Sorted Set)
• 유저 API Limit
• Job QUeue

마무리

오늘은 이렇게 Cache와 Redis의 기본적인 특징에 대해서 알아보는 시간을 가졌습니다.

해당 내용은 참조한 강의의 40분 정도 되는 분량을 요약한 내용입니다.

다음 시간에는 Redis의 기본 명령어에 대해서 알아보는 시간을 가지도록 하겠습니다.

감사합니다.

참고

강대명님의 우아한 테크 강의