RTO, RPO 및 MTTR: 복구 목표 정의

구체적이고 측정 가능한 복구 목표가 없으면 적절한 백업 전략을 설계하거나, 적합한 DR 사이트 등급을 선택하거나, 복구 기술 투자가 타당한지 평가할 수 없습니다. RTO, RPO, MTTR은 비즈니스 가용성 요구 사항을 정밀한 엔지니어링 목표로 변환합니다. 이러한 지표를 통해 보안 및 IT 팀은 downtime 비용과 DR 투자 비용을 근거를 바탕으로 경영진과 논의할 수 있으므로, 비즈니스 타당성을 추상적인 설명이 아닌 구체적인 내용으로 제시할 수 있습니다.

복구 시간 목표(RTO)는 중단이 시작된 시점부터 정상 Service가 복구될 때까지 허용되는 최대 시간입니다. 중요한 Payment 시스템이 오전 10시에 실패했고 비즈니스가 수용할 수 없는 매출 손실이나 SLA 위반이 발생하기 전까지 최대 2시간의 downtime만 감수할 수 있다면 RTO는 2시간입니다. 즉 늦어도 오후 12시까지 시스템을 복구해야 합니다. RTO는 DR 사이트 등급(15분 RTO에는 Hot 사이트, 48시간 RTO에는 Cold 사이트), Replication 빈도, 장애 조치 자동화에 관한 선택을 결정합니다.

복구 시점 목표(RPO)는 시간으로 측정한 허용 가능한 최대 데이터 손실, 즉 재해 발생 시 감수할 수 있는 데이터 손실의 범위입니다. RPO가 1시간이라는 것은 시스템이 복구되었을 때 재해 발생 시점보다 1시간 이상 이전의 데이터만 포함해서는 안 된다는 뜻입니다. RPO는 백업 빈도를 결정합니다. 1시간 RPO에는 최소한 Hourly 백업 또는 지속적인 Replication이 필요합니다. 4시간 RPO는 4시간 간격의 백업을 허용할 수 있습니다. RPO는 데이터 복구에 관한 것이고, RTO는 Service 가용성 복구에 관한 것입니다.

RTO와 RPO는 복구의 서로 다른 측면을 다루므로 독립적으로 정의해야 합니다. 시스템은 엄격한 RPO(1시간, 즉 데이터가 자주 Replication됨)와 완화된 RTO(4시간, 즉 데이터가 최신 상태여도 DR 환경을 구동하는 데 시간이 걸림)를 동시에 가질 수 있습니다. 반대로 완화된 RPO(24시간, 즉 Nightly 백업으로 충분)와 엄격한 RTO(1시간 내 장애 조치 필요)를 가질 수도 있습니다. 이 경우 즉시 활성화할 수 있도록 사전에 provisioned된 DR 환경이 준비되어 있어야 합니다. 두 지표 모두 비즈니스 영향 분석에서 도출됩니다.

평균 복구 시간(MTTR)은 incident 발생 후 Service를 복구하는 데 실제로 걸린 평균 시간, 즉 복구 성능을 운영 측면에서 측정한 값입니다. RTO가 허용 가능한 최대 downtime(목표/요구 사항)라면 MTTR은 관찰된 평균값(실제 성능)입니다. 조직은 시간 경과에 따른 여러 incident의 MTTR을 측정하고 RTO와 비교하여 복구 역량을 평가합니다. MTTR이 지속적으로 RTO를 초과한다는 것은 DR 역량이 충분하지 않으며 자동화, 인력 또는 인프라에 대한 투자가 필요하다는 뜻입니다.

평균 장애 간격(MTBF)은 시스템의 신뢰성을 측정하는 값으로, 시스템이 장애와 장애 사이에 작동하는 평균 시간입니다. Higher MTBF는 더 나은 신뢰성을 나타냅니다. MTBF와 MTTR은 함께 시스템의 가용성 백분율을 결정합니다. Availability = MTBF / (MTBF + MTTR). MTBF가 2000시간이고 MTTR이 2시간인 시스템의 Availability는 2000/2002 = 99.9%입니다. MTBF를 이해하면 장애가 발생할 가능성이 높은 시점을 예측하고 그에 맞춰 유지 관리 기간을 계획할 수 있습니다. MTBF가 감소하는 Hardware는 수명 종료 시점에 가까워지고 있으므로 사전에 교체해야 합니다.

최대 허용 downtime(MTD)은 비즈니스가 돌이킬 수 없는 피해를 입기 전에 시스템을 사용할 수 없는 상태로 둘 수 있는 절대적인 최대 시간입니다. 피해에는 고객 손실, 규제 처벌, 계약상 의무를 이행할 수 없는 상황 등이 포함됩니다. MTD는 항상 RTO보다 크거나 같습니다. 관계를 정리하면 MTD는 비즈니스의 한계이고 RTO는 IT 목표입니다. 계약상 SLA 위반이 4시간 지속되면 처벌이 시작되는 경우 MTD는 4시간일 수 있습니다. IT 팀은 MTD에 도달하기 전에 안전 여유를 확보하도록 1~2시간의 RTO를 설계합니다.

Service 수준 계약(SLA)은 고객에 대한 계약상 약속을 정의하며 RTO 및 RPO 요구 사항에 직접적인 정보를 제공합니다. 99.95% Uptime을 약속하는 Cloud 제공업체의 SLA는 연간 약 4.4시간의 downtime을 허용합니다. SLA 위반 시 Service 크레딧이나 계약 해지 권리가 발생합니다. IT와 비즈니스 부서 간의 내부 SLA도 이와 유사하게 작동합니다. 실제 downtime이 SLA 약속 범위 내에 유지되도록 RTO와 RPO를 설계해야 하며, 준수 여부를 입증하기 위해 MTTR을 측정하고 보고해야 합니다.

기술 선택은 RTO 및 RPO 요구 사항에 따라 직접 결정됩니다. 15분 RTO와 RPO 0에는 동기식 Replication을 사용하는 Active-Active 클러스터링이 필요합니다. 즉 데이터 손실이 없고 자동으로 장애 조치가 이루어져야 합니다. 4시간 RTO와 1시간 RPO에는 Warm standby로의 로그 전송 또는 비동기식 Replication을 사용할 수 있습니다. 24시간 RTO와 24시간 RPO에는 Cold 저장소에 대한 Daily 백업을 사용할 수 있습니다. 요구 사항보다 높은 복원력을 설계하면 예산이 낭비되고, 낮은 복원력을 설계하면 incident 발생 시 용납할 수 없는 비즈니스 위험이 발생합니다.

복구 목표는 정기적인 테스트를 통해 검증될 때만 유효합니다. 조직은 실제 MTTR을 측정하고 실제 데이터 복구 시점을 확인하는 복구 테스트를 수행해야 합니다(복원되었을 때 데이터가 얼마나 오래된 것인지 확인). 테스트 결과 MTTR이 RTO 1시간에 비해 지속적으로 3시간으로 나타난다면, 그 격차를 해결해야 합니다. DR 인프라를 개선하거나(자동화, 사전 프로비저닝), 업데이트된 BIA를 통해 비즈니스의 기대치를 재설정해야 합니다. 테스트 빈도는 중요도에 맞춰야 합니다. CRITICAL 시스템은 분기별로, 그 외 시스템은 매년 테스트해야 합니다.

RTO, RPO, MTTR 보고서는 비즈니스 이해관계자가 이해할 수 있는 용어로 전달해야 합니다. 'Tier 1 시스템의 MTTR은 47분입니다'라고 말하기보다는, '가장 중요한 시스템에 장애가 발생하면 평균 1시간 이내에 서비스를 복구합니다. 이는 계약상 허용된 2시간 이내입니다'라고 설명해야 합니다. 정기적인 보고는 이해관계자의 신뢰를 높이고 조직의 복원력 상태에 대한 공통된 이해를 형성합니다. 시간에 따른 MTTR 추세를 대시보드로 보고하면 프로그램의 개선을 보여 주고 DR 투자 예산의 타당성을 뒷받침할 수 있습니다.

이 lesson에서 다룬 CompTIA Security+ (SY0-701) 개념에 대한 이해도를 확인해 보십시오.

이 lesson에서는 다음을 배웠습니다. RTO는 서비스를 중단할 수 있는 최대 시간으로, 페일오버 속도 요구 사항을 결정합니다. RPO는 허용 가능한 최대 데이터 손실량으로, backup 및 복제 빈도를 결정합니다. 또한 MTTR은 실제 평균 복구 시간을 측정한 값으로, DR 프로그램의 효과를 평가하기 위해 RTO와 비교합니다. 다음에는 backup 전략인 3-2-1 규칙과 Ransomware가 파괴할 수 없는 불변 backup을 살펴봅니다.