Louis is

이번 글에서는 레디스를 도입할 때 고민했던 내용에 대해 공유해보고자 한다.

일반적으로 캐시는 메모리를 사용하기 때문에 DB 보다 훨씬 빠른 성능을 기대한다. 

하지만 올바르지 않은 방법으로 사용하게 된다면 데이터에 문제가 생길 수도 있고, DB만 사용하는 것보다 더 비효율적이 될 수도 있다. 

효율적으로 사용하기 위해서 캐시에 저장할 데이터의 기준확립과 캐싱 전략이 중요하다고 생각했다.

캐시 전략 패턴

캐시를 사용하게 되면 데이터의 정합성 문제에 직면하게 된다. 

서로 다른 두 저장소(메모리와 DB)에 데이터를 저장하게 되니 불일치가 발생할 가능성이 높다.

이 문제를 방지, 극복하기 위해선 적절한 캐싱 전략을 사용해야 하기 때문에 먼저 어떤 방법들이 있는지 찾아보았다.

크게 캐시는 읽기 전략과 쓰기 전략으로 나뉜다.

캐시 읽기 전략(cache read strategy)

1. Look Aside Pattern

• 캐시 우선 확인 전략, 캐시에 없으면 DB조회.
• 레디스 장애 시 DB에서 데이터를 가져올 수 있기 때문에 서비스에 문제없이 운영 가능.
• 캐시 connection이 많이 있던 경우 순간적으로 DB에 부하가 몰릴 수 있음.
• 반복적인 읽기가 많은 호출에 적합.

2. Read Through Pattern

• 캐시에서만 데이터를 읽는 전략
• cache miss가 많을 경우 look aside 전략보다 전체적인 성능이 느릴 수 있음.
• 레디스 다운 시 서비스 이용에 문제가 생김. 이중화 구조 필요.

캐시 쓰기 전략(cache write strategy)

1. Write Back Pattern

• 데이터를 DB에 바로 저장하지 않음.
• 캐시에 모아놨다가 DB에 저장. (DB 쓰기 비용, 부하 줄일 수 있음)
• Write가 빈번한 서비스에 적합.
• 레디스 장애 시 데이터 영구 소실가능.

2. Write Through Pattern

• 데이터를 캐시와 DB에 함께 저장하는 방식
• 캐시와 DB의 데이터 일관성 유지 가능.
• 데이터 유실 발생 가능성 적음.
• 매 요청마다 두 번의 write 발생.
• 빈번한 생성, 수정이 있는 서비스에서는 성능 이슈가 발생할 수 있음.

3. Write Around Pattern

• 모든 데이터를 DB에 저장.
• Write Through보다 훨씬 빠름.
• 캐시와 DB 데이터 불일치 가능성 있음.

전략패턴 조합

캐시 읽기 전략과 쓰기 전략을 조합해서 사용한다.

ex)

• Look Aside + Write Around
• Read through + Write Around
• Read through + Write Through

나의 도메인에 가장 적합한 방식은 Look Aside + Write Around라고 생각했다.

웹툰 서비스의 특성상

읽기가 빈번히 발생하고 레디스 장애 시에도 정상적으로 서비스 제공이 가능하기 때문에 Look Aside를 생각했고

상대적으로 뜸한 쓰기(작품 등록, 수정) 때문에 Write Around가 적합하다고 생각했다.

캐싱 데이터의 기준

두 번째로 아래의 원칙을 가지고 캐싱 데이터를 정리하였다.

• 자주 사용 되면서 자주 변경되지 않는 데이터를 추출.
• 중요한 정보, 민감 정보는 저장하지 않음.
• 휘발성을 염두하여 데이터가 유실, 또는 정합성이 맞지 않아도 괜찮은 데이터를 저장.

(간단하게 데이터를 표현하면 다음과 같다.)

AS-IS 콘텐츠 데이터:

성인작품여부
완결여부
제목
회차수
이벤트여부
오픈기간(시작, 끝)
뷰카운트
작가정보
썸네일정보
태그정보

우선 다른 도메인의 성격을 띠는 썸네일 정보, 태그 정보를 분리하였다.

그다음으로 상대적으로 자주 변경되는 데이터에 속하는 회차수, 이벤트 여부, 뷰카운트 정보를 분리하였다.

TO-BE 콘텐츠 데이터:

성인작품여부
완결여부
제목
오픈기간(시작, 끝)
작가정보

크게 변한 것은 없어 보이지만 원칙을 가지고 기준에 맞는 데이터만 남긴 부분이 추후 유지보수 할 때 용이할 것이라는 생각이 들었다.

또한, 캐시 관련 로직을 심플하게 작성할 수 있었다.

마무리

이번 경험을 통해서 수많은 문제 해결 방법 중에 하나의 적절한 방법을 결정하는 게 더 어렵다고 느꼈다.

나의 기준이 다른 도메인에서는 올바르지 않을 수 있다.

그렇기 때문에 문제를 해결하는 데 있어 중요한 것은 도메인에 대한 이해라고 생각했다.

Part2 글에서는 도입한 캐시를 가지고 진행한 성능 테스트에 대해 이야기해 보도록 하겠다.

참고 블로그

- 레디스를 이용한 캐싱 설계 전략