[CLOUD-009][중급] 서비스 장애에 대비해 백업과 복구 설계하기
페이지 정보
본문
[이번 수업]
서비스가 멈추거나 데이터가 손상되면 고가용성, 백업, 재해복구를 구분해 대응해야 합니다. 세 개념의 역할과 RPO·RTO를 이해하고 가상의 장애 시간을 계산해 복구 목표를 점검합니다.
[선수지식]
CLOUD-002의 리전·가용영역과 CLOUD-007의 관리형 데이터베이스 개념을 알면 좋습니다. Python 3로 파일 하나를 실행할 수 있으면 됩니다.
[학습목표]
1. 고가용성·백업·재해복구의 역할을 구분합니다.
2. RPO와 RTO를 서비스 요구사항으로 표현합니다.
3. 복구 순서와 백업 검증을 포함한 최소 계획을 만듭니다.
[핵심개념]
고가용성은 일부 구성 요소가 고장 나도 서비스를 계속 제공하도록 중복 구성, 상태 확인, 자동 전환을 준비하는 성질입니다. 함께 고장 날 수 있는 범위를 장애 영역이라고 합니다. 같은 영역에 복제본만 두면 전원·네트워크 장애를 함께 겪을 수 있으므로 중요한 구성 요소를 독립된 영역에 나눕니다. 고가용성은 중단 시간과 영향을 줄일 뿐 장애를 없애지는 않습니다.
백업은 원본을 잃었을 때 되돌릴 별도 복사본입니다. 실시간 복제는 가용성에 도움을 주지만 삭제나 오염도 빠르게 복제할 수 있어 백업을 완전히 대신하지 못합니다. 백업은 운영 데이터와 다른 장애 영역과 권한 경계에 보관하고 암호화·보존 기간·삭제 보호·무결성 확인을 설계합니다. 생성 성공 기록뿐 아니라 실제 복원 시험으로 사용할 수 있는지 확인합니다.
재해복구는 넓은 지역 장애나 계정 침해 뒤 서비스를 복원하는 사람·절차·기술의 계획입니다. RPO(복구 시점 목표)는 시간으로 나타낸 허용 가능한 데이터 손실 범위이고, RTO(복구 시간 목표)는 업무 영향이 커지기 전에 복구해야 하는 시간입니다. 짧은 목표는 잦은 복제, 대기 자원, 자동화가 필요해 비용과 복잡성이 커질 수 있으므로 업무 영향 분석으로 현실적인 값을 정합니다.
[따라하기]
다음은 가상의 장애 기록으로 실제 RPO와 RTO를 계산하는 로컬 예제입니다. `recovery_check.py`로 저장합니다.
```python
from datetime import datetime
last_backup = datetime.fromisoformat("2026-09-04 09:00")
failure = datetime.fromisoformat("2026-09-04 09:15")
restored = datetime.fromisoformat("2026-09-04 10:00")
rpo_minutes = int((failure - last_backup).total_seconds() / 60)
rto_minutes = int((restored - failure).total_seconds() / 60)
rpo_target = 30
rto_target = 60
print("실제 RPO(분):", rpo_minutes)
print("실제 RTO(분):", rto_minutes)
print("RPO 목표 충족:", rpo_minutes <= rpo_target)
print("RTO 목표 충족:", rto_minutes <= rto_target)
```
macOS·Linux는 `python3 recovery_check.py`, Windows PowerShell은 `py recovery_check.py`로 실행합니다. 결과는 실제 RPO 15분, 실제 RTO 45분, 두 목표 충족 값은 모두 `True`입니다. 여기서는 RPO를 마지막 복구 가능 시점부터 장애까지, RTO를 장애부터 서비스 복구까지로 단순화했습니다. 실제 계획에는 데이터 검증과 정상 서비스 제공 시점까지 포함합니다.
[흔한 실수]
한 가용영역의 복제본을 재해복구라고 부르거나 스냅샷 하나만 믿으면 같은 장애와 권한 침해에 함께 영향을 받습니다. 백업 성공 표시만 확인하고 복원을 시험하지 않는 것도 위험합니다. 데이터베이스만 복구하고 설정, 네트워크, 도메인, 외부 의존성의 복구 순서를 빠뜨리면 서비스는 열리지 않습니다. 목표를 측정하지 않으면 계획의 실효성도 알 수 없습니다.
[보안 주의]
백업에도 민감정보가 있으므로 최소 권한과 별도 자격증명, 전송·저장 암호화, 접근 기록을 적용합니다. 중요한 백업은 운영 계정에서 바로 삭제할 수 없는 오프라인 또는 변경 불가 사본을 검토하고 정기적으로 무결성과 복원 가능성을 시험합니다. 사고 복구 중에는 깨끗한 격리 환경에서 데이터와 시스템의 신뢰 상태를 확인한 뒤 다시 연결합니다.
[직접 해볼 과제]
코드에서 마지막 백업을 08:00, 복구 완료를 11:30으로 바꿔 결과를 확인하세요. 목표를 넘겼다면 백업 주기, 자동 전환, 복원 자동화 중 무엇을 바꿀지 이유와 함께 적습니다.
[확인문제]
1. 실시간 복제가 백업을 완전히 대신할 수 없는 이유는 무엇인가요?
2. RPO 30분과 RTO 60분은 각각 어떤 손실과 중단을 뜻하나요?
3. 백업 생성 성공 외에 복원 시험이 필요한 이유는 무엇인가요?
[다음 학습]
CLOUD-010에서는 자원 태그와 예산 알림으로 클라우드 비용을 관찰하고 통제하는 방법을 배웁니다.
[공식 참고 자료]
- NIST SP 800-34 Rev.1 비상계획 지침: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- NIST 복구 시점 목표 용어: https://csrc.nist.gov/glossary/term/recovery_point_objective
- NIST 복구 시간 목표 용어: https://csrc.nist.gov/glossary/term/recovery_time_objective
- CISA 랜섬웨어 대응·백업 지침: https://www.cisa.gov/stopransomware/ransomware-guide
- Python datetime 공식 문서: https://docs.python.org/3/library/datetime.html
서비스가 멈추거나 데이터가 손상되면 고가용성, 백업, 재해복구를 구분해 대응해야 합니다. 세 개념의 역할과 RPO·RTO를 이해하고 가상의 장애 시간을 계산해 복구 목표를 점검합니다.
[선수지식]
CLOUD-002의 리전·가용영역과 CLOUD-007의 관리형 데이터베이스 개념을 알면 좋습니다. Python 3로 파일 하나를 실행할 수 있으면 됩니다.
[학습목표]
1. 고가용성·백업·재해복구의 역할을 구분합니다.
2. RPO와 RTO를 서비스 요구사항으로 표현합니다.
3. 복구 순서와 백업 검증을 포함한 최소 계획을 만듭니다.
[핵심개념]
고가용성은 일부 구성 요소가 고장 나도 서비스를 계속 제공하도록 중복 구성, 상태 확인, 자동 전환을 준비하는 성질입니다. 함께 고장 날 수 있는 범위를 장애 영역이라고 합니다. 같은 영역에 복제본만 두면 전원·네트워크 장애를 함께 겪을 수 있으므로 중요한 구성 요소를 독립된 영역에 나눕니다. 고가용성은 중단 시간과 영향을 줄일 뿐 장애를 없애지는 않습니다.
백업은 원본을 잃었을 때 되돌릴 별도 복사본입니다. 실시간 복제는 가용성에 도움을 주지만 삭제나 오염도 빠르게 복제할 수 있어 백업을 완전히 대신하지 못합니다. 백업은 운영 데이터와 다른 장애 영역과 권한 경계에 보관하고 암호화·보존 기간·삭제 보호·무결성 확인을 설계합니다. 생성 성공 기록뿐 아니라 실제 복원 시험으로 사용할 수 있는지 확인합니다.
재해복구는 넓은 지역 장애나 계정 침해 뒤 서비스를 복원하는 사람·절차·기술의 계획입니다. RPO(복구 시점 목표)는 시간으로 나타낸 허용 가능한 데이터 손실 범위이고, RTO(복구 시간 목표)는 업무 영향이 커지기 전에 복구해야 하는 시간입니다. 짧은 목표는 잦은 복제, 대기 자원, 자동화가 필요해 비용과 복잡성이 커질 수 있으므로 업무 영향 분석으로 현실적인 값을 정합니다.
[따라하기]
다음은 가상의 장애 기록으로 실제 RPO와 RTO를 계산하는 로컬 예제입니다. `recovery_check.py`로 저장합니다.
```python
from datetime import datetime
last_backup = datetime.fromisoformat("2026-09-04 09:00")
failure = datetime.fromisoformat("2026-09-04 09:15")
restored = datetime.fromisoformat("2026-09-04 10:00")
rpo_minutes = int((failure - last_backup).total_seconds() / 60)
rto_minutes = int((restored - failure).total_seconds() / 60)
rpo_target = 30
rto_target = 60
print("실제 RPO(분):", rpo_minutes)
print("실제 RTO(분):", rto_minutes)
print("RPO 목표 충족:", rpo_minutes <= rpo_target)
print("RTO 목표 충족:", rto_minutes <= rto_target)
```
macOS·Linux는 `python3 recovery_check.py`, Windows PowerShell은 `py recovery_check.py`로 실행합니다. 결과는 실제 RPO 15분, 실제 RTO 45분, 두 목표 충족 값은 모두 `True`입니다. 여기서는 RPO를 마지막 복구 가능 시점부터 장애까지, RTO를 장애부터 서비스 복구까지로 단순화했습니다. 실제 계획에는 데이터 검증과 정상 서비스 제공 시점까지 포함합니다.
[흔한 실수]
한 가용영역의 복제본을 재해복구라고 부르거나 스냅샷 하나만 믿으면 같은 장애와 권한 침해에 함께 영향을 받습니다. 백업 성공 표시만 확인하고 복원을 시험하지 않는 것도 위험합니다. 데이터베이스만 복구하고 설정, 네트워크, 도메인, 외부 의존성의 복구 순서를 빠뜨리면 서비스는 열리지 않습니다. 목표를 측정하지 않으면 계획의 실효성도 알 수 없습니다.
[보안 주의]
백업에도 민감정보가 있으므로 최소 권한과 별도 자격증명, 전송·저장 암호화, 접근 기록을 적용합니다. 중요한 백업은 운영 계정에서 바로 삭제할 수 없는 오프라인 또는 변경 불가 사본을 검토하고 정기적으로 무결성과 복원 가능성을 시험합니다. 사고 복구 중에는 깨끗한 격리 환경에서 데이터와 시스템의 신뢰 상태를 확인한 뒤 다시 연결합니다.
[직접 해볼 과제]
코드에서 마지막 백업을 08:00, 복구 완료를 11:30으로 바꿔 결과를 확인하세요. 목표를 넘겼다면 백업 주기, 자동 전환, 복원 자동화 중 무엇을 바꿀지 이유와 함께 적습니다.
[확인문제]
1. 실시간 복제가 백업을 완전히 대신할 수 없는 이유는 무엇인가요?
2. RPO 30분과 RTO 60분은 각각 어떤 손실과 중단을 뜻하나요?
3. 백업 생성 성공 외에 복원 시험이 필요한 이유는 무엇인가요?
[다음 학습]
CLOUD-010에서는 자원 태그와 예산 알림으로 클라우드 비용을 관찰하고 통제하는 방법을 배웁니다.
[공식 참고 자료]
- NIST SP 800-34 Rev.1 비상계획 지침: https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- NIST 복구 시점 목표 용어: https://csrc.nist.gov/glossary/term/recovery_point_objective
- NIST 복구 시간 목표 용어: https://csrc.nist.gov/glossary/term/recovery_time_objective
- CISA 랜섬웨어 대응·백업 지침: https://www.cisa.gov/stopransomware/ransomware-guide
- Python datetime 공식 문서: https://docs.python.org/3/library/datetime.html
- 이전글[DEVOPS-009][중급] 서비스 목표와 오류 허용량 계산하기 26.09.04
- 다음글[NET-009][중급] 방화벽 규칙과 네트워크 분리 이해하기 26.09.04
댓글목록
등록된 댓글이 없습니다.