RTO, RPO - 장애복구의 목표 기준

RTO, RPO란?

서비스를 하면서, 장애가 없다면 무척 좋겠지만 장애가 없는 시스템은 없다. 대신, 장애가 발생하더라도 장애를 어떻게 복구할지에 대한 전략과 목표가 필요하다. 이 때, 목표를 기술하는 대표적인 용어가 이 두 가지라 보면 되겠다. 실제 장애가 났다고 해보자. 아마 이 질문을 귀가 따갑도록 가장 많이 받게 될 것이다.

1) 장애 언제 복구돼? (복구 다 됐어?)
2) 고객 임팩트는? 유실된 데이터는 없어?

 

RTO = 장애 언제 복구돼?

RTO(Recovery Time Objective; 장애 복구 목표 시간)는 장애 복구를 하는데 드는 시간이다. RTO가 4시간이라고 하면, 장애 복구에 4시간이 걸린다는 의미이다. 장애가 나도 괜찮은 시스템은 거의 없지만, 장애가 발생해도 어느 정도 괜찮느냐의 지표와 관련이 있다. 목표값이기 때문이다.

 

RPO = 유실된 데이터는 없어? 언제 시점으로 복구되는 거야?

RPO(Recovery Point Objective; 데이터상 장애 복구 가능 지점)는 장애 복구 가능 지점을 나타낸다. 만약, 적어도 1시간 이전의 데이터까지는 신뢰할 수 있는 데이터가 확보되어 있고, 장애 복구를 하면 1시간 이전 상태로 돌아간다면 RPO는 1시간이 된다. RTO와 마찬가지로 목표값의 의미를 갖는데, 이는 시스템을 얼마나 자주 백업하느냐에 따라, 그 백업주기 만큼의 RPO를 보장할 수 있다.

RTO와 RPO의 관계

그림에서 보다시피, RTO는 장애 발생시점보다 미래의 어떤 지점이 된다. 반면 RPO는 장애 발생시점보다 과거의 어떤 지점이 된다. 따라서, RTO는 가로 축의 양의 방향(오른쪽)으로 확산하고, RPO는 음의 방향(왼쪽)으로 확산한다. 장애 대응력이 좋은 시스템, 즉 가용성이 좋은 시스템일수록 RTO와 RPO의 화살표가 멀리 확산하지 않고, 장애 발생시점으로 가까워진다. 그리고, 이를 완수하기 위해서는 큰 비용이 들어가거나 훌륭한 엔지니어링 노력이 수반되어야 할 것이다.

 

정리

RTO와 RPO라는 이름을 잘 새겨보아야 한다. Objective라는 말이 들어가 있다. 즉, "목표"다. 장애가 발생했을 때의 실제 측정값을 기술하는 용어가 아니라, 우리 서비스에 장애가 발생했을 때 어떻게 그 상황을 빨리 극복하느냐에 대한 목표 설정을 기술하기 위한 용어다. 즉, 적어도 과거 어느 정도의 데이터까지는 신뢰성을 보장해 줄 것인지(RPO)와, 얼마만에 복구하는 것을 목표로 할 것인지(RTO)를 기술한다. 현상에 대한 측정을 표현하는 용어는 다른 용어를 사용한다.

 

참고

MTTD, MTTR - 장애 대응 능력의 현재 지표