Amazon DocumentDB 인스턴스의 CPU 과다 사용 및 오류를 해결하려면 어떻게 해야 합니까?

5분 분량

Amazon DocumentDB (MongoDB 호환) DB 인스턴스에서 CPU 사용률이 높은 것을 관찰했습니다.

간략한 설명

Amazon DocumentDB 인스턴스의 CPU 사용률은 현재 할당된 리소스가 진행 중인 워크로드에서 어떻게 작동하는지 파악하는 데 도움이 됩니다.

다음과 같은 이유로 CPU 사용률이 증가할 수 있습니다.

사용자가 시작한 과중한 워크로드
비효율적인 쿼리
클러스터의 읽기 로드가 분산되지 않아 클러스터의 라이터에 과부하가 걸렸습니다
리더는 라이터보다 하드웨어 구성이 낮으므로 높은 쓰기 워크로드와 동기화할 수 없습니다
Amazon DocumentDB 클러스터에서의 가비지 수집과 같은 내부 작업
데이터베이스 연결이 너무 많음 (유휴)
짧은 연결 버스트

Amazon DocumentDB 인스턴스에서 CPU 사용의 주요 소스를 식별하려면 다음 측면을 검토합니다.

Amazon CloudWatch 지표
성능 인사이트
네이티브 데이터베이스 쿼리
쿼리의 효율성 확인
과도한 로깅 설정

원인을 파악한 후에는 워크로드를 분석하고 최적화하여 CPU 사용량을 줄입니다. 그래도 문제가 지속되면 워크로드에 따라 인스턴스 크기를 늘립니다.

해결 방법

CloudWatch 지표 사용

Amazon DocumentDB는 CloudWatch와 통합되므로 클러스터의 운영 지표를 수집하고 분석할 수 있습니다.

CloudWatch 지표를 사용하면 CPU와 그에 비례하는 지표 패턴을 장기간에 걸쳐 식별할 수 있습니다. 다음 지표를 검토한 다음 CloudWatch 콘솔에서 모니터링합니다.

DatabaseConnections 및 DatabaseConnectionsMax를 사용하여 관련 타임라인에 열려 있는 연결 수를 식별할 수 있습니다.
WriteIOPs, ReadIOPs, ReadThroughput 및 WriteThroughput를 사용하여 Amazon DocumentDB 인스턴스의 전체 워크로드를 파악합니다.
DocumentsDeleted, DocumentsInserted, DocumentsReturned 및 DocumentsUpdated를 사용합니다. 지표를 통해 Amazon DocumentDB 인스턴스의 사용자 워크로드를 파악할 수 있습니다.
T3 또는 T4 인스턴스 클래스를 사용하는 경우 CPUCreditBalance 및 CPUSurplusCreditBalance 를 검토하여 컴퓨팅 제한을 확인합니다.

성능 인사이트 지표 사용

Amazon DocumentDB 성능 인사이트를 사용하여 데이터베이스 로드 및 대기 상태에 영향을 주는 쿼리를 식별합니다. 지표 관리 옵션에서 평균 활성 세션을 사용하여 로드 및 CPU 분포 (시스템%, 사용자% 또는 총%) 를 검토합니다.

로드 평균이 vCPU 수보다 크면 인스턴스에 과부하가 걸렸다는 것을 나타냅니다. 예를 들어, 로드 평균은 DB 인스턴스 클래스의 vCPU보다 작을 수 있습니다. 이는 CPU 제한이 애플리케이션 지연 시간의 원인이 아닐 수도 있음을 나타냅니다. 로드 평균을 확인하고 관련 대기 상태를 분석하여 I/O, 잠금, 래치와 같은 추가된 CPU 사용량의 원인을 파악합니다.

네이티브 데이터베이스 쿼리 사용

네이티브 쿼리를 통해 워크로드를 분석하고 CPU 사용량을 확인합니다. MongoDB 쉘을 사용하여 이 쿼리를 실행합니다. 여기에는 현재 Amazon DocumentDB 인스턴스에서 실행 중인 모든 작업이 나열되어 있습니다.

db.adminCommand({currentOp: 1, $all: });

이 쿼리는 currentOp 명령을 사용하여 차단되었거나 10초 이상 실행된 모든 쿼리를 나열합니다.

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {}},
                            {$match: {$or: [{secs_running: {$gt: 10}},
                                            {WaitState: {$exists: true}}]}},
                            {$project: {_id:0,
                                        opid: 1,
                                        secs_running: 1,
                                        WaitState: 1,
                                        blockedOn: 1,
                                        command: 1}}],
                 cursor: {}
                });

시스템 사용량 결과를 분석하려면 CPU 사용량이 높은 인스턴스에서 이 쿼리를 실행하십시오. 이 쿼리는 각 네임스페이스에서 실행되는 모든 쿼리의 집계를 반환합니다. 또한 모든 내부 시스템 작업과 네임스페이스당 고유한 대기 상태 수를 나열합니다.

db.adminCommand({aggregate: 1,
                 pipeline: [{$currentOp: {allUsers: true, idleConnections: true}},
                            {$group: {_id: {desc: "$desc", ns: "$ns", WaitState: "$WaitState"}, count: {$sum: 1}}}],
                 cursor: {}
                });

**참고:**내부 작업의 GARBAGE\ _COLLECTION 지표는 Amazon DocumentDB 클러스터의 MVCC 구현입니다. 이것은 사용하지 않은 문서 버전을 제거하고 데이터베이스의 업데이트 또는 삭제 횟수와 관련된 백그라운드 스위퍼입니다. 스위핑 프로세스는 수집 수준에서 내부 임계값을 기반으로 트리거되며 결과적으로 읽기/쓰기 IOPS 및 CPU 사용량을 초래합니다.

쿼리의 효율성 확인

쓰기 쿼리에 대한 인덱스 오버헤드 확인

데이터베이스와 관련된 인덱스가 너무 많거나 사용되지 않는 인덱스가 많으면 쓰기 오버헤드가 증가할 수 있습니다. 인덱스 통계를 검토하여 인덱스 사용량을 분석하고 식별합니다.

**쿼리 설명 계획 확인 **

관련 문서를 선택하려면 컬렉션 전체를 스캔해야 하므로 쿼리 실행 속도가 느릴 수 있습니다. 적절한 색인을 생성하여 쿼리 속도를 높입니다.

explain 명령을 사용하여 색인을 생성하려는 필드를 식별합니다. 또한 프로파일러 로그 사용하여 장기 실행 쿼리와 해당 작업의 세부 정보를 캡처할 수 있습니다.

컬렉션 통계 확인

사용하는 컬렉션에 대한 다음 통계를 확인하세요.

성능 인사이트의 상위 쿼리 섹션을 검토하여 로드에 가장 큰 영향을 미치는 컬렉션을 파악합니다.
컬렉션의 통계를 검토하여 컬렉션에 대해 수행된 삽입, 업데이트 및 삭제 작업의 양을 파악합니다. 수행된 인덱스 스캔 및 전체 컬렉션 스캔의 양을 검토할 수도 있습니다.
특히 업데이트 작업 횟수가 많은 경우 컬렉션을 분할하여 처리할 문서 크기를 줄입니다.

과도한 로깅 설정 확인

이벤트 감사는 데이터베이스 트래픽보다 우선 순위가 높습니다. 감사가 필요하지 않은 경우 감사를 끌 수 있습니다. 감사가 필요한 경우 필요한 이벤트만 기록하도록 audit_logs 매개 변수를 설정합니다. 로드 증가에 대비한 다음 필요한 경우 더 큰 인스턴스 클래스로 전환합니다.

프로파일러 로그의 경우 과도한 로깅을 피하려면 profiler_threshold_ms 매개 변수에 올바른 값을 설정되어 있는지 확인합니다. 애플리케이션 워크로드를 검토하여 쿼리를 장기 실행으로 분류하는 데 필요한 올바른 임계값을 파악합니다.

CloudWatch로 내보내려는 로그에 대해 로그 내보내기 옵션을 활성화했는지 확인합니다.

모범 사례 사용

**읽기 워크로드를 리더로 오프로드 **

Amazon DocumentDB 클러스터에 다중 DB 인스턴스가 있는 경우 읽기 워크로드를 리더 인스턴스로 오프로드합니다. 복제 세트로 연결하는 경우 연결에 대한 readPreference를 지정합니다. 읽기 기본 설정을 secondaryPreferred로 지정하면 클라이언트는 읽기 쿼리를 복제본으로 라우팅하려고 합니다. 클라이언트는 쓰기 쿼리를 기본 DB 인스턴스로 라우팅하려고 합니다.

리더는 최종 일관성을 유지합니다. 워크로드에 보다 강력한 쓰기 후 읽기 일관성이 필요한 경우 동적 읽기 기본 설정을 사용하고 쿼리 수준에서 이를 재정의하십시오. 예를 들어 쿼리가 보조 쿼리로 이동하도록 연결 수준에서 secondaryPreferred로 기본 설정할 수 있습니다. 보다 강력한 쓰기 후 읽기 일관성이 필요한 쿼리가 있는 경우 기본값을 재정의할 수 있습니다. 다음 예를 참조하세요.

db.collection.find().readPref("primary")

클러스터에 하나 이상의 리더 인스턴스 추가

Amazon DocumentDB 클러스터에 단일 DB 인스턴스 (라이터 전용) 가 있는 경우 클러스터에 하나 이상의 리더 DB 인스턴스를 추가하십시오. 그런 다음 readPreference=SecondaryPreferred 명령을 사용하여 로드를 효율적으로 처리합니다.

Amazon DocumentDB 프로파일러를 사용하여 느린 쿼리를 식별합니다.

Amazon DocumentDB 프로파일러를 사용하여 느린 쿼리를 기록합니다. 느린 쿼리 로그에 쿼리가 반복적으로 나타나는 경우 성능을 향상시키기 위해 추가 인덱스가 필요할 수 있습니다.

하나 이상의 COLLSCAN 단계를 수행하는 단계가 하나 이상 있는 장기 실행 쿼리를 찾습니다. 이는 쿼리 단계에서 쿼리에 대한 응답을 제공하기 위해 컬렉션의 모든 문서를 읽어야 함을 나타냅니다.

자세한 내용은 Amazon DocumentDB(MongoDB 호환)에서 실행 속도가 느린 쿼리 프로파일링 을 참조하세요.

CloudWatch를 사용하여 경보 알림 생성

CPU 사용률 지표가 특정 임계값을 초과할 경우 알려주는 CloudWatch 경보를 생성합니다.

**DB 인스턴스의 인스턴스 클래스 스케일 업 **

쿼리 조정 범위가 더 이상 없는 경우 클러스터에 있는 인스턴스의 인스턴스 클래스를 스케일 업하여 워크로드를 처리합니다.

**참고:**인스턴스 클래스를 스케일 업하면 비용이 증가합니다. 자세한 내용은 Amazon DocumentDB 요금을 참조하세요.