백업 전략: 특정 시점 복구와 표준 스냅샷 이해하기

MongoDB 백업 전략은 하나의 어려운 질문으로 귀결됩니다: 얼마나 많은 데이터 손실을 감당할 수 있습니까? 표준 스냅샷은 저장된 시점으로 데이터베이스를 복원할 수 있는 반면, 특정 시점 복구는 잘못된 배포, 실수로 인한 삭제 또는 손상 이벤트 직전의 정확한 초 단위로 복원할 수 있습니다.

이 글에서는 MongoDB 스냅샷과 특정 시점 복구(PITR)를 비교하고, oplog가 어떻게 작용하는지, 샤드 클러스터에서 까다로운 점, 그리고 복구 시점 목표(RPO)와 복구 시간 목표(RTO)에 기반한 선택 방법을 설명합니다.

데이터베이스 백업의 중요성

구체적인 전략을 살펴보기 전에 데이터베이스 백업이 왜 필수적인지 다시 강조하는 것이 중요합니다:

재해 복구: 하드웨어 장애, 자연 재해 또는 전체 데이터 센터 중단으로부터 보호합니다.
데이터 손상: 논리적 오류, 실수로 인한 삭제 또는 데이터를 손상시키는 애플리케이션 버그로부터 복구합니다.
규정 준수: 많은 규제 요구 사항(예: GDPR, HIPAA, PCI DSS)이 데이터 백업 및 복구 기능을 의무화합니다.
감사 및 포렌식: 조사를 위해 데이터를 특정 상태로 복원할 수 있습니다.

표준 스냅샷 백업

표준 스냅샷 백업은 특정 시점의 데이터베이스 상태를 캡처합니다. 데이터 볼륨의 사진을 찍는 것과 같습니다. 간단해 보이지만, 구현과 효과는 MongoDB 배포 방식에 따라 크게 다릅니다.

표준 스냅샷 작동 방식

표준 스냅샷은 일반적으로 두 가지 주요 형태로 제공됩니다:

파일시스템 스냅샷: 기본 스토리지 시스템(예: LVM 스냅샷, AWS EBS 스냅샷, Azure 디스크 스냅샷, Google Persistent Disk 스냅샷과 같은 클라우드 제공업체 볼륨 스냅샷)에서 제공하는 볼륨 수준 스냅샷입니다. 전체 데이터 디렉토리의 COW(Copy-On-Write) 스냅샷을 생성합니다. 이 방법은 일반적으로 빠르고 효율적입니다.
- 프로세스:
  1. 쓰기 작업을 일시적으로 중지하거나(XFS xfs_freeze와 같이 스냅샷 중 일관성을 보장하는 파일시스템 사용) MongoDB의 경우 일반적으로 mongod 인스턴스에서 db.fsyncLock()을 실행하여 스냅샷 전에 모든 더티 페이지가 디스크에 플러시되도록 한 후 스냅샷 후 잠금을 해제합니다. 또는 복제 세트의 세컨더리 멤버에서 스냅샷을 생성합니다.
  2. 데이터 볼륨의 스냅샷을 생성합니다.
  3. db.fsyncUnlock()을 실행하거나 쓰기를 재개합니다.
- 복구: 스냅샷에서 전체 볼륨을 복원합니다.
논리적 백업(예: mongodump): mongodump는 데이터베이스 콘텐츠의 바이너리 내보내기를 생성하는 MongoDB 유틸리티입니다. 실행 중인 mongod 인스턴스에서 데이터를 읽고 BSON 파일에 씁니다.
- 프로세스:
  1. MongoDB 인스턴스에 대해 mongodump를 실행합니다. 데이터베이스나 컬렉션을 지정할 수 있습니다.

mongodump --host <호스트명> --port <포트> --out /path/to/backup/directory 2. 복제 세트의 경우 프라이머리에 미치는 영향을 최소화하기 위해 세컨더리 멤버에 대해 `mongodump`를 실행하는 것이 좋습니다. * **복구:** `mongorestore`를 사용하여 BSON 파일을 MongoDB 인스턴스로 가져옵니다. bash mongorestore --host <호스트명> --port <포트> /path/to/backup/directory ```

표준 스냅샷의 장점

단순성: 단일 인스턴스 또는 간단한 복제 세트에 대해 설정 및 관리가 더 쉽습니다.
속도(파일시스템 스냅샷의 경우): 볼륨 스냅샷은 생성 및 복원이 매우 빠른 경우가 많으며, 특히 전체 데이터베이스를 마지막 스냅샷 시점으로 신속하게 복구해야 하는 재해 복구에 유용합니다.
비용 효율성: 복잡한 PITR 솔루션에 비해 스토리지 및 관리 오버헤드 측면에서 일반적으로 저렴합니다.

표준 스냅샷의 단점

낮은 세분성: 스냅샷이 생성된 정확한 시점으로만 복구할 수 있습니다. 스냅샷 사이의 모든 데이터 변경 사항은 손실됩니다.
일관성 문제(샤드 클러스터): 샤드 클러스터 전체에서 일관된 파일시스템 스냅샷을 생성하는 것은 매우 어렵습니다. 각 샤드와 구성 서버를 동시에 일관되게 스냅샷해야 하며, 이는 특수 도구 없이는 거의 불가능합니다. 각 샤드 볼륨의 단순한 비조정 스냅샷은 복원 시 일관성 없는 클러스터 상태를 초래할 가능성이 높습니다.
성능 영향: mongodump는 데이터베이스에 상당한 부하를 줄 수 있으며, fsyncLock()은 쓰기를 일시적으로 차단하므로 처리량이 많은 프로덕션 프라이머리에는 적합하지 않습니다. 세컨더리에서 실행하는 것이 좋습니다.

표준 스냅샷 사용 사례

덜 중요한 데이터: 약간의 데이터 손실(예: 몇 시간 또는 하루 치)이 허용되는 애플리케이션.
개발/테스트 환경: 데이터 복사본을 빠르고 쉽게 생성하는 방법.
간단한 배포: 스냅샷에 대해 복제 세트 프로토콜 자체가 여러 노드 간의 일관성을 관리하는 독립 실행형 인스턴스 또는 복제 세트.

특정 시점 복구(PITR)

특정 시점 복구를 사용하면 정의된 백업 기간 내의 모든 특정 초 단위로 데이터베이스를 복원할 수 있습니다. 이는 최고 수준의 데이터 내구성을 제공하며 데이터 손실을 최소화해야 하는 미션 크리티컬 애플리케이션에 필수적입니다.

MongoDB에서 특정 시점 복구 작동 방식

MongoDB의 PITR은 두 가지 핵심 구성 요소에 의존합니다:

기본 백업(스냅샷): 표준 스냅샷과 유사하게 특정 시간에 생성된 전체 데이터 스냅샷입니다. 복구의 시작점 역할을 합니다.
Oplog(작업 로그): MongoDB의 oplog는 복제 세트의 프라이머리에 적용된 모든 쓰기 작업(삽입, 업데이트, 삭제)을 기록하는 특별한 고정 크기 컬렉션입니다. 모든 변경 사항의 지속적인 시간순 기록 역할을 합니다.

PITR을 수행하려면 먼저 기본 백업을 복원합니다. 그런 다음 기본 백업 시점부터 원하는 복구 시점까지 보관된 oplog 항목을 재생합니다. 이 프로세스는 해당 초에 데이터베이스 상태를 정확하게 재구성합니다.

// 예: 프라이머리에서 oplog 상태 확인
rs.printReplicationInfo()

// 또는 더 직접적으로
db.getReplicationInfo()

// oplog 컬렉션 통계 보기
db.getSiblingDB("local").oplog.rs.stats()

PITR 구현을 위한 주요 고려 사항

지속적인 Oplog 보관: PITR의 가장 어려운 측면은 oplog를 안정적이고 지속적으로 보관하는 것입니다. 일반적으로 다음이 필요합니다:
- 스트리밍 Oplog: 복제 세트의 세컨더리 멤버에서 oplog를 지속적으로 테일링합니다.
- 보관: 이러한 oplog 항목을 안전하고 내구성 있는 위치(예: S3, Azure Blob Storage)에 저장합니다.
샤드 클러스터 및 전역 일관성: 샤드 클러스터의 경우 PITR은 훨씬 더 복잡해집니다. 다음이 필요합니다:
- 모든 샤드와 구성 서버에서 기본 백업을 생성합니다.
- 모든 샤드 복제 세트와 구성 서버 복제 세트의 모든 프라이머리 멤버에서 oplog를 보관합니다.
- 복구 중에는 이러한 oplog를 전역적으로 일관된 방식으로 재생해야 하며, 모든 구성 요소에서 타임스탬프를 신중하게 조정해야 합니다. 수동으로 수행하는 것은 매우 어렵습니다.
도구: MongoDB Cloud Manager 및 MongoDB Ops Manager(온프레미스 배포용)와 같은 엔터프라이즈급 솔루션은 샤드 클러스터를 포함한 복잡한 MongoDB 토폴로지에 대한 PITR을 처리하도록 특별히 설계되었습니다. 기본 백업, oplog 보관 및 조정된 복구 프로세스를 자동화합니다.

특정 시점 복구의 장점

세분화된 복구: 모든 초 단위로 복원하여 데이터 손실을 최소화합니다.
최소 RPO: 매우 낮은 복구 시점 목표를 달성하여 중요 데이터에 필수적입니다.
전역 일관성(적절한 도구 사용): 복구 시점에 모든 샤드에서 샤드 클러스터 데이터가 일관되도록 보장합니다.
비즈니스 연속성: 엄격한 가동 시간 및 데이터 무결성 요구 사항이 있는 애플리케이션에 필수적입니다.

특정 시점 복구의 단점

복잡성: 특히 특수 도구 없이 샤드 클러스터를 설정, 관리 및 모니터링하는 것이 훨씬 더 복잡합니다.
스토리지 요구 사항: 기본 백업뿐만 아니라 지속적인 oplog 아카이브도 저장해야 하므로 상당한 스토리지 공간을 소비할 수 있습니다.
복구 시간(RTO): 많은 양의 oplog 항목을 재생하면 복구 시간 목표가 증가할 수 있지만, 데이터 손실이 최소화되므로 종종 허용됩니다.
비용: 특히 상용 도구를 사용하여 강력한 PITR 솔루션을 구현하고 관리하는 데 더 많은 비용이 들 수 있습니다.

특정 시점 복구 사용 사례

미션 크리티컬 애플리케이션: 금융 시스템, 전자상거래 플랫폼, 의료 애플리케이션 또는 몇 초의 데이터 손실도 허용되지 않는 모든 시스템.
규정 준수: 엄격한 데이터 보존 및 복구 규정을 충족합니다.
실수로 인한 데이터 삭제/손상: 사용자 오류 또는 데이터 손실이나 손상을 초래하는 애플리케이션 버그로부터 신속하게 복구합니다.

특정 시점 복구와 표준 스냅샷 비교

기능	표준 스냅샷 백업	특정 시점 복구(PITR)
복구 세분성	스냅샷이 생성된 정확한 시점	백업 기간 내의 특정 시점
RPO 목표	스냅샷 이후 변경 사항이 손실될 수 있으므로 더 높음	oplog 보관이 안정적이면 매우 낮음
복잡성	독립 실행형 배포 및 복제 세트의 경우 낮음~중간	높음, 특히 샤드 클러스터의 경우
데이터 일관성	스냅샷이 조정되면 양호, 조정 없이 샤드 클러스터의 경우 위험	백업 도구가 스냅샷과 oplog 재생을 올바르게 조정하는 경우에만 일관됨
복구 시간	스냅샷 시점으로 복원하는 것이 일반적으로 더 빠름	oplog 항목을 재생해야 하므로 더 오래 걸릴 수 있음
스토리지 요구 사항	기본 스냅샷	기본 스냅샷 + 지속적인 oplog 아카이브
비용	일반적으로 낮음	도구, 스토리지 및 관리로 인해 일반적으로 높음
최적 대상	덜 중요한 데이터, 간단한 배포	미션 크리티컬 애플리케이션, 엄격한 RPO 요구 사항

실용적인 고려 사항 및 모범 사례

선택한 전략에 관계없이 다음 모범 사례를 고려하십시오:

RPO 및 RTO 정의: 비즈니스가 감당할 수 있는 데이터 손실(RPO) 및 다운타임(RTO)을 명확히 정의하십시오. 이것이 백업 전략의 주요 동인입니다.
모든 것을 자동화: 수동 백업은 인적 오류가 발생하기 쉽습니다. 스냅샷 생성, oplog 보관 및 백업 검증을 자동화하십시오.
정기적으로 복원 테스트: 백업은 복원만큼만 가치가 있습니다. 정기적으로 전체 복원 테스트를 수행하여 백업이 유효하고 복구 프로세스가 예상대로 작동하는지 확인하십시오. 다른 환경으로 복원하는 등 다양한 시나리오를 테스트하십시오.
백업 보안: 저장 및 전송 중인 백업 데이터를 암호화하십시오. 백업 스토리지에 대한 액세스를 제한하고 적절한 인증을 보장하십시오.
오프사이트 스토리지: 지역 재해로부터 보호하기 위해 별도의 지리적 위치 또는 클라우드 리전에 백업을 저장하십시오.
모니터링 및 알림: 백업 작업 성공/실패, 스토리지 사용량 및 oplog 지연을 모니터링하십시오. 문제가 발생하면 알림을 설정하십시오.
용량 계획: 보존 정책을 고려하여 기본 데이터와 백업 모두에 충분한 스토리지가 있는지 확인하십시오.
클라우드 제공업체 기능 활용: 클라우드에서 MongoDB를 실행하는 경우 기본 클라우드 제공업체 스냅샷 기능을 활용하십시오. 이러한 기능은 종종 잘 통합되고 효율적입니다.

핵심 요점

허용 가능한 데이터 손실이 스냅샷 간격으로 측정되고 토폴로지가 복원을 자신 있게 수행할 수 있을 만큼 간단한 경우 스냅샷을 선택하십시오. RPO가 훨씬 더 엄격한 경우, 특히 실수로 인한 삭제나 잘못된 쓰기를 정확한 시점으로 복구할 수 있어야 하는 프로덕션 시스템의 경우 PITR을 선택하십시오. 어떤 경로를 선택하든 복원 테스트를 예약하고 사고 발생 시 필요하기 전에 정확한 단계를 문서화하십시오.