MongoDB 배포 환경에서의 디스크 공간 관리 및 확보

MongoDB 배포에서 디스크 공간 관리 및 확보

디스크 공간 관리는 건전하고 고성능의 MongoDB 배포를 유지하는 데 있어 중요한 측면입니다. 기존 관계형 데이터베이스와 달리 MongoDB의 스토리지 엔진은 공간 할당을 동적으로 처리하므로, 삭제 후 물리적 디스크 공간이 즉시 회수되지 않는 경우가 많습니다. 관리하지 않으면 불필요한 스토리지 소비는 예기치 않은 중단, 쓰기 성능 저하, 특히 클라우드 환경에서 상당한 재정적 오버헤드로 이어질 수 있습니다.

이 가이드는 스토리지 사용량을 모니터링하고, 공간을 많이 차지하는 요소("공간 돼지" 또는 "space hogs")를 식별하며, 압축, 인덱싱 최적화, 강력한 보존 정책과 같은 효과적인 방법을 구현하여 디스크 공간을 선제적으로 확보하고 관리하기 위한 전문가 전략과 실용적인 명령을 제공합니다. MongoDB가 스토리지를 활용하는 방식을 이해함으로써 관리자는 장기적인 안정성과 효율성을 보장할 수 있습니다.

디스크 공간 사용량 모니터링

효과적인 관리의 첫 단계는 지속적인 모니터링입니다. 논리적 데이터 크기와 물리적 스토리지 크기를 구별할 필요가 있습니다.

시스템 수준 모니터링

MongoDB 데이터(dbPath) 및 저널 파일이 있는 파일 시스템을 항상 모니터링해야 합니다. 전체 디스크 사용량이 임계치(예: 80-90%)에 도달하면 경고를 보내기 위해 표준 운영 체제 도구가 필요합니다.

df -h /path/to/mongodb/data

MongoDB 특정 지표

MongoDB 내부의 스토리지 사용량을 이해하려면 mongosh 셸을 통해 db.stats() 및 db.collection.stats() 명령을 사용하십시오.

데이터베이스 통계 (`db.stats()`)

이 명령은 전체 데이터베이스의 개요를 제공합니다.

use myDatabase
db.stats()

관찰할 주요 필드:

dataSize: 모든 컬렉션에 걸친 원시 문서 데이터의 총 크기(논리적 크기).
storageSize: 데이터 및 패딩에 의해 소비되는 총 디스크 공간(물리적 크기).
indexSize: 디스크에 있는 모든 인덱스의 총 크기.

컬렉션 통계 (`db.collection.stats()`)

이것은 공간을 많이 차지하는 요소("space hogs")를 식별하는 데 가장 세분화되고 유용한 도구입니다.

db.myCollection.stats(1024 * 1024) // 메가바이트 단위로 크기 반환

관찰할 주요 필드:

size: 컬렉션 내 문서의 논리적 크기.
storageSize: 디스크에 컬렉션에 할당된 물리적 공간. size와 storageSize 간의 큰 차이는 종종 심각한 조각화 또는 높은 문서 변경률을 나타냅니다.
totalIndexSize: 이 컬렉션의 인덱스만으로 소비되는 물리적 디스크 공간.

팁: storageSize가 size보다 훨씬 크다면, 이는 비효율적인 스토리지 할당(조각화 또는 과도한 패딩)을 나타냅니다. totalIndexSize가 size에 비해 불균형적으로 크다면, 해당 컬렉션의 인덱싱 전략을 검토하십시오.

공간을 많이 차지하는 요소 식별

MongoDB의 공간 소비는 일반적으로 세 가지 요인에 의해 좌우됩니다.

1. 삭제로 인한 조각화

문서가 삭제되면 MongoDB(특히 WiredTiger)는 해당 공간을 사용 가능으로 표시하지만, 즉시 운영 체제로 반환하지 않습니다. 이 빈 공간은 향후 재사용을 위해 스토리지 엔진이 할당한 파일 내에 유지됩니다. 변경률이 높은 컬렉션(잦은 쓰기 및 삭제)은 조각화에 매우 취약하며, storageSize 지표를 부풀립니다.

2. 인덱스 오버헤드

인덱스는 데이터 문서와 별도로 저장됩니다. 복잡하거나 많은 인덱스는 컬렉션의 스토리지 요구 사항을 쉽게 두세 배로 늘릴 수 있습니다. 사용하지 않는 인덱스를 식별하고 제거하는 것이 종종 공간을 확보하는 가장 빠른 방법입니다.

3. 컬렉션 구조 및 패딩

MongoDB는 업데이트 시 문서 증가를 수용하기 위해 데이터 파일 내에 추가 공간(패딩)을 할당합니다. 이는 성능에 유익하지만(문서 재배치 필요성 감소), 업데이트가 드물거나 문서 생성 후 변경할 수 없는 경우 과도한 패딩은 스토리지를 비효율적으로 사용할 수 있습니다.

디스크 공간 확보 전략

1. 압축 및 데이터 재배치

WiredTiger 스토리지 엔진을 사용하는 최신 MongoDB 배포의 경우, 조각난 공간을 확보하는 두 가지 주요 방법이 있습니다.

A. `compact` 사용 (주의 필요)

compact 명령은 컬렉션 내 데이터를 재구성하여 조각난 공간을 확보하고 인덱스를 재구축합니다. 그러나 이 작업은 일반적으로 해당 컬렉션에 대한 모든 읽기/쓰기를 차단하며 리소스 집약적입니다.

db.runCommand({ compact: 'myCollection' })

경고: 압축은 절대적으로 필요한 경우가 아니라면 프로덕션 환경에서 일반적으로 피해야 하며, 가급적이면 제어된 유지보수 기간 동안 복제본 세트의 보조 멤버에서 수행해야 합니다.

B. `mongodump` / `mongorestore` 방식 (권장)

심각하게 조각난 컬렉션의 경우, 디스크 공간을 복구하는 가장 신뢰할 수 있는 방법은 데이터를 덤프하고 복원하는 것입니다. 이 프로세스는 데이터를 순차적으로 다시 작성하여 내부 조각화를 제거합니다.

데이터 덤프:
bash mongodump --db myDatabase --collection myCollection --out /path/to/dump
컬렉션 삭제: (이 단계 전에 완전한 백업이 있는지 확인하십시오)
javascript db.myCollection.drop()
데이터 복원: (복원 프로세스는 스토리지를 효율적으로 할당합니다)
bash mongorestore --db myDatabase --collection myCollection /path/to/dump/myDatabase/myCollection.bson

2. 인덱스 최적화

비효율적인 인덱스를 재구축하거나 삭제하면 상당한 공간을 절약할 수 있습니다.

사용하지 않는 인덱스 삭제

프로파일러 또는 db.collection.getIndexes()를 사용하여 쿼리 패턴을 분석하여 전혀 사용되지 않거나 거의 사용되지 않는 인덱스를 식별하십시오.

db.myCollection.dropIndex('index_name_to_drop')

인덱스 재구축

인덱스 자체도 조각화될 수 있습니다. 보조 멤버에서 인덱스를 재구축하면 물리적 공간을 줄일 수 있습니다.

db.myCollection.reIndex()

모범 사례: 기본 멤버에서 작업을 수행하기 전에 항상 보조 멤버에서 인덱스를 재구축하거나 삭제하고, 복제가 완료될 때까지 기다리십시오. 이는 다운타임을 최소화합니다.

3. 데이터 보존 및 아카이빙 정책

무한한 성장을 방지하는 것이 디스크 공간 문제에 대한 최선의 방어책입니다.

TTL (Time-To-Live) 인덱스 사용

로그, 세션 또는 시계열 데이터의 경우, TTL 인덱스는 정의된 기간 후 문서를 자동으로 만료시켜 수동 개입 없이 데이터 보존 정책이 적용되도록 합니다.

db.logEvents.createIndex(
   { "createdAt": 1 }, 
   { expireAfterSeconds: 86400 } // 문서는 24시간 후에 만료됩니다
)

아카이빙 구현

mongoexport 또는 사용자 지정 아카이빙 스크립트와 같은 도구를 사용하여 오래되고 자주 액세스되지 않는 데이터를 더 느린 스토리지 계층(예: S3 또는 Glacier)으로 이동한 후, 기본 배포에서 원본 문서를 삭제하십시오.

고급 스토리지 엔진 고려 사항 (WiredTiger)

최신 MongoDB 배포는 기본적으로 WiredTiger 스토리지 엔진을 사용하며, 이는 이전 MMAPv1 엔진에 비해 우수한 압축 및 동시성을 제공합니다.

압축 설정

WiredTiger는 기본적으로 압축을 활성화합니다(일반적으로 Snappy). 디스크 공간이 심각하게 제한된 경우, 알고리즘을 변경하여(예: zlib으로) CPU 사용량을 희생하면서 압축률을 높일 수 있습니다.

이 구성은 시작 시 또는 특정 컬렉션에 대해 동적으로 설정됩니다.

db.runCommand({
   collMod: "myCollection",
   storageEngine: {
      wiredTiger: {
         configString: "compression_engine=zlib"
      }
   }
})

사전 할당 및 공간 재사용

WiredTiger는 일반적으로 2GB 청크로 사전 할당된 데이터 파일을 사용합니다. 이는 처음에는 낭비되는 공간처럼 보일 수 있지만, 파일 시스템 조각화를 줄여 성능을 향상시킵니다. 핵심은 이 공간이 내부적으로 관리되며, 문서가 삭제되더라도 새 청크가 할당되기 전에 데이터베이스에 의해 재사용될 것이라는 점을 이해하는 것입니다.

경고: MongoDB 데이터 파일을 수동으로 축소하거나 저널 파일을 파일 시스템에서 직접 제거하려고 시도하지 마십시오. 이는 데이터 손상을 보장합니다. 제어된 공간 확보를 위해서는 mongodump 및 mongorestore와 같은 MongoDB 내장 도구를 사용하십시오.

결론

MongoDB의 선제적 디스크 공간 관리는 지속적인 모니터링과 현명한 데이터 보존 관행에 달려 있습니다. 논리적 데이터 크기와 물리적 스토리지 크기 간의 차이를 정기적으로 검사하고, 불필요한 인덱스를 최적화하며, TTL 인덱스를 통한 자동 정리를 활용함으로써 관리자는 운영 비용을 크게 절감하고 과도한 스토리지 조각화로 인한 성능 병목 현상을 방지할 수 있습니다. 심각한 조각화의 경우, mongodump/mongorestore 주기는 공간 확보를 위한 가장 효과적이고 안전하며 강력한 솔루션으로 남아 있습니다.