일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- IntelliJ
- PETERICA
- 코틀린 코루틴의 정석
- mysql 튜닝
- 티스토리챌린지
- 오블완
- Pinpoint
- MySQL
- minikube
- Java
- 정보처리기사 실기 기출문제
- CKA 기출문제
- kotlin
- 정보처리기사 실기
- Elasticsearch
- 정보처리기사실기 기출문제
- Linux
- kotlin querydsl
- Spring
- aws
- CKA
- 공부
- kotlin coroutine
- 기록으로 실력을 쌓자
- AI
- APM
- CloudWatch
- Kubernetes
- kotlin spring
- AWS EKS
- Today
- Total
피터의 개발이야기
RTO와 RPO: 재해 복구 계획의 핵심 지표 본문
ㅁ 들어가며
재해 복구 계획을 수립할 때 가장 중요한 두 가지 지표가 있다. 바로 RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)이다. 이 두 지표에 의미를 정리하였다.
ㅁ RTO (Recovery Time Objective): 목표 복구 시간
RTO는 재해 발생 후 시스템을 복구하여 정상 운영 상태로 돌아가는 데 걸리는 최대 허용 시간을 의미한다.
예를 들어, RTO가 4시간이라면 재해 발생 후 4시간 이내에 시스템이 정상 작동해야 한다는 의미이다.
- 정의: 애플리케이션이 오프라인 상태로 있을 수 있는 최대 허용 시간
- 목적: 비즈니스가 감당할 수 있는 최대 다운타임을 결정
- 특징: 시스템 복구 속도와 직접적으로 연관됨
ㅁ RPO (Recovery Point Objective): 목표 복구 시점
RPO는 데이터 손실과 관련된 지표로, 비즈니스가 감당할 수 있는 최대 데이터 손실 허용 기간을 나타난다.
예를 들어, RPO가 1시간이라면 최대 1시간 전의 데이터까지는 손실을 감수할 수 있다는 의미이다.
- 정의: 심각한 문제로 인해 애플리케이션으로부터 데이터 손실 상태가 지속되는 최대 허용 시간
- 목적: 허용 가능한 데이터 손실량 결정
- 특징: 백업 빈도와 직접적으로 연관됨
ㅁ RTO와 RPO의 중요성
비즈니스 연속성 보장: 적절한 RTO와 RPO 설정은 재해 발생 시 비즈니스 운영의 빠른 복구를 가능하게 한다.
비용 최적화: RTO와 RPO 값에 따라 필요한 인프라와 백업 전략이 결정되므로, 비용 효율적인 재해 복구 계획 수립이 가능하다.
리스크 관리: 비즈니스에 중요한 애플리케이션과 데이터에 대해 적절한 RTO와 RPO를 설정함으로써 재해로 인한 리스크를 효과적으로 관리할 수 있다.
ㅁ AWS 재해 복구 전략
ㅇ AWS는 4가지 재해 복구 전략을 가지고 있다.
- 백업 및 복구(Backup & Restore):
- RPO: 시간 단위
- RTO: 24시간 이내
- 주기적인 스냅샷을 통해 데이터와 애플리케이션을 보조 리전에 백업
- 파일럿 라이트(Pilot Light):
- RPO: 분 단위
- RTO: 시간 단위
- 시스템의 핵심 요소를 보조 리전에 액티브 상태로 유지
- 웜 스탠바이(Warm Standby):
- RPO: 초 단위
- RTO: 분 단위
- 축소된 버전의 전체 환경을 보조 리전에 구성
- 멀티 사이트 액티브/액티브(Multi-site Active/Active):
- RPO: 대기 시간 없음
- RTO: 초 단위
- 워크로드를 여러 리전에 배포하여 실시간으로 백업\
이러한 전략들은 RTO(Recovery Time Objective)와 RPO(Recovery Point Objective)에 따라 선택되며, 왼쪽에서 오른쪽으로 갈수록 더 높은 가용성과 비용이 요구된다.
ㅁ 마무리
RTO와 RPO는 재해 복구 계획의 근간을 이루는 중요한 지표이다. 비즈니스의 특성과 요구사항에 맞게 이 두 지표를 신중히 설정하고 관리함으로써, 효과적이고 효율적인 재해 복구 전략을 수립할 수 있다. 각 전략은 비즈니스 요구사항, 허용 가능한 다운타임, 데이터 손실 허용 범위, 그리고 비용을 고려하여 선택해야 한다. 특히 멀티 사이트 액티브/액티브 전략은 가장 높은 가용성을 제공하지만, 복잡성과 비용 측면에서 신중한 검토가 필요하다.
ㅁ 함께 보면 좋은 사이트
ㅇ AWS - Establishing RPO and RTO Targets for Cloud Applications
ㅇ RTO (복구 시간) / RPO (복구 지점) 무슨 의미일까?
ㅇ AWS 기반 재해 복구(DR) 아키텍처, 1부: 클라우드에서의 재해 복구 전략
'DevOps' 카테고리의 다른 글
Ubuntu 버전 및 EOL(End of Life) 날짜 정리 (0) | 2025.02.05 |
---|---|
[DevOps] Bamboo: DevOps와 CI/CD를 위한 강력한 도구 (0) | 2024.12.17 |
[k6] k6를 이용한 다중 부하 테스트 설정 및 실행 방법 (0) | 2024.12.17 |
TinyStatus란, 간단하고 가벼운 상태 페이지 만들기 (0) | 2024.11.17 |
네트워크 레이아웃에서 SSL이란? (0) | 2024.06.20 |