이 글은 AI가 원문을 분석하여 핵심 내용을 요약한 것입니다.
이 게시물은 기획전 API 성능 이슈를 컬렉션 구조와 조회 패턴 관점에서 개선한 경험을 정리한 것 니다.
영원희 도입 후 중복 조회 원인 발견
영원희로 조회 흐름을 추적하며 같은 planshop_item_info 도큐먼트를 테마/상품 단계에서 중복 조회하는 구조를 확인 니다. 또한 필요한 일부 테마만 가져오기 어려워 전체를 읽고 필터링해야 했고, 그룹 기획전 정보가 planshop 마스터에 중복 저장되어 수정 시 불필요한 전체 갱신이 반복됨을 확인 니다. 컬렉션 분리로 데이터 크기/중복 조회/갱신 제거
상품을 1 도큐먼트=1 상품 형태로 planshop_theme_item로 분리하고 테마 정보는 planshop 마스터로 옮겨 aggregation을 find로 단순화하고 필요한 구분자만 정확히 조회 가능하게 만듦 니다. 그룹 정보도 별도 컬렉션 분리
planshop_group 컬렉션을 신규 생성해 그룹 수정 시 토픽 발행을 1회로 제한하도록 개선 니다. 구조 변경 후 API에서 발생한 새로운 성능 병목
테마/기획전 단위로 병렬 조회하면서 DB 커넥션과 getMore/killCursor 이슈가 나타났고, limit과 cursorBatchSize를 맞추는 방식과 한계 조정이 필요했음 니다. 마지막으로 멀티기획전은 테마별 50건을 가져오던 방식을 상위 50건만 기획전ID 단일 조건으로 조회하도록 바꿔 조회량과 getMore 가능성을 줄임 니다. 분리는 목적이 아니라 설계 입력임을 강조
데이터 분리의 이점뿐 아니라 N회 조회, 인덱스 재검토, 조회 패턴 변화에 따른 운영 이슈까지 함께 그려봐야 한다고 정리 니다.