캐시와 원본 데이터의 차이: 만료와 무효화를 이해하기
페이지 정보
본문
화면에서 글을 수정했는데 목록에는 예전 제목이 보인다면 저장 실패부터 의심하기 쉽습니다. 하지만 원본은 바뀌었고 목록을 만드는 캐시에 이전 값이 남아 있을 수도 있습니다.
캐시는 자주 필요한 결과를 다시 쓰기 위해 보관한 데이터입니다. 이 글에서는 원본과 복사본의 역할을 나누고 만료와 무효화가 각각 어떤 문제를 다루는지 살펴봅니다.
AI 생성 삽화 · 원본 자료와 다시 사용하는 복사본의 관계를 표현한 개념 삽화입니다.
핵심 정리
만료는 사용 기한을 정하고 무효화는 더 이상 사용하지 않을 값을 지정합니다. 캐시 적중률이 높아도 최신 데이터가 보장되는 것은 아닙니다.
1. 원본과 캐시가 맡은 역할을 나눕니다
서비스에서 어떤 저장소를 기준으로 값을 판단하는지 먼저 정해야 합니다. 이 글에서는 게시글 데이터베이스를 원본, 목록 응답을 보관하는 저장소를 캐시로 가정합니다.
실제 시스템에서는 이 역할이 더 복잡할 수 있지만 처음에는 같은 제목이 두 곳에 존재한다는 점부터 이해하면 됩니다. 캐시를 조회해 필요한 값이 있으면 적중, 없으면 미스라고 부릅니다.
미스가 나면 원본을 조회해 값을 채우는 방식이 캐시 어사이드의 기본 흐름입니다. Microsoft의 패턴 문서에서도 이 읽기 순서를 설명합니다.
캐시에 없다는 것은 게시글이 존재하지 않는다는 뜻이 아닙니다. 원본을 조회한 결과까지 구분해야 합니다.
캐시를 지우는 동작 역시 이 예시에서는 게시글 삭제와 다릅니다. 저장 위치의 이름보다 각 위치가 어떤 데이터를 책임지는지 설명할 수 있어야 장애 상황에서 잘못된 조치를 피하기 쉽습니다.
2. 만료는 복사본에 사용 기한을 붙입니다
TTL은 캐시 항목을 얼마나 유지할지 정하는 데 쓰이는 시간 값입니다. Redis의 EXPIRE는 키에 초 단위 만료를 설정하는 명령입니다.
여기서 시간이 지났다는 사실은 원본이 변경됐다는 통지를 받은 것과 다릅니다. 원본이 그대로여도 기한이 끝날 수 있고 기한이 남았어도 원본은 바뀔 수 있습니다.
따라서 TTL을 최신성의 증명으로 읽으면 안 됩니다. 설명을 위한 가정으로 목록을 60초 동안 보관한다고 해보겠습니다.
값을 저장한 뒤 10초가 지나 제목을 수정하면, 별도 처리가 없을 때 남은 시간 동안 이전 복사본을 사용할 여지가 있습니다. 60초는 권장 설정이 아니라 시간 관계를 보기 위한 숫자입니다.
실제 값은 데이터의 변화 빈도와 오래된 정보를 허용할 수 있는 범위, 원본 조회 부담을 함께 보고 정합니다. 읽을 때마다 기한을 다시 늘리는 설정인지도 별도로 확인해야 합니다.
3. 무효화는 어떤 복사본을 버릴지 결정합니다
무효화는 특정 캐시 값을 더 이상 사용하지 않도록 만드는 처리입니다. 캐시 어사이드에서는 원본을 수정한 뒤 관련 캐시를 지워 다음 읽기에서 다시 채우는 방법을 사용할 수 있습니다.
만료가 시간 기준이라면 이 방식은 변경과 연결된 처리라고 볼 수 있습니다. 두 방법을 함께 쓸 수도 있습니다.
다만 관련 캐시가 무엇인지 찾아야 한다는 문제가 남습니다. 게시글 제목 하나가 상세 화면, 첫 페이지 목록, 검색 결과에 들어갈 수 있다고 가정하면 상세 키 하나만 지워도 충분한지 검토해야 합니다.
어떤 화면에 그 값이 쓰이는지 모르면 무효화 범위를 빠뜨리기 쉽습니다. 반대로 모든 캐시를 매번 비우면 다시 채우는 비용이 커질 수 있습니다.
구현을 시작하기 전에 원본 항목과 파생된 응답의 관계를 작은 표로 그려보면 어떤 키가 연결되는지 정리하는 데 도움이 됩니다.
4. 수정 직후의 시간 순서를 종이에 써봅니다
다음은 설명용 시나리오입니다. 첫 독자가 제목 A를 조회해 목록 캐시가 만들어졌습니다.
편집자는 데이터베이스의 제목을 B로 수정합니다. 다음 독자는 아직 남아 있는 목록 캐시에서 A를 받습니다.
이때 편집 화면에는 B가 보이고 목록에는 A가 보여도 두 화면이 같은 저장소를 읽는다는 전제가 없으면 모순은 아닙니다. 조사할 때에는 저장 요청의 결과, 원본 조회 값, 목록 응답의 출처를 순서대로 확인할 수 있습니다.
여기서 캐시를 먼저 지우고 원본을 나중에 수정하는 흐름을 상상해보겠습니다. 그 사이 다른 읽기가 들어오면 아직 A인 원본에서 복사본을 다시 만들 수 있습니다.
이런 시간 겹침 때문에 순서를 검토해야 합니다. 원본 수정 후 무효화 방식도 모든 동시성 문제를 자동으로 없애지는 않습니다.
이 시나리오는 특정 제품의 장애를 재현한 결과가 아니라 동작 순서를 이해하기 위한 예시입니다.
5. 적중률 외에 데이터가 맞는지도 봅니다
적중률은 캐시 조회 중 값을 찾은 비율을 보여주지만 그 값이 사용자에게 필요한 최신 값인지까지 말해주지는 않습니다. 예를 들어 같은 오래된 응답을 계속 반환하면 적중은 잘 일어나도 화면 수정 반영은 늦을 수 있습니다.
운영 지표를 정할 때에는 응답 시간과 원본 조회량뿐 아니라 어떤 종류의 오래된 응답이 문제가 되는지도 정의해야 합니다. 게시글의 조회 수와 회원의 접근 권한은 같은 최신성 요구로 다루기 어렵습니다.
학습용 프로젝트에서는 캐시를 읽었는지 원본을 읽었는지, 어떤 키를 사용했는지, 값이 언제 만들어졌는지를 확인할 수 있게 해보는 것이 좋습니다. 다만 기록에 실제 사용자의 비공개 내용을 그대로 넣을 필요는 없습니다.
문제를 설명하는 식별 정보와 상태만으로도 흐름을 추적할 수 있습니다. 수치 하나가 좋아졌다는 이유로 전체 동작이 올바르다고 결론 내리지 않는 연습입니다.
6. 캐시가 없을 때의 경로도 설계합니다
캐시는 항상 존재한다고 가정하기 어렵습니다. 만료 외에도 용량 정책이나 재시작 등으로 값이 없을 수 있으므로 미스가 정상적인 경로인지부터 살펴봅니다.
이 글의 캐시 어사이드 예시에서는 원본 조회가 그 다음 경로입니다. 원본을 사용할 수 없는 상황에서 이전 값을 보여줄지 오류를 반환할지는 서비스 요구와 별도 정책에 달려 있습니다.
모든 데이터에 같은 답을 적용할 수는 없습니다. 연습할 때에는 빈 캐시에서 처음 조회하는 경우, 이미 값이 있을 때 읽는 경우, 수정 후 다시 읽는 경우를 나누어 설명해보면 좋습니다.
같은 키를 여러 요청이 동시에 처음 조회할 때 어떤 일이 생기는지도 다음 학습 질문으로 남길 수 있습니다. 캐시 서버를 설치했다는 사실과 실패 상황의 동작이 정해졌다는 사실은 다릅니다.
도입 목적과 기본 읽기 흐름을 문장으로 적어 보면 빠진 조건이 드러납니다.
7. 작은 게시판 예제로 이해를 확인합니다
직접 만든 게시판이 있다면 한 글의 제목만 대상으로 생각 실험을 해볼 수 있습니다. 상세 조회는 원본, 목록은 캐시를 읽는다고 정한 뒤 제목을 바꾸기 전후에 각 화면에서 기대하는 값을 적습니다.
그런 다음 목록 캐시의 키와 만료 조건, 수정 시 무효화할 대상을 써봅니다. 실제 코드를 실행하지 않았더라도 이 표는 설계 가정을 점검하는 데 사용할 수 있습니다.
실행 검증을 한다면 예상과 관찰 결과를 구분해 기록합니다. 다음으로 페이지 번호나 검색어가 바뀐 목록을 추가해봅니다.
동일한 키를 공유해도 되는지, 사용자별로 달라지는 값이 섞이지 않는지 질문이 늘어납니다. 모든 경우를 한 번에 최적화하기보다 어떤 데이터가 같은 응답을 공유할 수 있는지부터 확인합니다.
캐시를 이해한다는 것은 빠른 저장소의 이름을 아는 것에 그치지 않습니다. 복사본이 언제 생기고 언제 쓸 수 없게 되며 없을 때 어디로 가는지 설명할 수 있는 상태를 목표로 삼으면 됩니다.
8. 자주 묻는 질문
Q1. TTL이 길수록 좋은가요?
원본 조회를 줄일 여지가 있지만 오래된 값이 남을 시간도 고려해야 합니다. 데이터별로 허용할 수 있는 변경 반영 지연과 조회 비용을 나누어 판단합니다.
Q2. 캐시를 지우면 원본도 없어지나요?
이 글의 구조에서는 서로 다른 저장 대상이므로 캐시 삭제가 게시글 삭제를 뜻하지 않습니다. 실제 코드에서 어떤 저장소의 어떤 키를 지우는지 확인해야 합니다.
Q3. 무효화를 넣으면 만료는 필요 없나요?
변경 경로와 실패 처리에 따라 함께 사용할 수 있습니다. 한쪽을 넣었다고 다른 조건을 검토할 필요가 사라지는 것은 아닙니다.
Q4. 적중률이 높은데 수정 내용이 안 보이는 이유는 무엇인가요?
캐시 적중과 최신성은 다른 기준입니다. 원본의 현재 값, 사용한 캐시 키, 생성 시점과 무효화 여부를 나누어 확인해야 합니다.
참고 자료
- 이전글재시도와 멱등성의 관계: 같은 요청을 두 번 보내도 괜찮을까요 26.09.13
- 다음글로그·메트릭·트레이스의 차이, 장애를 보는 세 가지 관점 26.09.12
댓글목록
등록된 댓글이 없습니다.