Google Cloud 아키텍처 프레임워크의 안정성 요소에 있는 이 원칙은 오류 발생 시 복구 테스트를 설계하고 실행하는 데 도움이 되는 권장사항을 제공합니다.
이 원칙은 안정성의 학습 중점 영역과 관련이 있습니다.
원칙 개요
시스템이 장애로부터 복구할 수 있는지 확인하려면 지역별 장애 조치, 출시 롤백, 백업에서 데이터 복원을 포함하는 테스트를 주기적으로 실행해야 합니다.
이 테스트를 통해 전체 지역의 서비스 중단과 같이 안정성에 큰 위험을 초래하는 이벤트에 대한 대응을 연습할 수 있습니다. 또한 이 테스트를 통해 서비스 중단 시 시스템이 의도한 대로 작동하는지 확인할 수 있습니다.
전체 리전이 다운되는 경우는 드물지만 모든 트래픽을 다른 리전으로 장애 조치해야 합니다. 워크로드의 정상 작동 중에 데이터가 수정되면 기본 리전에서 페일오버 리전으로 동기화해야 합니다. 사용자가 데이터 손실이나 세션 중단을 경험하지 않도록 복제된 데이터가 항상 최신 상태인지 확인해야 합니다. 또한 부하 분산 시스템은 서비스 중단 없이 언제든지 트래픽을 장애 조치 리전으로 전환할 수 있어야 합니다. 또한 지역 중단 후 다운타임을 최소화하려면 운영 엔지니어가 최대한 짧은 시간 내에 사용자 트래픽을 한 지역에서 다른 지역으로 수동으로 효율적으로 전환할 수 있어야 합니다. 이 작업을 리전 배수라고도 합니다. 즉, 리전으로의 인바운드 트래픽을 중지하고 모든 트래픽을 다른 곳으로 이동합니다.
권장사항
오류 복구 테스트를 설계하고 실행할 때는 다음 하위 섹션의 권장사항을 고려하세요.
테스트 목표 및 범위 정의
테스트에서 달성하고자 하는 목표를 명확하게 정의합니다. 예를 들어 목표에는 다음이 포함될 수 있습니다.
- 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)를 확인합니다. 자세한 내용은 DR 계획의 기초를 참고하세요.
- 다양한 장애 시나리오에서 시스템 복원력과 내결함성을 평가합니다.
- 자동 장애 조치 메커니즘의 효과를 테스트합니다.
테스트 범위에 포함할 구성요소, 서비스 또는 지역을 결정합니다. 범위에는 프런트엔드, 백엔드, 데이터베이스와 같은 특정 애플리케이션 계층이 포함될 수 있으며, Cloud SQL 인스턴스 또는 GKE 클러스터와 같은 특정 Google Cloud 리소스가 포함될 수도 있습니다. 또한 범위는 서드 파티 API 또는 클라우드 상호 연결과 같은 외부 종속 항목을 지정해야 합니다.
테스트 환경 준비
프로덕션 설정을 복제하는 스테이징 또는 샌드박스 환경과 같은 적절한 환경을 선택합니다. 프로덕션에서 테스트를 실행하는 경우 자동 모니터링 및 수동 롤백 절차와 같은 안전 조치를 준비해야 합니다.
백업 계획을 만듭니다. 테스트 중에 데이터 손실을 방지하기 위해 중요한 데이터베이스 및 서비스의 스냅샷 또는 백업을 만듭니다. 자동 장애 조치 메커니즘이 실패할 경우 팀에서 수동으로 개입할 준비가 되어 있는지 확인합니다.
테스트 중단을 방지하려면 IAM 역할, 정책, 장애 조치 구성이 올바르게 설정되어 있는지 확인하세요. 테스트 도구 및 스크립트에 필요한 권한이 있는지 확인합니다.
운영, DevOps, 애플리케이션 소유자를 비롯한 이해관계자에게 테스트 일정, 범위, 잠재적 영향을 알립니다. 이해관계자에게 예상 타임라인과 테스트 중에 예상되는 동작을 제공합니다.
장애 시나리오 시뮬레이션
Chaos Monkey와 같은 도구를 사용하여 장애를 계획하고 실행합니다. 맞춤 스크립트를 사용하여 다중 영역 GKE 클러스터의 기본 노드 종료 또는 사용 중지된 Cloud SQL 인스턴스와 같은 중요한 서비스의 장애를 시뮬레이션할 수 있습니다. 테스트 범위에 따라 방화벽 규칙 또는 API 제한을 사용하여 스크립트를 통해 지역 전반의 네트워크 중단을 시뮬레이션할 수도 있습니다. 장애 시나리오를 점진적으로 에스컬레이션하여 다양한 조건에서 시스템 동작을 관찰합니다.
장애 시나리오와 함께 부하 테스트를 도입하여 서비스 중단 시 실제 사용량을 재현합니다. 백엔드 서비스를 사용할 수 없을 때 프런트엔드 시스템이 어떻게 동작하는지와 같은 연쇄 장애의 영향을 테스트합니다.
구성 변경사항을 검증하고 사람의 실수에 대한 시스템의 복원력을 평가하려면 구성 오류가 포함된 시나리오를 테스트하세요. 예를 들어 잘못된 DNS 페일오버 설정이나 잘못된 IAM 권한으로 테스트를 실행합니다.
시스템 동작 모니터링
부하 분산기, 상태 점검, 기타 메커니즘이 트래픽 경로를 변경하는 방식을 모니터링합니다. Google Cloud 도구(예: Cloud Monitoring, Cloud Logging)를 사용하여 테스트 중에 측정항목과 이벤트를 캡처합니다.
장애 시뮬레이션 중과 후에 지연 시간, 오류율, 처리량의 변화를 관찰하고 전반적인 성능 영향을 모니터링합니다. 사용자 환경의 성능 저하 또는 불일치를 식별합니다.
서비스 중단 또는 페일오버와 같은 주요 이벤트에 대해 로그가 생성되고 알림이 트리거되는지 확인합니다. 이 데이터를 사용하여 알림 및 침해사고 대응 시스템의 효과를 확인합니다.
RTO 및 RPO에 따른 복구 확인
시스템이 장애 발생 후 정상 작동을 재개하는 데 걸리는 시간을 측정한 다음 이 데이터를 정의된 RTO와 비교하고 차이가 있는 경우 문서화합니다.
데이터 무결성과 가용성이 RPO와 일치하는지 확인합니다. 데이터베이스 일관성을 테스트하려면 오류 전후에 데이터베이스의 스냅샷 또는 백업을 비교합니다.
서비스 복원을 평가하고 모든 서비스가 최소한의 사용자 서비스 중단으로 작동 상태로 복원되었는지 확인합니다.
결과 문서화 및 분석
각 테스트 단계, 실패 시나리오, 해당 시스템 동작을 문서화합니다. 세부 분석을 위해 타임스탬프, 로그, 측정항목을 포함합니다.
테스트 중에 관찰된 병목 현상, 단일 장애점 또는 예기치 않은 동작을 강조 표시합니다. 수정사항의 우선순위를 지정하려면 심각도 및 영향도별로 문제를 분류하세요.
시스템 아키텍처, 장애 조치 메커니즘 또는 모니터링 설정의 개선사항을 제안합니다. 테스트 결과에 따라 관련 대체 정책 및 플레이북을 업데이트합니다. 이해관계자에게 사후 분석 보고서를 제출합니다. 보고서에는 결과, 교훈, 다음 단계가 요약되어야 합니다. 자세한 내용은 철저한 사후 분석 수행을 참고하세요.
반복 및 개선
지속적인 안정성과 복원력을 검증하려면 정기적인 테스트 (예: 분기별)를 계획하세요.
인프라 변경, 소프트웨어 업데이트, 증가된 트래픽 부하를 비롯한 다양한 시나리오에서 테스트를 실행합니다.
CI/CD 파이프라인을 사용하여 개발 수명 주기에 안정성 테스트를 통합하여 페일오버 테스트를 자동화합니다.
포스트모르템 중에 이해관계자와 최종 사용자의 의견을 사용하여 테스트 프로세스와 시스템 복원력을 개선합니다.