같은 데이터를 두 번 계산하지 않는다. 캐시가 통하는 조건
[브라우저 캐시]
|
[CDN / 엣지]
|
[앱 로컬 캐시]
|
[Redis 등 분산 캐시]
|
[DB 버퍼 풀] -> [디스크]
INFO stats의 keyspace_hits / keyspace_misses로 계산Q.캐시를 도입하기 전에 무엇을 먼저 확인해야 하나요?
캐시는 정합성을 내주고 속도를 얻는 거래입니다. 그 대가를 감당할 수 있는지부터 봅니다.
| 확인할 것 | 왜 |
|---|---|
| 병목이 정말 조회인가 | 실행 계획과 구간별 시간을 먼저 잰다 |
| 같은 데이터를 반복 조회하는가 | 매번 다른 키를 조회하면 히트율이 안 나온다 |
| 얼마나 오래된 값을 허용하는가 | 즉시 일치가 필요하면 캐시가 맞지 않는다 |
| 무효화 지점을 특정할 수 있는가 | 어디서 바뀌는지 모르면 옛 값이 남는다 |
| 인덱스나 쿼리로 풀리는가 | 그쪽이 정합성 비용이 없다 |
마지막이 중요합니다. 풀 스캔 때문에 느린 것이면 캐시가 미스일 때 그대로 느리고, 무효화 문제까지 새로 떠안습니다.
흔한 실수: 느리면 캐시부터 붙이는 것. 캐시는 읽기 패턴이 반복적이고 약간의 지연을 허용할 때 효과가 있습니다. 그 조건을 확인하지 않으면 복잡도만 늘어납니다.
Q.캐시 히트율이 낮을 때 어떤 순서로 원인을 찾나요?
| 순서 | 확인할 것 | 흔한 원인 |
|---|---|---|
| 1 | 키 설계 | 사용자 id 나 타임스탬프가 키에 섞여 매번 다른 키가 된다 |
| 2 | TTL | 너무 짧아 쓰이기 전에 만료된다 |
| 3 | 메모리와 축출 | 용량이 부족해 금방 밀려난다 |
| 4 | 조회 분포 | 롱테일이라 반복 조회 자체가 적다 |
| 5 | 무효화 범위 | 한 건 변경에 너무 많은 키를 지운다 |
1번이 가장 흔합니다. 페이지네이션 파라미터나 정렬 조건이 키에 그대로 들어가면 조합이 폭발합니다.
3번은 지표로 확인합니다. 축출 건수가 계속 늘고 메모리가 상한에 붙어 있으면 용량 문제입니다.
4번이면 캐시가 애초에 안 맞는 경우입니다. 조회가 고르게 흩어져 있으면 무엇을 담아도 히트가 안 납니다.
흔한 실수: 히트율만 보고 판단하는 것. 히트율이 낮아도 상위 소수 키가 전체 조회의 대부분을 차지하면 그 키만으로 큰 효과가 납니다. 키별 조회 분포를 함께 봐야 합니다.
Q.캐시에 넣으면 안 되는 데이터는 어떤 것인가요?
| 넣지 말 것 | 이유 |
|---|---|
| 즉시 일치가 필요한 값 | 잔액, 재고, 좌석. 옛 값이 곧 사고다 |
| 사용자별 민감 정보 | 키를 잘못 설계하면 남의 값이 노출된다 |
| 거의 조회되지 않는 값 | 메모리만 차지하고 히트가 안 난다 |
| 매번 바뀌는 값 | 담자마자 무효가 된다 |
| 매우 큰 값 | 네트워크 전송과 메모리를 크게 먹는다 |
첫 번째와 관련해 주의할 것이 있습니다. 잔액을 캐시하지 않더라도 화면 표시용으로만 잠깐 담는 것은 가능합니다. 다만 그 값으로 결정을 내리면 안 됩니다. 결제 시점에는 반드시 원본을 조건부로 확인합니다.
두 번째는 실제 사고가 자주 나는 자리입니다. 캐시 키에 사용자 식별자를 빠뜨리면 먼저 조회한 사람의 값이 다음 사람에게 나갑니다.
흔한 실수: 개인화 응답을 CDN 에 캐시하는 것. 공유 캐시는 사용자를 구분하지 않으므로 로그인 사용자 응답이 그대로 다른 사람에게 갑니다.
Q.브라우저 캐시, CDN, Redis는 각각 어떤 역할을 하나요?
어디에 두는지에 따라 역할이 다릅니다.
| 계층 | 위치 | 담는 것 | 무효화 |
|---|---|---|---|
| 브라우저 캐시 | 사용자 기기 | 정적 자원, 개인화 응답 | 어렵다. 파일명에 버전을 넣는다 |
| CDN | 사용자 근처 엣지 | 정적 자원, 공용 응답 | 퍼지 API 로 가능하지만 지연이 있다 |
| Redis | 서버 옆 | 조회 결과, 세션, 계산 결과 | 즉시 가능하다 |
사용자에 가까울수록 빠르고 무효화가 어렵습니다. 그래서 바뀌지 않는 것은 앞에, 바뀌는 것은 뒤에 둡니다.
| 대상 | 두는 곳 |
|---|---|
| 이미지와 번들 | 파일명에 해시를 넣고 브라우저와 CDN 에 길게 |
| 공용 API 응답 | CDN 에 짧게 |
| 개인화 데이터 | Redis 에만 |
흔한 실수: 세 계층을 같은 규칙으로 다루는 것. 브라우저 캐시는 우리가 지울 수 없으므로 만료를 길게 걸 때는 반드시 파일명이나 쿼리로 버전을 구분해야 합니다.
먼저 스스로 답해보고 아래 답변과 견줘보세요. 막히는 부분은 문제로 확인할 수 있어요.
읽었으면 문제로 확인해보세요
캐시/Redis 문제를 풀면 틀린 문제가 자동으로 노트에 쌓입니다. 가입 없이 5문제를 먼저 풀어볼 수도 있어요.