기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Amazon DocumentDB의 가비지 수집
Amazon DocumentDB는 모든 업데이트 작업에 대한 문서 및 인덱스 항목의 새 버전을 생성하는 다중 버전 동시성 제어(MVCC) 데이터베이스 아키텍처를 구현합니다. 이 아키텍처는 읽기 쿼리가 잠금 없이 버전이 지정된 문서를 사용할 수 있도록 하여 읽기 격리를 제공합니다.
Amazon DocumentDB의 가비지 수집 이해
가비지 수집(GC)은 Amazon DocumentDB에서 최적의 시스템 성능과 가용성을 유지하는 자동화된 백그라운드 프로세스입니다. 데이터를 덮어쓰는 기존 데이터베이스와 달리 Amazon DocumentDB의 MVCC 아키텍처는 각 업데이트 작업마다 문서 및 인덱스 항목의 새 버전을 생성합니다. 새 문서 버전을 생성하는 모든 쓰기 작업은 유한 카운터에서 고유한 MVCC ID를 사용하므로 효율적인 정리가 필수적입니다. 시간이 지남에 따라 이러한 이전 버전이 누적되므로 성능 저하를 방지하기 위해 정리해야 합니다.
가비지 수집의 함수
가비지 수집기는 세 가지 필수 함수를 제공합니다.
스토리지 공간 회수 - 활성 쿼리에 더 이상 필요하지 않은 더 이상 사용되지 않는 문서 및 인덱스 버전을 제거하여 향후 쓰기 작업을 위한 공간을 확보합니다.
MVCC ID 오버플로 방지 - MVCC ID의 유한 카운터를 관리하여 MVCC IDs 오버플로를 방지합니다. 이 관리가 없으면 카운터가 결국 한도에 도달하여 IDs합니다.
쿼리 성능 유지 - 쿼리 처리가 누적되고 느려지는 데드 문서 버전을 제거하여 최적의 쿼리 성능을 유지합니다.
가비지 수집 프로세스
GC 프로세스는 컬렉션별로 작동하며 여러 컬렉션에서 여러 프로세스를 동시에 실행할 수 있습니다. 이 프로세스는 4개의 순차적 단계로 구성됩니다.
식별 - 시스템은 활성 트랜잭션 또는 쿼리에서 더 이상 참조하지 않는 문서 및 인덱스 버전을 식별합니다.
메모리 로드 - 이전 문서와 인덱스 항목이 아직 없는 경우 메모리에 로드됩니다.
삭제 - 더 이상 사용되지 않는 버전이 영구적으로 삭제되어 스토리지 공간을 회수합니다.
MVCC ID 재활용 - 시스템은 새 작업을 위해 삭제된 버전에서 MVCC IDs 재활용합니다.
가비지 수집이 이전 문서 버전 처리를 완료하면 시스템에서 가장 오래된 MVCC IDs 제거됩니다. 이 정리는 MVCC ID를 재활용하여 MVCC IDs 오버플로를 방지하여 클러스터 전체에서 새 쓰기 작업에 사용할 수 있도록 하는 데 매우 중요합니다. 이 재활용 프로세스가 없으면 시스템은 결국 유한 MVCC ID 카운터를 소진하고 읽기 전용 상태가 됩니다.
가비지 수집 일정
가비지 수집은 주기적으로 백그라운드에서 자동으로 실행됩니다. 타이밍 및 빈도는 시스템 로드, 사용 가능한 리소스, 쓰기 볼륨 및 MVCC ID 소비 수준에 따라 동적으로 조정됩니다. 쓰기 작업이 많은 동안에는 GC 프로세스가 더 자주 실행되어 문서 버전의 수가 증가합니다.
가비지 수집 모니터링
클러스터 수준 지표
AvailableMVCCIds
위치 - Amazon CloudWatch
설명 - 0에 도달하기 전에 사용 가능한 나머지 쓰기 작업 수를 보여주는 카운터입니다. 이 카운터가 0에 도달하면 IDs가 회수되고 재활용될 때까지 클러스터가 읽기 전용 모드로 전환됩니다. 카운터는 각 쓰기 작업에 따라 감소하고 가비지 수집이 이전 MVCC IDs를 재활용함에 따라 증가합니다.
권장 사항 - 값이 13억 미만으로 떨어지면 경보를 설정합니다. 이 조기 경고를 통해 나중에 설명하는 권장 단계를 수행할 수 있습니다.
LongestRunningGCProcess
위치 - Amazon CloudWatch
설명 - 가장 긴 활성 가비지 수집 프로세스의 초 단위 기간입니다. 1분마다 업데이트하고 1분 내에 완료되는 프로세스를 제외하고 활성 작업만 추적합니다.
권장 사항 -
컬렉션 수준 지표
MVCCIDStats: MvccIdAgeScale
위치 - Database collStats 명령
설명 - 0~1의 척도로 MVCC ID 수명을 측정합니다. 여기서 1은 클러스터가 읽기 전용 상태가 되기 전의 최대 수명을 나타냅니다. 이 지표
AvailableMVCCIds를와 함께 사용하여 클러스터가 노후화된 가장 오래된 MVCC IDs가 포함된 컬렉션을 식별합니다.권장 사항 - 각 컬렉션에 대해 0.3 미만의 값을 유지합니다.
GCRuntimeStats
위치 - Database collStats 명령
설명 - 총 실행 횟수, 평균 기간, 최대 기간을 포함한 가비지 수집 지표의 2개월 기록을 제공합니다. 의미 있는 통계를 보장하기 위해 5분 이상 지속되는 가비지 수집 작업만 포함합니다.
UnusedStorageSize (수집 수준)
위치 - Database collStats 명령
설명 - 샘플링된 통계를 기반으로 컬렉션의 미사용 스토리지 공간을 추정합니다. 여기에는 삭제된 문서와 빈 세그먼트의 공간이 포함됩니다.
인덱스 수준 지표
UnusedStorageSize (인덱스 수준)
위치 - Database indexStats 명령
설명 - 샘플링된 통계를 기반으로 인덱스의 미사용 스토리지 공간을 추정합니다. 여기에는 더 이상 사용되지 않는 인덱스 항목과 빈 세그먼트의 공간이 포함됩니다.
권장 사항 -
reIndex명령을 사용하여 가동 중지 없이 인덱스를 다시 빌드하고 미사용 공간을 회수합니다. 자세한 내용은 인덱스 관리를 참조하세요.
예제 collStats 출력
{
"ns": "xid_consumption_test_db.xid_test_collection",
"MVCCIdStats": {
"MVCCIdScale": 0.03
},
"gcRuntimeStats": {
"numRuns": 1,
"historicalAvgRuntime": 3295,
"historicalMaxRuntime": 3295,
"lastRuntime": 3295,
"lastRuntimeStart": ISODate("2025-06-24T08:47:14Z")
},
"collScans": 14,
"count": 30000000,
"size": 1320000000,
"avgObjSize": 44,
"storageSize": 6461497344,
"capped": false,
"nindexes": 2,
"totalIndexSize": 9649553408,
"indexSizes": {
"_id_": 1910661120,
"c_1": 7738892288
},
"unusedStorageSize": {
"unusedBytes": 4201881600,
"unusedPercent": 65.05
},
"cacheStats": {
"collBlksHit": 171659016,
"collBlksRead": 754061,
"collHitRatio": 99.5627,
"idxBlksHit": 692563636,
"idxBlksRead": 1177921,
"idxHitRatio": 99.8303
},
"idxScans": 41823984,
"opCounter": {
"numDocsIns": 0,
"numDocsUpd": 20911992,
"numDocsDel": 0
},
"lastReset": "2025-06-24 05:57:08.219711+00",
"ok": 1,
"operationTime": Timestamp(1750968826, 1)
}자주 묻는 질문(FAQ)
주제
가비지 수집이 효율적으로 작동하지 않는지 확인하려면 어떻게 해야 합니까?
비효율적인 가비지 수집을 나타내는 다음 경고 신호를 모니터링합니다.
과도한 수집 팽창 - 특히 큰 인덱스의 경우 쓰기가 많거나 대량 삭제 시
UnusedStorageSize지표를 지속적으로 증가시킵니다.성능 저하된 쿼리 지연 시간 - 누적된 배달 못한 문서로 인한 쿼리 지연 시간 증가
GC 기간 연장 -의 과거 평균보다 오래 걸리는 가비지 수집 작업
GCRuntimeStatsGC 처리 향상 - 가비지 수집기가 시스템 요구 사항을 따라잡을 수 없음을
LongestRunningGCProcess나타내는 높음
가비지 수집이 데이터베이스 성능에 영향을 미치나요?
정상적인 조건에서는 가비지 수집이 성능에 미치는 영향을 최소화합니다. 그러나 가비지 수집이 뒤처지면 다음과 같은 상황이 발생할 수 있습니다.
누적된 배달 못한 문서로 인한 스토리지 비용 증가.
더 이상 사용되지 않는 인덱스 항목으로 인해 쿼리 성능이 느려집니다.
MVCC IDs가 고갈된 경우 임시 읽기 전용 모드입니다.
특히 더 작은 인스턴스에서 집약적인 수집 실행 중에 리소스 사용량이 증가합니다.
가비지 수집을 수동으로 트리거할 수 있나요?
아니요. Amazon DocumentDB의 가비지 수집은 수동으로 트리거할 수 없습니다. 시스템은 내부 유지 관리 작업의 일부로 가비지 수집을 자동으로 관리합니다.
운영 모범 사례로 설정해야 하는 경보는 무엇입니까?
Amazon DocumentDB 시스템의 최적의 성능을 보장하려면 클러스터 및 컬렉션 수준 모두에서 모니터링을 설정하는 것이 좋습니다.
클러스터 수준 모니터링의 경우
먼저 임계값이 AvailableMVCCId 13억인 지표에 대한 CloudWatch 경보를 생성합니다. 이렇게 하면 지표가 0에 도달하기 전에 조치를 취할 수 있는 충분한 시간을 확보할 수 있습니다. 그러면 클러스터가 읽기 전용 모드로 전환됩니다. 이 지표는 특정 사용 패턴에 따라 변동될 수 있습니다. 일부 고객은 가비지 수집이 작업을 완료하면 13억 미만으로 감소한 다음 15억 이상으로 복구됩니다.
CloudWatch를 통해 LongestRunningGCProcess 지표를 모니터링하는 것도 중요합니다. 이 지표는와 함께 시스템 전체에서 가비지 수집이 얼마나 효율적으로 수행되고 있는지 이해하는 데 GCRuntimeStats도움이 됩니다.
컬렉션 수준 모니터링의 경우
두 가지 주요 지표에 집중합니다. 먼저 각 컬렉션의 MvccIdAgeScale 값을 확인하는 것이 좋습니다. 값을 늘리면 MVCC IDs 노후화되어 주의가 필요할 수 있습니다. 둘째,를 모니터링GCRuntimeStats하여 비정상적으로 오래 걸리거나 며칠에 걸쳐 연장되는 가비지 수집 프로세스를 식별합니다. 쓰기 작업이 빈번한 컬렉션은 가비지 수집기에 더 많은 작업을 생성하므로 각별한 주의가 필요합니다. 가비지 수집이 워크로드를 따라잡을 수 있도록 쓰기 활동이 많은 컬렉션에 대해 이러한 지표를 더 자주 확인하는 것이 좋습니다.
이러한 모니터링 권장 사항은 시작점 역할을 합니다. 시스템 동작에 더 익숙해지면 특정 사용 패턴 및 요구 사항에 더 잘 맞게 이러한 임계값을 조정하는 것이 좋습니다.
13억 이하로 AvailableMVCCId 떨어지면 어떻게 해야 하나요?
지표가 AvailableMVCCId 13억 미만으로 떨어지면 클러스터가 읽기 전용 모드로 전환되지 않도록 즉각적인 조치를 취하는 것이 좋습니다. 먼저 인스턴스 크기를 확장하여 가비지 수집기에 더 많은 컴퓨팅 리소스를 제공하는 것이 좋습니다. 이렇게 하면 애플리케이션이 가비지 수집기에 따라 잡는 데 필요한 추가 전력을 제공하면서 정상적인 작업을 계속할 수 있습니다.
확장만으로도 상황이 개선되지 않는 경우 쓰기 작업의 감소를 고려하는 것이 좋습니다. MvccIdAgeScale 지표를 사용하여 주의가 필요한 이전 MVCC IDs가 포함된 특정 컬렉션을 식별합니다. 이러한 컬렉션을 식별한 후에는 가비지 수집이 따라잡을 수 있도록 컬렉션에 대한 쓰기 작업을 일시적으로 줄여야 할 수 있습니다. 복구 기간 동안 AvailableMVCCId 지표를 면밀히 모니터링하여 작업에 원하는 효과가 있는지 확인하는 것이 좋습니다. AvailableMVCCId 값이 15억 이상으로 반환되면 클러스터가 정상으로 간주됩니다.
이러한 단계는 시스템이 중요한 상태에 도달하기 전에 복구하는 데 도움이 되는 예방 조치입니다. 지표가 13억 미만으로 감소한 것을 확인한 후 더 빨리 조치를 취할수록 쓰기 작업에 미치는 영향을 피할 가능성이 높아집니다.
