우리가 중요한 API에서 캐싱을 제거한 이유

Source: Dev.to

Introduction

API에서 데이터 캐싱을 생각하면 자동으로 응답 시간이 빨라지고, 데이터베이스 호출이 줄어들며 전반적인 성능이 향상된다고 떠올립니다. API가 중요할수록(예: 금융) 캐싱이 가져다줄 이점도 커집니다. 하지만 특정 상황에서는 캐싱이 오히려 병목이 되었습니다.

Background

문제의 API는 Spring Boot와 다수의 연동을 사용해 구축된 온‑프레미스 REST 엔드포인트입니다. 프로덕션에서는 잘 동작했지만, 더 높은 확장성·안정성·고가용성·멀티 인스턴스 운영을 위해 아키텍처를 재검토해야 했습니다.

Options Considered

• Distributed caching (e.g., Redis) – 새로운 컴포넌트를 추가하고 유지보수 부담이 늘어나며 추가적인 기술 역량이 필요합니다.
• Synchronizing Spring cache between instances – 고전적인 캐시 무효화 문제 때문에 오류가 발생하기 쉽습니다.
• Removing caching altogether – 광범위한 논의 끝에 최종 선택되었습니다.

Reasons for Removing Caching

1. Cache synchronization complexity – 인스턴스 간 맞춤형 메커니즘이 취약합니다.
2. Infrastructure cost – Redis 도입은 추가 컴포넌트와 운영 부담을 초래합니다.
3. Write‑heavy workload – API가 읽기보다 쓰기를 더 많이 수행하므로 캐싱이 불필요한 조회를 늘립니다.
4. Low read traffic – 하트비트 체크가 30초마다 발생하고, 다른 읽기 트래픽은 미미합니다.
5. Gradual traffic growth – 트래픽이 급격히 증가하지 않고 서서히 늘어나고 있습니다.
6. Upcoming cloud migration – 향후 12개월 내에 재설계가 예정돼 있어 가벼운 설계가 바람직합니다.
7. High‑availability requirement – 고가용성은 설계 차원에서 확보해야 하며, 우연히 얻는 것이 아닙니다.

Trade‑offs

이 결정으로 인해 약간의 성능 저하가 있었지만, 고가용성, 안정성 및 단순성이 크게 향상되었습니다. 부하 테스트 결과 응답 시간에 대한 영향은 허용 가능한 수준임을 확인했습니다.

Lessons Learned

• 캐싱과 같은 베스트 프랙티스도 적용 전에 적합성을 평가해야 합니다.
• 배포 환경(온‑프레미스 vs. 클라우드), 데이터 양, 소비자 규모, 비기능 요구사항, 장기적인 영향을 고려합니다.
• 과도한 설계는 해결하려는 문제보다 더 많은 문제를 야기할 수 있습니다.

Outcome

API가 더 간결해졌으며, 오래된 데이터에 대한 걱정 없이 여러 인스턴스에서 실행될 수 있게 되었고, 고가용성 목표를 달성했습니다. 팀은 이제 향후 클라우드 마이그레이션을 대비해 더 단순하고 유지보수하기 쉬운 서비스를 보유하게 되었습니다.