장애 복구 테스트 실행

Google Cloud Well-Architected Framework의 안정성 부문에서 이 원칙을 따르면 오류 발생 시 복구를 위한 테스트를 설계하고 실행하는 데 도움이 되는 권장사항을 확인할 수 있습니다.

이 원칙은 안정성의 학습 중점사항과 관련이 있습니다.

원칙 개요

시스템이 장애로부터 복구할 수 있는지 확인하려면 리전별 장애 조치, 출시 롤백, 백업에서 데이터 복원을 포함하는 테스트를 주기적으로 실행해야 합니다.

이 테스트를 통해 전체 지역의 서비스 중단과 같이 안정성에 심각한 위험을 초래하는 이벤트에 대한 대응을 연습할 수 있습니다. 이 테스트를 통해 중단 중에 시스템이 의도한 대로 작동하는지 확인할 수도 있습니다.

전체 리전이 다운되는 드문 경우에 모든 트래픽을 다른 리전으로 장애 조치해야 합니다. 워크로드의 정상 작동 중에 데이터가 수정되면 기본 리전에서 장애 복구 리전으로 동기화해야 합니다. 사용자에게 데이터 손실이나 세션 중단이 발생하지 않도록 복제된 데이터가 항상 최신 상태인지 확인해야 합니다. 부하 분산 시스템은 서비스 중단 없이 언제든지 장애 조치 리전으로 트래픽을 전환할 수 있어야 합니다. 지역 장애 후 다운타임을 최소화하려면 운영 엔지니어가 가능한 한 짧은 시간 내에 사용자 트래픽을 지역에서 수동으로 효율적으로 이동할 수 있어야 합니다. 이 작업을 리전 드레이닝이라고도 합니다. 이는 리전으로의 인바운드 트래픽을 중지하고 모든 트래픽을 다른 곳으로 이동한다는 의미입니다.

권장사항

실패 복구 테스트를 설계하고 실행할 때는 다음 하위 섹션의 권장사항을 고려하세요.

테스트 목표 및 범위 정의

테스트를 통해 달성하고자 하는 목표를 명확하게 정의합니다. 예를 들어 목표에는 다음이 포함될 수 있습니다.

• 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)를 검증합니다. 자세한 내용은 DR 계획의 기본사항을 참고하세요.
• 다양한 장애 시나리오에서 시스템 복원력과 내결함성을 평가합니다.
• 자동 장애 조치 메커니즘의 효과를 테스트합니다.

테스트 범위에 포함할 구성요소, 서비스 또는 리전을 결정합니다. 범위에는 프런트엔드, 백엔드, 데이터베이스와 같은 특정 애플리케이션 계층이 포함될 수 있으며, Cloud SQL 인스턴스 또는 GKE 클러스터와 같은 특정 Google Cloud 리소스가 포함될 수도 있습니다. 범위는 서드 파티 API 또는 클라우드 상호 연결과 같은 외부 종속 항목도 지정해야 합니다.

테스트 환경 준비

프로덕션 설정을 복제하는 스테이징 또는 샌드박스 환경을 사용하는 것이 좋습니다. 프로덕션에서 테스트를 진행하는 경우 자동 모니터링 및 수동 롤백 절차와 같은 안전 조치가 준비되어 있는지 확인하세요.

백업 계획을 만듭니다. 테스트 중에 데이터 손실을 방지하기 위해 중요한 데이터베이스와 서비스의 스냅샷 또는 백업을 만듭니다. 자동 장애 조치 메커니즘이 실패할 경우 팀에서 수동으로 개입할 수 있도록 준비합니다.

테스트 중단을 방지하려면 IAM 역할, 정책, 장애 조치 구성이 올바르게 설정되어 있는지 확인하세요. 테스트 도구와 스크립트에 필요한 권한이 있는지 확인합니다.

운영, DevOps, 애플리케이션 소유자를 비롯한 이해관계자에게 테스트 일정, 범위, 잠재적 영향에 관해 알립니다. 이해관계자에게 예상 타임라인과 테스트 중 예상되는 동작을 제공합니다.

실패 시나리오 시뮬레이션

Chaos Monkey와 같은 도구를 사용하여 장애를 계획하고 실행합니다. 커스텀 스크립트를 사용하여 다중 영역 GKE 클러스터의 기본 노드 종료 또는 사용 중지된 Cloud SQL 인스턴스와 같은 중요 서비스의 장애를 시뮬레이션할 수 있습니다. 테스트 범위에 따라 방화벽 규칙 또는 API 제한을 사용하여 스크립트로 리전 전체 네트워크 중단을 시뮬레이션할 수도 있습니다. 다양한 조건에서 시스템 동작을 관찰하기 위해 장애 시나리오를 점진적으로 에스컬레이션합니다.

장애 발생 시 실제 사용량을 복제하기 위해 장애 시나리오와 함께 부하 테스트를 도입합니다. 백엔드 서비스를 사용할 수 없을 때 프런트엔드 시스템이 어떻게 작동하는지 등 연쇄 장애 영향을 테스트합니다.

구성 변경사항을 검증하고 인적 오류에 대한 시스템의 복원력을 평가하려면 잘못된 구성이 포함된 시나리오를 테스트하세요. 예를 들어 잘못된 DNS 장애 조치 설정 또는 잘못된 IAM 권한으로 테스트를 실행합니다.

시스템 동작 모니터링

부하 분산기, 상태 점검, 기타 메커니즘이 트래픽을 리디렉션하는 방식을 모니터링합니다. Cloud Monitoring 및 Cloud Logging과 같은 Google Cloud 도구를 사용하여 테스트 중에 측정항목과 이벤트를 캡처합니다.

실패 시뮬레이션 중과 후에 지연 시간, 오류율, 처리량의 변화를 관찰하고 전반적인 성능 영향을 모니터링합니다. 사용자 환경의 저하 또는 불일치를 식별합니다.

서비스 중단이나 장애 조치와 같은 주요 이벤트에 대해 로그가 생성되고 알림이 트리거되는지 확인합니다. 이 데이터를 사용하여 알림 및 사고 대응 시스템의 효과를 확인합니다.

RTO 및 RPO에 대한 복구 확인

실패 후 시스템이 정상 작동을 재개하는 데 걸리는 시간을 측정하고 이 데이터를 정의된 RTO와 비교하여 격차를 문서화합니다.

데이터 무결성 및 가용성이 RPO와 일치하는지 확인합니다. 데이터베이스 일관성을 테스트하려면 장애 발생 전후의 데이터베이스 스냅샷 또는 백업을 비교합니다.

서비스 복원을 평가하고 모든 서비스가 최소한의 사용자 중단으로 작동 상태로 복원되었는지 확인합니다.

결과 문서화 및 분석

각 테스트 단계, 실패 시나리오, 해당 시스템 동작을 문서화합니다. 자세한 분석을 위해 타임스탬프, 로그, 측정항목을 포함합니다.

테스트 중에 관찰된 병목 현상, 단일 장애점 또는 예기치 않은 동작을 강조 표시합니다. 수정사항의 우선순위를 정하려면 심각도와 영향에 따라 문제를 분류하세요.

시스템 아키텍처, 장애 조치 메커니즘 또는 모니터링 설정의 개선사항을 제안합니다. 테스트 결과를 바탕으로 관련 장애 조치 정책과 플레이북을 업데이트합니다. 이해관계자에게 사후 분석 보고서를 발표합니다. 보고서에는 결과, 교훈, 다음 단계를 요약해야 합니다. 자세한 내용은 철저한 사후 분석 실시를 참고하세요.

반복 및 개선

지속적인 안정성과 복원력을 검증하려면 정기적인 테스트 (예: 분기별)를 계획하세요.

인프라 변경, 소프트웨어 업데이트, 트래픽 부하 증가 등 다양한 시나리오에서 테스트를 실행합니다.

CI/CD 파이프라인을 사용하여 개발 수명 주기에 안정성 테스트를 통합하여 장애 조치 테스트를 자동화합니다.

사후 분석 중에 이해관계자와 최종 사용자의 의견을 사용하여 테스트 프로세스와 시스템 복원력을 개선합니다.