레디스 - 읽기 전략

모든 캐시 전략에는 장단이 있기 때문에 완전한 해결책이 없음을 염두하고 그저 적절한 상황에 맞게 적절한 전략을 선택하는 것

일반적인 상황에서는 낡은 데이터(갱신 안된 데이터)를 잠깐 보여줘도 되는 상황이 생가보다 많다는 것을 알고 접근하면 좋음

읽기 전략

읽기 전략은 데이터 정합성과 읽기 속도(캐시)의 줄다리기 싸움

트레이드 오프

속도와 정합성 사이 줄타기

캐시된 데이터는 언제나 낡은 데이터라는 사실을 잊으면 안됨, 캐시는 속도를 위해 데이터의 일시적 정합성을 희생하는 것

일반적으로 많이 사용하는 전력인 Cache-Aside 패턴에서는 DB 업데이트와 캐시 무효화 사이에 시차가 존재할 수밖에 없음

Write-Through 전략도 데이터 원천이 두 개로 결국 DB와 데이터 불일치가 발생할 수 밖에 없음

Cache-Aside (Lazy Loading)

애플리케이션이 캐시를 먼저 확인하고(hit) 없으면(miss) DB에서 조회 후 캐시에 넣는 전략

이미지 자료를 보면 레디스가 마치 DB를 조회하는 듯이 보이지만 개념상으로 표현한 것이지 실제로는 어플리케이션 주도함

 

흐름

1. 캐시 조회
2. 있으면 반환 HIT
3. 없으면 DB 조회
4. 데이터 캐시 적재
5. 데이터 반환

특이점

• Redis가 죽어도 서비스는 정상 동작한다. 이 경우 느릴 수는 있다.
• 데이터 원천이 두 곳이다. DB 업데이트 후 레디스 캐시를 비우지 않으면 데이터 불일치가 발생한다. 이런 실수에 대비해 적절한 TTL 설정이 필수
• 캐시 서버 재부팅 시 초기 요청은 전부 Miss가 발생한다. 따라서 적절한 Warm-up 전략이 필요하다

Read-Through

애플리케이션 대신 캐시 제공자가 데이터 로딩을 전담하는 방식

캐시 제공자는 Spring Cache, Redisson, Hibernate 등등

흐름

1. 캐시 제공자에게 데이터 요청
2. 캐시 제공자가 알아서 Miss 감지
3. 데이터 반환

특이점

• 캐시 관련 코드가 없다(단일 책임 원칙을 지키게 된다)
• 특정 데이터에 대한 동시 요청 시 대부분의 라이브러리가 알아서 DB를 한 번 만 조회하는 등 최적화된 처리를 한다
• 특정 라이브러리나 프레임워크에 강하게 의존한다
• DB 조인을 같은 복잡한 조회를 필요로 하는 경우 구현 난이도가 올라간다

읽기 전략 주의사항

Cache Stampede (Thundering Herd) 

자주 조회하는 데이터의 TTL이 만료되는 순간, 레디스가 감당하던 모든 요청이 DB에 몰려 DB가 부하를 받는 현상

해결책

• Locking
  캐시 미스 시, Lock을 획득한 1개의 프로세스만 DB에 접근하고, 나머지는 대기
  정합성이 중요할 때 사용한다
• Probabilistic Early Recomputation
  만료 시간(TTL)이 다가오면, 확률적으로 미리 캐시를 갱신, 락은 사용하지 않아 성능 저하가 없음
  초속 트래픽 환경에서 사용한다(google, facebook 등에서 사용하는 방식)
• The Soft Expiration
  레디스 TTL 보다 빠르게 만료되는 값을 데이터 내부에 넣어 이 값이 만료되면 갱신하는 방

보통의 경우 Locking과 Soft Expriation 방법을 병용한다. 인위적 만료 시간이 지나 캐시 미스가 발견된 경우 해당 스레드나 서비스가 락을 걸고 갱신을 하고 락을 반납한다. 락을 걸때는 반드시 만료시간을 걸어 락을 걸고 서버가 죽을 경우를 대비해야 한다.(데드락) 

락을 얻는게 실패한 스레드나 서비스가 처리하는 방식을 크게 3 가지로 잠시 대기 후 재귀 호출, 예외 반환, 옛날 데이터지만 반환