AWS 재해복구는 어느 수준까지 준비해야 합니까

재해복구 계획을 요구받으면 대개 “어느 수준으로 할까”부터 묻게 됩니다. 그런데 그 질문에는 답이 없습니다. 수준은 고르는 것이 아니라 두 숫자에서 따라 나오는 것이기 때문입니다.

이 글은 그 두 숫자가 무엇인지, AWS가 제시하는 네 가지 전략이 각각 무엇을 상시로 켜 두는지, 그리고 운영 중인 서비스에 어느 전략이 적합한지를 판단하는 순서로 정리합니다.

백업, 복구, 재해복구는 서로 다릅니다

세 낱말이 자주 섞여 쓰이는데 가리키는 범위가 다릅니다.

• 백업 — 데이터의 사본을 다른 곳에 두는 일입니다. 여기까지는 자료의 문제입니다.
• 복구 — 그 사본으로 데이터를 되돌리는 일입니다. 여기부터 절차의 문제가 됩니다.
• 재해복구 — 정해진 시간 안에 서비스를 다시 세우는 일입니다. 데이터뿐 아니라 네트워크 구성, 접근 권한, 배포 절차, 그리고 그것을 실행할 사람과 순서가 함께 있어야 성립합니다.

백업만 갖춘 상태를 재해복구를 갖춘 것으로 오해하는 경우가 있습니다. 백업이 있어도 복구가 안 되는 구조적 이유는 백업은 있는데 왜 복구가 안 되는가에서 따로 다뤘으므로, 이 글은 복구가 된다고 가정한 뒤 어느 속도로 될 것인가에서 시작합니다.

수준을 정하는 두 숫자 — RTO와 RPO

• RTO(Recovery Time Objective) — 사고가 난 시점부터 서비스가 다시 정상 동작할 때까지 허용되는 시간입니다. “4시간 안에는 다시 열려야 한다”가 RTO입니다.
• RPO(Recovery Point Objective) — 사고 직전으로부터 잃어도 되는 데이터의 범위입니다. “마지막 15분치까지는 잃어도 된다”가 RPO입니다.

두 숫자는 성격이 다릅니다. RTO는 얼마나 빨리 복구할 수 있는 구성을 평소에 유지하고 있는가에 달려 있고, RPO는 데이터를 얼마나 자주 다른 곳으로 옮기고 있는가에 달려 있습니다. 그래서 한쪽만 개선하는 것도 가능합니다. 예를 들어 데이터는 실시간으로 복제하면서 애플리케이션을 배포하는 절차는 수작업인 구성은 RPO가 짧고 RTO가 깁니다.

두 숫자는 기술 조직이 정하는 값이 아닙니다. 얼마의 손실을 감수할 것인가에 대한 판단이므로 사업 부서가 정하고, 기술 조직은 그 숫자가 실현 가능한지와 무엇이 필요한지를 답합니다. 그리고 업무별로 나눠 정하는 편이 현실적입니다 — 결제 처리와 사내 게시판에 같은 기준을 적용하면 비용이 필요 이상으로 커집니다.

AWS가 제시하는 네 가지 전략

AWS는 재해복구 전략을 네 가지로 나눠 설명합니다. 이 네 가지는 등급이 아니라 상시로 무엇을 켜 두는가의 차이입니다.

핵심은 백업·복구에서 멀티사이트로 갈수록 평소에 쓰지 않는 자원이 늘어난다는 것입니다. 복구 시간과 상시 비용은 맞바꾸는 관계이고, 어느 쪽을 우선할지를 RTO가 정합니다.

금액은 구성마다 다릅니다. 상시로 켜 두는 자원의 종류와 양이 달라 일반화할 수 있는 수치가 없습니다. 지금 구성을 기준으로 한 추정이 필요하시면 AWS 비용 분석 · 간편 견적에서 직접 계산해 보실 수 있습니다.

자주 어긋나는 세 가지

다중 가용 영역(Multi-AZ)은 재해복구가 아닙니다

자주 혼동되는 부분입니다. 다중 가용 영역은 같은 리전 안의 물리적으로 분리된 구역에 이중화해 한 구역의 장애를 견디는 가용성 구성입니다. 재해복구는 리전 단위의 사고나 데이터 자체의 손상처럼 그 범위를 넘는 상황을 다룹니다.

차이가 분명해지는 경우는 데이터가 망가졌을 때입니다. 운영 실수로 테이블을 지웠거나 악성 코드가 파일을 암호화하면, 그 상태가 이중화된 쪽에도 그대로 복제됩니다. 가용성 구성은 상태를 복제하는 것이 목적이므로 잘못된 상태도 그대로 복제합니다. 되돌리려면 시점을 거슬러 갈 수 있는 백업이 있어야 합니다.

복제와 백업은 목적이 다릅니다

같은 이유로, 실시간 복제를 백업의 대체물로 쓰면 안 됩니다. 복제는 지금 상태를 같게 유지하는 기능이고 백업은 과거 어느 시점으로 되돌릴 수 있게 하는 기능입니다. 사람의 실수와 악성 코드에 대응할 수 있는 것은 백업입니다.

문서의 RTO는 훈련으로 검증해야 합니다

문서에 “RTO 4시간”이라고 적는 것과 실제로 4시간 안에 복구할 수 있는 것은 다릅니다. 둘 사이의 차이는 대개 사고 당일에 드러납니다. 그래서 복구 훈련을 주기적으로 실시하고 걸린 시간을 기록해 정해 둔 값과 대조하는 절차까지가 계획에 들어갑니다. 훈련으로 검증되지 않은 절차서는 사고 당일에 그대로 실행되기 어렵습니다.

어느 수준이 맞는지 정하는 순서

1. 업무를 나눕니다. 모든 업무에 같은 기준을 적용하지 않습니다. 중단되면 곧바로 매출이나 법적 의무에 영향을 주는 업무와, 하루 중단되어도 되는 업무를 먼저 구분합니다.
2. 업무별로 RTO와 RPO를 사업 부서와 합의합니다. 이 단계가 빠지면 이후의 모든 판단이 근거를 잃습니다.
3. 지금 구성이 그 숫자를 만족하는지 계산합니다. 데이터를 옮기는 주기, 자원을 만드는 데 걸리는 시간, 배포 절차에 사람이 개입하는 지점을 각각 재서 더합니다.
4. 기준에 못 미치는 업무만 상시로 켜 두는 범위가 더 넓은 전략으로 옮깁니다. 전부를 한 수준으로 맞추지 않습니다.
5. 훈련 주기와 기록 방식을 함께 정합니다. 여기까지가 계획입니다.

3번에서 자주 빠지는 것이 사람이 개입하는 시간입니다. 자동화되지 않은 단계에는 담당자가 연락을 받고 대응을 시작하기까지의 시간이 더해집니다. 사고는 업무 시간에만 나지 않으므로, 이 시간을 빼고 계산하면 실제보다 낙관적인 숫자가 나옵니다. 장애 대응에서 역할과 기록이 왜 먼저인지는 AWS 장애 대응에 반드시 필요한 역할과 기록에서 다뤘습니다.

운영을 위탁할 때 정해 둘 책임 범위

빌드업웍스의 운영 경험에서는, 재해복구가 비어 있는 경우보다 문서로는 있지만 검증된 적이 없는 경우가 더 자주 문제가 됩니다. 계획서와 실제 구성이 어긋나는 일은 드러나지 않게 진행되고, 그 사실은 훈련하거나 사고가 나야 드러납니다.

운영을 위탁한다면 복구 절차의 유지와 훈련 실행, 그 결과 기록을 누가 맡는지는 계약 범위에 따로 적어야 하는 항목입니다. 그리고 어느 수준으로 할 것인가는 사업 판단이므로, 운영을 위탁받은 쪽이 대신 정하지 않습니다. 운영 위탁의 수준을 어떻게 정하는지는 운영을 맡기기로 했다면 어느 수준으로 계약해야 합니까에 정리돼 있습니다.

다음 단계

현재 구성이 어느 수준인지부터 확인하시는 것이 순서상 먼저입니다. AWS 무료 점검에서 백업과 복구 구성이 현재 어떤 상태인지 함께 정리해 드립니다.

인프라를 새로 세우거나 옮기는 과정에서 재해복구 수준을 함께 정해야 하는 상황이라면 AWS 구축 · 이전에서 설계 범위를 확인하실 수 있습니다. 업무별 RTO와 RPO 기준을 어떻게 나눌지 함께 정리하고 싶으시면 상담 신청으로 연락 주십시오.

참고 자료

• AWS 백서 — Disaster Recovery of Workloads on AWS
• AWS Well-Architected — Reliability Pillar
• Amazon RDS — Multi-AZ 배포
• AWS Backup 사용 설명서