웹, 서버 간 대학 관련 캐시 전략과 개선 방안

[whqtker]

서버 캐싱 전략

@ThunderingHerdCaching(
    key = "univApplyInfoTextSearch:{0}:{1}:{2}",
    cacheManager = "customCacheManager",
    ttlSec = 86400
)
public UnivApplyInfoPreviewResponses searchUnivApplyInfoByText(
        String text,
        Long homeUniversityId,
        Long termId
)

캐시 키 요소는 다음과 같습니다.

캐시 키 요소	의미
{0}	검색어 (text)
{1}	소속 대학 id (homeUniversityId)
{2}	학기 id (termId)

캐싱된 데이터는 TTL 1일로 설정됩니다.

동일한 캐시 키에 대해 캐시 미스가 동시에 발생하는 경우 하나의 요청이 Redis lock을 획득하여 캐시하고, 나머지 요청은 캐시 생성 완료를 기다린 뒤 생성된 캐시 값을 조회하며, 대기 시간 내 캐시가 생성되지 않으면 fallback으로 DB에 직접 접근합니다.

캐시 만료 시점에 동일 키 요청이 한꺼번에 DB로 향하는 상황을 줄이기 위해 TTL이 일정 기준 이하로 내려가면 refresh lock을 획득한 요청 하나가 캐시를 갱신하고, 다른 요청은 기존 캐시 데이터를 가져갑니다.

데이터가 변경되는 경우 검색 캐시는 univApplyInfoTextSearch* prefix 기준으로 삭제합니다.

웹 캐싱 전략

GET /univ-apply-infos/search/text?value=&termId={학기ID}&homeUniversityId={소속대학ID}

대학 목록 페이지를 SSG로 정적 생성합니다. 릴리즈 시 위 API를 호출합니다.

대학 데이터가 변경되는 경우 revalidate 를 통해 정적 페이지를 다시 생성합니다.

결론

Redis 캐시가 사용되는 부분은 다음과 같습니다.

1. 릴리즈 시 SSG 페이지 생성
2. revalidate 시 정적 페이지 재생성
3. 검색 API를 직접 호출

데이터가 변경된 경우 Redis 캐시를 무효화하고, revalidate를 호출해야 합니다.

웹과 서버의 캐시 전략이 역할과 계층이 다르다보니 자칫 잘못되면 의도와 다르게 동작할 수 있습니다. 예를 들어 DB에서 직접 데이터 수정 후(== 캐시 무효화 X) revalidate하는 경우 그대로 Redis 캐시 데이터를 가져옵니다.

---

전반적인 캐시 로직 개선하고 싶은데, 이 부분 관련해서 자유롭게 의견 주세요 !