RTO(목표 복구 시간) 3시간을 위한 스토리지 구축 방안
이 기사는 지난 23일 바이라인플러스가 개초한 ‘DR(DisasterRecovery)의 중요성’이라는 주제로 웨비나 세션의 내용을 담고 있습니다.
최근 카카오 데이터센터 화재로 재해복구(DR) 시스템에 대한 관심이 커지고 있다. 지금까지 많은 기업들이 DR 시스템의 필요성은 인지하면서도 비용문제로 투자에 소극적인 면이 있었다. 그러나 이번 사건은 DR 시스템 미비로 기업이 사회적 지탄의 대상이 될 수도 있고, 예상했던 것보다 더 큰 위기 상황에 빠질 수도 있다는 것을 보여준다.
이에 바이라인플러스는 지난 23일 ‘DR(DisasterRecovery)의 중요성’이라는 주제로 웨비나를 개최했다. 이번 웨비나의 첫 세션은 ‘재해 복구의 시간을 단축하기 위한 스토리지 구축 가이드’라는 주제로 효성인포메이션시스템의 권필주 전문위원과 박용진 부장이 발표했다.
권 전문위원은 이 자리에서 재해복구 시간을 최대한 줄일 수 있는 다양한 백업 스토리지 아키텍처에 대해 소개했다.
권 전문위원은 우선 RPO(목표 복구 시점)와 RTO(목표 복구 시간)의 개념에 대해 설명했다. RPO는 데이터를 어느 주기로 백업할 것인지 결정하는 기준이다. 만약 RPO를 1시간으로 정했다면 장애가 났을 때 백업 시스템에는 1시간 전까지의 데이터만 기록돼 있을 가능성이 있다. 그럼 1시간 동안 발생한 데이터는 사라질 위험에 빠진다. 반면 RTO는 얼마나 빨리 복구할 것인지 목표를 세우는 것이다. RTO가 3시간이면 3시간 이내에 시스템을 재가동시킨다는 목표를 두고 있는 것이다.
RPO가 1시간이라면, 1시간 동안의 데이터는 사라져도 상관없을까? 단 하나의 데이터도 유실되면 안되는 시스템이 많다. 예를 들어 은행의 원장 데이터가 사라지면 고객의 돈도 사라지게 된다. 권 전문위원은 기업의 중요 시스템 데이터가 유실되는 것은 있을 수 없는 일이라고 말했다.
이 때문에 유실된 데이터는 다른 방법으로라도 복구를 해야 한다. 예를 들어 데이터베이스의 아카이브 로그 등의 데이터를 활용해 유실된 1시간 동안의 데이터를 찾아내서 복구할 수도 있고, 심지어는 수기로 저장된 데이터도 찾아내서 복구하기도 한다.
그러나 문제는 유실된 데이터를 찾아서 복구하는 동안 시스템은 중단상태가 유지된다는 것이다. 즉 RPO가 길어지면, RTO 역시 길어진다. 이 때문에 권 전문위원은 “RPO를 제로(0)로 하는 시스템을 구축해야 한다”고 설명했다. 금융권의 경우 전자금융감독규정에서 “핵심업무의 경우 RTO를 3시간 이내로 해야 한다(23조 9항)”고 돼 있는데, RPO를 1시간으로 하면 RTO 3시간은 불가능할 수 있다. 권 전문위원은 “데이터 복구 시간을 없애야 RTO 3시간의 목표를 충족할 수 있다”고 말했다.
그럼 어떻게 RPO를 제로로 만들 수 있을까? 권 전문위원은 “데이터는 실시간 동기화로 이중화 되어야 한다”고 강조했다.
그에 따르면 RPO 제로를 위한 가장 이상적인 방법은 두 개의 스토리지를 동기화하는 것이다. 애플리케이션에서 I/O 쓰기 요청이 있을 때 원본과 복제본에 동일한 내용으로 저장되는 것이다. 두 곳에 모두 쓰기가 완료됐을 때만 앱의 요청이 완료된 것으로 처리하는 방식이다.
이 방안은 원본과 복제본을 모두 쓸 때까지 앱은 기다려야 한다는 단점이 있다. 원본과 복제본이 가까운 곳에 있으면 체감할 수 없는 시간이겠지만, 복제본이 멀리 있다면 앱 성능 저하의 원인이 될 수 있다.
권 전문위원은 “실시간 동기화는 원본과 복제본을 100km 이내 구성하는 방식”이라고 설명했다.
유사한 방식으로 액티브-액티브 미러링 방식도 있다. 이는 원본과 복제본을 구분하지 않고 읽기/쓰기를 지원하는 방식이다. 앱은 두개의 스토리지를 마치 하나처럼 인식하기 때문에 어떤 스토리지가 장애 나더라도 살아 있는 스토리지를 통해 지속적으로 서비스가 가능하다.
이 방식은 RPO가 제로일 뿐 아니라 RTO도 제로로 만드는 것이 가능하다. 그러나 이 방식 역시 거리가 멀면 성능 저하를 일으킨다. 재해복구 센터를 주 센터에서 거리가 멀지 않은 곳에 두면, 지진이나 전쟁과 같은 하나의 재해에 두 센터가 모두 장애를 일으킬 수 있기 때문에 최대한 멀리 둘 것이 권고된다.
센터간 거리에 한계가 없는 비동기식 방식도 있다. 데이터가 주 스토리지에 저장되는 것과 별개로 백그라운드에서 원격지로 일정 기간마다 데이터를 복제하는 방식이다. 두 개의 스토리지에 쓰기가 완료될 때까지 기다리지 않기 때문에 백업 스토리지의 거리가 멀어도 앱 성능에 영향을 미치지 않는다.
다만 일정한 시간마다 백업 스토리지에 데이터가 전송되기 때문에 완전한 RPO 제로는 어려울 수 있다.
이를 개선해서 변동 데이터를 시간 주기로 전송하지 않고, 데이터 생성 즉시 백업 스토리지로 보내는 방식도 있다. 이 때는 시간 정보를 함께 보내서 백업 데이터센터에서 받은 데이터를 시간대별로 다시 조립해서 데이터 정합성을 유지한다.
위에서 살펴본 것처럼 동기식과 비동기식은 각각의 장단점이 있다. 동기식은 성능 문제로 주 스토리지와 백업 스토리지의 거리가 멀지 않아야 한다. 비동기식은 RPO 제로를 장담할 수 없어 데이터 유실 가능성이 존재한다.
권 전문위원은 두 방식이 가진 문제를 해결하기 위해 데이터를 세 벌로 동기화하는 방식이 있다고 소개했다. 우선 거리가 멀지 않은 곳(100km 이내)에 두 스토리지를 두고 동기화하면서, 거리가 먼 곳에 비동기 백업 스토리지를 두는 방식이다.
물론 데이터가 실시간으로 복구된다고 해서 시스템 전체가 복구된다고 보장할 수는 없다. 이번 카카오 장애도 데이터 유실은 없었던 것으로 알려졌지만 복구에 오랜 시간이 걸렸다. 권 전문위원은 “3시간이라는 RTO를 맞추기 위해서는 모든 시스템이 구비된 핫 사이트나 미러 사이트 구성이 되어 있어야 한다”면서 “미러 사이트의 경우 서버와 네트워크 등이 사이트간 재해 시 자동 페일오버 혹은 액티브-액티브 상태를 유지하는 기술이 필요하다”고 말했다.
박용진 부장은 웨비나에서 이와 같은 재해복구를 가능케하는 자사의 솔루션을 소개했다.
박 부장은 “자사는 이미 오래전부터 스토리지 기반 재해복구 환경에 최적화된 복제솔루션을 제공해오고 있다”면서 “동기화 방식의 트루카피(TrueCopy), 데이터 손실없는 실시간 비동기 방식의 유니버설 리플리케이터(Universal Replicator), 액티브-액티브 방식의 글로벌 액티브 디바이스(Global-Active-Device) 솔루션이 있다”고 말했다.
박 부장은 “RTO를 최소한으로 줄이되, 한정된 예산 내에서 보유 자원을 최대한 끌어올리고자 하는 두가지 니즈가 액티브-액티브 데이터 센터 구현으로 보다 가까워지고 있다”면서 “서로 다른 2대의 히타치 VSP 스토리지를 하나의 볼륨처럼 관리하는 강력한 미러링 기술을 통해 데이터센터가 요구하는 스토리지 RPO, RTO를 보장할 수 있다”고 말했다.
글. 바이라인네트워크
<심재석 기자>shimsky@byline.network
