기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amazon DocumentDB의 폐영역 회수

Amazon DocumentDB는 모든 업데이트 작업에 대한 문서 및 인덱스 항목의 새 버전을 생성하는 다중 버전 동시성 제어(MVCC) 데이터베이스 아키텍처를 구현합니다. 이 아키텍처는 트랜잭션 격리를 활성화하여 한 트랜잭션의 변경 사항이 다른 트랜잭션에 나타나지 않도록 합니다.

Amazon DocumentDB의 가비지 수집 이해

폐영역 회수(GC)는 Amazon DocumentDB에서 최적의 시스템 성능과 가용성을 유지하는 자동화된 백그라운드 프로세스입니다. 여러 최신 데이터베이스와 마찬가지로 Amazon DocumentDB의 MVCC 아키텍처는 각 업데이트마다 새 문서 및 인덱스 버전을 생성합니다. 각 쓰기 작업은 유한 카운터에서 고유한 MVCC ID를 사용합니다. 이러한 IDs 문서 버전이 속한 트랜잭션과 커밋 또는 롤백 여부를 식별합니다. 시간이 지남에 따라 이러한 이전 버전과 해당 MVCC IDs 누적되므로 성능 저하를 방지하기 위해 정리가 필요합니다.

폐영역 회수의 함수

폐영역 회수기는 세 가지 필수 함수를 제공합니다.

폐영역 회수 프로세스

GC 프로세스는 컬렉션별로 작동하며 여러 컬렉션에서 여러 프로세스를 동시에 실행할 수 있습니다. 이 프로세스는 4개의 순차적 단계로 구성됩니다.

폐영역 회수가 이전 문서 버전 처리를 완료하면 시스템에서 가장 오래된 MVCC ID가 제거됩니다. 이 정리는 MVCC ID를 재활용하여 클러스터 전체에서 새 쓰기 작업에 사용할 수 있도록 하여 MVCC ID 오버플로를 방지하는 데 매우 중요합니다. 이 재활용 프로세스가 없으면 시스템은 결국 유한 MVCC ID 카운터를 소진하고 읽기 전용 상태가 됩니다.

폐영역 회수 일정

폐영역 회수는 주기적으로 백그라운드에서 자동으로 실행됩니다. 타이밍 및 빈도는 시스템 로드, 사용 가능한 리소스, 쓰기 볼륨 및 MVCC ID 소비 수준에 따라 동적으로 조정됩니다. 쓰기 작업이 많은 동안에는 GC 프로세스가 더 자주 실행되어 문서 버전의 수가 증가합니다.

스토리지 아키텍처 및 확장 스토리지

Amazon DocumentDB는 문서 스토리지를 두 개의 개별 세그먼트로 분리하는 정교한 스토리지 아키텍처를 사용합니다.

기본 스토리지 세그먼트

기본 스토리지 세그먼트에는 기본 문서 데이터와 메타데이터가 포함되어 있습니다. 이 세그먼트는 다음을 저장합니다.

확장 스토리지 세그먼트

확장 스토리지 세그먼트는 표준 스토리지 페이지 크기를 초과하는 문서를 처리하도록 설계된 특수 대형 문서 객체 스토어를 활용합니다. 이 세그먼트는 다음을 제공합니다.

확장 스토리지 세그먼트는 다음과 같은 경우에 특히 유용합니다.

폐영역 회수 모니터링

클러스터 수준 지표

AvailableMVCCIds

LongestActiveGCRuntime

컬렉션 수준 지표

MVCCIDStats: MVCCIdScale

gcRuntimeStats

storageSizeStats

unusedStorageSize(수집 수준)

documentFragmentStats

인덱스 수준 지표

unusedStorageSize(인덱스 수준)

collStats 출력 예제

다음 예제에서는 가비지 수집 및 스토리지 지표가 포함된 일반적인 collStats 출력을 보여줍니다.

{
    "ns" : "Mvcc_consumption_test_db.mvcc_test_collection",
    "MVCCIdStats" : {
        "MVCCIdScale" : 0.03
    },
    "gcRuntimeStats" : {
        "numRuns" : 1,
        "historicalAvgRuntime" : 3295,
        "historicalMaxRuntime" : 3295,
        "lastRuntime" : 3295,
        "lastRuntimeStart" : ISODate("2025-06-24T08:47:14Z")
    },
    "documentFragmentStats" : {
        "totalDocFragmentsCount" : 45000000,
        "deadDocFragmentsCount" : 2250000,
        "deadDocFragmentsPercent" : 5.0,
        "deadDocFragmentBytes" : 98304000,
        "storageSegmentBase" : {
            "totalDocFragmentsCount" : 30000000,
            "deadDocFragmentsCount" : 1500000,
            "deadDocFragmentsPercent" : 5.0,
            "deadDocFragmentBytes" : 65536000
        },
        "storageSegmentExtended" : {
            "totalDocFragmentsCount" : 15000000,
            "deadDocFragmentsCount" : 750000,
            "deadDocFragmentsPercent" : 5.0,
            "deadDocFragmentBytes" : 32768000
        }
    },
    "collScans" : 14,
    "count" : 30000000,
    "size" : 1320000000,
    "avgObjSize" : 44,
    "storageSize" : 6461497344,
    "storageSizeStats" : {
        "storageSegmentBase" : 4307664896,
        "storageSegmentExtended" : 2153832448
    },
    "capped" : false,
    "nindexes" : 2,
    "totalIndexSize" : 9649553408,
    "indexSizes" : {
        "_id_" : 1910661120,
        "c_1" : 7738892288
    },
    "unusedStorageSize" : {
        "unusedBytes" : 4201881600,
        "unusedPercent" : 65.05,
        "storageSegmentBase" : {
            "unusedBytes" : 2801254400,
            "unusedPercent" : 65.05
        },
        "storageSegmentExtended" : {
            "unusedBytes" : 1400627200,
            "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)

폐영역 회수의 효율적 작동 여부를 확인하려면 어떻게 해야 하나요?

비효율적인 폐영역 회수를 나타내는 다음 경고 신호를 모니터링합니다.

폐영역 회수가 데이터베이스 성능에 영향을 미치나요?

정상적인 조건에서는 폐영역 회수가 성능에 미치는 영향을 최소화합니다. 그러나 폐영역 회수가 뒤처지면 다음과 같은 상황이 발생할 수 있습니다.

폐영역 회수를 수동으로 트리거할 수 있나요?

아니요. Amazon DocumentDB의 폐영역 회수는 수동으로 트리거할 수 없습니다. 시스템은 내부 유지 관리 작업의 일부로 폐영역 회수를 자동으로 관리합니다.

운영 모범 사례로 설정해야 하는 경보는 무엇인가요?

Amazon DocumentDB 시스템의 성능을 최적화하려면 클러스터 및 컬렉션 수준 모두에서 모니터링을 설정하는 것이 좋습니다.

클러스터 수준 모니터링의 경우 먼저 임계값이 AvailableMVCCIds 13억인 지표에 대한 Amazon CloudWatch 경보를 생성합니다. 이렇게 하면 지표가 0에 도달하기 전에 조치를 취할 수 있는 충분한 시간을 확보할 수 있습니다. 그러면 클러스터가 읽기 전용 모드로 전환됩니다. 이 지표는 특정 사용 패턴에 따라 변동할 수 있습니다. 일부 고객은 가비지 수집이 작업을 완료하면 지표가 13억 미만으로 감소한 다음 15억 이상으로 복구됩니다.

Amazon CloudWatch를 통해 LongestActiveGCRuntime 지표를 모니터링하는 것도 중요합니다. 이 지표는 gcRuntimeStats와 함께 시스템 전체에서 폐영역 회수가 얼마나 효율적으로 수행되고 있는지 이해하는 데 도움이 됩니다.

컬렉션 수준 모니터링의 경우 다음 주요 지표에 집중하세요.

쓰기 작업이 빈번한 컬렉션은 폐영역 회수기에 더 많은 작업을 생성하므로 각별한 주의가 필요합니다. 폐영역 회수가 워크로드를 따라잡을 수 있도록 쓰기 활동이 많은 컬렉션에 대해 이러한 지표를 더 자주 확인하는 것이 좋습니다.

이러한 모니터링 권장 사항은 시작점 역할을 합니다. 시스템 동작에 더 익숙해지면 특정 사용 패턴 및 요구 사항에 더 잘 맞게 이러한 임계값을 조정하는 것이 좋습니다.

AvailableMVCCIds가 13억 이하로 떨어지면 어떻게 해야 하나요?

AvailableMVCCIds 지표가 13억 미만으로 떨어지면 클러스터가 읽기 전용 모드로 전환되지 않도록 즉각적인 조치를 취하는 것이 좋습니다. 먼저 인스턴스 크기를 확장하여 폐영역 회수기에 더 많은 컴퓨팅 리소스를 제공하는 것이 좋습니다. 이는 애플리케이션이 가비지 수집기에 따라 잡는 데 필요한 추가 전력을 제공하면서 정상적인 작업을 계속할 수 있도록 하기 위한 기본 권장 사항입니다.

확장만으로도 상황이 개선되지 않는 경우 쓰기 작업의 감소를 고려하는 것이 좋습니다. MVCCIdScale 지표를 사용하여 주의가 필요한 이전 MVCC ID가 포함된 특정 컬렉션을 식별합니다. 또한를 모니터링documentFragmentStats하여 가비지 수집 비효율성에 기여할 수 있는 데드 조각 비율이 높은 컬렉션을 식별합니다.

이러한 컬렉션을 식별한 후에는 폐영역 회수가 따라잡을 수 있도록 컬렉션에 대한 쓰기 작업을 일시적으로 줄여야 할 수 있습니다. 복구 기간 동안 AvailableMVCCIds 지표를 면밀히 모니터링하여 작업에 원하는 효과가 있는지 확인하는 것이 좋습니다. AvailableMVCCIds 값이 15억 이상으로 반환되면 클러스터가 정상으로 간주됩니다.

이러한 단계는 시스템이 중요한 상태에 도달하기 전에 복구하는 데 도움이 되는 예방 조치입니다. 지표가 13억 미만으로 감소한 것을 확인한 후 더 빨리 조치를 취할수록 쓰기 작업에 미치는 영향을 피할 가능성이 높아집니다.