글 : 맨텍 OM사업본부 이진현 이사

2회. 100% 복구 가능한 재해복구 시스템을 어떻게 갖출 것인가

하지만 제아무리 완벽한 시스템이라 할지라도 장애나 재해로 인한 서비스 중단의 위험요소는 늘 존재하며, 이는 운영자에게 있어 큰 스트레스로 작용한다.

따라서 장애나 재해로 인한 전산 서비스 중단은 발생 가능성을 열어 둘 수밖에 없고 이러한 최악의 상황 발생 시 완벽에 가까운 복구를 어떻게 할 것인가에 대해서 체계적인 프로세스를 정립해야만 한다.

복구를 위해 가장 먼저 고려해야 할 사항

먼저 각 업무별로 서비스 중단을 감내할 수 있는 시간을 정의해야 하는데, 이를 RTO(Recovery Time Objective)라고 칭한다. RTO가 규정으로 정해져 있는 기관들도 있지만 그렇지 못한 기업이나 기관들은 업무 중단에 따른 손실 비용과 기업의 연속성에 어떠한 영향을 끼칠지 감안해 이를 설정해야 한다.

각 업무별 RTO에 대한 정의가 끝나면 이와 연관된 IT 자원들이 어떻게 구성돼 있으며, 이에 대한 각 요소들의 복구 절차와 RTO에 대한 정의가 필요하다.

RTO에 대한 정의가 완료되면, 복구 시점에 대해 정의해야 한다. 이를 RPO(Recovery Point Objective)라고 한다. 복구할 데이터의 중요도에 따라 RPO는 바로 재해 직전, 1시간, 3시간, 하루, 일주일, 한 달 등 다양한 시점이 나올 수 있다. RPO=0이 가장 이상적이겠지만 문제는 비용이다.

이는 솔루션에 대한 비용 뿐만 아니라 운영센터와 재해복구센터 간 데이터를 손실 없이 실시간으로 동기화하기 위해 필요한 큰 네트워크 대역폭으로 인해 발생하는 과도한 회선 비용, 네트워크 장비 등에 대한 유지비용을 불러오기 때문이다.

따라서 업무와 데이터의 중요도에 따라 RPO를 정의해야 한다. 예를 들어 금융업무라고 해도 모두 수시간 내의 RTO와 0에 가까운 RPO를 설정할 필요가 없다.

계정계와 같은 단 하나의 트랜잭션이 1조 원의 가치를 증빙할 수 있는 업무나 데이터의 경우에는 완전 무중단과 무손실의 복구 체계를 갖춰야 하겠지만 사내 업무 공유를 위한 포털의 경우는 좀 더 느슨한 RTO와 RPO를 설정할 수도 있을 것이다. 이러한 RTO와 RPO의 설정이 마무리되면 이를 충족할 수 있는 백업 및 복구 솔루션은 자연스럽게 매칭이 된다.

복구 순서, 변경관리 그리고 복구 테스트의 중요성

2010년대 초반, 금융권과 언론사에서 해킹으로 인한 재해가 발생하였는데 재해복구 센터가 작동되지 않은 사건들이 있었다. 또한, 외국계 모 금융기관은 재해복구 센터를 가동하는데 성공은 했지만 금감원의 권고사항인 RTO 3시간 이내를 준수하지 못했었다.

이로 인해 재해복구 무용론이 대두되었는데, 그 이유들을 살펴보면 100% 재해복구 센터가 제 기능을 발휘하지 못하였기 때문이다(20여 년간 이 분야에 종사하면서 부끄럽게도 재해복구 센터가 아주 매끄럽게 작동되는 경우는 거의 못 본 것 같다). 제 기능을 발휘하지 못한 원인들은 많겠지만 대표적인 원인들을 꼽자면 세 가지로 축약된다.

첫째, 복구 순서를 제대로 인지하지 못한다.

좀 황당하게 들릴 수도 있겠지만 엄연한 사실이다. 가상화와 클라우드로 인해 IT 자원이 무한에 가깝게 수 분내로 생성이 가능한 세상이다. 관리자나 운영자가 인지하기도 전에 이러한 자원들이 마구 생성된다.

또한 시간과 장소에 제한없이 접속 가능한 모바일로 인해 애플리케이션의 라이프사이클이 단축되면서 거의 매일같이 버전이 바뀌고 있다. 그에 비해 복구 순서가 정의된 복구 절차서는 이미 수년 전의 상태에서 업데이트되지 못한 채로 캐비닛에 보관돼 있다.

지난 십수년 간 거의 매일같이 변화를 겪어온 IT의 인프라의 장애나 재해를 복구하기엔 복구 절차서가 너무 오랜 세월이 지나 버렸다. 게다가 조직의 인원 또한 수시로 변경됨에 따라 이러한 상황을 인지하지 못하는 경우가 허다하다. 그 누가 자신이 운영 부서로 부임되고 나서 재해가 발생하게 될 거라고 상상이나 하겠는가?

둘째, 변경 관리가 쉽지 않다. 앞서 언급된 오래된 복구절차서와 일맥 상통하는 내용이다. IT 인프라가 최초 구축될 당시의 형태를 수년간 유지하면서 운영되는 조직은 없을 것이다.

자원들의 추가, 폐기, 변경, 업데이트 등 거의 매일같이 발생하는 변경사항은 재해복구 센터에도 동일하게 적용돼야 한다. 그러나 시간이 지날수록 운영센터와 재해복구센터 간 환경 차이는 점점 커져가고 복구를 해야 할 시점에서 실시간으로 복제된 데이터가 아주 오래된 애플리케이션에서 인식을 못 하는 사태가 부지기수로 발생되고 있다.

셋째, 제대로 된 복구 테스트를 하지 못한다.

백업 솔루션을 도입하는 이유가 무엇이냐고 물어보면, 10명 중 9명은 데이터 백업을 위해서 도입한다고 대답한다. 틀린 대답이다. 목적은 복구를 위한 것이고 백업은 이를 위한 과정일 뿐이다.

그런데 이를 공급하는 솔루션 벤더들은 대부분 백업에 대해서 이야기하지 복구에 대해서는 거의 언급하지 않는다. 또한 이러한 솔루션들은 백업에 대해서는 자동으로 스케줄을 걸어놓고 수행을 하는데 반해 복구는 100% 수작업으로 진행한다.

이러한 불편함 때문에 복구를 위한 테스트를 제대로 하기 쉽지 않다. 사실 복구 테스트를 한 달에 한 번 주기적으로 제대로 진행을 한다면 첫번째와 두번째에서 언급됐던 복구 리스크를 쉽게 찾아내고 보완할 수 있다. 하지만 이에 대한 테스트를 제대로 진행하지 못하는 관계로 재해복구는 무용지물이 되어 버리고 큰 IT 재해 때만 반짝 관심을 보였다가 사그라지는 현상이 계속 반복되고 있다.

이제 백업과 복제에만 기울여왔던 관심을 ‘복구’로 돌려야 한다. 제대로 된 복구를 위해서 어떻게 해야 할지에 대한 프로세스를 정립하고 이를 실천해야 한다.

우리의 모든 일상생활이 디지털로 전환되어가고 있기 때문이다. 데이터 센터의 단순 화재가 열흘 넘는 복구 지연으로 수많은 영세 자영업자에게 매출 중단이라는 눈물을 안겨서야 되겠는가.

IT 운영의 가장 기본인 백업과 복구가 되지 않는 것으로 인해 IT 강국에 오점을 남기지는 말아야 하겠다.