이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.

조회 전략

데이터를 조회할 때 주로 사용하는 전략이 Cache Aside 전략이다. Look Aside 전략 또는 Lazy Loading 전략이라고 부른다.

캐시에 데이터가 있을 경우 (= Cache Hit)

캐시에 데이터가 없을 경우 (= Cache Miss)

Cache Aside 전략은 캐시(Cache)에서 데이터를 확인하고, 없다면 DB를 통해 조회해오는 방식이다. 

쓰기 전략

Write Around 전략

Cache Aside 전략이 데이터를 어떻게 조회할 지에 대한 전략이었다면, Write Around 전략은 데이터를 어떻게 쓸지(저장, 수정, 삭제)에 대한 전략이다. 

Write Around 전략은 Cache Aside 전략과 같이 자주 활용되는 전략이다.

Write Around 전략은 데이터를 저장할 때는 레디스에 저장하지 않고 데이터베이스에만 저장하는 방식이다.

그러다 데이터를 조회할 때 레디스에 데이터가 없으면 데이터베이스로부터 데이터를 조회해와서 레디스에 저장시켜주는 방식이다. 

Write Around 전략은 쓰기 작업(저장, 수정, 삭제)을 캐시에는 반영하지 않고, DB에만 반영하는 방식을 뜻한다.

Cache Aside, Write Around 전략의 한계점

• 캐시 미스(cache miss) 발생: 데이터가 처음 요청될 때 캐시에 저장되지 않기 때문에, 데이터가 자주 사용되지 않는다면 캐시가 활용되지 않고, 그로 인해 캐시 미스가 자주 발생할 수 있다. 이는 캐시의 효율성을 떨어뜨릴 수 있다.
  
  
• 데이터 일관성 문제: 데이터베이스에 업데이트가 일어나면, 캐시에 있는 데이터를 직접적으로 갱신하지 않기 때문에 캐시와 데이터베이스 간에 일관성 문제가 생길 수 있다. 데이터베이스가 변경된 후 캐시가 갱신되지 않으면 오래된 데이터를 참조하게 될 수 있다.
  
  
• 저장 공간 문제: DB는 디스크(Disk)에 저장해서 많은 양을 저장하기 용이하지만, 캐시는 메모리(RAM)에 저장하기 때문에 DB에 비해 많은 양의 데이터를 저장할 수가 없다.

이러한 한계점 때문에 캐시를 적용시키기에 적절한 데이터는 아래와 같다.

• 자주 조회되는 데이터
• 잘 변하지 않는 데이터
• 실시간으로 정확하게 일치하지 않아도 되는 데이터

장기간동안 데이터가 일치하지 않는 것은 큰 문제가 될 수 있기 때문에 적절한 주기로 데이터를 동기화시켜서 싱크를 맞추어줘야 한다.

이때 활용하는 기능이 레디스의 TTL(만료시간 설정) 기능이다.

일정 시간이 지나면 데이터가 캐시에서 삭제된다. 그럼 특정 사용자가 조회를 하는 순간 Cache Miss가 발생한다. DB의 데이터를 새로 조회해와서 캐시에 데이터를 넣게 된다. 즉, 데이터가 새롭게 갱신되는 효과가 있는 것이다. 

캐싱보단 SQL 튜닝이 우선

캐싱으로 조회 성능을 하기전에 SQL 튜닝을 먼저 최우선적으로 고려해야 한다.

SQL 튜닝을 제외한 나머지 방법은 추가적인 시스템을 구축해야 한다. 따라서 금전적, 시간적 비용이 추가적으로 발생한다.

조금 더 복잡해진 시스템 구조로 인해 관리 비용이 늘어난다. 그에 비해 SQL 튜닝은 기존의 시스템 변경 없이 성능을 개선할 수 있다.

또한 근본적인 문제를 해결하는 방법이 SQL 튜닝일 가능성이 높다.

SQL 자체가 비효율적으로 작성됐다면 아무리 시스템적으로 성능을 개선한다고 하더라도 한계가 있다.

하지만 SQL 튜닝을 통해 기본적으로 성능을 향상시킨다면, 시스템적인 성능 개선이 필요없거나 훨씬 간단한 개선으로 큰 성능 개선 효과를 얻을 수 있다.

이 글은 인프런의 지식 공유자 박재성님의 강의를 듣고 개인적으로 정리하는 글임을 알립니다.

Redis

Oracle, MySQL, PostgreSQL 등 RDB는 디스크에 데이터를 저장하기 떄문에 상대적으로 느리다.

하지만 NoSQL인 레디스(Redis)는 인메모리(in-memory)에 모든 데이터를 저장한다.

그래서 데이터의 처리 성능이 굉장히 빠르다.

NoSQL은 아래와 같이 Key와 Value 형태로 데이터를 저장하는 데이터베이스이다.

Redis 네이밍 컨벤션

여러가지 컨벤션이 존재하지만 콜론(:)을 이용해서 계층적으로 의미를 구분해서 사용한다는 것을 꼭 기억해야 한다.

• users:100:profile : 사용자들(users) 중에서 PK가 100인 사용자(user)의 프로필(profile)
• products:123:details : 상품들(products) 중에서 PK가 123인 상품(product)의 세부사항(details)

이런식으로 컨벤션을 정했을 때의 장점은 아래와 같다.

• 가독성 : 데이터의 의미와 용도를 쉽게 파악할 수 있다. 
• 일관성 : 컨벤션을 따름으로써 코드의 일관성이 높아지고 유지보수가 쉬워진다. 
• 검색 및 필터링 용이성 : 패턴 매칭을 사용해 특정 유형의 Key를 쉽게 찾을 수 있다 .
• 확장성 : 서로 다른 Key와 이름이 겹쳐 충돌할 일이 적어진다.

Redis 기본 명령어

레디스 실행 및 종료

# redis 실행
brew services start redis

# redis 실행 여부 확인
brew services info redis

# reids 중지
brew services stop redis

# redis 접속
redis-cli

127.0.0.1:6379> ping
PONG # 이렇게 출력되면 정상적으로 Redis가 실행되고 있다는 뜻

데이터 저장

# set [key 이름] [value]
set jaeseong:name "jaeseong park" # 띄워쓰기 해서 저장하려면 쌍따옴표로 묶어주면 됨
set jaeseong:hobby soccer

데이터 조회

# get [key 이름]
get jaeseong:name
get jaeseong:hobby

get pjs:name # 없는 데이터를 조회할 경우 (nil)이라고 출력됨

저장된 모든 key 조회

keys *

데이터 삭제

# del [key 이름]
del jaeseong:hobby

get jaeseong:hobby # 삭제됐는 지 확인

데이터 저장 시 만료시간(TTL) 지정

레디스의 특성상 메모리 공간이 한정 되어 있기 때문에 모든 데이터를 레디스에 저장할 수 없다. 따라서 만료시간(TTL)을 활용해 자주 사용하는 데이터만 레디스에 저장해놓고 쓰는 식으로 활용한다. 

# set [key 이름] [value] ex [만료 시간(초)]
set jaeseong:pet dog ex 30

만료시간(TTL) 확인

# ttl [key 이름]
# 만료 시간이 몇 초 남았는 지 반환
# 키가 없는 경우 -2를 반환
# 키는 존재하지만 만료 시간이 설정돼 있지 않은 경우에는 -1을 반환
$ ttl jaeseong:pet 
$ ttl jaeseong:name
$ ttl pjs:name

모든 데이터 삭제

flushall