본 게시글은 미리디의 김민석, 이효성, 노정훈님과 함께 작성하였습니다. 미리디의 미리캔버스 소개 미리디의 미리캔버스는 “누구나 쉽게, 함께 만드는 디자인” 이라는 철학 아래, 프레젠테이션부터 SNS 카드뉴스, 유튜브 썸네일, 포스터까지 일상의 모든 시각 콘텐츠를 브라우저 하나로 만들 수 있는 실시간 협업 디자인 플랫폼입니다. 앞선 포스팅에서 소개한 MongoDB Atlas에서 Amazon DocumentDB로 전환 이후, 수백만 건의 디자인 데이터 위에서 수많은 […] ||
본 게시글은 미리디의 김민석, 이효성, 노정훈님과 함께 작성하였습니다.
미리디의 미리캔버스 소개
미리디의 미리캔버스는 “누구나 쉽게, 함께 만드는 디자인” 이라는 철학 아래, 프레젠테이션부터 SNS 카드뉴스, 유튜브 썸네일, 포스터까지 일상의 모든 시각 콘텐츠를 브라우저 하나로 만들 수 있는 실시간 협업 디자인 플랫폼입니다.
앞선 포스팅에서 소개한 MongoDB Atlas에서 Amazon DocumentDB로 전환 이후, 수백만 건의 디자인 데이터 위에서 수많은 사용자가 동시에 편집하고, 검색하고, 불러오는 환경에서는 단 몇 밀리초의 쿼리 지연도 사용자 경험에 직결됩니다. 미리디 팀이 마주한 다음 과제는 바로 이 쿼리 성능을 안정적으로 유지하는 것이었습니다.
이 블로그에서는 Amazon DocumentDB로 전환하면서 겪은 인덱스 최적화 과정을 실제 쿼리 예시와 함께 공유합니다. 어떤 인덱스 전략이 효과적이었는지, MongoDB Atlas와의 동작 차이에서 비롯된 문제를 어떻게 해결했는지, 그 구체적인 경험을 담았습니다.
전환 배경과 전체 여정은 이전 포스트를 참고하세요.
→ Amazon DocumentDB로 미리캔버스의 성능 50%와 비용 30%를 개선하다
개요
MongoDB에서 인덱스 설계의 정석으로 알려진 ESR(Equality-Sort-Range) 원칙이 있습니다. Equality 조건을 먼저, Sort 필드를 다음에, Range 조건을 마지막에 배치하면 최적의 인덱스 스캔이 가능하다는 원칙입니다.
그런데 Amazon DocumentDB로 전환한 후, 동일한 인덱스와 동일한 쿼리가 기대와 다르게 동작하는 경우를 여러 차례 경험했습니다. Amazon DocumentDB의 Query Planner가 MongoDB의 것과 다르기 때문입니다.
이 블로그에서는 저희가 실제로 겪은 4가지 인덱스 패턴 문제와 해결 방법, 그리고 프로덕션 운영에서의 튜닝과 모니터링 노하우를 공유합니다.
Partial Index: $exists 조건의 함정
문제 상황
MongoDB에서는 partial index를 생성할 때 partialFilterExpression에 $exists: true 조건을 넣고, 쿼리에서도 해당 필드가 존재하는 문서만 조회하면 인덱스가 활용됩니다.
// 인덱스 생성
db.node.createIndex(
{ itemIdx: 1, type: 1 },
{ partialFilterExpression: { itemIdx: { $exists: true } } }
)
// 쿼리
db.node.find({
itemIdx: { $in: [1, 2, 3] },
type: "USER_DESIGN"
})
MongoDB에서는 이 쿼리가 partial index를 활용하여 IXSCAN으로 처리됩니다. 그러나 Amazon DocumentDB에서는 이 인덱스를 사용하지 않았습니다.
원인
Amazon DocumentDB의 partial index 활용 조건은 MongoDB보다 엄격합니다. Amazon DocumentDB는 쿼리 필터가 partialFilterExpression과 정확히 일치하고 동일한 데이터 유형인 경우에만 부분 인덱스를 사용합니다.
즉, partialFilterExpression이 { itemIdx: { $exists: true } }인데 쿼리 조건이 { itemIdx: { $in: [...] } }이면, 조건이 “정확히 일치”하지 않으므로 인덱스를 사용하지 않습니다.
해결
partialFil