시스템 재해 복구를 위해 알아야 할 것들

IT 시스템과 인프라는 재해를 당하면 운영에 차질이 생긴다. 그러면 사용자들은 큰 불편을 겪고, 심할 경우 막대한 국가적 손실이 발생할 수 있다. 이 같은 피해를 방지하고 서비스 무중단을 위해 필요한 것이 바로 ‘재해 복구(Disaster Recovery)’이다. 재해 복구의 개념과 중요성에 대해 알아보자.

작년 10월 판교 데이터센터 화재로 국내 한 유명 메신저 앱이 먹통이 된 사례가 있었다. 사용자는 오후 3시30분부터 그 다음 날 아침 10시 30분까지 무려 19시간 동안 서비스 이용에 어려움을 겪었고, 모든 서비스가 정상화되기까지 127시간이 걸렸다. 이로 인해 시스템 복구와 사용자 손해 배상에 엄청난 비용이 투입됐을 것으로 추정된다.

당시 서비스 복구에 오랜 시간이 걸린 이유는 주요 데이터와 서비스 응용프로그램에 대한 이중화는 되어 있었지만, 개발자들의 주요 작업 및 운영 툴이 이중화 되어있지 않아 3만 2천 대에 달하는 서버를 일일이 수동으로 부팅해야 했기 때문인 것으로 확인됐다.

이 사태를 계기로, 해당 업체는 데이터센터 전체에 장애가 발생하더라도 모니터링과 장애 탐지 기능이 원활하게 작동하도록 모니터링 시스템을 다중화하고, 인프라 하드웨어 설비에서 서비스 애플리케이션에 이르는 전체 시스템 레이어에 다중화를 설계하고 구축해 나갈 방침이라고 밝혔다.

재해복구시스템의 운용

데이터센터는 늘 안전할 수 없다. 자연재해부터 인프라 장애, 사람의 실수에 의해 발생하는 데이터 삭제나 손실, 사이버 공격에 이르는 각종 위험으로부터 인프라를 예방 및 보호하고, 복구하는 재해 복구 기술을 강구해야 한다.

 

기술적인 관점에서 재해 복구의 핵심은 데이터 복구에 있다. 재해 복구를 위해서는 실시간으로 변경되는 데이터를 어떻게 실시간으로 동기화하는지가 관건이다.

 

데이터 동기화 방식으로는 서버에서 입출력(I/O) 쓰기 요청에 대해 원본과 복제본에 대한 쓰기가 완료된 후 하나의 I/O를 완료하는 싱크(Sync) 동기식 방식과, 원본 저장과 별개로 백그라운드에서 원격지 복제본으로 동기화하는 어싱크(Async) 비동기식 방식, 그리고 원본과 복제본을 구분하지 않고 어떤 볼륨이든 동시에 읽기와 쓰기를 지원하는 액티브-액티브(Active-Active) 미러링 방식이 있다.

 

또, 동기식과 비동기식 방식의 단점을 극복한 하이브리드 복제 방식도 있다. 이는 동시에 3곳의 데이터센터에서 데이터를 동기화하는 방식으로, 근거리는 동기식으로 이중화하고 원거리는 비동기식으로 운영하는 제3의 데이터센터를 두는 방식이다.

 

국내에서는 데이터센터 상당수가 주센터와 재해 복구 센터를 액티브-스탠바이(Active-Standby) 형태로 운영한다는 점이 문제점으로 지적된다. 액티브-스탠바이는 서버 2대를 각각 운영 서버와 장애 발생 시 대체해서 작동하는 방식을 말한다. 이는 재해 복구 센터에 주기적으로 백업하지만 데이터 정합성 등의 이슈로 인한 장애 발생 시 복구에 시간이 걸린다. 평상시에도 재해 복구 센터를 활용하는 액티브-액티브 구성을 활용하는 곳은 많지 않다. 운영 비용이 몇 배로 들기 때문이다.

 

재해 복구는 백업과 달리 단순히 과거의 데이터를 안전하게 보호하는 것이 아닌, 중단된 서비스를 재개하는 데 중점을 둔다. 이를 위해서는 운영되고 있는 실제 서비스와 거의 차이가 없는 실시간 데이터를 별도로 관리해야 하고, 본 서비스에 문제가 발생했을 때 예비 시스템으로 전환해 서비스 운영을 이어갈 수 있어야 한다. 재해 복구는 얼마나 빠르게, 얼마나 적은 데이터 손실로 서비스를 재개하느냐가 중요하다.

 

재해복구시스템의 평가 지표와 복구 계획

연중무휴로 가동돼야 하는 PC에서 100% 가동 시간을 보장하는 것은 쉽지 않다. 운영 측면에서 보면 시스템의 문제뿐만 아니라 자연재해, 전력 손실과 같은 물리적 재해에 대비하기 위한 계획도 필요하다.

 

가용성, 즉, 온라인 서비스 가동 시간 측정 시 나온 결과값에서 9의 개수에 따라 예정된 서비스 가동 중지 시간이 달라진다. 9가 많을수록 서비스 중단 시간은 감소한다. 예를 들어, 99%의 가용성은 일년에 중단 시간이 3.65일 이내가 되어야 하고 99.9%는 8.77시간, 99.99%는 52.60분 이내, 그리고 99.999%는 5.26분 이내로 가용성을 보장해야 한다.

 

재해 복구 계획을 수립할 때 결정해야 할 사항은 RTO와 RPO이다. RTO(Recovery Time Objective)는 복구에 걸리는 시간에 대한 목표이다. 다시 말해, 재해 발생 시 서비스가 복구되는데 걸릴 수 있는 시간을 말한다. RPO(Recovery Point Objective)는 복구 시점에 대한 목표로, 마지막 백업 또는 스냅샷 이후 재해발생 시점까지 경과된 시간을 의미한다.

 

가장 낮은 수준의 백업 및 복원은 RTO/RPO가 시간 기준인 경우이다. 서비스가 몇 시간 오프라인이 되어도 괜찮은 방법으로, 백업한 자료로 복원하면 끝이다. 가장 저렴하고 간단하다.

 

그 다음으로는 보통 수준의 재해 복구로 액티브/패시브 전략이다. RTO/RPO가 분 기준일 때 사용할 수 있는 전략으로, 리소스의 액티브 버전이 실패할 경우 대기 상태의 리소스를 패시브 버전으로 보유하면 된다. 액티브 서버가 종료되면 패시브 서버와 DB로 신속하게 전환한다.

 

가장 높은 수준의 액티브/액티브 버전은 RTO/RPO가 거의 실시간으로 작동한다. 동일한 서버의 여러 복사본을 나란히 실행하고 로드 밸런서(Load Balancer)를 배치하며 서버가 작동을 중단할 경우 로드 밸런서는 죽은 서버를 무시하고 해당 요청을 처리할 수 있는 서버로 전달해서 처리한다.