MongoDB에서 대용량 데이터를 효율적으로 다루기 위해 꼭 알아야 할 핵심 개념이 있습니다. 바로 샤드 키(Shard Key)입니다. 잘못 선택하면 성능 저하, 올바르게 선택하면 수평 확장의 핵심! 이 글에서 샤드 키의 개념부터 선택 전략까지 정리합니다.
 

🔹 샤드 키란 무엇인가?

MongoDB에서 샤드 키(Shard Key)는 데이터를 여러 샤드(서버)에 분산 저장할 기준 필드입니다. 이는 MongoDB의 샤딩 구조에서 가장 중요한 개념이며, 성능과 확장성에 직접적인 영향을 줍니다.
 
예:

sh.shardCollection("mydb.users", { user_id: 1 });

 
위 명령은 user_id 필드를 기준으로 데이터를 분산하겠다는 의미입니다.

🔹 샤드 키 분할 방식: 범위 vs 해시

• Range: 시간 순 정렬에 유리하나 데이터 쏠림(hotspot) 위험 존재
• Hashed: 고르게 분산되나 범위 쿼리 불리

🔹 좋은 샤드 키의 조건

🔹 샤드 키 선택 예시 비교

🔹 샤드 키 잘못 선택 시 발생하는 문제

• 특정 샤드에 데이터/트래픽 몰림 → Hotspot 문제
• 샤드 키 없는 쿼리 → 모든 샤드에 브로드캐스트
• 변경 불가 → 초기 설계가 매우 중요

🔹 샤드 키 선택 전략 요약

1. 쿼리 패턴 분석: 어떤 조건으로 데이터를 자주 조회하는가?
2. 데이터 분포 시뮬레이션: 고르게 나뉘는가?
3. 성장성 고려: 트래픽과 데이터 증가에 잘 대응하는가?

✅ 마무리: 샤드 키가 MongoDB 성능을 결정한다

MongoDB에서 샤드 키는 단순한 필드가 아닙니다.
잘못 설정하면 전체 성능이 급락할 수 있고, 잘 설정하면 무중단 확장도 가능하게 만들어줍니다.
초기 설계부터 신중하게 접근하고, 실 운영 쿼리 패턴을 꼭 반영해보세요.

🧨 사례 1. "TTL 인덱스를 만들었는데 데이터가 지워지지 않아요"

💬 문제 상황

db.logs.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 })

• 인덱스는 정상적으로 생성됨
• 시간이 지나도 문서가 삭제되지 않음

🕵️ 원인 분석

✅ createdAt 필드가 Date 타입이 아님
MongoDB TTL은 필드가 ISODate, new Date() 형식이 아니면 작동하지 않음

✅ 해결 방법

// 잘못된 예
{ createdAt: "2025-06-29T10:00:00Z" }  // 문자열 ❌

// 올바른 예
{ createdAt: ISODate("2025-06-29T10:00:00Z") }  // Date 타입 ✅

🔧 TTL 인덱스는 문자열/숫자 필드에서는 절대 작동하지 않음!

🧨 사례 2. "일부 문서만 TTL 삭제가 안 됨"

💬 문제 상황

• 1시간 TTL 인덱스를 적용했는데, 일부 문서만 남아 있음

🕵️ 원인 분석

✅ createdAt 필드가 없는 문서
TTL은 해당 필드가 존재하지 않으면 대상에서 제외함

✅ 해결 방법

• 컬렉션 내 모든 문서에 TTL 기준 필드(createdAt)이 반드시 존재하도록 보장
• 또는 createdAt이 null일 경우를 감지하여 사전 처리

🧨 사례 3. "삭제 타이밍이 너무 늦어요"

💬 문제 상황

• expireAfterSeconds: 600 설정했는데
• 삭제가 15분~20분 후에 발생

🕵️ 원인 분석

✅ TTL은 실시간이 아니라, MongoDB 내부 백그라운드 스케줄러에 의해 동작
→ 기본적으로 60초 간격으로 TTL 스캔
→ 시스템 부하 또는 locking 상황이면 딜레이 발생

✅ 해결 방법

• TTL은 정확한 시간 보장을 하지 않음
• 만약 정확한 삭제 시간이 필요하면 → cron-job 또는 TTL + 상태필드 관리 조합 사용

📌 요약: TTL 인덱스가 작동하지 않는 주요 원인

🔧 운영 팁: TTL 오작동 방지 체크리스트

✅ TTL 대상 필드는 반드시 Date 타입인지 확인
✅ 문서 생성 시 TTL 기준 필드를 무조건 포함
✅ 지연 허용이 가능한 데이터에만 TTL 사용
✅ TTL 인덱스 외에도 cron-job이나 soft delete 백업 전략 병행

📝 마무리

MongoDB TTL 인덱스는 강력하지만, 제약이 분명한 기능입니다.
실제 운영에서는 TTL이 자동 삭제를 보장하지 않을 수 있고,
이때는 원인 분석과 대체 전략이 반드시 필요합니다.

TTL 인덱스는 "간단한 만료 처리용",
복잡한 삭제 제어는 cron-job 또는 상태 필드 기반 soft delete가 정답입니다.

📝 관련 블로그

데이터 자동 삭제, 어떤 방식이 더 좋을까?"

MongoDB에는 오래된 데이터를 자동으로 삭제할 수 있는 방법이 여러 가지가 있습니다.
가장 대표적인 것이 바로:

• ✅ TTL 인덱스
• ✅ cron-job(크론 잡)

둘 다 "시간이 지난 데이터를 제거한다"는 공통 목적을 갖고 있지만,
동작 방식, 유연성, 삭제 로직 제어 측면에서 큰 차이가 있습니다.

👉 이번 글에서는 TTL 인덱스 vs cron-job을 비교하고,
상황별로 무엇을 선택해야 더 효율적인지 알아보겠습니다!

🧠 1. MongoDB TTL 인덱스란?

• MongoDB의 내장 기능
• 특정 날짜 필드를 기준으로, expireAfterSeconds가 지나면 자동 삭제
• DB 내부에서 백그라운드로 동작 (기본 60초 간격으로 스캔)

db.logs.createIndex({ createdAt: 1 }, { expireAfterSeconds: 3600 });

🛠️ 2. cron-job이란?

• 운영체제 수준의 스케줄러 작업
• 특정 시간마다 스크립트를 실행
• MongoDB 쿼리를 포함한 어떤 명령이든 실행 가능

# 매시간 logCleaner.js 실행
0 * * * * /usr/bin/node /scripts/logCleaner.js

📊 3. TTL 인덱스 vs cron-job 비교표

💡 4. 어떤 상황에서 무엇을 써야 할까?

✅ TTL 인덱스를 쓰기 좋은 경우

• 정해진 시간 이후 단순 삭제만 하면 됨
• 예: 세션, OTP, 알림, 캐시, 임시 파일

✅ cron-job을 써야 하는 경우

• 복잡한 삭제 조건이 필요하거나,
• 삭제 전/후 추가 작업이 필요한 경우
  (백업, 로그 기록, 알림 전송 등)

🔧 5. 두 가지를 함께 쓰는 하이브리드 전략

TTL은 간단한 삭제 담당, cron은 복잡한 비즈니스 로직 처리용

예:

• TTL로 30일 지난 로그 자동 삭제
• cron-job으로 90일 지난 로그를 백업 후 삭제

✅ 마무리 요약

MongoDB TTL 인덱스는 설정이 간단하고, 성능에 부담이 적은 반면,
cron-job은 복잡한 작업과 제어가 필요한 경우 훨씬 강력한 선택입니다.

✅ 관련 블로그

💡 MongoDB는 자동으로 데이터를 삭제할 수 있다?!

MongoDB는 대용량 데이터를 저장하는 데 탁월하지만, 오래된 로그나 캐시, 세션 데이터를 그대로 두면
💥 성능 저하와 디스크 낭비가 발생할 수 있습니다.

이런 문제를 해결하기 위한 강력한 기능이 바로
✅ TTL 인덱스 (Time-To-Live Index) 입니다.

이번 포스팅에서는

• TTL 인덱스란 무엇인지
• 어떤 상황에 쓰는지
• 실제 사용법과 주의사항은 무엇인지

실전 중심으로 정리해드립니다!

🕒 1. MongoDB TTL 인덱스란?

⏳ TTL = 정해진 시간이 지나면 문서를 자동 삭제하는 인덱스

MongoDB는 문서에 있는 날짜(Date) 필드를 기준으로
expireAfterSeconds 값만큼 시간이 지나면 해당 문서를 자동으로 삭제합니다.

📌 복잡한 배치 스크립트 없이, DB가 알아서 처리!

💡 2. TTL 인덱스는 언제 사용할까?

📉 성능 최적화와 저장 공간 확보에 매우 유용!

🛠️ 3. TTL 인덱스 사용법

🔹 1) 문서 구조 예시

{ "token": "abc123", "createdAt": ISODate("2025-06-29T10:00:00Z") }

🔹 2) TTL 인덱스 생성

db.tokens.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 1800 } // 30분 후 자동 삭제 )

⏰ 기준 시점은 createdAt 필드의 값이며, 이 필드는 반드시 ISODate 타입이어야 합니다.

⚙️ 4. TTL 인덱스 동작 원리

• MongoDB는 내부적으로 60초마다 TTL 인덱스를 스캔합니다.
• 조건에 해당하는 문서를 자동 삭제합니다.

🕐 생성 → 30분 경과 → TTL 인덱스 스캔 → 삭제

📌 삭제는 실시간은 아니며, 최대 60초 지연될 수 있습니다.

⚠️ 5. 주의사항 꼭 확인!

• ⛔ 필드는 반드시 Date 타입이어야 함
• 🔄 TTL 인덱스는 삭제만 가능, 업데이트 불가
• 🔍 쿼리 성능에는 영향 없음 (인덱스 용도는 삭제만)
• 🧱 복합 인덱스는 TTL 필드를 맨 뒤에 배치해야 함
• 📛 한 컬렉션에 TTL 인덱스는 1개만 유효

❓ 6. 자주 묻는 질문 (FAQ)

Q. 문서마다 다른 만료 시간을 줄 수 있나요?

❌ 불가능합니다. TTL 인덱스는 고정된 시간만 지원합니다.

Q. 삭제 로그를 확인할 수 있나요?

❌ TTL 인덱스로 삭제된 문서는 로그가 남지 않습니다.
✅ 필요하다면 soft delete 방식(삭제 플래그)을 사용하세요.

✅ 마무리 요약

MongoDB의 TTL 인덱스는
✅ 불필요한 데이터를 자동 삭제하고
✅ 성능과 저장 공간을 효율적으로 관리하는
최적의 자동 정리 솔루션입니다.

처리할 데이터가 많아 고민이라면, 지금 바로 TTL 인덱스 도입을 고려해보세요!

✅ 관련 블로그

💡 MongoDB의 성능, 한계는 어디까지일까?
서비스가 성장할수록 데이터는 기하급수적으로 늘어나고, 단일 서버로는 감당할 수 없는 시점이 찾아옵니다.
바로 그때 필요한 기술이 샤딩(Sharding)입니다.

📌 이번 포스팅에서는

• MongoDB 샤딩이란 무엇인지
• 왜 필요한지
• 어떻게 구성되고, 어떤 주의점이 있는지

를 알기 쉽게 정리해드립니다.
대용량 데이터 처리의 실전 전략, 지금 시작합니다! 🔍

🧩 1. MongoDB 샤딩이란?

🧠 샤딩(Sharding)이란?
데이터를 여러 서버에 분산 저장하여, 단일 노드의 부하를 줄이고 수평 확장을 가능하게 하는 기술입니다.

📦 한 문장으로 요약하면?
"데이터를 나눠서 여러 서버에 저장하고, 이를 하나의 DB처럼 사용하는 것!"

🎯 2. 샤딩이 필요한 이유

✔️ 데이터가 많아 저장 공간이 부족할 때
✔️ 읽기/쓰기 요청이 많아 처리 지연이 생길 때
✔️ 특정 쿼리에 서버가 병목현상을 겪을 때

이럴 때 MongoDB 샤딩은 필수입니다!

🏗️ 3. MongoDB 샤딩 구성 요소

🔹 Shard: 실제 데이터를 저장하는 서버
🔹 mongos: 쿼리 라우터, 클라이언트 요청 분배
🔹 Config Server: 샤딩 메타데이터 저장소

[Client]
   |
 [mongos]
   |
[Shard1] [Shard2] ...
   |
[Config Servers]

🔑 4. 샤딩 키(Sharding Key)의 중요성

샤딩 키는 데이터를 어떻게 분산할지를 결정하는 가장 핵심적인 설계 포인트입니다.

📌 샤딩 키 예시 및 전략

⚠️ 잘못된 샤딩 키는 "핫스팟" 문제를 일으킬 수 있어요!

💪 5. 샤딩의 장점과 단점

📈 장점

• 수평 확장성 (서버 추가만으로 확장 가능)
• 고가용성 (Replica Set으로 장애 대비)
• 부하 분산 (병목 없이 빠른 처리)

⚠️ 단점

• 운영 복잡도 증가 (샤드 구성 및 관리)
• 샤딩 키 변경 어려움 (MongoDB 5.0 이상부터 지원)
• 분산 트랜잭션은 성능 이슈 발생 가능

🔧 6. 실전 팁

🔸 초기 설계 단계부터 샤딩을 고려하세요
🔸 트래픽 패턴에 맞는 샤딩 키를 선택하세요
🔸 MongoDB 5.0 이상에서는 resharding 기능으로 키 변경이 가능하니 참고하세요!

✅ 마무리 (Conclusion)

🔍 MongoDB 샤딩은 더 이상 선택이 아닌 필수 전략입니다.
데이터가 커질수록 성능 저하와 병목 문제는 반드시 발생합니다.
샤딩 구조를 미리 설계하면, 대규모 서비스에서도 안정적으로 MongoDB를 운용할 수 있어요!

MongoDB는 고가용성과 확장성을 자랑하는 NoSQL 데이터베이스입니다. 하지만 분산 시스템인 만큼, "언제 어디서 데이터를 읽느냐" 에 따라 결과가 달라질 수 있습니다.

바로 이때 중요한 설정이 readConcern과 readPreference입니다.

이 포스트에서는 MongoDB의 읽기 일관성(readConcern)과 읽기 우선순위(readPreference)를 정리하고, 조합 시의 특징까지 알아봅니다. 실무에서 어떻게 적용하면 좋을지도 함께 살펴보세요.

✅ readConcern이란?

readConcern은 읽은 데이터의 일관성 수준을 지정합니다.
다르게 말하면, "이 데이터가 얼마나 확실하게 저장된 건지"를 결정하죠.

💡 실무 팁: 일반적인 애플리케이션에서는 majority가 안정성과 성능의 균형이 좋습니다.

✅ readPreference란?

readPreference는 클라이언트가 어떤 노드에서 데이터를 읽을지를 지정합니다.
분산 환경에서의 부하 분산, 지연 시간 최적화 등에 중요합니다.

💡 실무 팁: 읽기 지연(latency)이 중요한 경우에는 nearest가, 데이터 일관성이 중요한 경우에는 primary 또는 majority 조합이 적합합니다.

🔀 조합 시 특징

📌 정리

• readConcern은 읽을 때 데이터가 얼마나 안전하게 커밋되었는가를 의미
• readPreference는 어느 노드에서 데이터를 읽을지를 설정
• 실무에서는 majority + primary 조합이 가장 안전한 기본값
• 트랜잭션이 필요한 경우 snapshot 사용
• 데이터 지연을 감수해도 성능이 중요할 땐 secondary 또는 nearest 고려

📚 마무리

MongoDB는 읽기 설정만으로도 다양한 일관성과 가용성 전략을 선택할 수 있는 유연한 데이터베이스입니다.
readConcern과 readPreference는 단순한 설정값이 아니라, 비즈니스의 요구사항에 따라 데이터의 안전성과 성능을 맞출 수 있는 중요한 도구입니다.