ML in-memory TtlCache 제거 여부 결정
상태
승인
후보군
| 방안 | 설명 |
|---|---|
| TtlCache 제거 | ml/app/main.py의 signal_cache = TtlCache(...) 및 get_or_compute 래퍼를 완전히 제거 |
| TtlCache 유지 | 기존 in-memory 캐시 유지하되 TTL 값만 조정 |
결정
ml/app/main.py의 signal_cache = TtlCache(...) 및 get_or_compute 래퍼를 제거한다.
결정 이유
- 영속화를 Aggregator → Backend가 담당하게 되면 ML의 in-memory TtlCache는 의미가 없다.
- Aggregator가 DB를 먼저 확인하고 MISS 또는 refresh일 때만 ML을 호출하므로, ML은 요청이 올 때마다 계산하는 순수 계산 서비스가 된다.
- 캐시 레이어를 단순화하여 코드 복잡도를 낮춘다.
검토 대안
| 방안 | 기각 이유 |
|---|---|
| TtlCache 유지 | 이중 캐시가 유지되어 복잡도만 높아짐, 영속화 계층과 역할 중복 |
트레이드 오프
- refresh 요청 시 계산이 항상 실행된다. 이는 의도된 동작이다.
- ML 코드가 단순해지고 캐시 계층이 단일화된다.