IT 서비스와 Data는 기업의 생사를 좌우할 정도로 중요해졌습니다. 기업들이 많은 예산을 사용하여 시스템 백업, 이중화, 재해복구 센터 구축을 하는 이유는 장애, 재해 상황에 대비하기 위함이고, 이는 기업의 존을 위한 필수 지출 입니다.
백업, 이중화, 재해복구 구축 등 데이터 보호를 고민하는 기업에서 정보시스템을 구축하는데 주요 고려사항으로 4가지 ‘R’이 있습니다. RPO, RTO , RLO , RIO이다. 최근 유닉스 시스템에서 탈피하며 x86 시스템을 중심으로 이른바 U2W(Unix to Windows), U2L(Unix to Linux)로 시스템 전환이 되면서 추가적으로 고려해야 할 요소가
바로 RLO와 RlO가 있는데 이것과 포함해서 알아보겠습니다.
RPO란
RPO(Recovery Point Objectives) : 복구 목표 시점, 데이터 손실 최소화와 관련
- 재해복구 시점목표(데이터 관점)
- 재해 발생시 데이터 손실을 수용 손실 허용 시점(특정 백업 시점 데이터 복구, 전일 마감 백업 시점 복구)
정보시스템이 운영 중에 장애가 발생해 온라인 비즈니스를 유지할 수 없거나 주요 정보의 유실로 더 이상의 서비스를 할 수 없을 때 비즈니스 연속을 위해 어느 시점으로 정보시스템을 되돌리거나 정보의 복구가 되어야 하는지를 결정하게 하는 지표다.
기존 레거시 관점에서는 정보를 일일 백업해 정보 유실 시에 바로 하루 이전 데이터 또는 그 이전의 과거 데이터 를 복구해 서비스를 재가동했다. 이 때 바로 RPO는 1일이 되는 것이며 또는 1일보다 더 과거가 되는 2일, 3일 등이 될 수도 있다.
물론 과거에는 데이터 복원만이라도 되면 그나마 다행이었던 시절이라 이러한 RPO가 용납이 되던 시절이었으며 운영 시스템의 장애에 대해 클러스터(Cluster) 기술을 이용해 정보 시스템을 이중화/다중화했다.
그러나 이러한 클러스터 기술은 기업의 비즈니스 로직을 담고 있는 애플리케이션의 이중화일 뿐이지 정보 데이터를 보호하지는 못했다. 오늘날 IT 기술이 더 이상 기업의 비즈니스를 조력하는 위치에서 리드하는 자리로 변화된 지금 적절한 RPO는 무엇일까?
일 단위의 RPO를 고집한다면 더 이상 온라인 비즈니스를 유지하기 어려울 것이다. 정보시스템이 파격적인 변화를 초래할 것이다.
RTO란
RTO(Recovery Time Objectives) : 복구 목표 시간, 서비스 다운타임 최소화와 관련
- 재해복구 시간 목표(업무관점)
- 업무 중단 시점부터 복구되어 가동될 때까지 시간 목표(예: 2시간, 7일, 1개월)
RTO는 정보시스템 장애 시 시스템을 원상태로 복원하는데 소요되는 시간을 의미한다. 불과 몇 해 전만 해도 대다수 기업들은 RPO를 4~6시간 정도로 고려해 정보 시스템을 설계했다. 그러나 폭발적으로 증가하는 정보와 재사용 및 공유로 인하여 이제 4 ~ 6 시간 안에 정보를 보호하여 두었다가 복원하는 것이 이제 불가능에 가깝다.
또한 시간 단위의 복원은 사슬처럼 복잡하게 얽혀 있는 기업의 비즈니스 시스템을 유지하는 것은 불가능하다. 이제는 실시간 그리고 실시간에 근접한 복구 시간을 요구하고 있다. 물론 과거에도 기업의 중요한 시스템은 고 비용을 들여서 실시간 복구 시스템을 구축하였다.
FTS(Fault Tolerant System) 또는 BCS(Business Continuity
System)은 기업의 주요 시스템에만 적용되어 있었다. 이러한 시스템은 고 비용으로 모든 정보 시스템에 적용할 수 없었고 최소 업무 영향도를 가지고 구축하였다.
그러나 오늘날에는 모든 단위 시스템의 중요도가 비슷하다. 예전처럼 어느 한 개의 단일 시스템 서비스 구동만 오르는 기업의 비즈니스 연속성을 유지하기 어렵다. 그러므로 대 고객 접점인 프레젠테이션 레이어부터 데이터 베이스 시스템 안쪽까지 일련의 정보 시스템이 동등한 RTO를 요구한다. 또한 장애 시 복구에 소요되는 시간도
분 또는 초 단위의 소요시간을 목표로 해야 한다.
2000년대 초반에 RTO를 줄이기 위한 노력 중 하나가 바로 VTL(Virtual Tape Library) 도입이었다. 정보 복구를 위하여 Sequential I/O를 하는 테이프(Tape) 매체보다는 Random I/O를 하는 디스크(Disk) 매체를 마치 테이프 (Tape)처럼 가상화해 사용한 것이다. 백업 시간에는 큰 차이가 없으나 디스크(Disk) 매체 복구 시 복구해야 할 블록 위치로 바로 접근해 복구하기 때문에 테이프 매체보다는 빠른 RTO를 제공할 수 있었다.
그리고 오늘날에는 리스토어 과정 없이 백업된 이미지를 바로 서비스에 사용하는 기술이 x86 플랫폼(물리, 가상화)에서 손쉽게 구현되면서 RTO ~ 초 단위로 변화되고 있다.
RLO란
RLO(Recovery Level Objectives) : 목표 복구 레벨(수준)
정보 시스템을 구성 요소는 크게 OS(운영체제), 파일 데이터, 데이터베이스, 애플리케이션으로 나눌 수 있다. 즉 정보시스템 장애 시 복구가 요구되는 요소이기도하다. 그러나 지금까지 대부분의 정보시스템은 데이터(파일, 데이터베이스)만을 보호해 복구하는데 중점을 뒀다. 운영체제나 애플리케이션은 다시 재설치가 가능했기 때문이다.
정보 및 데이터는 유실되면 다시는 돌이킬 수 없었기 때문에 당연한 것이었다고 생각된다. 많은 시간이 소요되던라도 운영체제와 애플리케이션을 재설치해왔던 것이다.
하물며 애플리케이션의 많은 튜닝 값들은 모두 복원하기 어려웠을 것이다. 그리고 과거에 유닉스 시스템을 중심으로 하는 정보시스템에서 운영체제의 복원 방법은 각 서버 제조사의 특화된 기능으로만 제공되던 것이기 때문에
고려대상에서 제외되어 왔다.
그러나 오늘날의 x86 중심의 다운사이징 환경에서는 다양한 수준의 복원이 가능하다.
정보시스템의 장애 유형에 따라서 운영체제, 파일 데이터, 데이터베이스 및 애플리케이션의 선택적인 복원이 가능한 기술들이 소개되고있다. 또한 선별적인 복원을위해 각 요소들을 별도로 백업 및 보관할 필요 없이 단일 백업으로 각 필요한 장애에 따라서 복원을 하기 때문에 Backup Window(백업 스케줄 구성)를 단순하게 운영하는 것 또한 큰 장점이다.
즉 단일 백업 이미지로 논리적인 선별적 복원을 하게 한다.
RIO란
RlO(Recovery Location Objectives) : 목표 복구 위치
전통적으로 데이터 백업은 테이프(Tape) 매체에 기록했다. 그리고 아직도 여전히 소산을 위해 일부 운영 중이다. 그리고 앞서 언급했듯이 보다 신속한 복구를 위하여 디스크(Disk) 매체를 이용한 VTL을 사용하는 경우도 있다.
이것이 전통적인 레거시 백업 저장소라고 할 수 있다. 최근 트렌드는 무엇일까? 바로 디스크에 백업하거나 어플라이언스에 백업 및 복제하는 것이며 또한 클라우드
를 활용해 백업 및 서비스 재 시작할 이미지를 보관하는 것이다. 글로벌 비즈니스를 하는 기업은 클라우드를 활용해 비즈니스 성장과 축소에 발 빠르게 대응하고 있으며 이러한 정보시스템 보호 기술도 변화되고 있다.
최근 트렌드의 공통점은 백업 및 보관된 이미지를 리스토어라는 일련의 장시간이 필요로 하는 과정에서 탈피 하여 즉각 서비스하는 관점으로 옮겨갔다는 것이다. 이 또한 오늘날 기업의 비즈니스 생존 전략에 부합한다고 할 수 있다.
최근 동향은 어플라이언스를 도입해 정보시스템을 보호하며 원격지 소산 또한 어플라이언스를 원격지에 두고 백업 이미지를 복제하는 구축 방식이다. 그리고 다양한 장애 유형에 따라서 선별적인 복구 방안을 마련함 으로써 소프트웨어와 저장장치를 단일 구축해 도입 비용, 운영 편의성 및 확장성을 보장한다.