클라우드 스냅샷… 마법인가, 아니면 도구 상자의 또 다른 도구인가?

얼마 전에 클라우드의 재해 복구 및 비즈니스 연속성 계획(DR / BCP)에 대해 설명하는 프레젠테이션에 참석했는데, 거의 8시간이 소요되는 멀티 테라바이트 데이터베이스의 백업과 단 8초밖에 걸리지 않은 스냅샷을 비교한 통계가 발표되었습니다. “물리학 법칙을 거스르는 이 스냅샷 마법은 무엇이지?"라고 생각했습니다. 그래서 스냅샷의 작동 방식을 정확히 알아내기 위해 조사해 보았습니다.

백업 대 스냅샷 – 개괄적 개요

이미 알고 있듯이, 백업은 READ 작업 이후 다른 위치로 후속 WRITE 작업을 수행하여 읽은 내용의 두 번째 사본을 만드는 작업입니다. 이 두 번째 사본은 다른 디스크/테이프에 있거나 다른 데이터 센터/클라우드 환경의 객체 스토어에 있을 수 있습니다. 백업은 복사하는 동안 변경되는 것을 방지하기 위해 READ 중인 모든 항목에 대해 배타적 잠금을 설정해야 합니다. 쓰기를 중단할 필요가 없는 "온라인 백업"을 수행하는 옵션이 있지만 성능 면에서 몇 가지 고려해야 할 사항이 있습니다.

반면에 스냅샷은 특정 시점의 전체 디스크 볼륨에 대한 정확한 block-for-block 사본입니다. 이 작업은 백업과 같은 애플리케이션(또는 OS) 수준이 아닌 디스크/하드웨어 수준에서 발생하므로 어느 정도는 훨씬 빠르고 훨씬 침해가 덜합니다. 여전히 스냅샷 중인 디스크를 정지하고 모든 메모리 버퍼를 플러시해야 하지만, 전체 READ 작업 기간 동안 백업에 필요한 배타적 잠금보다는 기간이 훨씬 짧습니다. 이를 설명하기 위해 위에서 언급한 8시간 대 8초의 예를 좀 더 자세히 살펴보겠습니다.

8시간 대 8초 – 무엇을 얻을 수 있나요?

8시간의 백업이 완료되면 다른 위치에 백업의 소스였던 모든 사본이 생성됩니다. 데이터베이스의 경우 백업을 활용하려면 데이터베이스 인스턴스로 백업을 복원해야 합니다.

8초 정도 후에 클라우드 스냅샷이 완료되면 변경된 모든 블록이 표시되어 나중에 추가로 처리하기 위해 객체 스토어에 "lazy copy"할 수 있습니다. 여기서 중요한 점은 아직 데이터 사본을 보유하고 있지 않다는 것입니다! 스냅샷을 "표시"하는 블록만 있는 상태입니다. 이 스냅샷 단계에서는 모든 노드에서 데이터베이스의 무결성을 보장하기 위해 모든 데이터베이스 활동을 중지해야 합니다. 즉, 모든 읽기 및 쓰기가 "TPASUSPEND" 명령을 통해 일시 중단되어야 합니다. 볼륨의 블록 수에 따라 몇 초 또는 몇 분이 소요될 수 있는 표시 작업이 완료되면 데이터베이스 작업을 재개할 수 있습니다. 후속 READ 작업은 방해 받지 않고 계속되지만 WRITE 작업이 복사 예정으로 표시된 블록을 변경하려고 시도하는 경우, 쓰기 작업이 처리되기 전에 스냅샷 프로세스에서 블록의 사본을 만들어야 합니다(Copy-on-Write 참조). WRITE 작업량이 많은 시스템의 경우, 쓰기가 발생하기 전에 각 블록의 사본을 만들어야 하므로 작업부하의 성능에 영향을 줄 수 있습니다. 일괄처리 로드 창과 같이 쓰기 활동이 많은 기간에 스냅샷을 예약하여 이러한 영향을 완화하는 방법이 있습니다.

스냅샷 완료... 하지만 아직 끝나지 않았습니다!

스냅샷용으로 표시된 블록이 클라우드 공급업체에 의해 객체 스토어로 복사되는 동안 스냅샷은 "처리 중"으로 표시됩니다. 여기서 강조하고 싶은 것은 이전에 언급했듯이 표시된 블록은 “lazy copy”된다는 것입니다. 즉, Cloud Snapshot 프로세스의 이 단계에서 모든 블록을 객체 스토어로 복사하는 데 걸리는 시간은 SLA를 충족하지 않습니다. 이는 사용 가능한 리소스를 기반으로 백그라운드에서 발생하며 데이터 소유자가 제어할 수 있는 것이 아닙니다.

"완료"로 표시되면 이제 소스와 동일한 리전에 있는 객체 스토어, Cloud Snapshot에 귀하의 사본이 생성됩니다. 따라서 아직 재난 상황에서는 보호받지 못합니다. 이제 객체 스토어에서 스냅샷을 가급적이면 다른 클라우드 리전으로 복사해야 합니다.

복구를 위해 스냅샷을 사용하려면 원래 스냅샷이 생성된 것과 동일한 구성으로 정확히 동일한 양의 스토리지를 할당한 다음 스냅샷 블록을 새 스토리지 볼륨으로 “re-hydrate” 해야 합니다. 스냅샷은 스토리지의 특정 시점에 대한 사본이므로, 12시간마다 스냅샷을 만들고 마지막 4개의 스냅샷을 보관하는 경우, 보관한 4개의 스냅샷 기간 중 하나로 다시 복구할 수 있습니다. DR 목적으로 사용하는 경우 대부분 가장 최근의 스냅샷을 복원하지만, 백업과 매우 유사한 유연성이 있다는 것을 참고하세요.

결론

원래 질문인 "마법인가, 아니면 도구 상자의 또 다른 도구인가?"로 돌아가 봅시다. 일반적으로 스냅샷은 컴퓨팅 노드에 연결된 스토리지의 전체 사본을 만드는 좋은 방법입니다. 데이터베이스 엔진을 통한 동일한 백업 작업에 비해 빠르며 작업부하에 미치는 영향이 상대적으로 미미합니다. 그러나 스냅샷은 마법이 아닙니다! 스냅샷은 동일한 클라우드 리전에 있든 완전히 다른 리전에 있든, 동일한 시스템에 스토리지를 복사하고 복원할 수 있는 다른 방법일 뿐입니다. 백업과 비교했을 때 스냅샷의 단점은 객체 수준 복구 기능이 없다는 것입니다. 가치가 높은 하나의 객체가 손상된 경우, 백업에서는 해당 객체만 복원할 수 있지만 스냅샷에서는 가능하지 않습니다. 또 다른 단점은 백업에서는 원하는 경우 크기가 다른 시스템으로 복원할 수 있지만, 스냅샷의 경우 복구할 시스템은 원래 시스템과 크기 및 구성이 동일해야 합니다. 결론은 단순히 시간만 비교하는 "8시간 대 8초"로 스냅샷을 혼동하지 마십시오. 스냅샷을 통해 데이터베이스 사본을 만드는 데는 시간이 덜 걸리지만, 재해로부터 완전히 보호하는 데는 8초 이상 걸릴 것입니다.