사전 계산과 달랐던 Redis 과부하
- 문제
- 데이터 용량·예상 요청 건수로는 문제가 없다고 판단했지만, 실제로는 Redis 과부하가 발생
- 해결
- Redis 사용을 제외해 정상화한 뒤 조회 흐름을 분석. 채널·영상 정보의 연쇄 캐싱으로 캐시 건수가 늘어난 원인을 찾아 DevOps팀에 공유
- 결과
- 집계 결과의 저장 용량과 공통 조회 부하를 구분. 플랫폼 차원의 변경이 필요하다는 피드백 확인
개요
영상에서 추출한 브랜드·제품 언급을 긍정·부정·중립 통계와 일별 추이로 제공했습니다. PM·Frontend·Designer와 협업하며 대시보드의 백엔드 전체 구조와 API를 담당했습니다.
담당 업무
영상 맥락 데이터를 만든 파이프라인부터 대시보드 서빙까지 담당. 캐시 생성 충돌, 동일 요청 중복, 서로 다른 집계의 총부하를 각각 나눠 제어
- 운영 개선
- 일별 결과 재사용, 같은 요청의 중복 집계 방지, 집계 동시 실행 제한과 사전 계산
- 브랜드당 영상 수
- 최대 2만
- 데이터 갱신 특성
- 일 단위
- 엔터프라이즈 고객
- 계약 기여
구조
- 01영상 맥락 데이터브랜드·제품·언급 정보
- 02브랜드별 조회영상 목록과 관련 언급
- 03날짜별 집계긍정 · 중립 · 부정 통계
- 04결과 저장·재사용일 단위 캐시와 사전 집계
- 05대시보드 제공언급 현황과 일별 추이
문제 및 해결
기획 기준에 맞아도 고객에게는 잘못된 분류
- 문제
- 개발자는 기존 기준에 맞는 결과로 봤지만, PM은 고객에게 잘못된 결과로 받아들여질 수 있다고 판단
- 해결
- 불만 사례를 검토하고 고객에게 유용한 결과라는 공동 목적을 확인. 고객 관점의 명확한 오답을 피하도록 분류 프롬프트 수정
- 결과
- 합의한 기준을 반영해 논의 대상이던 유형의 오류를 해소
구현 내용
- 동일 요청 공유
- RequestCoalescer가 진행 중 Promise를 공유해 같은 키의 중복 집계를 방지
- 동시 실행 제한
- Semaphore는 캐시 미스 작업만 제한. 캐시 적중 요청은 집계 대기열을 거치지 않음
- 저장소 잠금
- 잠금과 완료 대기로 여러 실행 주체의 동일 집계 작업 충돌을 줄임
- 데이터 접근
- OpenSearch의 영상 정보와 Cassandra의 일별 통계를 조회해 집계하고 S3에 결과를 저장
- 사전 집계
- 대형 브랜드와 최근 조회 브랜드는 오프피크에 계산해 요청 시 새 집계를 줄임