온프레미스 환경, 공용 데이터 센터(IaaS) 또는 클라우드 서비스 제공업체(CSP)에 관계없이 재해는 항상 발생하며 기술에 대한 의존도가 높아짐에 따라 비즈니스 데이터를 보호하기 위한 추가 조치를 취해야 합니다. 불행하게도 많은 조직은 재해 및 데이터 손실 후에야 적절한 재해 복구 솔루션을 돌아봅니다.
지난 10월, 한국은 대규모 서비스 중단 사태를 경험했습니다. 두 대기업 중, 한 곳은 기존 백업으로 인해 심각한 결과가 발생하진 않았으나 나머지 한 곳은 32,000개의 서버가 종료되고 다음날 12,000개만 복구되는 등 10시간의 다운타임을 겪었습니다. 이러한 서비스 중단은 며칠 동안 지속되었고 한국의 활성 사용자 중 4,300만 명에게 영향을 미쳤습니다.
그렇다면 이 기업은 어디에서부터 잘못이 됐을까요?
해당 기업은 포괄적인 비상 계획을 마련하지 않았기 때문에 모든 필수 데이터베이스를 단일 데이터 센터에 저장해왔습니다. 또한 자체 데이터 센터를 운영하지 않음으로써 비용을 절감하고자 했습니다. 애초에 재해 복구 계획의 부재와 유일한 백업본이 한 곳에 저장되어 있다는 사실만으로도 사상 최대 규모의 서버 중단을 초래하기에 충분했습니다.
재해 복구 모범 사례로 별도의 지리적 위치에 웜 대기 데이터베이스를 보유하는 것이 중요하다고권고할 수 있습니다. 이는 단일 클라우드 또는 데이터 센터 내의 중복성이 데이터 보안을 보장하지 않기 때문입니다. 기본 위치가 영향을 받는 경우 지리적 및 인프라 분리가 필요합니다. 백업은 복원하는 데 시간이 오래 걸리기 때문에 더 이상 백업에만 의존하지 않는 것을 권장합니다. 또한 철저하게 자주 테스트하지 않는 한 재해 발생 시 백업이 작동할지 여부도 알 수 없습니다. 기술적 도구를 갖추는 것만으로는 충분하지 않다는 것을 인식하는 것이 중요합니다. 재해복구 프로세스와 지속적인 유지 관리가 매우 중요합니다. 이것이 오늘날의 모범 사례에 따라 정기적으로 테스트되고 빠른 장애 복구/활성화가 가능한 최신 대기 환경이 필요한 이유입니다.
그렇다면 이와 같은 사건은 어떻게 예방할 수 있을까요?
잠재적인 매출을 놓치고 고객 및 시장에서 명성을 잃지 않으려면 대기 데이터베이스를 배포하고 정기적인 DR 테스트를 수행하는 것이 중요합니다. 제한 사항과 중요한 장애 지점을 이해하는 것이 첫 번째 단계입니다. 이는 다운타임이 발생한다는 사실을 인정하고 예측 가능한 모든 위험을 완화하는 강력한 솔루션을 개발해야 함을 의미합니다. 다행히 Standby Multi Platform 과 같은 소프트웨어 솔루션은 모든 재난으로부터 빠른 복구와 거의 제로에 가까운 데이터 손실을 보장할 수 있는 웜 대기 환경을 쉽고 효율적으로 만들 수 있습니다. 이러한 종류의 설정은 데이터베이스 관리의 비상 계획과 관련하여 최적의 표준이 되어야 합니다. 이와 같은 재해 복구 전략을 마련하면 예상치 못한 문제가 발생할 경우 데이터를 보다 쉽고 효율적으로 복구할 수 있습니다. 후회하는 것보다 안전한 것이 낫습니다.
