“온프레미스-서드파티-클라우드” 재해복구 구축 방법과 장단점 비교

재해 복구(disaster recovery, DR) 계획을 세울 때 기업이 첫 번째로 내려야 할 결정은 가장 중요한 데이터센터에 재난이 닥쳤을 때 어디에서 운영을 재개할 것인가다. 수 년 간 기업의 사이버 복구 계획을 도운 필자의 경험에 따르면, 기업의 재해 복구 사이트 선택지는 크게 3가지다. 각 선택지의 장단점, 비용과 위험을 살펴보자.
 

 

기업이 자체 재해 복구 사이트를 구축하기

첫 번째 선택지는 현재 주 사이트와 떨어진 다른 장소에 자체적인 보조 재해 복구 데이터센터를 세우는 것이다. 많은 대기업이 이 방법을 선택한다. 프로덕션 환경의 데이터를 그대로 반영하는 재해 복구 인프라를 구축하기 때문에 '이론적으로는' 재해가 발생해도 즉시 전환해 서비스를 계속할 수 있다.

이 방법의 장점은 운영 제어권에 있다. 기업이 하드웨어를 소유, 운영하기 때문에 호환성, 용량, 보안 제어 등 모든 면을 관장하고, 다른 서드파티 업체에 의존하지 않는다. 단점은 비용이다. 평소에는 유휴 상태로 있을 뿐이지만, 이렇게 중복된 인프라를 운영하는 비용은 절대 저렴하지 않다. 기업은 여벌의 보조 서버, 스토리지, 네트워킹 장비 등을 모두 구매하고 설치, 유지해야 한다. 부동산과 전력, 냉각 등 데이터센터의 모든 요소에서 중복 비용이 발생한다.

뿐만 아니라, 재해 복구 사이트는 전체 규모의 복제본이기 때문에, 프로덕션 환경에서 하드웨어를 추가하거나 변경할 때마다 재해 복구 환경에도 똑같은 바꿔야 한다. 재해 복구 사이트를 유지하는 것은 마치 아무도 사용하지 않는 수영장을 운영하는 것과 같다. 꾸준히 수질을 깨끗하게 유지하고 관리하며 주변 풀도 제거해야 한다. 운영 자원이 바쁘게 돌아가면서도 구체적인 일상적 가치는 거의 없는 작업이라고 할 수 있다.

자체 구축의 위험은 시간이 지나면서 재해 복구 사이트가 뒷전으로 밀린다는 것이다. 프로덕션 환경에 맞춰 변경해야 할 작업이 쌓이고, 설정이 여러 차례 변경된 상태에서, 어느 날 갑자기 재난 사고가 일어나면, 기대와 달리 복구 프로세스가 즉각 작동하지 않을 수 있다. 기업엔 진짜 재앙 같은 현실이다. 이런 일을 방지하려면 주 데이터센터와 재해 복구 사이트 모두를 동기화하는 꼼꼼한 규칙이 필요하다. 물론 정기적인 재해 복구 테스트는 필수다.
 

서드파티 재해 복구 서비스 이용하기

두 번째 방법은 외부의 재해 복구 서비스 업체를 선택해 기업 대신 복구 사이트를 구축, 관리하게 하는 것이다. 선가드(SunGard) 같은 업체가 이런 사업을 하고 있다. 이 방법의 장점은 기업이 재해 복구에 대한 책임에서 벗어난다는 것이다. 기업이 자체적으로 인프라를 구축하지 않고도, 업체와 함께 기본적인 재해 복구 데이터센터 역량을 보유할 수 있다.

선가드 등의 여러 업체는 클라이언트 인프라와 데이터를 호스팅할 목적으로 만들어진 대형 복구 사이트를 구축하고 운영한다. 재해가 일어나면 서비스 업체는 바로 시스템을 복원하고 운영을 재개할 준비를 한다. 비용은 보통 기업이 자체적으로 재해 복구 시설을 관리하는 것보다 저렴하다. 서비스 업체가 클라이언트 기반을 공유하며 자원을 최대화하기 때문이다.

그러나 이 방법에도 위험은 있다. 가장 큰 함정은 이 모델에 내재된 ‘공유’라는 단어에 있다. 대형 재해가 광범위한 지역에 타격을 입히면, 여러 기업이 같은 재해 복구 자원을 두고 동시에 경쟁을 벌일 수 있기 때문이다. 공급업체가 수요를 과소평가하거나 용량을 실제 역량 이상으로 할당했다면 복구 품질이 저하될 수밖에 없다. 테스트 작업은 공유 하드웨어를 사용해도 잘 돌아가지만, 실제 복구 작업에는 프로덕션과 유사한 설정이 필요할 확률이 높다. 따라서 서비스 업체가 유연성과 맞춤화를 아무리 강조하더라도 기업이 특별하거나 독특한 환경을 요구할 경우 복구 성능이 저하될 수 있다.
 

퍼블릭 클라우드로 복구하기

기업이 재해 복구 인프라를 구축할 때 세 번째 선택지는 퍼블릭 클라우드를 활용하는 것이다. AWS나 애저 같은 거대 업체는 재해 상황에서의 방대한 컴퓨팅 자원 요구를 충족할 만큼 확대할 수 있는 거의 무제한의 용량을 제공한다. 정상적 운영 때와 마찬가지로 복구 상황에서 기업에 필요한 연산 역량과 스토리지도 필요한 만큼 사용할 수 있다. 퍼블릭 클라우드의 기본 특징인 확장성은 기존 재해복구 업체의 ‘과도한 요금제 위험’으로부터의 보호를 제공한다. 매우 드물게 리전 단위의 대규모 서비스 중단이 발생하는 경우가 아니라면, 클라우드 업체는 클라이언트 자원 요구치가 급등하는 순간에도 대응할 수 있는 여분의 스토리지를 보유하고 있다.

비용과 소비가 유연하다는 것도 이 방식의 장점이다. 기업은 테스트나 실제 복구 상황에 쓰인 클라우드 인프라만큼만 비용을 내면 된다. 그저 백업을 복사하기만 하는 정상 상황의 ‘재해 복구 유휴’ 모드에서는 비용이 최소화된다. 기존 공급 업체와 달리, 클라우드의 용량은 정확히 기업의 요구 사항에 맞춰 늘어나고 줄어든다. 언젠가 필요할지도 모르는 용량까지 예측할 필요가 없는 것이다.

이 방식에서는 재해 복구 테스트를 더 엄격하고 정기적으로 수행할 수 있다. 클라우드 서버를 운영하는 것은 빠르고 경제적이므로, 비용이나 자원이 제한적인 테스트도 자유롭게 할 수 있다. 기업은 불필요한 비용을 내지 않고도 최신 백업 부팅을 빠르게 검증할 수 있다. 테스트 빈도가 개선되고 그 결과 전반적인 재해 복구 준비도 적절하게 이루어진다.

클라우드는 인프라 자동화와 스크립팅에도 적합하다. 기업은 코드로서인프라(IaaC) 기술을 지원하는 도구를 통해 서버 설정, 자원 프로비저닝 로직, 네트워크 토폴로지 등을 사전 정의할 수 있다. 재해 복구가 작동해야 하는 시점이 되면, 모든 클라우드 장비가 기업의 템플릿과 사전 설정에 기반해 거의 자동으로 실행된다. 수동 개입이 필요한 여지는 전혀 없다.
 

클라우드 기반 재해 복구의 함정

반면, 퍼블릭 클라우드에서의 복구 운영에도 몇 가지 위험이 있다. 다른 대안과 비교해 가장 분명한 단점은 항상 클라우드 공급업체의 데이터센터가 네트워크에 연결되어 있어야 한다는 점이다. 재해 영향으로 로컬 인터넷 연결이 중단되면 클라우드 액세스도 중지된다. 가끔 인터넷 연결을 이중화하는 경우도 있지만, 그렇지 않다면 재해가 발생할 때 클라우드 연결을 유지하기 위해 위성 네트워크 같은 다른 방식이 필요할 수도 있다. 이 경우 별도의 비용이 들고 설정하기가 다소 복잡할 수 있다.

또 다른 중요한 고려 사항은 클라우드 계정에서 미리 재해 복구 데이터의 복제본을 관리해야 한다는 것이다. 향후 필요할 때 프로덕션 서버를 실행하려면 꾸준히 백업 데이터와 가상머신(VM) 이미지를 클라우드 스토리지에 저장해 둘 필요가 있다. 이 모든 데이터를 구축하는 데 필요한 복제 소프트웨어, 네트워크 대역폭, 클라우드 스토리지는 무료가 아니다. 마지막 위험은 온프레미스에서 원활하게 실행되는 일부 애플리케이션과 데이터베이스가 클라우드 운영 환경에서는 문제를 일으킬 가능성이 있다는 점이다. 이런 설계상 결함을 미리 발견하려면 섬세한 시스템 테스트가 필요하다.
 

탄력성 있는 문화 도입하기

기업이 어떤 방법을 선택하든 종합적인 재해 복구 계획을 수립하는 데는 상당한 시간과 자원, 비용이 든다. 그러나 너무 몸을 사리고 자원을 아끼면, 비즈니스 자체에 치명적인 위험이 될 수 있다. 미국 연방재난관리청에 따르면, 소기업의 약 40%가 재해를 겪은 후 영구 폐업한다. 시스템을 복구할 수 없었기 때문이다.

회복력 있는 사이버 복구 프로그램을 설계하며 수 없이 많은 기업을 지원한 필자의 조언을 정리하면 다음과 같다. 종합적 대비란 종료 일자가 정해진 프로젝트가 아니다. 오히려 계속해서 끌고 가야할 뿌리 깊은 기업 철학에 더 가깝다. 재해 복구 기획 담당자를 지정하고, 장애 상황에서 어떻게 대비할 수 있는지 점검하라. 정책과 문서 절차를 명확하게 정의하고, 대응 확인과 테스트 루틴을 정해야 한다. 재해 대비에 들어가는 리소스를 위험과 불확실성으로 가득 찬 오늘날 기업을 계속 운영하는 데 필요한 표준 비용으로 생각해야 한다. 기업이 실제 재난이나 장애에 직면했을 때, 회복 탄력성에 중점을 둔 문화는 생존과 성공의 핵심 열쇠가 된다.
editor@itworld.co.kr