장애 대응과 DR (Disaster Recovery)
목차
- 장애 대응과 DR을 왜 같이 묻는가
- 장애 대응과 DR의 차이
- 백업과 DR은 같은 것이 아니다
- 장애 범위를 어떻게 나눌 것인가
- Single AZ, Multi AZ, Multi Region 감각
- RTO와 RPO
- Failover 전략
- Runbook과 대응 절차
- 복구 검증과 DR Drill
- 비용과 운영 복잡도 트레이드오프
- 면접 포인트
- 참고 자료
장애 대응과 DR을 왜 같이 묻는가
백엔드 면접에서 이 주제는 “백업은 하고 있는가” 수준에서 끝나지 않습니다.
보통은 다음 질문으로 이어집니다.
- 장애가 나면 누가 무엇부터 확인하는가
- 같은 리전 안 장애와 리전 전체 장애를 어떻게 다르게 볼 것인가
- 몇 분 안에 복구해야 하는가
- 데이터 몇 분치를 잃어도 되는가
즉, 이 문서의 핵심은
장애를 막는 것뿐 아니라, 장애 이후 얼마나 빨리 어떤 수준으로 복구할지 설명할 수 있는가입니다.
데이터 복구 관점은 백업과 복구 (Backup and Recovery),
관측성과 장애 감지 관점은 로깅 및 모니터링 (Logging & Monitoring) 과 같이 보면 좋습니다.
장애 대응과 DR의 차이
둘은 자주 같이 말하지만 초점이 다릅니다.
| 주제 | 핵심 질문 | 주 대상 |
|---|---|---|
| 장애 대응 | 지금 발생한 장애를 어떻게 탐지하고 완화할 것인가 | 운영 절차, 알림, 우회, 롤백 |
| DR | 큰 장애 이후 서비스를 어떤 수준으로 복구할 것인가 | 복구 목표, 대체 인프라, 데이터 보전 |
장애 대응은 현재 진행 중인 사고에 대한 운영 절차에 가깝고,
DR은 더 큰 실패를 전제로 한 복구 전략에 가깝습니다.
좋은 답변은 둘을 한 문장으로 섞기보다
즉시 완화와 장기 복구를 나눠 설명하는 것입니다.
백업과 DR은 같은 것이 아니다
백업은 DR의 일부일 수 있지만, DR 그 자체는 아닙니다.
예를 들어:
- 백업은 있는데 복원 시간이 12시간이면 RTO 요구를 못 맞출 수 있음
- 데이터는 살아 있어도 애플리케이션, 네트워크, DNS 전환 절차가 없으면 서비스는 복구되지 않음
- Multi AZ 구성은 있어도 운영자가 failover 절차를 모르면 실제 복구가 늦어질 수 있음
즉, DR은 다음을 같이 봐야 합니다.
- 데이터 복구
- 애플리케이션 재기동
- 네트워크와 라우팅 전환
- 인증서 / secret / 설정 복원
- 운영 절차와 의사결정 경로
면접에서는 “백업합니다”보다
백업만으로 충분하지 않고, 서비스 복구 경로 전체를 본다고 설명하는 편이 좋습니다.
장애 범위를 어떻게 나눌 것인가
복구 전략은 장애 범위에 따라 달라집니다.
대표적으로는 다음처럼 나눌 수 있습니다.
- 단일 인스턴스 장애
- 단일 노드 / 단일 파드 장애
- 단일 AZ 장애
- 데이터베이스 주 인스턴스 장애
- 리전 전체 장애
- 외부 의존성 장애
좋은 운영은 모든 장애를 한 가지 템플릿으로 다루지 않습니다.
예를 들어:
- 인스턴스 장애는 오토스케일링과 재스케줄링으로 완화
- AZ 장애는 Multi AZ 구성과 로드 밸런서로 흡수
- 리전 장애는 DNS, traffic manager, 데이터 복제 전략까지 필요
즉, DR 논의는 먼저 무엇이 망가졌을 때를 상정하는지부터 분명해야 합니다.
Single AZ, Multi AZ, Multi Region 감각
| 구성 | 장점 | 주의점 |
|---|---|---|
| Single AZ | 단순하고 비용이 적음 | AZ 장애에 취약 |
| Multi AZ | 동일 리전 내 가용성 향상 | 리전 전체 장애는 못 막음 |
| Multi Region | 더 강한 복원력 | 비용과 운영 복잡도가 크게 증가 |
Single AZ
개발 / 테스트 환경이나 작은 내부 시스템에서는 가능하지만,
면접에서는 일반적으로 운영 핵심 서비스의 기본 구성으로 보긴 어렵습니다.
Multi AZ
많은 서비스의 현실적인 기본값입니다.
- 애플리케이션을 여러 AZ에 배치
- 로드 밸런서로 분산
- 관리형 DB의 standby / failover 활용
좋은 답변은 “고가용성이 됩니다”보다
같은 리전 안 장애는 흡수할 수 있지만, 리전 단위 장애는 별도 전략이 필요하다고 설명하는 편이 좋습니다.
Multi Region
정말 필요한 서비스에만 신중하게 도입하는 편이 자연스럽습니다.
- 글로벌 사용자
- 강한 복구 요구
- 리전 장애 허용이 어려운 비즈니스
- 데이터는 active-active 인가, active-passive 인가
- 쓰기 충돌은 어떻게 다룰 것인가
- 운영 배포를 두 리전에 어떻게 맞출 것인가
RTO와 RPO
DR 문서에서 가장 자주 나오는 기본 개념입니다.
- RTO (Recovery Time Objective): 몇 분 또는 몇 시간 안에 서비스 복구가 되어야 하는가
- RPO (Recovery Point Objective): 몇 분치 데이터까지 잃어도 되는가
예를 들어:
- RTO 15분: 15분 안에 핵심 기능이 살아나야 함
- RPO 5분: 최대 5분치 데이터 손실만 허용
이 둘이 작을수록 비용이 커집니다.
- 더 자주 복제해야 하고
- 더 빠른 failover가 필요하고
- 더 많은 준비된 자원이 필요합니다
면접에서는 숫자를 외우는 것보다
비즈니스 요구가 RTO / RPO를 결정하고, 기술 선택은 그 뒤에 온다고 설명하는 편이 좋습니다.
Failover 전략
failover는 장애 시 대체 경로로 넘기는 방식입니다.
대표 패턴은 다음과 같습니다.
- 자동 failover: 관리형 DB, 로드 밸런서, 오토힐링 기반
- 반자동 failover: 감지와 일부 전환은 자동, 최종 승인이나 검증은 수동
- 수동 failover: 문서화된 절차에 따라 운영자가 직접 전환
실무에서는 무조건 자동이 정답은 아닙니다.
- 잘못된 자동 전환이 더 큰 장애를 만들 수 있음
- 데이터 불일치 검증이 필요한 경우가 있음
- 외부 결제나 메시징 연동은 전환 전에 확인이 필요할 수 있음
좋은 답변은 “장애 나면 다른 리전으로 넘깁니다”보다
무엇이 자동이고, 무엇이 운영 판단이 필요한지를 나눠 설명하는 편이 더 좋습니다.
Runbook과 대응 절차
장애 대응에서 문서와 절차는 생각보다 중요합니다.
대표 내용은 다음과 같습니다.
- 알림 기준과 온콜 체계
- 장애 등급 구분
- 우선 확인할 메트릭과 로그
- 롤백 / 우회 / failover 절차
- 커뮤니케이션 채널과 의사결정자
좋은 runbook은 장황한 매뉴얼이 아니라,
누가 어떤 신호를 보고 어떤 순서로 판단할지 빠르게 안내하는 문서입니다.
면접에서는 “대응합니다”보다
탐지, 완화, 근본 원인 분석, 후속 개선으로 나눈다고 설명하는 편이 실무적입니다.
복구 검증과 DR Drill
복구 전략은 문서에만 있으면 충분하지 않습니다.
다음이 중요합니다.
- 백업 복원 테스트
- failover 리허설
- DNS / traffic manager 전환 연습
- 읽기 전용 축소 운영 모드 검증
- 모니터링 / 알람이 복구 후 정상 동작하는지 확인
특히 DR Drill은 “정말 전환이 되는가”보다
예상보다 오래 걸리는 단계가 무엇인지 미리 찾는 과정에 가깝습니다.
면접에서는 “정기적으로 점검합니다”보다
복구 절차도 배포처럼 연습하고 검증한다고 설명하는 편이 좋습니다.
비용과 운영 복잡도 트레이드오프
| 선택 | 장점 | 주의점 |
|---|---|---|
| Multi AZ 기본화 | 일반적인 가용성 향상 | 비용 증가 |
| Warm standby | 빠른 복구 가능 | 유휴 자원 비용 |
| Active-active 다중 리전 | 강한 복원력과 분산 | 데이터 일관성과 운영 복잡도 증가 |
| 수동 failover | 잘못된 자동 전환 위험 감소 | 복구 시간이 늘어날 수 있음 |
좋은 답변은 “무조건 다중 리전”이 아니라
비즈니스 중요도와 RTO / RPO 요구에 맞춰 단계적으로 올린다는 식이 자연스럽습니다.
면접 포인트
- 백업과 DR은 다르다. 백업은 데이터 보전 수단이고 DR은 서비스 복구 전략이다.
- 장애 범위를 인스턴스, AZ, 리전 단위로 나눠 설명하면 답변이 더 또렷해진다.
- RTO와 RPO는 기술보다 비즈니스 요구에서 먼저 나온다.
- failover는 자동화 범위와 운영 판단 범위를 함께 설명하는 편이 좋다.
- DR 문서는 drill과 복구 검증까지 가야 실제 운영 답변이 된다.