MongoDB 문제 해결을 위한 5가지 일반적인 시나리오와 빠른 해결 방법

MongoDB 문제 해결은 일반적으로 앱 속도가 느려지거나, 쓰기가 실패하거나, 복제 세트가 뒤처질 때 시작됩니다. 이 가이드는 프로덕션 환경에서 자주 발생하는 5가지 일반적인 시나리오를 설명하고, 가장 먼저 확인해야 할 사항을 보여줍니다.

더 큰 변경을 하기 전에 이러한 확인 사항을 1차 점검으로 사용하세요. 이를 통해 쿼리 문제를 인프라, 복제 또는 샤딩 문제와 구분할 수 있습니다.

1. 느린 쿼리 성능

느린 쿼리는 프로덕션 환경에서 가장 흔히 보고되는 성능 문제일 것입니다. 몇 밀리초 대신 몇 초가 걸리는 쿼리는 애플리케이션 응답성을 심각하게 저하시킬 수 있습니다.

진단: explain() 사용

느린 쿼리를 진단하는 첫 번째 단계는 쿼리가 느린 이유를 이해하는 것입니다. MongoDB의 explain() 메서드는 이 분석에 필수적인 도구입니다. 실행 계획을 보여주며, 어떤 인덱스가 사용되었는지(또는 사용되지 않았는지)를 자세히 설명합니다.

명령 예시:

db.collection.find({ field: 'value' }).explain('executionStats')

출력을 분석하여 특히 다음을 확인하세요.

• winningPlan.stage: 단계가 COLLSCAN이면 MongoDB가 모든 문서를 읽고 있는 것입니다. 이는 종종 인덱스가 없거나 사용할 수 없음을 나타냅니다.
• executionStats.nReturned와 executionStats.totalKeysExamined 및 executionStats.totalDocsExamined 비교.

빠른 해결 방법

1. 올바른 인덱스 생성: 쿼리 계획에 컬렉션 스캔이 표시되면 필터 및 정렬 패턴과 일치하는 인덱스를 추가하세요. 예를 들어, 앱에서 user_id와 최신 timestamp로 주문을 자주 검색하는 경우 복합 인덱스를 생성하세요.

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. 쿼리 개선: 너무 많은 데이터를 가져오고 있는지 확인하세요. 프로젝션을 사용하여 페이지나 작업에 실제로 필요한 필드만 반환하세요. 3. 느린 쿼리 로그 검토: 워크로드에 맞는 임계값으로 프로파일러 또는 느린 쿼리 로그를 사용하세요. 정확한 임계값은 보편적인 규칙이 아닌 운영상의 선택으로 취급하세요.

팁: 인덱스는 읽기 속도를 향상시키지만 쓰기를 약간 느리게 합니다. 쿼리 조건자(find()), 정렬 작업(sort()) 또는 범위 쿼리에서 자주 사용되는 필드에만 인덱스를 생성하세요.

2. 복제 세트의 복제 지연

복제 지연은 복제 세트의 보조 멤버가 oplog(작업 로그)에서 작업을 적용하는 데 있어 기본 멤버보다 크게 뒤처질 때 발생합니다.

진단: replSetGetStatus 확인

복제 세트의 모든 멤버에서 replSetGetStatus 명령을 사용하여 모든 멤버의 상태 및 동기화 상태를 확인하세요.

명령 예시:

rs.printReplicationInfo()
// 또는 상태를 직접 쿼리:
rs.status()

기본 및 보조 멤버의 optimeDate를 확인하세요. 기본 멤버의 optime과 보조 멤버의 optime 간의 차이는 지연을 나타내며, 일반적으로 각 멤버의 secsBehind 필드에 표시됩니다.

빠른 해결 방법

1. 네트워크 지연 시간 확인: 멤버 간의 높은 지연 시간은 oplog 전송을 느리게 할 수 있습니다.
2. 지연되는 보조 멤버 확인: 높은 CPU, 느린 디스크 I/O 또는 시끄러운 이웃 워크로드는 보조 멤버가 쓰기를 충분히 빠르게 적용하지 못하게 할 수 있습니다.
3. oplog 적용 범위 검토: 지연이 심각한 경우 보조 멤버에 필요한 oplog 항목이 더 이상 없을 수 있습니다. 이 경우 해당 멤버를 재동기화하거나 다시 빌드해야 할 수 있습니다.

3. 연결 오류 및 인증 실패

애플리케이션 서비스는 구성 오류, 방화벽 문제 또는 잘못된 자격 증명으로 인해 MongoDB에 연결하지 못하는 경우가 많습니다.

진단: 로그 및 네트워크 확인

먼저 MongoDB 서버가 예상 IP 주소와 포트에서 수신 대기 중인지 확인하세요. MongoDB 서버 로그에서 특정 오류를 확인하세요.

일반적인 로그 오류:

• Address already in use: 다른 프로세스가 포트를 사용 중입니다.
• Connection refused: 서버 프로세스가 중단되었거나, 차단되었거나, 다른 곳에서 수신 대기 중입니다.
• Authentication failed: 사용자 이름, 비밀번호, 인증 데이터베이스 또는 역할 할당이 잘못되었습니다.

빠른 해결 방법

1. 방화벽 규칙 확인: MongoDB 포트(일반적으로 27017)가 애플리케이션 호스트에서 연결 가능한지 확인하세요.
2. bindIp 확인: mongod.conf가 127.0.0.1에만 바인딩된 경우 원격 클라이언트가 연결할 수 없습니다. 가능하면 특정 개인 인터페이스에 바인딩하세요. 네트워크 제어 및 인증이 이미 설정되어 있지 않은 한 0.0.0.0은 피하세요.
3. authSource 확인: 사용자가 admin에서 생성된 경우 연결 문자열에 ?authSource=admin이 필요할 수 있습니다.

4. 디스크 공간 부족

문서 데이터베이스인 MongoDB는 데이터를 디스크에 직접 저장합니다. 예상치 못한 데이터 증가 또는 부적절한 데이터베이스 정리로 인해 디스크 공간이 빠르게 소진되어 모든 쓰기 작업이 중단될 수 있습니다.

진단: 모니터링 및 db.stats()

OS 모니터링 도구(Linux의 df -h)를 사용하여 전체 디스크 사용량을 확인하세요. MongoDB 내에서 db.stats() 명령을 사용하여 개별 데이터베이스가 사용 중인 공간을 확인하세요.

명령 예시:

db.stats()

특히 storageSize 및 dataSize 필드를 확인하세요.

빠른 해결 방법

1. 쓰기가 실패하는 경우 시간 확보: 중요하지 않은 작업을 중지하고, 관련 없는 임시 파일을 제거하거나, 플랫폼이 지원하는 경우 볼륨을 확장하세요.
2. 사용하지 않는 데이터 제거: 더 이상 필요하지 않고 백업이 있는지 확인한 후에만 오래된 컬렉션이나 데이터베이스를 삭제하세요.
3. 신중하게 압축: 삭제나 업데이트가 많은 컬렉션의 경우 compact는 예약된 공간을 확보할 수 있지만, 중단을 유발할 수 있습니다. MongoDB 버전 및 스토리지 엔진에 대한 영향을 테스트하세요.

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. 스토리지 용량 증가: 장기적인 해결책은 일반적으로 더 큰 디스크, 더 나은 보존 규칙 또는 로그 및 백업을 위한 별도의 스토리지입니다.

경고: 디스크가 완전히 가득 차면 MongoDB는 데이터 손상을 방지하기 위해 쓰기를 중단합니다. 정상적인 작업을 재개하기 전에 공간 문제를 해결해야 합니다.

5. 샤딩 클러스터 오류(오래된 라우터/구성 서버)

샤딩 환경에서는 구성 서버(config servers) 또는 쿼리 라우터(mongos 인스턴스) 내의 연결 또는 상태 문제로 인해 전체 시스템이 중단될 수 있습니다.

진단: 클러스터 상태 확인

mongos 인스턴스에 대해 실행되는 sh.status() 명령은 샤딩 상태 진단을 위한 기본 도구입니다.

실행 가능한 명령 예시:

sh.status()

출력에서 확인해야 할 주요 영역:

• 구성 서버: 구성 서버 복제 세트에 정상적인 과반수가 있는지 확인하세요.
• 샤드: 나열된 모든 샤드가 연결되어 있고 올바르게 보고되는지 확인하세요.
• 오래된 상태: 라우터 또는 샤드에 오래된 메타데이터가 있다는 경고를 찾으세요.

빠른 해결 방법

1. 적절한 경우 mongos 다시 시작: 하나의 라우터가 오래되었거나 응답하지 않는 경우 다시 시작하면 구성 서버에 대한 새 연결을 강제할 수 있습니다.
2. 먼저 구성 서버 상태 수정: 구성 서버 복제 세트에 정상적인 과반수가 없으면 샤드 메타데이터 작업이 실패할 수 있습니다.
3. 샤드 수준 문제 해결: 디스크 압박이나 복제 지연으로 인해 샤드가 다운된 경우 라우터 증상을 추적하기 전에 근본 원인을 해결하세요.

전문가의 도움이 필요할 때

데이터 손실 가능성이 있거나, 복제 세트를 재동기화해야 하거나, 구성 서버가 비정상이거나, 디스크 공간이 이미 쓰기에 영향을 미치는 경우 MongoDB 관리자 또는 플랫폼 엔지니어를 투입하세요. 프로덕션 환경에서 압축 또는 멤버 재구축과 같은 중단을 유발하는 명령을 실행하기 전에 도움을 받으세요.

결론

MongoDB 문제 해결은 사용자 영향에 가장 가까운 증상(느린 페이지, 실패한 연결, 중단된 쓰기, 지연되는 보조 멤버 또는 샤딩된 클러스터 오류)부터 시작하세요. 그런 다음 explain(), rs.status(), db.stats() 및 sh.status()를 사용하여 인덱스 변경, 라우터 다시 시작 또는 멤버 재구축 전에 원인을 확인하세요.