업무 연속성(BCP) 달성을 위해 RTO(복구시간), RPO(데이터 손실 허용치), 최대 허용 중단시간(MTDA)을 명문화합니다.
SolutionDR / BCP
복구 시나리오 가이드 (DR Playbook)
장애/재해 상황에서 RTO/RPO 목표에 맞춰 신속한 결정–실행–커뮤니케이션을 돕는 표준 플레이북입니다. 한 번의 클릭으로 시나리오 가이드를 생성하고, 실행 템플릿을 복사해 바로 적용하세요.
애플리케이션, DB, 스토리지, DNS/LB, IAM, 비밀/인증서, 로그/모니터링, 네트워크 경계(프록시 보호 포함).
예방(백업/스냅샷) → 탐지(모니터링/경보) → 완화(오토스케일/페일오버) → 복구(프로시저).
변경관리, 접근통제(IAM), 감사로그, 테스트 주기/증빙 보관, 담당 역할 지정(Incident Commander 등).
시나리오 선택 가이드
입력값을 선택하고 가이드 생성을 누르세요.추천 가이드
의사결정 트리(요약)
| 조건 | 권장 토폴로지 | 데이터 전략 | DNS/LB | 비고 |
|---|---|---|---|---|
| RTO ≤ 5분 / RPO ≤ 1분 | Active-Active (다중 리전) | 비동기 복제 + 지연 모니터 | 헬스 기반 자동 라우팅 | 쓰기 충돌 방지 설계 필요 |
| RTO ≤ 15분 / RPO ≤ 1시간 | Active-Standby (핫) | 주기적 증분 + 리플레이 | 반자동 전환(DNS TTL↓) | 비용/복잡도 균형형 |
| RTO ≤ 24시간 / RPO ≤ 24시간 | 콜드 스탠바이 | 스냅샷/백업 복원 | 수동 전환 | 최저 비용, 가장 느림 |
실행/자동화 샘플
DNS 전환(의사코드)
# 헬스가 실패하면 DR 엔드포인트로 CNAME 전환 if ! curl -fsS https://health.primary.example/status; then echo "switch to dr.example"; # provider-cli dns update --name api.example.com --cname dr.example.com --ttl 30 fi
DB 승격/재포인팅(예시)
# 읽기 전용 복제본을 승격 후 애플리케이션 포인팅 변경 # db-cli promote --target dr-replica-01 # app-cli set-config DATABASE_URL=postgres://dr-primary:5432/app
오브젝트 스토리지 읽기 전환
# 버킷 레플리케이션 상태 확인 후 리전 우선순위 변경 # objctl geo set --bucket media --prefer=dr-region
디도스보호(프록시) 모드 토글
# 엣지 프록시 보호 프로파일을 DR 정책으로 전환 # edgectl policy switch --profile dr-shield
커뮤니케이션 템플릿
① 내부 알림(엔지니어링)
[SEV-1] 서비스 장애 감지 - 발견: 10:02 KST, 헬스 체크 실패율 30%↑ - 영향: API 오류율 25%, 평균 지연 2.5s - 조치: DR Playbook AAS-15 실행, DNS TTL 30s로 하향 - 다음 업데이트: 10분 후
② 고객 공지(외부)
[공지] 일부 서비스 지연 안내 현재 일부 구간에서 지연이 발생하고 있습니다. 대체 경로로 전환 중이며, 핵심 기능은 정상 서비스 예정입니다. 불편을 드려 죄송합니다.
③ 사후 보고서 요지
사건 개요 / 타임라인 / 영향 범위 / 근본 원인 / 재발 방지 / 개선 계획
테스트 / 드릴
Tabletop — 분기 1회 시나리오 검증, R&R 점검.
Game Day — 스테이징에서 자동 전환/롤백 리허설.
Failover Drill — 주기적 실전 전환, 평균 RTO 측정.
데이터 무결성 — 승격 후 스키마/레플리카 지연 검증.
관찰성 — 로그/메트릭/트레이싱 경보 임계 재튜닝.
보안 — IAM 키/비밀/인증서 만료 및 권한 재검토.
운영 체크리스트
| 단계 | 항목 | 담당 | 완료 기준 |
|---|---|---|---|
| 탐지 | 알림 확인, 영향 범위 산정 | On-call | SEV 분류, IC 지명 |
| 완화 | 트래픽 차단/우회, 프록시 보호 강화 | NetOps | 오류율↓, 지연 안정 |
| 복구 | DNS/LB 전환, DB 승격 | App/DBA | 핵심 경로 200 OK |
| 검증 | 데이터 무결성, 기능 점검 | QA | 체크리스트 통과 |
| 사후 | RCA/개선과제 등록 | IC | 보고서 승인 |
런북 템플릿(YAML 예시)
playbook: AAS-15
trigger: healthcheck_failure
rto_target: 15m
rpo_target: 1m
steps:
- name: Reduce DNS TTL
run: provider-cli dns ttl set --name api.example.com --ttl 30
- name: Promote DR DB
run: db-cli promote --target dr-replica-01
- name: Switch Edge Policy
run: edgectl policy switch --profile dr-shield
- name: Validate
run: curl -fsS https://api.example.com/health
FAQ
RTO/RPO는 어떻게 정하나요?⌄
비즈니스 영향도(매출/규제/이미지)를 기준으로 계층별 목표를 다르게 둡니다. 핵심 경로는 낮게, 내부 시스템은 완화합니다.
자동 전환은 항상 안전한가요?⌄
쓰기가 많은 DB/캐시는 분할(brain split) 위험이 있어 반자동이 권장됩니다. 승격 전 쓰기 정지/락다운 절차를 포함하세요.
드릴 주기는 어느 정도가 적절한가요?⌄
분기 1회 Tabletop, 반기 1회 Failover Drill을 권장합니다. 드릴 후 평균 RTO/RPO를 갱신해 목표와 격차를 관리합니다.