경험은 언제나 옳다

MongoDB의 TTL(Time-To-Live) Index는 일정 시간이 expired Document를 자동으로 삭제하는 기능이며
로그, 세션, 캐시 데이터 등등 기간이 있는 데이터에 사용됩니다.

OS환경 : Centos Linux 7.9 (64bit)
DB 환경 : MongoDB 6.0.19

🤔 TTL Index란?

TTL 인덱스는 문서에 있는 Date 타입 필드를 기준으로 일정 시간이 지나면

MongoDB가 백그라운드 작업으로 해당 Document를 삭제합니다.

삭제는 실시간이 아니라 약 60초 간격의 백그라운드 스케줄러가 수행됨

✅ TTL INDEX 만드는 방법

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

• createdAt: Date 필드
• expireAfterSeconds: 생성된 시간 기준으로 3600초(=1시간) 후 삭제
  
  
  

TTL 인덱스의 특징과 주의사항

• TTL 인덱스는 단일 필드만 허용되며, 복합 인덱스로는 설정 불가
• 기준 필드는 Date 타입이어야 하며, 문자열 또는 숫자는 동작 불가 

※ update()를 통해 Date 필드를 갱신하면 TTL 타이머가 초기화됩니다.

🧪 TTL INDEX 테스트 시나리오

1. 테스트 환경 초기화

TTL 인덱스를 실험하기 위해 사용할 ttl_test 데이터베이스와 sessions 컬렉션을 정리합니다.
MongoDB는 Document를 insert하면 Collection이 자동으로 생성되기 때문에, 따로 createCollection() 명령은 생략해도 됩니다.

use ttl_test
db.sessions.drop() // 이전 테스트가 남아있을 수 있으므로 기존 컬렉션을 삭제

※ 참고 db.sessions.drop()은 기존 컬렉션 및 인덱스를 삭제하는 명령입니다. 테스트 전 초기화 하기 위한 작업

2. TTL 인덱스 생성

createdAt필드를 기준으로, Document가 삽입된 후 30초가 지나면 자동으로 삭제되도록 설정합니다.

db.sessions.createIndex(
  { "createdAt": 1 },
  { expireAfterSeconds: 30 }
)

3. 테스트 데이터 Insert

현재 시간 기준으로 createdAt 필드를 포함하여 session collection에 Document를 Insert 합니다.

db.sessions.insertOne({
  userId: "korea123",
  createdAt: new Date()
})

4. Document 확인 및 삭제 확인

Document 가 잘 Insert되었는지 확인한 후, 30~90초 정도 기다렸다가 데이터 삭제 여부를 다시 확인합니다.

// 삽입 직후 확인
db.sessions.find()
TestReplSet [direct: primary] ttl_test> db.sessions.find()
[
  {
    _id: ObjectId('682a93668711c6afa4625e60'),
    userId: 'korea123',
    createdAt: ISODate('2025-05-19T02:11:50.933Z')
  }
]


// 약 1분 후 재확인 (자동 삭제됨)
db.sessions.find()

※참고: MongoDB는 TTL 삭제를 실시간으로 수행하지 않습니다.
내부 TTL Monitor가 약 60초 간격으로 동작하기 때문에, 삭제 시점은 약간의 지연이 있을 수 있습니다.

TTL 인덱스는 세션, 로그, 인증 데이터처럼 시간이 지나면 자연스럽게 삭제되어야 하는 데이터에 매우 유용하면서 중요한 기능입니다. 불필요한 공간 낭비를 최소화 하기 위해 필요하며, 애플리케이션에서 별도의 삭제 로직을 구현하지 않아도 되므로 개발 효율성과 시스템 자원 관리를 동시에 잡을 수 있습니다.

🙌 댓글, 공감, 공유는 큰 힘이 됩니다! 😄

참조 : https://www.mongodb.com/ko-kr/docs/manual/core/index-ttl/

https://www.mongodb.com/ko-kr/docs/manual/tutorial/expire-data/

📝 RDBMS DBA 관점에서  바라보는 MongoDB 커리큘럼

[1] MongoDB 소개와 기본 개념 이해

• RDBMS vs NoSQL
  • 관계형 vs 비관계형 개념 비교
  • 스키마 유연성 개념
• MongoDB 기본 구조
  • Database (RDBMS) → Database (MongoDB)
  • Table → Collection
  • Row → Document
  • Column → Field
  • Primary Key → _id 필드
  • JOIN 연산 → Embedded Document, Reference
• JSON과 BSON 데이터 형식 이해
  • BSON(Binary JSON)의 개념과 사용법 이해

[2] MongoDB 설치 및 기본 환경 구축

• MongoDB 설치
  • 설치 및 구성 (단일 노드, 레플리카 세트 구성)
  • 환경 변수 설정 및 서비스 등록
• CLI 툴 사용
  • mongosh, mongoimport, mongodump, mongorestore

[3] CRUD 및 쿼리 활용

• 기본 CRUD
  • SELECT → find(), findOne()
  • INSERT → insertOne(), insertMany()
  • UPDATE → updateOne(), updateMany(), replaceOne()
  • DELETE → deleteOne(), deleteMany()
• 쿼리 필터링과 프로젝션
  • 조건 연산자($eq, $ne, $gt, $lt, $gte, $lte, $in, $nin)
  • 정규 표현식 검색, 문자열 검색
  • 정렬, 페이징 처리(sort, skip, limit)
• 집계 연산(Aggregation Framework)
  • GROUP BY → $group
  • HAVING → $match (after group)
  • SUM, COUNT, AVG 연산

[4] MongoDB 데이터 모델링과 설계

• 정규화 vs 비정규화 전략
  • Embedding (내장) vs Referencing (참조)
  • 성능과 유지보수성 고려 설계
• 모델링 사례 연구 (Oracle → MongoDB 변환)
  • Oracle 스키마의 MongoDB로의 전환 연습

[5] 성능 튜닝과 인덱스 관리

• MongoDB 인덱스 이해
  • 단일 필드 인덱스, 복합 인덱스
  • TTL 인덱스, 부분 인덱스
  • Explain Plan (쿼리 실행 계획 확인)
• 성능 이슈와 튜닝
  • 느린 쿼리 분석 및 최적화
  • 인덱스 커버리지, 힌트 기능 활용
  • MongoDB Profiler 및 로깅 분석

[6] MongoDB 아키텍처 심화

• WiredTiger 스토리지 엔진 이해
  • 데이터 파일 구조, 캐싱 메커니즘
  • Checkpoint, Journal
• 레플리카 셋 구성 및 관리
  • Primary, Secondary, Arbiter 개념
  • Failover와 High Availability 설정
  • Read Preference 설정
• 샤딩 클러스터 이해
  • 샤드 구성 요소 (mongos, config server, shard node)
  • 데이터 분산 전략, Shard Key 설계

[7] 백업과 복구 전략

• 백업 방법
  • mongodump/mongorestore (논리적 백업)
  • 파일 시스템 기반 백업(Snapshot 기반, 물리적 백업)
• 복구 시나리오
  • Oplog를 이용한 Point-in-Time Recovery (PITR)
  • 레플리카 세트 복구 및 노드 교체

[8] MongoDB 보안 관리

• 사용자 관리와 권한 설정
  • Role-Based Access Control(RBAC) 이해
• 암호화 및 감사 로깅
  • 데이터 암호화(at rest, in transit)
  • 감사 로그 설정 및 분석 방법

[9] MongoDB 모니터링 및 운영 관리

• 모니터링 툴 활용
  • MongoDB Compass, MongoDB Ops Manager, Percona Monitoring and Management (PMM)
  • Prometheus 및 Grafana를 통한 커스터마이징
• 운영 트러블슈팅
  • Disk 사용량, 메모리 관리, CPU 병목 분석
  • slow operation 분석 및 개선 방법

[10] 클라우드 환경의 MongoDB

• MongoDB Atlas (DBaaS)
  • Atlas에서의 관리, 모니터링, 백업
• 클라우드 환경에서의 운영
  • AWS, Azure, GCP에서의 배포 및 운영 전략
  • 클라우드 마이그레이션 전략(Oracle에서 MongoDB Atlas로 마이그레이션)

📚추천 교재 및 공식 문서

• MongoDB 공식 문서
• MongoDB University
  • 무료 온라인 강의 제공 (기초~고급)
• 몽고디비 완벽 가이드 MongoDB (개정3판) 한빛미디어

🙌 댓글, 공감, 공유는 큰 힘이 됩니다! 😄

⚡ MongoDB 성능 튜닝 실전편: 인덱스 전략과 Aggregation Pipeline 최적화

MongoDB가 느려지는 원인의 90%는 잘못된 인덱스 구성과 비효율적인 Aggregation Pipeline 때문입니다.
이번 포스트에서는 쿼리 성능을 극적으로 올릴 수 있는 핵심 튜닝 전략을 실전 중심으로 소개합니다.

1️⃣ 인덱스(Index) 전략

✅ 기본 원칙

• 항상 조회 조건(where)에 사용되는 필드는 인덱싱
• 정렬(sort)에 자주 쓰이는 필드도 인덱스 고려
• 복합 인덱스는 조건 사용 빈도 + 필드 순서가 중요

📌 단일 vs 복합 인덱스

// 단일 인덱스
db.users.createIndex({ age: 1 })

// 복합 인덱스 (조건 + 정렬)
db.users.createIndex({ age: 1, createdAt: -1 })

🧠 인덱스가 작동하지 않는 경우

• 조건과 인덱스 순서가 다를 때
• 복잡한 $or / $regex 조합
• Aggregation에서 $project를 먼저 쓰는 경우

🔍 실행 계획 확인

db.users.find({ age: 30 }).explain("executionStats")

• COLLSCAN: 전체 Collection 스캔 → 성능 저하
• IXSCAN: 인덱스 사용 → OK

2️⃣ 인덱스 튜닝 실전 예제

🧪 문제 상황

db.orders.find({
  status: "shipped",
  createdAt: { $gte: ISODate("2023-01-01") }
}).sort({ createdAt: -1 })

이 쿼리가 느리다면?

✅ 해결 전략

• 복합 인덱스 생성

db.orders.createIndex({ status: 1, createdAt: -1 })

📌 WHERE → SORT 순서대로 인덱스 필드 배치하는 게 핵심입니다.

3️⃣ Aggregation Pipeline 최적화

Aggregation은 강력하지만, 성능 병목도 자주 발생하는 영역입니다.

⚠️ 자주 발생하는 비효율 구조

db.sales.aggregate([
  { $project: { total: { $multiply: ["$price", "$qty"] } } },
  { $match: { total: { $gt: 100 } } }
])

$project → $match 순서는 인덱스를 사용할 수 없습니다.

✅ 올바른 순서

db.sales.aggregate([
  { $match: { price: { $gt: 10 } } },
  { $project: { total: { $multiply: ["$price", "$qty"] } } }
])

• 인덱스 가능한 조건은 $match로 먼저 걸어야 성능 확보 가능
• 필터 → 가공 → 정렬 → 그룹 순서로 설계

4️⃣ $group 최적화 팁

대규모 데이터 집계에서 $group은 가장 느린 연산입니다.

💡 최적화 전략

• group 전에 가능한 한 match/filter로 줄이기
• allowDiskUse: true 옵션으로 메모리 초과 방지

db.logs.aggregate([
  { $match: { level: "ERROR" } },
  { $group: { _id: "$service", count: { $sum: 1 } } }
], { allowDiskUse: true })

5️⃣ 성능 튜닝 종합 체크리스트

• ✅ 모든 쿼리는 .explain() 으로 실행계획 확인
• ✅ 인덱스는 조회 조건 + 정렬 순서 기반으로 설계
• ✅ Aggregation은 $match → $project → $sort → $group 순서 지키기
• ✅ 복합 인덱스는 자주 사용하는 쿼리 패턴 중심으로

📌 추천 도구

• MongoDB Compass → 쿼리 분석 + 인덱스 추천
• Atlas Performance Advisor → 인덱스 자동 추천
• mongostat / mongotop → 실시간 부하 확인

✅ 마무리 요약

• 인덱스 전략은 MongoDB 성능의 핵심!
• Aggregation은 설계 순서와 필터링 범위가 성능을 좌우
• 쿼리 튜닝은 분석(Explain) → 테스트 → 튜닝의 반복

도움 되셨다면 공감/구독도 부탁드립니다 😊

🔥 MongoDB 운영 중 자주 발생하는 문제와 실전 대응법

MongoDB는 유연하고 강력한 NoSQL DB지만, 실 운영 환경에서는 다양한 이슈가 발생할 수 있습니다.
이 포스팅에서는 현장에서 자주 접하는 문제 상황과 그에 대한 대응 전략을 실제 경험 기반으로 정리해드립니다.

1️⃣ Oplog Overflow (오플로그 오버플로우)

• 🔍 문제 현상: Secondary 노드 복제 실패, 에러 로그에 missing oplog records
• 🧠 원인: Secondary가 복제 지연 상태일 때 Oplog에서 오래된 로그가 삭제됨

✅ 대응 방법

• Replication 지연 확인: rs.printSlaveReplicationInfo()
• Secondary 초기화 후 재시작 (전체 동기화)

🛡️ 예방 전략

• Oplog 크기 충분히 확보 (디폴트보다 ↑)
• 복제 지연 감시 → 알람 설정

2️⃣ Replication Lag (복제 지연)

• 🔍 문제 현상: Secondary가 Primary 변경을 늦게 반영함
• 🧠 원인: 느린 네트워크, Disk I/O 병목, 쿼리 부하

✅ 대응 방법

rs.printSlaveReplicationInfo()

• 지연이 10초 이상이면 주의, 수 분이면 위험
• Secondary가 과부하 상태인지 top 또는 mongotop으로 확인

🛡️ 예방 전략

• 네트워크 품질 확인 (Private VPC 권장)
• Secondary에 백업, 분석 작업 몰리지 않도록 분리

3️⃣ Lock 경합 (Write/Read 경합)

• 🔍 문제 현상: 응답 지연, CPU 사용량 급증
• 🧠 원인: 동일 컬렉션에 대한 동시 쓰기, 대용량 업데이트

✅ 대응 방법

• db.currentOp()로 오래된 쿼리 확인
• killOp(opid)로 불필요한 작업 중단

🛡️ 예방 전략

• 배치 작업은 슬라이스로 나눠서 실행
• 업데이트 쿼리는 조건 최소화, 필드 선택적으로 업데이트

4️⃣ 커넥션 수 초과 (Too Many Connections)

• 🔍 문제 현상: "Too many connections" 에러
• 🧠 원인: 커넥션 풀 미사용, 앱 재시도 로직 과잉

✅ 대응 방법

db.serverStatus().connections

• 앱의 커넥션 풀 설정 확인 (e.g., Mongoose, Spring Data 등)
• 최대 커넥션 수 조정: maxIncomingConnections 파라미터

🛡️ 예방 전략

• 앱단에서 커넥션 풀 필수
• Atlas에서는 Auto-scaling + 경고 알림 활용

5️⃣ 쿼리 성능 저하 (Index 미사용 / Full Collection Scan)

• 🔍 문제 현상: 응답 시간 ↑, 서버 CPU 사용량 ↑
• 🧠 원인: 인덱스 누락, 복합 조건 쿼리의 비효율적 설계

✅ 대응 방법

db.collection.find({ ... }).explain("executionStats")

• COLLSCAN이면 인덱스 미사용
• 적절한 인덱스 생성: db.collection.createIndex()

🛡️ 예방 전략

• slow query log 활성화 & 주기적 리뷰
• 복합 인덱스는 자주 쓰는 순서로 구성

6️⃣ 디스크 공간 부족

• 🔍 문제 현상: MongoDB 다운, insert 불가
• 🧠 원인: oplog, log, WiredTiger cache가 디스크를 가득 채움

✅ 대응 방법

• db.stats()로 DB 사이즈 확인
• logRotate 설정으로 로그 압축

🛡️ 예방 전략

• 모니터링 도구에서 디스크 임계값 경고 설정
• 데이터 아카이빙 전략 운영 (cold data 이동)

✅ 마무리 요약

• Oplog & Replication Lag은 고가용성 핵심
• Lock 경합, 쿼리 성능 저하는 실시간 트래픽 대응력에 영향
• 모니터링 도구 & 경고 알람은 반드시 설정해야 함
• 지속적인 점검 & 튜닝 없이는 MongoDB도 결국 느려집니다

도움이 되셨다면 공감과 구독도 부탁드립니다! 😊

🛠️ MongoDB DBA가 꼭 챙겨야 할 관리 포인트 정리

MongoDB를 운영 환경에 도입했다면, 이제부터는 DBA 입장에서의 관리 전략이 중요합니다.
이 글에서는 MongoDB를 안정적으로 운영하기 위한 주요 관리 포인트를 하나씩 짚어볼게요.

1️⃣ 운영 환경 구성

✅ Replica Set

• MongoDB 고가용성을 위한 기본 구성
• 최소 3개 이상의 노드 구성: 1 Primary + 2 Secondary
• 자동 Failover 지원

rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongo1:27017" },
    { _id: 1, host: "mongo2:27017" },
    { _id: 2, host: "mongo3:27017" }
  ]
});

✅ Sharding

• 수평 확장(Scale-out)을 위한 기능
• 샤드 키(Shard Key) 선정이 매우 중요
• 불균형 파티셔닝은 성능 저하로 이어짐

📌 샤딩은 반드시 트래픽 패턴 기반으로 설계해야 합니다.

2️⃣ 모니터링 포인트

운영 환경에서는 지속적인 모니터링이 필수입니다.

🧪 주요 명령어

• mongostat: 실시간 트래픽 확인
• mongotop: 컬렉션별 읽기/쓰기 시간 확인

📊 MongoDB Atlas Monitoring

• CPU, 메모리, IOPS, 컬렉션별 쿼리 수행 시간
• Slow Query Analytics 제공

🔍 300ms 이상 걸리는 쿼리는 slow query log로 추적하세요.

3️⃣ 성능 최적화

✅ 인덱스 관리

• 쿼리에 사용되는 필드는 인덱스 필수
• 복합 인덱스는 순서 중요 ({ a: 1, b: 1 })

✅ 쿼리 분석

db.collection.find({ a: 1 }).explain("executionStats")

• COLLSCAN → 인덱스 미사용 경고
• IXSCAN → 인덱스 정상 사용

✅ Write Concern / Read Concern

• 데이터 일관성을 위해 적절히 조정 필요
• 기본: { w: "majority" }

4️⃣ 백업과 복구

🧰 mongodump & mongorestore

# 백업
mongodump --out=/data/backup

# 복구
mongorestore /data/backup

🌀 Point-in-Time 복구 (MongoDB Atlas)

• 클러스터 설정 시 PITR(지점 복구) 설정 가능
• 실수로 인한 삭제/변경 복구에 유용

5️⃣ 사용자 권한과 보안

🔐 Role-Based Access Control (RBAC)

• read, readWrite, dbAdmin 등 역할 기반 권한
• 운영 계정에는 최소 권한 부여 원칙 적용

🔒 인증 & 암호화

• 비밀번호 인증 기본
• LDAP, Kerberos 등 외부 인증 연동 가능
• 데이터 암호화: TLS/SSL + Encryption-at-Rest

6️⃣ 장애 대응 체크리스트

• Primary 전환 감지 (rs.status())
• Secondary 복제 지연 확인 (Replication Lag)
• 디스크 공간, 커넥션 수 상시 모니터링
• 애플리케이션에서 재시도 로직 포함 여부 확인

📍 MongoDB는 장애 발생 시 자동 복구 기능이 있지만, DBA의 사전 대응 설계가 핵심입니다.

✅ 마무리 요약

• Replica Set은 기본, Sharding은 상황에 따라
• 인덱스/쿼리 분석은 성능 유지의 핵심
• 권한 관리와 백업은 운영 안정성의 필수 요소
• Atlas 활용 시 시각화된 모니터링과 자동 백업이 장점

도움이 되셨다면 공감과 구독도 부탁드립니다! 😊