DevOps 지식 허브
DevOps 지식 허브

MongoDB 복제 지연의 일반적인 문제 진단 및 해결

이 종합 가이드를 통해 MongoDB 복제 지연의 복잡성을 탐색하십시오. 복제본 세트의 데이터 일관성과 고가용성을 손상시키는 일반적인 문제를 식별, 진단 및 해결하는 방법을 알아보십시오. 이 문서는 oplog 이해 및 `rs.status()`를 이용한 지연 감지부터 불충분한 oplog 크기, 네트워크 병목 현상, 리소스 제약 및 누락된 인덱스에 대한 실용적인 해결책까지 모든 것을 다룹니다. 건강하고 성능이 뛰어나며 탄력적인 MongoDB 환경을 유지하기 위한 실행 가능한 전략과 모범 사례를 갖추십시오.

32 조회수

MongoDB 복제 지연 문제 진단 및 해결 방법

MongoDB 복제본 세트는 최신 MongoDB 배포에서 고가용성 및 데이터 중복성의 중추입니다. 기본 노드에 장애가 발생해도 데이터가 계속 사용 가능하도록 보장하며, 읽기 작업 확장에도 사용할 수 있습니다. 그러나 복제본 세트를 정상적으로 유지하는 데 중요한 측면은 모든 보조 멤버가 기본 멤버와 동기화되도록 하는 것입니다. 보조 멤버가 뒤처지면 복제 지연이라고 하는 현상이 발생하며, 이는 데이터 일관성을 손상시키고, 읽기 성능에 영향을 미치며, 장애 조치를 지연시킬 수 있습니다.

이 종합 가이드에서는 MongoDB 복제본 세트 동기화의 복잡한 내용을 다루며, 복제가 어떻게 작동하는지 이해하고, oplog 지연의 근본 원인을 파악하며, 효과적인 수정 조치를 적용하는 데 도움을 줍니다. 이러한 문제를 사전에 해결함으로써 고가용성을 유지하고, 데이터 일관성을 보장하며, MongoDB 클러스터의 성능을 최적화할 수 있습니다.

MongoDB 복제본 세트 복제 이해하기

MongoDB 복제본 세트는 기본 노드와 여러 보조 노드로 구성됩니다. 기본 노드는 모든 쓰기 작업을 처리합니다. 기본 멤버에서 발생한 모든 변경 사항은 작업 로그 또는 oplog에 기록됩니다. oplog는 데이터 세트를 수정하는 모든 작업의 순환 기록을 저장하는 특수한 고정 크기 컬렉션입니다. 그런 다음 보조 멤버는 기본 멤버로부터 이 oplog를 비동기적으로 복제하고 자체 데이터 세트에 해당 작업을 적용하여 최신 상태를 유지하도록 합니다.

oplog에서 작업을 적용하는 이 지속적인 프로세스는 보조 멤버를 기본 멤버와 동기화 상태로 유지합니다. 정상적인 복제본 세트는 일반적으로 밀리초 또는 몇 초로 측정되는 작고 일관된 지연 시간을 유지합니다. 이 기준선에서 상당한 편차는 즉각적인 주의가 필요한 문제를 나타냅니다.

복제 지연이란?

복제 지연은 기본 멤버에서 적용된 마지막 작업과 보조 멤버에서 적용된 마지막 작업 간의 시간 차이를 의미합니다. 간단히 말해, 보조 멤버가 기본 멤버로부터 얼마나 뒤처져 있는지를 나타냅니다. 비동기 복제 시스템에는 어느 정도의 최소 지연이 내재되어 있지만, 과도한 지연은 여러 가지 문제를 야기할 수 있습니다.

  • 오래된 읽기: 읽기가 보조 멤버로 전달되는 경우 클라이언트는 오래된 데이터를 받을 수 있습니다.
  • 느린 장애 조치: 장애 조치 중에 보조 멤버는 기본 멤버가 되기 전에 보류 중인 모든 작업을 따라잡아야 하므로 다운타임이 길어집니다.
  • 데이터 불일치: 극단적인 경우 보조 멤버가 너무 뒤처져 기본 멤버로부터 더 이상 동기화할 수 없게 되어 전체 재동기화가 필요할 수 있습니다.

복제 지연 식별

복제 지연을 감지하는 것이 이를 해결하기 위한 첫 번째 단계입니다. MongoDB는 복제본 세트의 상태를 모니터링하고 지연되는 멤버를 식별하기 위한 여러 가지 방법을 제공합니다.

rs.printReplicationInfo() 사용

이 명령은 복제본 세트의 oplog 상태에 대한 빠른 개요를 제공하며, oplog 창과 보조 멤버가 따라잡는 데 필요한 예상 시간을 포함합니다.

rs.printReplicationInfo()

출력 예시:

syncedTo: Tue Jun 11 2024 10:30:00 GMT+0000 (UTC)
oplog first entry: Mon Jun 10 2024 10:00:00 GMT+0000 (UTC)
oplog last entry: Tue Jun 11 2024 10:30:00 GMT+0000 (UTC)
oplog window in hours: 24

rs.status() 사용

rs.status() 명령은 복제본 세트의 각 멤버에 대한 자세한 정보를 제공합니다. 주목해야 할 주요 필드는 optimeDate 및 optime입니다. 기본 멤버의 optimeDate를 각 보조 멤버의 optimeDate와 비교하여 지연 시간을 계산할 수 있습니다.

rs.status()

rs.status() 출력에서 검토할 주요 필드:

  • members[n].optimeDate: 이 멤버에 적용된 마지막 작업의 타임스탬프입니다.
  • members[n].stateStr: 멤버의 현재 상태(예: PRIMARY, SECONDARY, STARTUP2)입니다.
  • members[n].syncingTo: 보조 멤버의 경우, 동기화 중인 멤버를 나타냅니다.

지연 시간 계산: 보조 멤버의 optimeDate에서 기본 멤버의 optimeDate를 빼서 초 단위의 지연 시간을 얻습니다.

// 예시: 보조 멤버의 지연 시간 계산
const status = rs.status();
const primaryOptime = status.members.find(m => m.stateStr === 'PRIMARY').optimeDate;
const secondaryOptime = status.members.find(m => m.name === 'myreplset/secondary.example.com:27017').optimeDate;

const lagInSeconds = (primaryOptime.getTime() - secondaryOptime.getTime()) / 1000;
print(`Replication lag for secondary: ${lagInSeconds} seconds`);

모니터링 도구

프로덕션 환경에서는 수동 rs.status() 호출에만 의존하는 것은 불충분합니다. MongoDB Atlas, Cloud Manager, Ops Manager와 같은 도구는 복제 지연을 시간에 따라 시각화하고, 경고를 트리거하며, 기록 인사이트를 제공하는 강력한 모니터링 대시보드를 제공하여 문제를 사전에 더 쉽게 감지하고 진단할 수 있습니다.

복제 지연의 일반적인 원인

복제 지연은 다양한 요인, 종종 그 조합으로 인해 발생할 수 있습니다. 이러한 원인을 이해하는 것은 효과적인 문제 해결에 중요합니다.

1. 불충분한 Oplog 크기

Oplog는 고정 크기 고정 컬렉션입니다. oplog가 너무 작으면 보조 멤버가 너무 뒤처져 기본 멤버가 보조 멤버가 아직 필요로 하는 작업을 덮어쓸 수 있습니다. 이로 인해 보조 멤버는 전체 재동기화를 수행해야 하며, 이는 시간이 많이 걸리고 리소스 집약적인 작업입니다.

  • 증상: oplog window is too small, oplog buffer full, 보조 멤버의 RECOVERING 상태.
  • 진단: rs.printReplicationInfo()에서 oplog window in hours 확인.

2. 네트워크 지연 및 처리량 문제

기본 멤버와 보조 멤버 간의 느리거나 불안정한 네트워크 연결은 oplog 항목의 적시 전송을 방해하여 지연을 유발할 수 있습니다.

  • 증상: 노드 간 높은 ping 시간, 모니터링 도구에서 네트워크 포화 경고.
  • 진단: ping 또는 네트워크 모니터링 도구를 사용하여 복제본 세트 멤버 간의 지연 시간 및 대역폭 확인.

3. 보조 멤버 리소스 제약 (CPU, RAM, I/O)

oplog 작업을 적용하는 것은 I/O 및 CPU 집약적일 수 있습니다. 보조 멤버의 하드웨어 리소스(CPU, RAM, 디스크 I/O)가 기본 멤버의 쓰기 작업량을 따라가지 못할 정도로 불충분하면 필연적으로 지연이 발생합니다.

  • 증상: 보조 멤버에서 높은 CPU 사용률, 낮은 가용 RAM, 높은 디스크 I/O 대기.
  • 진단: 보조 멤버에서 mongostat, mongotop, 시스템 모니터링 도구 (top, iostat, free -h) 사용.

4. 기본 멤버에서의 장기 실행 작업

매우 크거나 장기 실행 쓰기 작업(예: 대량 삽입, 여러 문서를 포함하는 대규모 업데이트, 인덱스 빌드)은 기본 멤버에서 많은 oplog 항목을 생성할 수 있습니다. 보조 멤버가 이러한 작업을 충분히 빨리 적용할 수 없으면 지연이 발생합니다.

  • 증상: 대규모 쓰기 작업 후 oplog 크기의 갑작스러운 급증과 이에 따른 지연 증가.
  • 진단: 기본 멤버에서 db.currentOp()를 모니터링하여 장기 실행 작업 식별.

5. 보조 멤버에서의 집중적인 읽기

애플리케이션이 상당한 양의 읽기 트래픽을 보조 멤버로 보내는 경우, 이러한 읽기는 oplog 적용 프로세스와 리소스(CPU, I/O)를 놓고 경쟁하여 동기화를 늦출 수 있습니다.

  • 증상: 보조 멤버 리소스 경합, 보조 멤버에서의 높은 쿼리 수.
  • 진단: 보조 멤버에서 mongostat 및 쿼리 로그를 사용하여 읽기 작업 모니터링.

6. 보조 멤버에서의 인덱스 누락

oplog에 기록된 작업은 종종 문서를 효율적으로 찾기 위해 인덱스에 의존합니다. 기본 멤버에 있는 인덱스가 보조 멤버에 없는 경우(예: 인덱스 빌드 실패 또는 수동 삭제로 인해), 보조 멤버는 oplog 항목을 적용하기 위해 전체 컬렉션 스캔을 수행하여 복제 프로세스를 크게 늦출 수 있습니다.

  • 증상: 높은 쓰기 활동을 겪는 컬렉션의 경우, 보조 멤버에서 특정 쿼리가 기본 멤버에서는 빠르더라도 비정상적으로 오래 걸립니다.
  • 진단: 높은 쓰기 활동을 겪는 컬렉션에 대해 기본 멤버와 보조 멤버 간의 인덱스 비교. 복제에서 발생하는 느린 작업에 대해 보조 멤버에서 db.currentOp() 확인.

7. 지연된 멤버 (의도적 지연)

엄밀히 말하면 "문제"는 아니지만, 지연된 멤버는 지정된 시간만큼 기본 멤버보다 뒤처지도록 의도적으로 구성됩니다. 지연된 멤버가 있는 경우, 이러한 지연은 예상된 것이며 문제로 혼동해서는 안 됩니다. 그러나 위에 나열된 이유로 인해 구성된 지연 위에 추가 지연이 발생할 수 있습니다.

복제 지연 문제 해결

복제 지연을 해결하려면 식별된 근본 원인을 대상으로 하는 체계적인 접근 방식이 필요합니다.

1. Oplog 크기 조정

불충분한 oplog 크기가 원인이라면 크기를 늘려야 합니다. 권장 크기는 종종 디스크 공간의 5%에서 10% 사이이며, 피크 시간 동안 최소 24-72시간의 작업을 처리할 수 있는 충분한 크기이며, 인덱스 빌드와 같은 유지 관리 작업을 위한 공간도 포함해야 합니다.

Oplog 크기 조정 단계 (각 멤버에 대한 다운타임 또는 롤링 재시작 필요):

a. 복제본 세트의 각 멤버에 대해 해당 멤버를 오프라인 상태로 만듭니다 (기본 멤버 스텝다운 후 종료).

b. mongod 인스턴스를 --replSet 옵션 없이 독립 실행형 서버로 시작합니다:
bash mongod --port 27017 --dbpath /data/db --bind_ip localhost

c. 독립 실행형 인스턴스에 연결하고 새 oplog를 생성하거나 기존 oplog의 크기를 조정합니다. 예를 들어, 10GB의 새 oplog를 생성하려면:
javascript use local db.oplog.rs.drop() db.createCollection("oplog.rs", { capped: true, size: 10 * 1024 * 1024 * 1024 })

자체 수정: 직접 크기 조정은 특히 기존 데이터의 경우, 삭제 및 재생성보다 덜 방해적이고 쉽습니다. replSetResizeOplog 명령은 MongoDB 4.4+부터 사용할 수 있습니다.

MongoDB 4.4+ (온라인 크기 조정):
기본 멤버에 연결하고 실행합니다:
javascript admin = db.getSiblingDB('admin'); admin.printReplicationInfo(); // 현재 크기 확인 admin.command({ replSetResizeOplog: 1, size: 10240 }); // 10 GB로 크기 조정
minOplogSize 매개변수를 사용하지 않는 경우 이 명령은 각 멤버에서 실행해야 합니다.

이전 버전 (오프라인 크기 조정):
크기가 현저히 작은 경우 백업 후 repairDatabase를 사용하거나 oplog를 다시 만들어야 할 수 있습니다. 4.4 미만 버전의 경우 롤링 재시작을 사용하거나 원하는 oplog 크기로 새 노드를 시작한 다음 이전 노드를 제거하는 것이 더 안전한 방법입니다. 재생성하는 경우, 정상 멤버로부터 최신 동기화가 있는지 확인하십시오.
d. --replSet 옵션을 사용하여 mongod 인스턴스를 다시 시작합니다.

e. 멤버가 재동기화하거나 따라잡도록 허용합니다. 모든 멤버에 대해 반복합니다.

2. 네트워크 구성 최적화

  • 네트워크 대역폭 향상: 노드 간 네트워크 인터페이스 또는 연결 업그레이드.
  • 지연 시간 감소: 복제본 세트 멤버가 가까운 거리에 있는지 확인합니다(예: 동일한 데이터 센터 또는 클라우드 영역).
  • 방화벽/보안 그룹 확인: 병목 현상이나 패킷 손실을 유발하는 규칙이 없는지 확인합니다.
  • 전용 네트워크: 가능한 경우 복제 트래픽에 전용 네트워크 인터페이스 사용 고려.

3. 보조 리소스 확장

  • 하드웨어 업그레이드: 보조 멤버의 CPU 코어, RAM, 특히 디스크 I/O(예: SSD 사용 또는 클라우드 환경에서 프로비저닝된 IOPS)를 늘립니다.
  • 디스크 큐 길이 모니터링: 높은 큐 길이는 I/O 병목 현상을 나타냅니다. 여기서는 디스크 성능 업그레이드가 중요합니다.

4. 쿼리 및 인덱스 최적화

  • 필요한 인덱스 생성: 기본 멤버에 있는 모든 인덱스가 모든 복제본 세트 멤버에도 있는지 확인합니다. 보조 멤버에 인덱스가 누락되면 oplog 적용 성능이 심각하게 저하될 수 있습니다.
  • 쓰기 작업 최적화: 대규모 일괄 작업을 더 작고 관리 가능한 청크로 분할하여 oplog 급증을 줄입니다. 처리량을 높이기 위해 ordered: false와 함께 bulkWrite를 사용하지만 오류 처리에 유의하십시오.
  • 백그라운드 인덱스 빌드: 인덱스 생성 중 쓰기 작업을 차단하지 않도록 createIndex({<field>: 1}, {background: true}) (4.2+에서 사용 중단, 기본값은 백그라운드) 또는 db.collection.createIndexes()를 사용합니다. 특히 보조 멤버에서 중요합니다.

5. 쓰기 고려 사항 및 읽기 선호도 조정

  • 쓰기 고려 사항: w:1(기본값, 기본 멤버 승인)은 빠르지만, w:majority는 승인 전에 쓰기가 과반수 노드에 적용되도록 보장합니다. 이는 기본 멤버가 기다리도록 강제하여 잠재적 지연을 본질적으로 줄이지만 쓰기 지연 시간이 증가합니다. 내구성 요구 사항에 따라 조정합니다.
  • 읽기 선호도: 일관성이 중요한 읽기의 경우 primary 읽기 선호도를 사용합니다. 최종 일관성 읽기의 경우 secondaryPreferred 또는 secondary를 사용합니다. 보조 멤버가 자주 지연되는 경우 모든 읽기에 secondary를 사용하지 마십시오. 너무 오래된 데이터를 제공할 수 있기 때문입니다. 과도하게 오래된 읽기를 방지하기 위해 maxStalenessSeconds가 적절하게 설정되었는지 확인합니다.

6. 로드 밸런싱 및 읽기 분산

  • 집중적인 읽기가 보조 멤버에서 지연을 유발하는 경우, 클러스터를 샤딩하여 더 많은 노드로 부하를 분산하거나, 복제 전용 보조 멤버를 전담하도록 고려합니다(읽기 없음).
  • maxStalenessSeconds를 존중하면서 사용 가능한 보조 멤버에 읽기를 균등하게 분산하기 위해 적절한 로드 밸런싱을 구현합니다.

7. 모니터링 및 알림

복제본 세트에 대한 강력한 모니터링을 구현합니다. 다음 항목에 대한 경고를 설정합니다:

  • 높은 복제 지연: 임계값은 애플리케이션의 오래된 데이터 허용 오차를 기반으로 구성해야 합니다.
  • 리소스 사용률: 모든 멤버의 CPU, RAM, 디스크 I/O.
  • Oplog 창: oplog 창이 너무 많이 축소되면 경고.

지연 방지를 위한 모범 사례

사전 예방 조치가 사후 대응보다 항상 낫습니다:

  • 적절한 크기 조정: 모든 복제본 세트 멤버, 특히 보조 멤버에 충분한 하드웨어 리소스(CPU, RAM, 빠른 I/O)를 할당하여 피크 쓰기 작업을 따라잡을 수 있도록 합니다.
  • 일관된 인덱싱: 모든 복제본 세트 멤버에 필요한 모든 인덱스가 있는지 확인하는 전략을 개발합니다. 보조 멤버에 먼저 인덱스를 빌드하기 위해 replicaSet 인식을 사용합니다(해당하는 경우).
  • 네트워크 최적화: 복제본 세트 멤버 간에 낮은 지연 시간과 높은 대역폭의 네트워크를 유지합니다.
  • 정기 모니터링: 전용 도구를 사용하여 복제 지연 및 리소스 사용률을 지속적으로 모니터링합니다.
  • 쓰기 작업 조정: 보조 멤버를 압도하는 대규모의 급증 작업이 발생하지 않도록 애플리케이션 수준 쓰기를 최적화합니다.
  • 정기 유지 관리: 컬렉션 최적화(WiredTiger에서는 덜 일반적이지만)와 같은 정기적인 데이터베이스 유지 관리를 수행하고 소프트웨어가 최신 상태인지 확인합니다.

결론

복제 지연은 MongoDB 복제본 세트에서 흔히 발생하는 운영상의 문제이지만, 적절한 진단과 수정 조치를 통해 관리할 수 있습니다. oplog의 역할을 이해하고, 복제본 세트의 상태를 적극적으로 모니터링하며, 불충분한 oplog 크기, 리소스 제약, 최적화되지 않은 작업과 같은 일반적인 원인을 해결함으로써 MongoDB 배포가 고가용성, 성능 및 일관성을 유지하도록 할 수 있습니다. 사전 예방적 모니터링과 모범 사례 준수는 지연을 방지하고 강력한 데이터 인프라를 유지하는 데 핵심입니다.