RTO와 RPO 차이

재해 복구 소개

기업 DR(재해 복구)을 위한 모범 사례는 기본적으로 재해 발생 시에도 계속 작동할 수 있고("비즈니스 연속성"), 정상 작업을 재개할 수 있으며("비즈니스 재개"), 작업자의 개입을 최소화하고, 이상적으로는 데이터 손실이 전혀 발생하지 않는 내결함성 하드웨어 및 소프트웨어를 설계하고 구현하는 과정으로 이뤄집니다. 기업 DR 목표와 실제 예산 제약 조건을 충족시키기 위한 내결함성 환경을 구축하려면 비용과 시간이 많이 들며, 경영진의 강력한 지원 약속이 필요합니다.

DR 계획은 일반적으로 다음과 같은 유형의 재해 중 하나 이상을 해결할 수 있어야 합니다.

• 자연적인 재해(지진, 폭풍, 홍수 등) 또는 기타 원인(화재, 파괴, 절도 등)으로 인한 광범위한 또는 확장된 IT 설비의 손상

• 정전, 냉각 또는 네트워크 액세스 손실 등과 같은 IT 설비의 핵심 서비스의 확장된 손실

• 주요 작업자 손실

DR 계획 프로세스는 기업이 반드시 견뎌내야 하고 업무를 재개할 수 있어야 하는 재해 유형을 식별하고 분류하는 것으로부터 시작됩니다. 계획 프로세스에서는 필요한 내결함성 정도를 포함해서 높은 레벨의 BC(비즈니스 연속성)와 BR(비즈니스 재개) 요구사항이 식별됩니다. DR 계획의 결과물은 설정된 제약 조건에 따라 이러한 요구사항이 충족될 수 있도록 지원하는 내결함성 시스템, 응용 프로그램 및 데이터를 위한 복구 및 재개 아키텍처입니다. 일반적인 DR 제약 조건에는 RTO(복구 시간 목표), RPO(복구 지점 목표) 및 사용 가능한 예산이 포함됩니다. 비즈니스 제약 조건과 함께 DR 아키텍처는 전반적인 DR 프로세스에 대해 예측 가능한 결과를 보장할 수 있도록 진정한 "종단간" 방식으로 모든 시스템 요소를 통합하는 DR 절차로 이어집니다.

내결함성 시스템은 일반적으로 중복성을 통해 성능 및 복원성을 얻을 수 있습니다. 종종 상당한 비용을 통해 얻게 되는 완전히 중복된 시스템은 해당 아키텍처 내에서 단일 장애 지점이 존재하지 않으며, 해당 한도 내에서 가장 심각한 재해가 발생하더라도 계속 작동할 수 있으며, 업무를 재개할 수 있습니다. 우주 왕복선과 비행 제어 시스템은 완전히 중복된 시스템의 좋은 예입니다. 중요도가 높지 않은 IT 응용 프로그램의 경우에는 일반적으로 이보다 낮은 중복성을 통해 조금 덜 강력한 시스템을 사용할 수 있습니다. 이러한 시스템은 구축하는 데 비용이 덜 소비되며, 필연적으로 재해 발생 후 서비스 중단이 발생할 수 있으며, 이 기간 동안 기업은 복구 가능한 시스템, 응용 프로그램 및 데이터를 복원해야 합니다.

궁극적으로 DR 요구사항을 정하는 데 있어서 핵심은 비즈니스 특성과 고객 요구사항 및 DR에 사용 가능한 예산이라고 볼 수 있습니다. 비용이 많이 들더라도 반드시 포괄적인 DR 솔루션을 구축할 수 있어야 합니다. 재해가 발생했을 경우 비용과 하드웨어 및 소프트웨어를 모두 잃어버리고 단순히 업무를 재개할 수 있기를 바랄 수만은 없습니다. 하지만 지능적으로 DR을 계획 및 설계할 경우에는 완전히 서비스를 재개할 수 있을 때까지 중단이 길어지고 서비스 레벨이 저하되더라도, 제한적이지만 의존할 수 있는 DR 솔루션을 준비할 수 있습니다.

하지만 발생 가능한 모든 DR 시나리오를 예상하고 대응할 수 있는 계획은 어디에도 존재하지 않는다는 것을 이해해야 합니다. 예를 들어, 특정 시스템에서 사소한 문제로 시작된 것이 시간이 지남에 따라 여러 가지 방식으로 다른 시스템으로 확산되면서 결국에는 복구 시나리오가 준비되지 않은 재해로 발전할 수도 있습니다. 이와 비슷하게, 핵심 부품 또는 서비스를 사용할 수 없게 되거나 DR 공급자의 제공 성능이 광고한 만큼 강력하지 않은 경우와 같이 주요 가정이 실제와 다를 경우 서비스 계약 이행이 어려울 수 있습니다. 하지만 실제로 중요한 핵심은 계획했던 가장 최악의 시나리오를 초월하는 재해가 발생한 경우, 복구가 가능하지 않게 될 수 있다는 것입니다.

RTO(복구 시간 목표) 정의

RTO는 재해가 발생한 후 원하는 작업 성능에 도달하기 위해 걸리는 시간에 대한 서비스 레벨 목표입니다. 예를 들어, DR 기능이 존재하지 않을 경우 1시간 이상 지속될 수 있는 계획되지 않은 작동 중단이 발생할 경우에도 비즈니스 요구사항에 따라 30분 이내에 모든 프로덕션 시스템이 작동되어 재해 이전 성능의 80%로 실행되도록 RTO를 지정할 수 있습니다. RTO 목표를 설정하는 데에는 재해 발생 후에 필요한 RPO 처리 시간, 공인된 IT 직원 가용성 및 수동적인 IT 프로세스의 복잡성 등의 제약 조건이 있을 수 있습니다. 완전한 내결함성 시스템의 경우에는 재해 발생 중 및 재해 발생 후 어떠한 서비스 개입도 없이 절대적으로 시스템이 복구되기 때문에 RTO가 적용되지 않습니다.

DR 계획자는 정의된 BC 요구사항의 일부 또는 전체에 대해 RTO를 서로 다른 방식으로 설정할 수 있습니다. 비즈니스 업무 유형이 다르면 필요한 RTO도 달라질 수 있습니다. 예를 들어, 온라인 시스템과 일괄 처리 작업은 필요한 RTO가 서로 다를 수 있습니다. 또한 각 단계에 정의된 RTO가 포함되는 단계별 DR 계획의 단계에 다른 RTO가 적용될 수 있습니다. 또한 복구 가능한 응용 프로그램은 각각의 여러 서비스 레벨에 대해 RTO가 서로 다를 수 있습니다.

BC 데이터 가용성 요구사항은 RTO를 계획하는 데 있어서 매우 중요합니다. DR 복구 프로세스에 입력으로 사용되어야 하는 데이터가 재해 복구 사이트에 없을 경우, 온사이트로 데이터를 가져오는 데 걸리는 시간으로 인해 RTO가 지연됩니다. 예를 들어, 오프사이트 스토리지 보관소에 있는 데이터를 가져오려면 시간이 소요됩니다. 재해 복구 작업이 시작되기 전에 최신 입력 데이터가 복구 사이트에 복제되어 있는 경우에는 복구를 신속하게 진행할 수 있습니다.

RPO(복구 지점 목표) 정의

RPO는 재해 복구 프로세스로 모든 복구 가능한 시스템이 복원된 다음 도달해야 하는 비즈니스 상태 또는 비즈니스 현재성을 기술하는 비즈니스 연속성 목표입니다. 개념적으로 RPO는 재해 발생 이전의 알려진 상태로의 "롤백" 또는 동기화 목표 상태를 의미합니다. 즉, RPO는 중단된 복구 가능한 응용 프로그램에서 처리를 재개할 수 있는 재해 이후 복구 지점입니다. RPO와 재해 시점 사이의 기간 중에 발생하는 모든 트랜잭션은 복구할 수 없습니다. 완전한 내결함성 시스템의 경우에는 재해가 발생해도 이러한 시스템의 비즈니스 연속성에 영향을 주지 않기 때문에 RPO가 적용되지 않습니다.

그림 1-1에서는 DR 계획자가 고려해야 할 여러 가지 복구 지점 제안을 통해 RPO 개념을 보여줍니다. 계획 시에는 원하는 RPO가 선택한 RTO와 서로 비슷한 수준으로 유지될 수 있도록 해야 합니다. 일반적으로 재해 복구 계획 시 재해 발생 시점과 근접한 RPO를 요구할수록 보다 뛰어난 내결함성이 요구되며, 간격이 큰 RPO에 비해 구현 비용이 높아질 수 밖에 없습니다. RTO에서와 같이 DR 계획자는 여러 가지 BC 요구사항에 따라 서로 다른 RPO, DR 계획 단계 또는 응용 프로그램 서비스 레벨을 설정할 수 있습니다.

그림 1-1 복구 지점 목표

설명 그림 1-1 복구 지점 목표

보다 일반적으로, RPO 계획에는 데이터, 메타데이터, 응용 프로그램, 플랫폼, 설비 및 인력 등을 포함해서 각 복구 가능한 시스템을 복원하기 위해 준비되어야 하는 모든 지원 요소가 식별되어야 합니다. 또한 계획 시에는 이러한 요소들이 복구를 위해 필요한 비즈니스 현재성 레벨에서 제공될 수 있도록 보장해야 합니다. BC 데이터 현재성 요구사항은 RPO를 계획하는 데 있어서 특히 중요합니다. 예를 들어, BC 요구사항에 따라 1시간 RPO가 지정된 경우 복구 프로세스에 공급하는 데이터 또는 메타데이터가 RPO에 대해 최신 상태여야 하며, 그렇지 않으면 RPO를 달성할 수 없습니다. 조직의 DR 프로세스에는 지정된 RTO 내에서 정의된 모든 RPO를 달성하기 위한 절차가 지정되어야 합니다.

RPO 복구를 위해 필요한 시스템 메타데이터에는 OS 카탈로그 구조 및 테이프 관리 시스템 정보가 포함됩니다. 이러한 항목은 선택한 모든 RPO를 사용으로 설정하기 위해 재해 복구 프로세스 중에 업데이트되어야 합니다. 예를 들어, DR 복구 프로세스에 대한 여러 메타데이터 입력 간의 일관성을 보장하기 위해서는 RPO에 다시 생성되는 기존 데이터 세트가 카탈로그화 취소되어야 하며, RPO와 재해 시점 사이에 업데이트된 데이터 세트는 RPO 또는 이전에 존재하던 버전으로 복원되어야 하며, 테이프 관련 카탈로그 변경사항이 있을 경우 테이프 관리 시스템과 동기화되어야 합니다.

일시적인 작동 중단 처리

재해 복구는 프로덕션 사이트를 장기간 사용할 수 없게 만드는 매우 장기적인 작동 중단에 대한 해결책을 제공합니다. 이 소개 섹션의 남은 부분에서는 재해 복구 방식에 대해 설명하지만, 비교적 일시적인 작동 중단이 발생할 경우 이러한 문제가 처리되기 전까지 프로덕션에 부정적 영향을 줄 수 있으므로, 이를 완화하기 위한 절차를 개발하는 것도 마찬가지로 중요한 일이 될 수 있습니다. 예를 들어, 특정 하드웨어 또는 네트워크 설비를 한 두 시간 정도 사용할 수 없지만, 일시적으로 신속한 조정을 통해 "성능 저하 모드"로 프로덕션이 계속 작동할 수 있는 서비스 중단 상태가 발생했다고 가정해보십시오. 일시적인 작동 중단 절차에는 문제를 격리시키는 방법, 변경할 사항, 알림을 제공할 대상 직원 및 서비스 복원 후 정상 작동 환경으로 복원하는 방법이 기술되어야 합니다.

핵심 개념: 동기화 지점 복구

실제 재해 복구 및 DR 테스트 중에 수행되는 핵심 활동은 정의된 RPO로 프로덕션 응용 프로그램을 다시 시작하는 일입니다. 복원력이 가장 뛰어난 DR 환경에서는 아웃소싱 또는 내부 개발에 관계없이 모든 복구 가능한 응용 프로그램이 핵심 DR 요구사항을 강제 적용하도록 보장합니다. 즉, 응용 프로그램이 동기화 지점이라고 부르는 계획된 시점으로부터 다시 시작되어, 응용 프로그램 실행 중 일정이 잡히지 않은 중단으로 인한 영향을 완화할 수 있도록 설계됩니다. 중단된 응용 프로그램이 동기화 지점에서 다시 시작될 경우, 결과는 해당 응용 프로그램이 작동 중지되지 않았을 때와 동일하게 나타납니다.

복구 가능한 응용 프로그램의 다시 시작 절차는 응용 프로그램 및 해당 입력의 특성에 따라 달라집니다. 실제 재해 복구 또는 DR 테스트에 대한 응용 프로그램 다시 시작 절차는 정상적인 프로덕션 실행 중 응용 프로그램이 실패할 경우 응용 프로그램을 다시 시작하기 위해 사용되는 절차와 동일합니다. 가능한 경우에는 실제 재해 복구 또는 DR 테스트를 위한 프로덕션 다시 시작 절차를 재사용함으로써 DR 절차의 생성 및 유지 관리를 간소화하고, 이러한 입증된 절차를 활용할 수 있습니다. 가장 단순하게 봤을 때 복구 가능한 응용 프로그램은 해당 단계에서 호출되는 프로그램의 시작 지점인 동기화 지점이 하나만 포함된 단일 작업 단계입니다. 이 경우, 복구 절차는 중단된 작업을 다시 제출하는 것만큼 간단할 수 있습니다. 이보다 조금 더 복잡한 다시 시작 절차에는 마지막 실행 중에 응용 프로그램에서 생성된 모든 출력 데이터 세트를 카탈로그화 취소한 후 응용 프로그램을 다시 시작하는 과정이 포함될 수 있습니다.

선택 가능한 여러 개의 내부 동기화 지점이 포함된 응용 프로그램의 다시 시작 절차는 그렇게 단순하지 않을 수 있습니다. 이러한 동기화 지점을 구현하기 위해 체크포인트/다시 시작 기법을 사용하는 응용 프로그램은 진행 상태를 주기적으로 기록하고 중단 전에 기록된 마지막 내부 동기화 지점에서 다시 시작할 수 있도록 기록된 체크포인트 정보를 사용합니다. 다시 시작 절차는 각 동기화 지점의 요구사항을 따릅니다. 체크포인트가 사용 중이면, 체크포인트가 응용 프로그램 복구에 대해 유효한 상태로 유지되는 동안 체크포인트와 연관된 데이터 세트가 만료되거나 카탈로그화 취소되거나, 스크래치되지 않은 상태여야 합니다. 기존 입력 데이터 세트를 수정하는 작업 단계에 대해 동기화 지점을 간단하게 설정하기 위해서는 해당 단계를 실행하기 전에 수정 가능한 각 데이터 세트의 백업 복사본을 만들면 됩니다. 이러한 수정 가능한 입력 데이터 세트는 DD 문 또는 동적 할당 요청에서 JCL 속성 DISP=MOD를 검색하여 쉽게 식별할 수 있습니다. 작업 단계가 실패하거나 중단될 경우, 수정된 입력 데이터 세트를 단순히 폐기하고, 백업 복사본에서 입력 데이터 세트를 복원하여, 복원된 복사본으로부터 단계를 다시 시작하면 됩니다. 이러한 백업 복사본은 원본이 만료, 카탈로그화 취소 또는 스크래치된 실패 또는 중단된 작업 단계를 다시 시작하는 데에도 유용합니다.

RPO를 동기화 지점 복구와 연결

RPO가 동기화 지점과 일치할 경우 이 동기화 지점에 대해 개발된 응용 프로그램 다시 시작 절차를 수행하면 중단이 발생하지 않은 것처럼 이 원점에서 응용 프로그램이 재개됩니다(그림 1-2). 이 RPO부터 재해 발생 시점까지 처리된 모든 트랜잭션은 복구할 수 없는 것으로 간주됩니다.

그림 1-2 동기화 지점의 RPO

설명 그림 1-2 동기화 지점의 RPO

다른 시점에서는 BC 요구사항에 따라 동기화 지점 사이에 RPO 배치를 조정할 수 있습니다. 이러한 경우, 동기화 지점 내부의 복구는 가장 최근의 동기화 지점이 설정된 후 발생하는 모든 중요 응용 프로그램 상태 변경 또는 이벤트를 기술하는 보완 데이터에 의존합니다. 예를 들어, RPO가 재해 발생 전 1분이라고 가정해보십시오. 복구 가능한 응용 프로그램이 해당 진행 상태를 기록하기 위해 체크포인트를 사용하도록 설계되었지만, 이러한 체크포인트를 1분 단위로 작성하기 위한 오버헤드가 허용될 수 없는 수준이라고 가정해보십시오. 이 경우 한 가지 해결 방법은 체크포인트 작성 간격을 더 늘리고 체크포인트 간에 커밋되는 모든 트랜잭션을 기록하는 것입니다. 그러면 체크포인트 복구 프로세스가 최근의 동기화 지점을 넘어서 RPO에서 다시 시작하기 위해 트랜잭션 로그를 보완적인 입력 데이터로 사용할 수 있습니다. 이 예제에서 응용 프로그램 다시 시작 절차는 최근의 체크포인트 데이터를 액세스하고 체크포인트 이후 및 RPO 이전에 처리된 모든 커밋된 트랜잭션을 복원하기 위해 보완적인 트랜잭션 로그를 적용합니다(그림 1-3). 이러한 방식으로 동기화 지점 복구는 여러 소스로부터의 입력 데이터를 사용해서 목표 RPO를 달성할 수 있습니다. RPO부터 재해 발생 시점까지 처리된 모든 트랜잭션은 복구할 수 없는 것으로 간주됩니다.

그림 1-3 동기화 지점 사이의 RPO

설명 그림 1-3 동기화 지점 사이의 RPO