복구 지점 목표 및 복구 시간 목표 설명
복구 시간 및 복구 지점 목표는 가용성 솔루션의 토대가 되므로 이를 이해하는 것은 HADR(고가용성 및 재해 복구) 계획을 수립하는 데 매우 중요합니다.
복구 시간 목표
RTO(복구 시간 목표)는 중단 또는 문제가 발생한 후 리소스를 온라인으로 전환하는 데 사용할 수 있는 최대 시간입니다. 이 프로세스에 소요되는 시간이 RTO를 초과하는 경우 재정적 패널티, 작업 불가능 등의 결과가 발생할 수 있습니다. RTO는 모든 리소스를 포함한 전체 솔루션뿐만 아니라 SQL Server 인스턴스 및 데이터베이스와 같은 개별 구성 요소에 대해서도 지정할 수 있습니다.
복구 지점 목표
RPO(복구 지점 목표)는 데이터베이스를 복구해야 하는 과거의 시점으로, 비즈니스에서 받아들일 의향이 있는 데이터 손실의 최대량과 동일합니다. 예를 들어 오전 10시 정각에 SQL Server가 포함된 IaaS VM에 가동 중단이 발생하고 SQL Server 인스턴스 내 데이터베이스의 RPO는 15분이라고 가정해 보겠습니다. 인스턴스 및 해당 데이터베이스를 다시 가져오기 위해 어떤 기능이나 기술을 사용하든 최대 15분 분량의 데이터가 손실될 것으로 예상됩니다. 즉, 데이터베이스를 오전 9시 45분 이후의 시점으로 복구하여 데이터 손실을 최소화하거나 데이터 손실이 전혀 발생하지 않도록 함으로써 위에 언급한 RPO를 충족할 수 있습니다. RPO 달성 여부를 결정짓는 요인이 있을 수 있습니다.
복구 시간 및 복구 지점 목표 정의
RTO 및 RPO는 비즈니스 요구 사항에 따라 결정되지만, DBA뿐만 아니라 관리자의 기술 및 역량과 같은 다양한 기술적 요인 및 기타 요인에 따라 달라지기도 합니다. 비즈니스에서는 가동 중지 시간 또는 데이터 손실이 전혀 발생하지 않기를 바라겠지만, 이는 여러 이유로 인해 비현실적이거나 불가능할 수 있습니다. 솔루션의 RTO와 RPO는 관련된 모든 당사자 간의 공개적이고 솔직한 논의를 통해 결정되어야 합니다.
RTO와 RPO 모두와 관련하여 중요한 측면 중 하나는 가동 중지 시간의 비용을 파악하는 것입니다. 해당 수치와 더불어 가동 중지 또는 사용 불능이 비즈니스에 미치는 전반적 영향을 정의하면 솔루션을 더 쉽게 정의할 수 있습니다. 예를 들어 무엇인가를 처리할 수 없어 비즈니스에 시간당 1만 달러의 손실이 발생하거나 정부 기관으로부터 벌금 처분을 받을 수 있는 경우에는 RTO와 RPO를 정의하는 데 도움이 되는 측정 가능한 방법이 됩니다. 솔루션에 대한 지출은 가동 중지 시간으로 인한 금액 또는 비용에 비례해야 합니다. HADR 솔루션의 비용이 X달러이지만 문제가 발생할 경우 영향을 받는 시간이 몇 시간 또는 며칠이 아닌 몇 초에 불과한 상황이라면 충분히 합리적인 비용입니다.
비즈니스 외적인 관점에서 RTO는 구성 요소 수준(예: SQL Server) 및 전체 애플리케이션 아키텍처에 맞게 정의되어야 합니다. 가동 중단으로부터 복구하는 능력은 가장 약한 링크를 복구하는 능력으로 제한됩니다. 예를 들어 SQL Server 및 해당 데이터베이스를 온라인 상태로 복구하는 데는 5분이 걸리지만, 애플리케이션 서버의 경우 동일한 작업에 대해 20분이 걸린다면 전체 RTO는 5분이 아니라 20분입니다. SQL Server 환경에서는 RTO가 여전히 5분으로 정의되어 있을 수 있으나 해당 RTO로 인해 전체 복구 시간이 바뀌지는 않습니다.
RPO는 특히 데이터를 다루며, 모든 HARD 솔루션의 설계뿐 아니라 관리 정책 및 절차에 직접적인 영향을 미칩니다. 사용되는 기능은 정의된 RTO 및 RPO를 모두 지원해야 합니다. 예를 들어 트랜잭션 로그 백업이 30분마다 예약되어 있지만 RPO가 15분인 경우 데이터베이스는 사용 가능한 마지막 트랜잭션 로그 백업으로만 복구될 수 있으며 이 백업은 기껏해야 30분 전의 것입니다. 이 시간 설정은 다른 문제가 없고 백업이 테스트를 거쳐 양호한 것으로 확인되었다고 가정합니다. 환경의 각 데이터베이스에 대해 생성된 모든 백업을 테스트하기란 어려운 일이며, 백업은 파일 시스템 상의 파일일 뿐입니다. 최소한의 주기적인 복원 작업 없이는 양질의 백업을 보장할 수 없습니다. 백업 프로세스 중에 검사를 실행하면 어느 정도 신뢰도를 보장할 수 있습니다.
Always On AG(가용성 그룹) 또는 Always On FCI(장애 조치(Failover) 클러스터 인스턴스)와 같은 특정 기능의 사용은 RTO 및 RPO에도 영향을 줍니다. 기능을 어떻게 구성하느냐에 따라 IaaS 또는 PaaS 솔루션이 다른 위치로 자동으로 장애 조치(failover)될 수도 있고 그렇지 않을 수도 있으며, 이로 인해 가동 중지 시간이 길어질 수 있습니다. RTO 및 RPO를 정의하면 시간과 데이터 손실의 허용 정도를 아는 상태에서 해당 요구 사항을 지원하는 기술 솔루션을 설계할 수 있습니다. 목표가 비현실적이라는 결론이 내려지면 이에 따라 RTO와 RPO를 적절하게 조정해야 합니다. 예를 들어 원하는 RTO는 2시간이지만 백업을 대상 서버에 복사하여 복원하는 데 3시간이 걸린다면 RTO를 충족할 수 없습니다. RTO 및 RPO를 결정할 때는 해당 유형의 요인을 고려해야 합니다.
HA와 DR 모두에 대해 정의된 RTO 및 RPO가 있어야 합니다. HA는 보다 쉽게 복구할 수 있는 더욱 로컬화된 이벤트로 여겨집니다. 고가용성의 한 가지 예로 Azure 지역 내에서 AG가 한 복제본에서 다른 복제본으로 자동 장애 조치(failover)되는 경우를 들 수 있습니다. 자동 장애 조치에는 몇 초가 걸릴 수 있으며 이때 장애 조치 후에 애플리케이션이 연결될 수 있도록 만전을 기해야 합니다. SQL Server의 가동 중지 시간이 최소화됩니다. 로컬 RTO 또는 RPO는 솔루션이나 시스템의 중요한 특성에 따라 몇 분 내로 측정할 수 있습니다.
DR은 완전히 새로운 데이터 센터를 가져오는 것과 비슷합니다. 퍼즐에 많은 조각이 있는 것처럼 SQL Server는 하나의 구성 요소일 뿐입니다. 모든 항목을 온라인으로 전환하기까지는 몇 시간 이상이 걸릴 수 있습니다. 따라서 RTO와 RPO는 서로 다릅니다. HA와 DR에 동일한 기술과 기능이 사용될지라도 이에 수반되는 노력과 시간은 동일하지 않을 수 있습니다.
모든 RTO와 RPO는 공식적으로 문서화해야 하고 주기적으로 또는 필요에 따라 수정해야 합니다. 문서화한 후에는 아키텍처에 어떤 기술과 기능을 사용할 수 있을지 고려할 수 있습니다.