캐시는 저장보다 삭제가 어렵다: NestJS 캐시 무효화 재설계
NestJS 서비스에 Redis 캐시를 처음 붙일 때는 조회 메서드 앞에 데코레이터를 추가하는 일로 끝났습니다. 목록, 상세, 통계처럼 호출이 잦은 API의 응답 시간이 줄었고 데이터베이스 부하도 낮아졌습니다. 분산 락에서 사용한 데코레이터와 인터셉터 패턴을 캐시에도 적용했지만, 문제는 기능이 늘어난 뒤 나타났습니다. 프로젝트 이름을 수정했는데 상세 API는 새 값을…
성능 최적화
-
-
실시간 집계가 느려졌을 때 통계를 미리 계산하는 방법
대시보드의 통계 API는 처음에 원본 이벤트와 결과 항목 테이블을 요청마다 집계했습니다. 정확하고 구현이 단순했지만 데이터가 늘면서 하나의 화면이 여러 개의 GROUP BY를 동시에 실행했습니다. 기간, 장비, 제품, 결함 종류 조합이 다양해 캐시 적중률도 낮았습니다. 짧은 기간은 괜찮았지만 장기 조회와 동시 사용자가 겹치면 응답 시간이 크게 흔들렸습니다.…
-
대규모 시계열 데이터를 PostgreSQL 파티션으로 나누기
시간 순서로 계속 쌓이는 이벤트 데이터는 처음에는 단일 PostgreSQL 테이블로도 충분했습니다. 최근 며칠을 조회하는 API, 장비별 필터, 결함 통계 모두 적절한 복합 인덱스로 빠르게 처리됐습니다. 문제는 데이터와 인덱스가 함께 커진 뒤 나타났습니다. 조회 조건은 최근 범위였지만 조회에 사용되는 인덱스는 전체 이력을 포함했습니다. 대량 삭제로 발생한 WAL과…