캐시 무효화

캐시에는 항상 과거가 들어 있다

캐시가 하는 일을 다시 봅시다. 어떤 시점의 답을 적어두고 재사용합니다. 그런데 원본은 그 뒤로도 계속 바뀝니다. 그리고 메모지는 그 사실을 모릅니다.

카운터에 붙여 둔 "오늘 배송비 3,000원" 메모지. 사장님이 어제 배송비를 4,000원으로 올렸습니다. 메모지는 그대로입니다.

이것이 캐시의 유일하고 근본적인 문제입니다. 성능 문제가 아니라 진실 문제입니다.

컴퓨터 과학에 유명한 농담이 있습니다.

컴퓨터 과학에서 어려운 문제는 딱 둘이다 — 캐시 무효화와 이름 짓기.

캐시를 넣는 건 쉽습니다. 언제 지울지 정하는 게 어렵습니다.

방법 1 — 시간이 지나면 버린다 (TTL)

가장 단순합니다. 적어둘 때 "5분 뒤 폐기"라고 써 둡니다. 5분이 지나면 그 값은 없는 것으로 칩니다. 다음 요청은 미스가 되고 원본에서 새로 가져옵니다.

누구에게 알릴 필요도, 관리할 목록도 없습니다. 그래서 압도적으로 많이 쓰입니다.

대가는 정직합니다. 최대 5분 동안 틀린 값이 나갑니다. 그리고 TTL은 그대로 거래 조건이 됩니다.

TTL을 짧게 하면 캐시가 캐시가 아니게 됩니다. TTL 1초짜리 캐시는 거의 모든 요청을 원본으로 보냅니다. 그러면 애초에 캐시를 왜 넣었나요.

방법 2 — 바뀌면 즉시 지운다

값을 바꾸는 쪽이 캐시에 알려 줍니다. "42번 지워." 그러면 다음 조회는 미스가 되고 최신 값을 가져옵니다. 이걸 무효화라고 합니다.

틀린 값이 나가는 시간이 거의 0이 됩니다. 좋아 보입니다. 그런데 어렵습니다.

• 지울 것을 다 알아야 합니다. 상품 42번이 바뀌면 상품 상세 캐시만

지우면 될까요? 그 상품이 들어간 카테고리 목록은? 검색 결과는? 추천 목록은? 하나를 고쳤는데 지워야 할 게 열 곳입니다. 하나를 빠뜨리면 거기서만 옛날 값이 계속 나갑니다. 그리고 그런 버그는 몇 달 뒤에 발견됩니다.

• 지우는 것도 실패할 수 있습니다. 지우라는 신호가 유실되면 그 값은

TTL이 끝날 때까지 틀린 채로 남습니다.

그래서 현실적인 답은 대개 둘 다 하는 것입니다. 무효화로 대부분을 빠르게 처리하고, TTL을 안전망으로 깔아 둡니다. 무효화가 실패해도 TTL이 언젠가는 정리해 줍니다.

무효화의 숨은 청구서

여기가 이 강의에서 새로 배우는 부분입니다.

값을 지우는 것은 공짜가 아닙니다. 지운 항목은 다음 조회에서 반드시 미스가 되고, 그 미스는 원본까지 갑니다.

쓰기 한 번  →  무효화 한 번  →  나중에 원본 조회 한 번

즉 쓰기가 많아질수록 캐시의 적중률이 떨어집니다. 읽기만 있던 14강에서는 적중률이 95%가 넘었습니다. 그런데 쓰기가 20% 섞이면 인기 항목이 계속 지워지므로 적중률이 그만큼 내려갑니다.

이 사실의 결론이 중요합니다.

캐시는 읽기가 압도적으로 많은 데이터에서만 잘 작동한다.

읽기와 쓰기 비율이 1:1인 데이터를 캐시하면 거의 효과가 없습니다. 캐시를 붙이기 전에 읽기/쓰기 비율부터 확인해야 하는 이유입니다.

그래서 얼마나 오래된 값까지 괜찮은가

이건 기술 질문이 아닙니다. 데이터마다 답이 다릅니다.

이 표를 채우는 건 업무 담당자입니다. "가격이 3분 늦게 반영돼도 되나요?"는 개발자가 답할 질문이 아닙니다. 그런데 개발자가 답하지 않으면 아무도 답하지 않으므로, 개발자가 TTL을 300초로 적어 넣고 아무도 모르게 됩니다. 정책을 정하지 않으면 정책이 저절로 생깁니다.

직접 해보세요

아래 과제는 14강과 비슷해 보이지만 결정적으로 다릅니다. 쓰기가 20% 섞여 있습니다. 캐시를 넣어 데이터베이스를 살리되, 통과한 뒤 적중률을 14강과 비교해 보세요. 그 차이가 무효화의 청구서입니다.