오늘의 회고

캐시

Redis 캐시로 몰려드는 트래픽을 견디다 — 토니모리 공식몰 성능 개선기
토니모리 사례를 통해 시스템의 병목을 정확히 파악하고 캐시를 전략적으로 도입함으로써 성능과 안정성을 근본적으로 개선할 수 있다는 것을 배웠다.

데이터 분야에서도 마찬가지로 어떤 데이터가 자주, 반복적으로, 동일하게 조회되는 지를 분석해서 캐시를 사용하면 데이터 파이프라인이나 모델 파이프라인을 개선할 수 있다는 인사이트를 얻었다.

파이프라인 설계 시 고려해야 할 점

데이터 접근 패턴 분석

• 어떤 데이터가 자주, 반복적으로, 혹은 유사하게 접근되는지를 분석해야 함
• 예: 피처 캐싱, 모델 출력 캐싱, 중간 결과 저장 등

캐시의 전략적 위치 선정

• 파이프라인 내에서 어느 지점에 캐시를 둘지 결정
• 예: DB 앞단, 모델 서빙 앞단, API 응답 처리 전 등

TTL(Time-To-Live)과 만료 전략 설계

• 캐시 데이터의 갱신 시점과 수명을 어떻게 설정할지 계획
• 실시간으로 갱신할 것인지, 주기적인 배치로 갱신할 것인지 선택 필요

안정성 확보 수단으로서의 캐시 활용

• 트래픽 급증이나 장애 상황에서도 안정적으로 서비스가 동작하도록 보완
• 예: 대시보드, ML 모델 서빙, 실시간 ETL 처리 등에서 Redis를 활용하여 시스템의 탄력성을 높일 수 있음

Redis

Redis는 In-memory key-value store로 디스크가 아닌 메모리에 데이터를 저장하는 방식이다. 그렇기 때문에 마이크로초 단위 응답이 가능할 정도로 매우 빠르다.
Key-value 구조 외에도 String, List, Set, Hash 등 다양한 자료구조를 지원한다.

데이터 파이프라인을 아직 설계하지는 않았지만 이번 프로젝트에서 Redis를 사용할 것 같다. 시간날 때 틈틈히 알아봐야겠다.

브랜치 전략

프로젝트를 진행할 때 질서있게(?) 유지되지 않았던 것이 있다면 브랜치 전략이었다. 이전까지 해왔던 프로젝트의 팀원들은 대부분 플젝이 처음이었고 기능 개발 등에 집중하느라 merge 등이 잘 이루어지지 않아, 프로젝트가 끝나면 브랜치가 두루마리 휴지마냥 길게 남아있었다.

이번 프로젝트는 팀원들과 브랜치 관리를 제대로 해서 프로젝트 마지막에는 dev와 release 등 필요한 브랜치만 남아있는 깔끔한 모습으로 프로젝트를 마무리하고 싶다.