재난 회복 시나리오
1) DR이 필요한 이유와 목적은 무엇입니까
재난 복구 (DR) 는 재난 후 서비스 복구를위한 일련의 아키텍처, 프로세스 및 교육 (데이터 센터/지역 고장, 데이터 손실, 질량 구성 오류) 입니다. DR의 목표는 고객의 신뢰와 규제 준수를 유지하면서 통제 된 비용과 위험으로 목표 RTO/RPO를 충족시키는 것입니다.
RTO (Recovery Time Objective) -허용 다운 타임.
RPO (Recovery Point Objective) -허용 가능한 데이터 손실 (마지막 일관된 지점 이후 시간).
RLO (복구 수준 목표): 먼저 반환해야하는 기능 수준 (최소 실행 가능한 서비스).
2) 중요도에 따른 시스템 분류
계층 0 (필수): 결제, 로그인, KYC, 핵심 거래-RTO
1 단계 (높음): 작동 패널, D-1-RTO
2 단계 (평균): 백 오피스, 거의 실시간 분석-RTO
3 단계 (낮음): 중요하지 않은 보조-RTO
서비스 카탈로그의 각 서비스에 Tier + 대상 RTO/RPO 할당; 결정과 예산을 확인해야합니다.
3) 위협 모델 및 시나리오
인공: AZ/지역/공급자 실패, 네트워크 저하/DNA, 데이터베이스/스토리지 오류, 대량 릴리스 버그.
인적 요인: 잘못된 구성 요소/IaC, 데이터 삭제, 주요 타협.
자연/외부: 화재/홍수, 정전, 법적 차단.
각각에 대해 확률/영향을 평가하고 DR 시나리오 및 플레이 북에 링크하십시오.
4) DR 아키텍처 패턴
1. 액티브 액티브 (다중 지역): 두 지역 모두 트래픽을 제공합니다.
장점: 최소 RTO/RPO, 높은 안정성.
단점: 데이터 복잡성/일관성, 높은 가격.
어디에: 읽기 무거운, 캐시 된로드, 무국적 서비스, 멀티 마스터 DB (엄격한 충돌 규칙).
2. 액티브 패시브 (Hot Standby): 핫 패시브는 완전히 가열 된 카피를 보유합니다.
RTO: 분; RPO: 분. 자동화 된 장애 및 복제가 필요합니다.
3. 따뜻한 대기: 자원의 일부가 예열되어 사고시 확장됩니다.
RTO: 수십 분; RPO: 15-60 분. 더 경제적이지만 더 길다.
4. 파일럿 라이트: 최소 "스파크" (메타 데이터/이미지/스크립트) + 빠른 확산.
RTO: 시간; RPO: 시간. 저렴하고 2-3 단계에 적합합니다.
5. 백업 및 복원: 오프라인 백업 + 수동 예열.
RTO/RPO: 시간/일. 낮은 중요도와 보관소에만 해당됩니다.
5) 데이터와 일관성
데이터베이스 복제:- 동기식-거의 제로 RPO이지만 q latentnost/stoimost.
- 비동기식-더 나은 성능, RPO> 0 (꼬리 꼬리).
- 일관성: 모델을 선택하십시오 (강력/최종/인과). 엄격히, 분석에 대한 지불은 최종적으로 이루어집니다.
- 스냅 샷: 일관된 포인트를 정기적으로 + 저장 로그 (WAL/redo) 로 만듭니다.
- 지역 간 거래: 2PC 피하기; dempotent 작업, deli-and-reputy (중복 재 시도), 이벤트 소싱 사용.
- 대기열/버스: 복제/미러링, DLQ, 소비자의 주문 및 demempotency.
6) 네트워크, 트래픽 및 DNSName
GSLB/Anycast/DNA: 실패/실패 정책, 낮은 TTL (그러나 너무 많지는 않음), 여러 지역의 건강 점검.
L7 라우팅: 지역 맵, 열화 플래그 (함수 제한).
개인 링크/VPN: 공급자에 대한 백업 채널 (PSP/KYC/CNC).
속도 제한: 복구 중 폭풍 방지.
7) Stateful vs Stateless
Stateless는 스크립트/autoscale에 의해 수행됩니다. Statefall은 일관된 데이터 전략 (복제, 스냅 샷, 복제 프로모션, 쿼럼) 이 필요합니다.
캐시/세션: 교차 영역 복제 또는 로그로 다시 시드 할 수있는 외부 (Redis/Memcashed); 토큰 (JWT) 또는 공유 스토리지에서 세션을 개최합니다.
8) DR 트리거 및 자동화
SLO gardrails 및 쿼럼 프로브 → 자동 지역 장애 런북입니다.
사고시 동결 변경: 관련없는 릴리스/마이그레이션을 차단하십시오.
코드로서의 인프라: 스탠드 바이 표현 배포, 드리프트 점검.
역할 프로모션: 복제본 DB + 작가/비밀 드레싱을 자동으로 홍보합니다.
9) 통신 및 준수
전쟁 실: IC/TL/Comms/Scribe; SEV 업데이트 간격.
상태 페이지: 영향력의 지리, ETA, 해결 방법.
규제: 알림 마감일, 데이터 보안, 변경 불가능한 증거 저장소.
파트너/공급자: 확인 된 연락처, 전용 채널.
10) DR 테스트 및 운동
테이블 탑: 시나리오 및 솔루션 토론.
게임 데이 (스테이지/프로드 라이트): AZ/지역 고장 시뮬레이션, 공급자 종료, DNA 재설정.
테스트 복원: 정기적으로 백업을 정기적으로 복원하고 무결성을 검증합니다.
혼돈/실패 분사: 제어 된 네트워크/노드/종속성 오류.
운동 KPI: RTO/RPO, 플레이 북 결함, CAPA 달성.
11) 재무 및 기획 선택 (FinOps)
RPO/RTO 감소에 대해 $ 를 계산하십시오: 목표가 낮을수록 채널, 라이센스, 준비금이 더 비쌉니다.
하이브리드: Tier 0-액티브 액티브/핫; 1 단계 - 따뜻한; 2-3 단계-파일럿/백업.
비싼 데이터: 콜드 레이어 (아카이브/S3/GLACIER), 증분 스냅 샷, 중복 제거 사용.
DR- 인프라 비용 및 인증서/라이센스에 대한 정기적 인 검토.
12) DR 성숙도 지표
각 계층에 대한 RTO (실제) 및 RPO (실제).
DR 적용 범위: 설계된 스크립트/플레이 북/테스트 서비스의%.
백업 성공 및 복원 성공: 백업 및 입증 된 복원의 일일 성공.
선언 할 재난: 실패 결정의 속도.
Failback Time은 일반 토폴로지로 돌아갑니다.
결함 속도 운동: 발견 된 격차/가르침.
준수 증거 완료.
13) 점검표
DR 구현 전
- 서비스 디렉토리에는 Tier, RTO/RPO, 종속성 및 소유자가 포함됩니다.
- 계층 및 예산별로 선택된 패턴 (AA/AP/WS/PL/BR).
- 일관성 및 복제 계약이 문서화되어 있습니다.
- GSLB/DNA/라우팅 및 건강 검진이 구성되고 테스트되었습니다.
- 백업, 스냅 샷, 로그 변경-활성화, 복원 확인
- DR 플레이 북 및 공급자 연락처가 최신입니다.
사고 중 (간단히)
- SEV를 선언하고 전쟁 실을 조립하십시오. 동결 해제.
- 프로브의 쿼럼을 확인하십시오. 충격/지리를 기록하십시오.
- Failover Runbook 실행: 트래픽, 프로모션 DB, 대기열, 캐시.
- 저하 -UX/한계 활성화; SLA에 업데이트를 게시하십시오
- 증거 수집 (타임 라인, 그래프, 로그, 명령).
사고 후
- N 간격의 SLO 관찰; 계획대로 실패를 실행하십시오.
- AAR/RCA 수행; CAPA를 발행하십시오.
- 플레이 북 업데이트, 경보 촉매, DR 테스트 사례.
- 이해 관계자/규제 기관에보고하십시오 (필요한 경우).
14) 템플릿
14. DR 스크립트 카드 1 개 (예)
ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support14. 2 개의 런북 "복제 데이터베이스 홍보" (조각)
1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m14. 3 DR 운동 계획 (간단한)
Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output15) 반 패턴
정기적 인 복원 테스트없이 "백업이 있습니다".
비밀/엔드 포인트가 자동으로 전환되지 않습니다.
demempotency → 재전송시 중복/손실 트랜잭션이 없습니다.
분해가없는 영역에 대한 동일한 구성 요소는 플래그를 특징으로
"거짓 경보" 에 대한 두려움으로 오랫동안 선언하십시오.
대안이없는 단일 지역 제공 업체 (PSP/KYC).
실패 계획은 없습니다. 우리는 "영원히" 긴급 토폴로지에 살고 있습니다.
16) 구현 로드맵 (6-10 주)
1. 네드. 1-2: Tier 별 서비스 분류, 대상 RTO/RPO 설정, DR 패턴 선택.
2. 네드. 3-4: 복제/백업 설정, GSLB/DNA, 프로모션 절차; 플레이 북과 런북 '및.
3. 네드. 5-6: 첫 번째 DR 연습 (탁상 → 단계), 메트릭 수정 및 CAPA.
4. 네드. 7-8: 교통 제한 운동 프로드 라이트; 장애 조치 자동화.
5. 네드. 9-10: 비용 최적화 (FinOps), Tier 0을 핫/AA로 이전, 분기 별 운동 및보고 규정.
17) 결론
효과적인 DR은 백업에 관한 것이 아닙니다. 이들은 일관된 아키텍처, 장애/실패 자동화, 데이터 분야 (demotency/replication), 교육 및 투명한 커뮤니케이션입니다. RTO/RPO가 실제 인 경우 플레이 북이 해결되고 운동이 규칙적으로 진행되면 재난이 통제 된 이벤트로 바뀌고 서비스는 빠르고 예측 가능하게 정상으로 돌아갑니다.