perf: 공개 코스 조회 API에 Redis 캐싱 적용 - #203
Merged
Merged
Conversation
부하테스트(초당 20건)에서 p95 9.3초, 에러율 71%로 KPI 미달성. 응답시간이 구간마다 계속 치솟고 대기 요청이 눈덩이처럼 쌓이는 패턴 확인 — 리전 간 DB 왕복(회당 약 60~90ms)이 동시 요청마다 반복되며 스레드/커넥션을 묶어두는 것이 원인으로 진단됨. 읽기 전용 3개 API(전체 페이지 수/마라톤/추천 목록)에 @Cacheable 적용, TTL 1분. total-page-count는 전체 유저 공통이라 키 없이 캐싱하고, 나머지 둘은 응답에 유저별 스크랩 여부가 섞여있어 userId를 캐시 키에 포함함(실 트래픽에서는 이번 부하테스트만큼 히트율이 높지 않을 수 있음). RedisConfig에 명시적 CacheManager 빈 추가 — GenericJackson2JsonRedisSerializer로 DTO 직렬화, TTL 1분으로 캐시 무효화 리스크를 제한.
unam98
requested review from
RinRinPARK,
YuSuhwa-ve and
funnysunny08
as code owners
July 28, 2026 21:02
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This was referenced Jul 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
배경
dev 환경에서 Artillery 부하테스트(초당 20건, KPI: p95 500ms 이하·에러율 0%) 결과 p95 9.3초·에러율 71%로 KPI 미달성. 응답시간이 구간마다 계속 치솟고 대기 요청이 눈덩이처럼 쌓이는 패턴을 확인 — 리전 간 DB 왕복(회당 약 60~90ms)이 동시 요청마다 반복되며 스레드/커넥션을 묶어두는 것이 원인으로 진단됨.
변경 내용
읽기 전용 3개 API(전체 페이지 수/마라톤/추천 목록)에
@Cacheable적용, TTL 1분.total-page-count: 전체 유저 공통 응답이라 키 없이 캐싱marathon,recommend: 응답에 유저별 스크랩 여부(isScrap)가 섞여있어userId(+페이지/정렬)를 캐시 키에 포함 — 실 트래픽에서는 유저가 분산되는 만큼 히트율이 이번 부하테스트(단일 유저 반복 호출)만큼 극적이진 않을 수 있음RedisConfig에 명시적CacheManager빈 추가 —GenericJackson2JsonRedisSerializer로 DTO 직렬화, TTL 1분으로 캐시 무효화 리스크를 제한.검증 (dev 환경)
동일 조건(초당 20건, 워밍업 10초+타겟 30초) 재테스트 결과:
목표 부하(20건/s)에서 p95 500ms 자체는 아직 못 넘겼지만, 에러율은 사실상 해소되고 서버 크래시도 없어짐. 잔여 지연은 Render 0.1 vCPU 자체의 순수 처리 용량 한계로 판단(캐싱으로 해결 가능한 범위 밖).
알려진 한계