MongoDB 리드·아키텍트 데이터베이스 심화 면접

주문과 주문상품은 Embedding 방식을 선택합니다. 주문상품은 주문 생성 시점에 함께 생성되고 이후 거의 변경되지 않으며, 항상 주문과 함께 조회되기 때문입니다. 배송 정보는 Referencing 방식을 선택합니다. 배송 상태는 빈번하게 업데이트되고, 배송 추적 시스템에서 독립적으로 조회될 수 있기 때문입니다. 또한 주문상품을 임베딩하면 JOIN 없이 한 번의 쿼리로 주문 전체를 조회할 수 있어 성능상 이점이 큽니다. 다만 주문상품 배열이 16MB를 초과할 가능성이 있다면 Bucket Pattern을 적용하여 일정 개수마다 분할하는 것을 고려해야 합니다. 이러한 하이브리드 접근법이 MongoDB의 장점을 최대한 활용하면서도 실무적 제약을 충족하는 방법입니다.

ESR 규칙에 따라 {userId: 1, eventType: 1, timestamp: 1} 순서로 복합 인덱스를 생성합니다. userId와 eventType은 equality 조건이고 timestamp는 range 조건이므로 이 순서가 최적입니다. Equality 필드를 먼저 배치하면 인덱스 스캔 범위를 최소화할 수 있고, Range 필드를 마지막에 두면 정렬 작업을 인덱스로 처리할 수 있습니다. Covered Query를 구현하려면 projection에 _id를 제외하고 인덱스에 포함된 필드만 요청해야 합니다. 예를 들어 쿼리에 {userId, eventType, timestamp, count}가 필요하다면 인덱스를 {userId: 1, eventType: 1, timestamp: 1, count: 1}로 확장하여 IXSCAN만으로 결과를 반환할 수 있습니다. explain() 결과에서 totalDocsExamined가 0이면 Covered Query가 성공한 것입니다.

MongoDB 트랜잭션은 WiredTiger의 스냅샷 격리를 사용하여 성능 오버헤드가 발생하며, 특히 샤딩 환경에서는 분산 트랜잭션 코디네이터로 인한 지연이 증가합니다. 트랜잭션 시간 제한(기본 60초)과 oplog 크기 제한도 고려해야 하며, 장기 실행 트랜잭션은 다른 작업을 블로킹할 수 있습니다. 대안으로 Single Document Atomicity를 활용한 설계를 권장합니다. 예를 들어 계좌 이체의 경우 거래 문서를 먼저 생성하고(pending 상태), 각 계좌를 개별적으로 업데이트한 후 거래 상태를 completed로 변경하는 Two-Phase Commit 패턴을 사용할 수 있습니다. 또는 관련 데이터를 하나의 문서로 임베딩하여 단일 문서 업데이트로 원자성을 보장하는 방법도 효과적입니다. 보상 트랜잭션(Saga Pattern)을 구현하여 실패 시 롤백 로직을 애플리케이션 레벨에서 처리하는 것도 고려할 수 있습니다.

먼저 Database Profiler를 level 1 또는 2로 설정하여 느린 쿼리를 system.profile 컬렉션에서 수집합니다. 해당 aggregation에 explain('executionStats')를 실행하여 각 스테이지의 실행 시간과 문서 처리량을 확인합니다. executionTimeMillis, totalDocsExamined, totalKeysExamined 비율을 분석하여 인덱스 효율성을 평가하고, COLLSCAN이 발생하는지 확인합니다. $match와 $sort 스테이지를 파이프라인 앞쪽으로 이동시켜 인덱스를 활용하고 처리 문서 수를 조기에 줄입니다. $lookup이나 $group 같은 메모리 집약적 연산은 allowDiskUse: true 옵션을 고려하되, 가능하면 인덱스를 활용하도록 재설계합니다. nReturned 대비 totalDocsExamined 비율이 높으면 인덱스 추가나 쿼리 재작성이 필요합니다. 최종적으로 serverStatus의 wiredTiger 캐시 히트율과 opcounters를 모니터링하여 시스템 레벨 병목도 확인합니다.

userId 단독 샤드 키는 해시 샤딩 시 데이터가 균등하게 분산되지만, region 기반 쿼리에서 모든 샤드를 스캔하는 broadcast 쿼리가 발생합니다. {region: 1, userId: 1} 복합키는 region별 쿼리에서 targeted 쿼리가 가능하여 성능이 우수하지만, region의 카디널리티가 낮으면 특정 샤드에 데이터가 집중되는 핫스팟 문제가 발생할 수 있습니다. 최적 전략은 {region: 1, userId: hashed}로 설정하여 region별 격리와 균등 분산을 동시에 달성하는 것입니다. Chunk 크기는 기본 64MB에서 시작하되, Chunk Migration 빈도를 모니터링하여 조정합니다. Jumbo Chunk 방지를 위해 샤드 키의 카디널리티를 충분히 확보하고, 단일 샤드 키 값이 64MB를 초과하지 않도록 설계해야 합니다. sh.status()로 청크 분포를 정기적으로 확인하고, balancer 윈도우를 업무 시간 외로 설정하여 운영 영향을 최소화합니다.