프로젝트를 진행하다가 자주 사용될 수도 있는 테이블인데, 이를 일반 테이블로 만들긴 개인적으로 애매하다는 생각이 들었습니다. 외부의 API를 이용하여 처리한 결과를 따로 저장할지 말지 고민중이었습니다. 서버 경험은 많지 않지만, 굳이 이걸 저장까지 해야하나? 라는 생각이 들었습니다.. 이걸 해결할 수 있는 방법을 찾아보다가 캐시 테이블(Cache Table)이란 것을 알게 되어 이번 게시글에서 정리하고 소개해보려 합니다.
1. 캐시에 대한 정보
캐시의 정의
자주 사용되는 데이터나 값을 임시로 저장해두는 고속 데이터 저장소 또는 계층.
캐시를 사용하면 동일한 데이터에 대한 반복적인 요청이 있을 때, 원본 데이터 저장소 보다 훨씬 빠르게 데이터를 이용할 수 있다.
캐시의 특징
- 고속성: 캐시는 메모리 등 빠른 저장 매체를 활용해 접근 속도를 높입니다.
- 암시성: 저장되는 데이터는 일시적이며, 자주 사용되는 데이터의 하위 집합이 저장됩니다.
- 효율성: 반복적으로 조회되는 데이터를 미리 저장함으로써, 원본 데이터에 대한 접근을 줄이고 시스템 전체의 성능과 확장성을 높입니다.
- 적중/미스: 원하는 데이터가 캐시에 있으면 '캐시 히트(Cache Hit)', 없으면 '캐시 미스(Cache Miss)'라고 한다. 원하는 캐시가 없을 경우 원본 저장소에서 데이터를 가져와 캐시에 저장하게 됩니다.
캐시 TTL(Time To Live) 설정 유의사항
데이터의 변경 빈도 및 중요도에 따른 캐시 유효 기간 설정 필요
- 짧은 TTL: 자주 변경되는 데이터
- 긴 TTL: 잘 변경되지 않는 데이터
2. 캐시테이블이란
캐시 테이블의 정의
캐시 테이블은 데이터베이스에서 자주 조회되는 데이터를 미리 저장해두고, 필요할 때마다 빠르게 꺼내 쓸 수 있또록 메모리나 별도의 저장소에 보관하는 테이블입니다. 이런 방식은 디스크 I/O를 줄이고, 전체 시스템의 응답 속도를 많이 높일 수 있습니다.
캐시 테이블의 원리
- 자주 사용되는 데이터 (예: 전체 데이터의 20%인 데이터가 요청의 80%를 차지할 때)를 미리 저장해 두어, 반복적인 DB 조회를 줄입니다.
- DB에 직접 접근하지 않고, 캐시에서 데이터를 가져오므로 처리 속도가 빨라집니다.
- 캐시는 메모리 영역에 저장 됩니다.
캐시 테이블의 장단점
[장점]
- DB 부하 감소: 반복적인 쿼리로 인한 DB 트래픽 감소
- 응답 속도 개선: 메모리에서 직접 반환하여 빠른 속도 응답
- 확장성: 대규모 트래픽 안정적 대응 가능
[단점]
- 데이터 최신성: 캐시된 데이터가 실제 DB와 달라질 수 있으므로, 최신화가 중요한 데이터에는 X
- 캐시 일관성: DB의 데이터 변경 시 캐시도 갱신 필요
- 캐시 무효화, 캐시 관통, 캐시 쇄도 등 운영상 이슈 대응 필요
캐시 테이블 사용 케이스
- 읽기 빈도가 높은 데이터일 때
상품 목록, 인기 게시글 등 자주 조회되고, 자주 변경되지 않는 데이터 - 사용자 정보
예시: 로그인한 사용자의 프로필, 세션, 권한 정보 - 쿼리 결과 캐싱
복잡한 쿼리 결과를 캐시 테이블에 저장해두고, 동일한 요청이 들어올 시 빠르게 응답 가능
예시: 통계 데이터, 추천 상품 목록 - 외부 시스템 연동 결과
API 호출 결과 등을 캐시에 저장해 중복 호출 방지
예시: 실시간 환율 정보 - 읽기 트래픽이 집중되는 서비스
SNS 등 특정 데이터에 읽기 요청이 집중될 때 - 데이터가 없는 사실 자체도 캐싱
없는 데이터에 대한 반복적인 조회를 막기 위해, 값이 없는 상태도 캐싱
3. 결론
인메모리 캐시와 영구 저장소의 차이점
구분 | 캐시 메모리 저장소 | 영구 저장소 |
저장 위치 | 주로 RAM(메모리)에 저장 | 디스크(SSD, HDD 등)에 저장 |
데이터 지속성 | 휘발성(임시적, 서버 종료 시 데이터 소실 가능) | 비휘발성(영구적, 전원 꺼져도 유지) |
접근 속도 | 매우 빠름(마이크로초~밀리초 단위) | 상대적으로 느림(밀리초~초 단위) |
용량 | 제한적(메모리 크기에 의존) | 대용량 저장 가능 |
주요 목적 | 데이터 접근 성능 향상, 반복 조회 최소화 | 데이터의 장기적 보존 및 관리 |
사용 예시 | 자주 조회되는 데이터, 세션, 임시 결과 등 | 사용자 정보, 트랜잭션 기록 등 |
내구성 | 낮음(데이터 손실 위험 존재) | 높음(데이터 무결성 보장) |
내 경우 케이스를 어떻게 할지 GPT 와 오랜 대화를 나누어 봤는데, 그냥 영구 저장소에 저장하라는 안내를 받았습니다. 언제 고객 문의가 들어와서 이거 언제 어떤 문제가 생겼는데요~, 하면서 수정해달라고 할 수도 있기 때문이라고 했습니다.
서버 측면에서 이런 CS가 들어올 수도 있고, 대비해두면 에러를 해결할 수도 있다는 것을 알게 되었습니다.
아쉽게도 이번에는 쓰지 않게 되었지만, 캐시 테이블을 배웠기 때문에 적재적소에 이용해볼 수 있을 것 같습니다.
즐거운 개발 생활 되세요~
'Programming' 카테고리의 다른 글
[도메인 구매] 도메인 구매 사이트 비교하고 구매하기 (+ 서브도메인 설정하기) (0) | 2025.07.27 |
---|---|
서브도메인 vs 서브 디렉터리 차이 | 내 사이트엔 어떤 것을 적용할까? (0) | 2025.04.26 |
클라이언트 컴포넌트와 서버 컴포넌트(그리고 use client) (0) | 2025.01.31 |
Next.js의 Middleware가 뭘까? (0) | 2024.02.19 |
dangerouslySetInnerHTML 쓸 때 Styled-components가 동작하지 않는 문제 (0) | 2022.12.17 |