[칼럼] 재해복구 자동화를 통해 RTO 3시간을 충족 시키자

비지니스 연속성의 전략을 수립함에 있어서 빼놓을 수 없는 요소가 IT인프라에 대한 재해복구와 데이터 보호 체계를 마련하는 것입니다. 예기치 못한 IT서비스 중단이 이제 기업의 지속 가능성에 대해서도 영향을 끼칠 만큼 대부분의 기업 및 조직들은 전산시스템에 대한 장애나 재해에 대해서도 서비스 중단을 최소화한 데이터 보호와 재해복구 전략을 수립하여 이에 대한 복구 체계를 마련해 놓았습니다. 여기서 우리가 현재까지 구축한 재해복구 체계에 대해서 되짚어 볼 필요가 있습니다.
금융감독권에서 권고한 금융기관의 3시간 이내 RTO는 마치 공공 및 기업에 대해서도 서비스 재개를 완료 시켜야 하는 척도가 되어왔습니다. 또한 이 시간을 맞추기 위해 데이터의 복구 시점인 RPO또한 0 혹은 1시간 이내로 설정하고 이를 만족할 수 있는 솔루션, 스토리지, 네트워크 등의 인프라를 구축하였습니다. 막대한 예산을 투입하여 구축한 재해복구 체계가 SLA를 만족하며 정상적으로 운영이 되고 있을까요? 다음의 도전과제에 대해서 되짚어 보도록 하겠습니다.

– 재해복구 운영 메뉴얼과 지침을 모두 숙지하고 있는가?
– 복구를 위해 외부 파트너에게 의존해야 되지 않는가?
– 운영센터의 변경내역들이 복구센터에도 동일하게 적용되고 있는가?
– 재해복구 센터의 데이터와 애플리케이션들은 실제 가동 가능한 상태인지 어떻게 알 수 있는가?
– 재해 시 정말로 3시간 이내 업무 재개가 가능한가? (현 시점에서 금감원은 2시간으로 강화)

재해복구 센터의 운영 메뉴얼과 복구지침일반적으로 기업 혹은 조직내에서는 다양한 업무군이 존재합니다. 제조업을 예를 들어보면 하나의 제조기업의 전산인프라는 대표적으로 ERP, MES, SCM 의 업무군이 존재하고 이들은 상호 유기적으로 의존하며 운영이 됩니다. 또한 각 업무군의 정상가동을 위해서 여러 대의 서버, 스토리지, 네트워크, 애플리케이션 등의 자원들이 상호 의존하여 각 자원들의 장애와 성능저하는 다른 자원들에게 영향을 끼칠 수 있습니다. 단위업무의 ERP를 예를 들어보겠습니다. ERP업무를 운영하기 위해서는 데이터베이스, 애플리케이션, 스토리지, 네트워크, 보안시스템, 계정시스템 등의 여러 서버들과 자원들이 구동이 되어야 하며 이들은 순서에 맞게 또한 서로 의존성으로 연결되어 있습니다. 여기서 한 단계 더 들어가면 서버내에서 프로그램이 정상적으로 구동되기 위해서 서버내의 자원들 또한 구동순서와 의존성에 맞게 기동 되고 운영되어야 할 것입니다. 즉 한 기업의 전산인프라가 정상적인 기동과 운영을 하기위해서는 서버내의 자원들간, 서버들간, 업무들간 여러 복합적인 자원들의 구동순서, 의존성, 상호 영향도 등을 모두 알고 있고 그 계층 연결도를 꿰뚫고 있어야 할 것입니다. 재해 발생시 이러한 모든 내용을 숙지하고 복구 메뉴얼의 지침서에 근거하여 복구를 하기 란 큰 조직일 수록 매우 어려운 작업이고 휴먼 에러를 피할 수 없습니다. 이러한 작업들을 단순화 하고 자동화 하기 위해서는 자동 스크립트를 작성하고 각 업무 태스크별로 스크립트를 실행하여 복구 워크플로우를 자동화 할 수 있습니다. 그리고 많은 기업들과 조직들이 실질적으로 스크립트 기반의 워크플로우를 운영하고 있습니다. 그러나 스크립트 기반의 워크플로우는 다음의 취약점이 존재하고 이를 보완해 나갈 필요가 있습니다.

• 가시성 : 각 자원간 계층구조와 상호 영향도를 가시적으로 볼 수 없으며, 복구 과정의 현대 단계 또한 한눈으로 파악하기 힘들다.
• 운영성 : 스크립트 자체가 Text기반이며, 복잡하며, 개발 및 관리가 어렵습니다.
• 연동성 : 단위 업무의 복구를 위해서 서로 다른 벤더 간의 스토리지, 서버, 응용프로그램, 네트워크 등의 자원들이 조합이 됩니다. 각 자원들간 구동을 위한 자동화 스크립트를 작성하고 실행하는 구조가 조금씩 다릅니다. 따라서 상호 자원간 연동성을 일일이 확인하고 호환성을 맞추기간 여간 쉽지 않으며, 항상 전문인력의 수급이 필요합니다.

재해복구센터 운영의 인력 유지위에서도 언급하였듯이 하나의 단위업무를 구동하기 위해서 여러 자원들이 상호 연동되어 실행이 되고 서로간 계층적 구조와 의존성을 가지고 있습니다. 그리고 IT인프라가 오픈 분산 환경으로 바뀌면서 이제 더 이상 단일 제조사로부터 자원들이 공급되지 않고 있습니다. 즉, 여러 이기종의 제조사로부터 공급된 자원들이 상호 연동되어 하나의 단위 업무를 구동 시키는 구조입니다. 여기서 운영 인력의 교육과 스킬 셋에 대한 전문성을 짚고 넘어가지 않을 수 없습니다. 모든 운영 인력들이 다양한 자원들에 대한 전문성을 확보하기는 불가능에 가깝습니다. 따라서 재해로 인한 업무 복구를 각 해당 자원들에 대한 전문 공급사나 파트너의 지원에 의존할 수 밖에 없는 구조입니다. 따라서 복구의 모든 과정을 단순화하고 자동화할 필요가 있습니다.

변경관리초기 재해복구 센터 구축을 완료하고 모의훈련 등을 통해 재해복구 센터를 가동해 보면 대부분 정상적으로 업무수행이 진행됩니다. 그러나 시간이 지날 수록 재해복구 센터의 업무들이 원활하게 구동되지 않는 경우가 많은데, 그 대표적인 이유는 아래와 같습니다.

• 운영센터의 OS, 애플리케이션 등의 패치와 업그레이드가 진행되었으나 재해복구 센터에는 반영되지 않음
• 스토리지, 네트워크 구조 및 환경이 바뀌었는데 재해복구 센터에 반영되지 않음
• 데이터가 out of sync 상태
• 신규 추가된 업무와 자원들이 재해복구 센터에 적용되지 않음

위 사항들 이외 여러가지 이유로 재해복구 센터가 정상가동 되지 못하는 사례들이 점점 증가되고 있습니다. 따라서 변경에 대한 추적, 상태 동기화, 최신의 데이터 유지 등에 대한 모니터링이 필요하고 잦은 모의훈련을 통해 복구 위험도를 조기 발견하고 목표 RTO와 RPO를 만족하는지 상시 점검할 수 있는 체계가 필요합니다.

RTO 3시간을 충족 할 수 있는가?

재해복구를 수행하는 단계는 아래와 같습니다.
1. 재해감지
2. 운영센터의 복구가능성 판단
3. 재해복구 센터 가동 결정
4. 각 자원들에 대한 제조사의 전문 엔지니어 섭외
5. 복구지침서에 따른 워크플로우 리뷰
6. 자원 및 업무간 계층구조에 따른 스토리지, 네트워크, 서버, 애플리케이션 기동
7. 재해복구 센터로 접속하여 업무 가용성 체크
8. 재해복구 센터로 업무 전이 완료

현실적인 관점에서 보았을 때 큰 조직일 수록 위의 워크플로우를 3시간 이내 수행하기란 쉬워 보이지 않습니다. 실제적으로 과거 모 금융사의 해킹, 화재 등의 재난이 발생하였을 시 업무 정상화까지 한달 혹은 2주 이상의 시간들이 소요되었음을 경험하였듯이 단 한대의 단위 서버로만 업무가 구동되는 구조가 아닌 이상 수 많은 자원들로 집합된 금융, 공공, 통신, 제조업 등의 업무들을 수 시간내에 복구를 하기 위해서는 자동화된 워크플로우를 마련해야 합니다.

재해복구 운영관리 자동화를 위한 요구사항 증대

위에 언급하였듯이 수많은 기업과 조직들이 수년 혹은 십 여년간 재해복구 센터를 구축하여 운영하는 과정에서 여러 위험요소들에 직면하게 되었습니다. 따라서 이런 직면한 도전과제에 대한 극복을 위해 재해복구 구축과 더불어 운영 관리적인 측면에서 다음의 솔루션의 구축이 뒤따라야 할 것입니다.
• 워크플로우 자동화
• 복구과정의 가시화
• SLA 준수사항 모니터링

맨텍의 MDRM (Mantech Disaster Recovery Maestro)

MDRM은 GUI기반의 워크플로우 엔진을 통하여 가시적인 복구 계획을 손쉽게 정의할 수 있습니다. 또한 재해복구센터에서 서비스 기동을 위한 모든 일련의 과정들을 자동화하여 원클릭으로 쉽고 빠르게 서비스 복구가 가능합니다.
MDRM의 주요 기능과 장점은 다음과 같습니다.
• 워크플로우 자동화를 통한 휴먼 에러 최소화
• 복구과정 가시화를 통한 관리 효율성 증대
• SLA 미 준수 사항의 조기 발견과 이로 인한 복구 실패 미연에 방지
• 운영인력의 스킬 셋 격차없이 표준화된 재해복구 운영관리 가능

MDRM의 아키텍처

MDRM은 100% 소프트웨어로 구성되어 있으며, 맨텍의 HADR제품인 MCCS뿐만 아니라 타사의 HADR제품과도 상호 연동이 가능하며, 재해복구 운영관리 자동화를 위해서 기 구축된 환경을 수정하거나 대규모의 하드웨어 인프라가 구축이 필요하지 않습니다. MDRM은 다음과 같은 컴포넌트로 구성됩니다.
• Disaster Recovery Agent (DRA) – Agent는 복구 대상이 되는 서버에 자동으로 설치가 되며, 서버내의 스토리지, 네트워크, 프로그램, 사용자 스크립트 등의 정상상태 감시와 이들 자원들의 자동화된 구동을 수행하는 역할을 담당합니다. 또한 서버내의 자원들이 구동 완료되는 시간 및 각 할당된 스토리지 볼륨 별 데이터 시점을 감시하여 RTO와 RPO의 준수사항에 대한 감시를 수행합니다.
• GAM (Global Availability Manager) – GAM은 웹기반의 통합관리 콘솔입니다. 맨텍의 HADR 솔루션인 MCCS Enterprise의 통합관리 콘솔인 GAM과 통합되어 운영관리가 가능하며, 기존 MCCS Enterprise에 추가적으로 DRM(Disaster Recovery Manager)항목이 더 추가됩니다. GAM을 통해서 워크플로우 생성, 모의훈련 생성, SLA 준수 모니터링 등의 전반적인 운영 관리 자동화를 수행하게 됩니다.

결론

재해복구센터는 데이터센터를 새롭게 구축하는 작업에 준하는 방대한 프로젝트입니다. 또한 자원의 사용율에 비하면 상당히 비용 소모적일 수도 있습니다. 이렇게 막대한 비용을 투입하여 구축한 재해복구 센터가 결정적인 순간에 제역할을 담당하지 못하는 것만큼 큰 재해는 없습니다. 따라서 전반적으로 재해복구 센터의 운영 관리를 효율적으로 자동화할 수 있는 지휘자를 통해서만 목표한 재해복구 운영과 기동이 가능합니다.