[Infra] RTO / RPO란?

장애 대응을 "느낌"이 아니라 "숫자"로 말하기

 

"장애 나면 빨리 복구하겠습니다"라는 말은 누구나 할 수 있다. 하지만 "얼마나 빨리", "데이터는 얼마나 잃어도 되는가"를 숫자로 답하지 못하면 그건 계획이 아니라 다짐에 불과하다. RTO와 RPO는 바로 이 두 질문에 숫자로 답하기 위한 지표다.

---

RTO — 얼마나 빨리 복구할 것인가

RTO(Recovery Time Objective, 복구목표시간)는 장애가 발생한 시점부터 서비스가 정상적으로 복구되기까지 허용 가능한 최대 시간을 의미한다. 예를 들어 RTO가 4시간이라면, 장애가 나더라도 4시간 안에 서비스를 다시 정상 가동시켜야 한다는 목표치다.

내 출근 알람

RTO를 짧게 잡을수록 요구되는 인프라 수준은 확연히 달라진다. RTO가 며칠 단위로 여유롭다면 백업 테이프에서 데이터를 복원하고 서버를 다시 세팅하는 방식으로도 충분하다. 하지만 RTO가 몇 분 단위로 촘촘하다면, 장애 발생 즉시 대기 중이던 예비 시스템으로 자동 전환되는 구조(Active-Standby 혹은 Active-Active)를 미리 구축해둬야 한다.

즉 RTO는 "복구 방법의 정교함"을 결정하는 지표다.

---

RPO — 얼마나 되돌아가도 되는가

RPO(Recovery Point Objective, 복구목표시점)는 장애 발생 시 허용 가능한 최대 데이터 손실 범위를 의미하며, 마지막으로 백업된 시점을 기준으로 계산한다. RPO가 1시간이라면, 장애 직전 1시간 이내의 데이터는 유실될 수 있다는 뜻이다.

돌아가자

 

이 지표가 RTO와 결정적으로 다른 지점은, RTO가 "시간이 얼마나 걸리는가"를 묻는 반면 RPO는 "과거의 어느 시점으로 되돌아가는가"를 묻는다는 것이다. 예를 들어 밤 12시에 백업을 한 번 돌리는 시스템에서 오전 11시에 장애가 났다면, 자정부터 11시까지 쌓인 11시간치 데이터는 전부 사라진다. RPO를 1시간으로 좁히고 싶다면 백업 주기를 하루 한 번이 아니라 매시간, 혹은 실시간 복제 수준으로 끌어올려야 한다.

---

왜 두 지표를 같이 봐야 하는가

RTO와 RPO는 각각 "복구 속도"와 "데이터 손실 허용치"라는 서로 다른 축을 다루기 때문에, 하나만 관리해서는 재해 복구 전략이 완성되지 않는다.

 

예를 들어 RTO는 짧게 잡아 몇 분 안에 서비스를 복구하도록 시스템을 이중화해뒀다 해도, RPO를 하루 단위로 느슨하게 잡았다면 서비스는 금방 복구되지만 복구된 화면에는 하루 전 데이터가 떠 있는 상황이 벌어진다.

반대로 RPO를 실시간 복제 수준으로 촘촘히 잡아 데이터 손실은 거의 없더라도, RTO를 며칠 단위로 느슨하게 잡았다면 데이터는 안전하게 보존돼 있어도 서비스 자체는 며칠간 먹통이 된다.

 

결국 두 지표는 짝을 이뤄야 하며, 서비스의 성격에 따라 우선순위가 달라진다. 금융 거래 시스템처럼 데이터 무결성이 생명인 서비스는 RPO를 극도로 짧게(초 단위 실시간 복제) 가져가고, 콘텐츠 스트리밍처럼 잠깐 멈춰도 큰 피해가 없는 서비스는 RTO/RPO 모두 상대적으로 여유 있게 잡아 비용을 아낀다.

---

짧을수록 비용이 오르는 이유

RTO와 RPO를 짧게 설정하는 것 자체는 목표 설정에 불과하지만, 그 목표를 실제로 달성하려면 그만큼의 인프라 투자가 따라온다.

출처: https://itwiki.kr/w/RPO

 

RPO를 줄이려면 백업 주기를 촘촘히 해야 하고, 이는 스토리지 용량과 네트워크 대역폭 소비를 직접적으로 늘린다. 실시간 복제 수준까지 가려면 별도의 복제 전용 인프라와 이를 유지하는 운영 비용까지 추가된다.

RTO를 줄이려면 평소에는 놀고 있는 예비 시스템을 상시 대기시켜야 하는데, 이 예비 시스템 자체가 이중으로 드는 고정 비용이다. Active-Active 구성처럼 예비 시스템도 실제 트래픽을 함께 처리하도록 만들면 자원 낭비는 줄지만, 그만큼 시스템 복잡도와 데이터 동기화 난이도는 올라간다.

 

즉 RTO/RPO를 0에 가깝게 만드는 것은 기술적으로는 가능하지만, 비용과 복잡도가 기하급수적으로 증가하기 때문에 실무에서는 "이 서비스가 감당해야 할 손실과 감당할 수 있는 비용" 사이에서 현실적인 목표치를 정하는 것이 핵심이다.

---

마무리

장애 대응은 콩쥐처럼.

 

RTO와 RPO는 결국 "장애가 났을 때 우리는 무엇을 얼마나 포기할 수 있는가"를 미리 합의해두는 작업이다.

이 숫자를 정하지 않은 채 재해 복구 체계를 설계하는 건, 목적지 없이 지도를 그리는 것과 같다.

 

반대로 이 두 지표를 명확히 정의해두면, 백업 주기부터 이중화 구조, 심지어 클라우드 리전 선택까지 이후의 모든 인프라 설계 결정이 이 숫자를 기준으로 자연스럽게 정렬된다.