ML 응답 캐시 저장소 선택
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| Redis | 독립 인프라로 ML 응답 JSON을 symbol 키, TTL 600s로 저장 |
| In-memory (Caffeine) | Aggregator 프로세스 내 메모리 캐시 |
| DB (MySQL) | 관계형 DB에 캐시 테이블 신설 |
| BE DB 공유 | Aggregator가 BE의 MySQL에 직접 의존 |
결정
ML 응답을 Redis에 symbol 키로 TTL 600초 캐시한다.
결정 이유
- Redis는 독립 인프라 → Aggregator 재시작 후에도 캐시 유지
- TTL 기반 자동 만료 → 별도 정리 로직 불필요
- ML 자체 캐시 TTL(600s)과 동일하게 설정해 일관성 유지
검토 대안
| 방안 | 기각 이유 |
|---|---|
| In-memory (Caffeine) | Aggregator 재시작 시 캐시 유실 |
| DB (MySQL) | Aggregator가 DB를 가지면 무상태 원칙 위반, 스키마 관리 부담 |
| BE DB 공유 | Aggregator가 BE DB에 직접 의존 → 서비스 간 결합 |
트레이드오프
- Redis 컨테이너 추가로 로컬 환경 복잡도 증가
- 재시작 후에도 캐시가 유지되어 ML 장애 상황에서 가용성 확보