DR 전략 및 RTO/RPO
1) 기본 원칙
1. 이전의 목표. 먼저 RTO/RPO와 중요한 시나리오를 공식화 한 다음 기술을 선택합니다.
2. 중요성에 의한 세분화. 모든 서비스에 "골드" 가 필요한 것은 아닙니다 비즈니스 중요도별로 나눕니다.
3. 데이터는 하드웨어보다 DR. 일관성, 복제, 손상 감지 및 복구 지점의 핵심입니다.
4. 자동화 및 검증 가능성. DR은 IaC, 회귀 회귀 테스트 및 원격 측정 없이는 의미가 없습니다.
5. 가르침과 증거. 정기적 인 "게임 데이" 가없는 계획은 준비의 환상입니다.
6. 안전과 준수. 암호화, 격리, WORM/불변성 백업, DPA/관할 구역.
2) 이용 약관
RTO-이벤트 순간부터 서비스가 "정상" 으로 복원 될 때까지의 시간.
RPO는 복구시 마지막 건강한 데이터 포인트의 "연령" 입니다.
RLO (Recovery Level Objective) - 복원해야하는 기능 수준 (최소 실행 가능한 서비스).
MTD (Maximum Tolerable Downtime) -비즈니스가 용납 할 수없는 피해를 입은 임계 값.
RTA/RPA (실제) -실무의 실제 시간/복구 지점.
커뮤니케이션: RTO 계정 MTD; RPA 지정 RPO. 목표와 사실 사이의 격차는 사후 부검과 개선의 주제입니다.
3) DR 전략 클래스 (준비 수준)
4) 우리가 방어하는 시나리오
지역/클라우드/데이터 센터 손실 (전기, 네트워크, 공급자).
데이터 손상/운영자 오류 (삭제, 파손 된 복제본, 논리적 손상).
악성 코드/랜섬웨어.
릴리스/구성 결함 (대량 중단).
중독의 붕괴 (KMS, DNA, 비밀, 지불 제공 업체).
법적 사건 (관할 구역에서 데이터 수출 차단, 금지).
각 시나리오에 대해 RTO/RPO, DR 레벨, 플레이 북, 책임있는 사람을 지정하십시오.
5) 데이터 전략 (RPO의 키)
5. 백업 1 개
전체 + 증분 + 트랜잭션 로그 (DB 용).
불변의/WORM 저장 및 오프라인 사본 ("에어 갭").
메타 데이터 및 암호화 서명이있는 백업 카탈로그; 예정된 테스트가 복원됩
5. 2 복제
동기식 (낮은 RPO, TP latentnost, 전리품 전파 위험).
비동기식 (perf에 미치는 영향, RPO> 0; 부패한 아이와 결합).
스트리밍 복제 및 상태 재구성을위한 CDC (Change Data Capture).
5. 3 논리적 부패로부터 보호
창이있는 PITR (Versioning/" points in time) "
불변량 서명 (밸런스, 합계, chexum) 은 "파손 된" 데이터를 조기에 탐지합니다.
즉각적인 손상에 대한 버퍼로서 "느린" 복제 채널 (15-60 분 지연).
python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)6) 응용 프로그램, 상태, 캐시
Stateless 레이어-모든 지역에서 스케일 및 재시작 (Git의 이미지/차트/선언).
상태 (DB/caches/kew): 진실의 원천은 DB 중 하나입니다. 캐시와 지수는 과도하게 생성 가능합니다.
이념과 재구성-이벤트의 재전달은 허용됩니다. Outbox/받은 편지함, dedup 및 버전을 사용하십시오.
7) 네트워크 및 진입 점
GSLB/DNS- 페일 오버: 대기 시간/건강 기반, 짧은 TTL-충돌 창.
Anycast/L7 프록시: 단일 IP, 지역 건강 라우팅.
지역 도메인 및 관할 정책 (PII의 지오 피닝).
인증서 파일/KMS: 여분의 체인, 이중 키.
python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()8) 운영 모델 및 자동화
IaC/GitOps: 두 번째 지역 인프라 = 코드, "단일 버튼" 배포.
코드로서의 정책: 게이트 "DR은/백업/경고를 나타내지 않으며 릴리스도 없습니다".
런북: 단계별 명령어 및 두 영역과 동일한 "빨간색 버튼".
비밀: 단기 크레딧, OIDC 연맹, 타협/리콜 계획.
rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}9) 연습 및 테스트 (게임 일)
시나리오 테이블: 데이터베이스 손실, "파손 된" 데이터, KMS 장애, 지역 강하, 갑작스런 탈출 한계.
빈도: 미션 크리티컬을위한 분기 별; 6 개월에 한 번-나머지는.
운동 지표: RTA/RPA vs 목표, 자동 단계 비율, 수동 중재 수, 플레이 북 오류.
릴리스의 혼돈 연기: 종속성 저하가 DR 경로를 "파괴" 해서는 안됩니다.
T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements10) 플레이 북 (표준 템플릿)
yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"11) DR 관측 지표
Replica lag (sec), RPO 드리프트 (대상과 실제 RPO의 차이).
SLI 복원: 환경별 차가운/따뜻한 복구 시간.
적용 범위: 플레이 북/백업/PITR
드릴 점수: 자동 단계의 비율, RTA 분포, 오류율.
불변성: WORM/air-gapped 백업의%.
이벤트 메트릭: 가짜 후 대기열 길이/재 구동 속도.
12) 비용 및 절충
CapEx/OpEx: 따뜻한 스탠드는 Active/Active보다 저렴하지만 파일럿 라이트보다 비쌉니다.
탈출: 지역 간/클라우드 간 복제에는 비용이 듭니다. 캐시/압축/로컬 집계.
RTO/RPO vs $: 각각의 "9" 가용성과 1 초의 RPO는 비즈니스와 조화를 이룹니다.
녹색 창: 배치 복제-저렴한/" 녹색 "시간.
13) 안전 및 준수
"휴식 중" 및 "운송 중" 암호화는 지역별로 KMS 도메인을 분리합니다.
불변의 백업, 랜섬웨어 보호: "3-2-1" (3 부, 2 개 미디어, 1 개 오프라인), MFA 삭제.
Jurisdictions: PII 용 지오 피닝, 백업 현지화, TTL 위의 Legal Hold.
시간 액세스: DR 운영에 대한 임시 역할, 감사 로그.
14) 반 패턴
"나중에 계획을 작성합시다" -운동없이 DR.
논리적 손상으로부터 보호하지 않고 복제하면 오류가 즉시 곱해집니다.
하나의 KMS/비밀 지역-feilover가 불가능합니다.
규칙적인 복원없이 백업- "Shredinger" DR.
지역 간 밀접하게 관련된 동기 트랜잭션은 캐스케이드 대기 시간/하강입니다.
우선 순위 없음: 모든 것에 대해 동일한 DR 수준 (비싸고 쓸모없는).
15) 건축가 점검표
1. 서비스 및 시나리오별로 정의 된 RTO/RPO/RLO?
2. 분류 된 데이터: 진실의 출처, PITR/창, WORM/불변성?
3. 서비스 당 DR (백업/복원, 파일럿, 따뜻함, A/P, A/A) 이 선택됩니까?
4. 네트워크: GSLB/Anycast, 여백이있는 인증서/키, 읽기 전용 플래그?
5. 앱: dempotence, Outbox/받은 편지함, 트랜잭션 상쇄?
6. IaC/GitOps/Policy as Code: 두 번째 지역을 출시 할 때마다 클릭하십니까?
7. 드릴: 스케줄, KPI RTA/RPA, 교육 후 활동?
8. 모니터링: 지연, RPO 드리프트, 복원 SLI, 드릴 스코어, 불변의 백업?
9. 보안/준수: KMS Domains, Jurisdictions, Legal Hold?
10. 비용: 예산, 녹색 창, 경제적으로 건전한 수준?
16) 미니 레시피와 스케치
16. Postgres 용 PITR 1 개 (아이디어):
bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...16. 2 논리적 손상으로부터 보호 (복제 지연):
yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption16. 3 트래픽 전환 (GSLB 의사 API):
bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 10016. 4 feilover (pseudocode) 후 불변량을 확인하십시오
python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))결론
DR은 피해가 증가하는 것보다 기술 및 조직 결정을 더 빨리 내릴 수있는 능력입니다. 현실적인 RTO/RPO를 식별하고, 충분한 가용성을 선택하고, 인프라와 점검을 자동화하고, 정기적으로 운동하고, 실제 RTA/RPA를 측정합니다. 그런 다음 사고는 재난으로 바뀌지 않고 예측 가능한 결과로 통제 된 사건으로 바뀝니다.