장애 관리 - AWS Well-Architected 프레임워크

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

장애 관리

통상적인 수준의 복잡한 시스템에는 장애가 발생하기 마련입니다. 신뢰성을 유지하려면 워크로드에서 장애가 발생할 때 이를 인식하고 가용성에 미치는 영향을 방지하는 조치를 취해야 합니다. 워크로드는 장애를 견디는 동시에 문제를 자동으로 복구할 수 있어야 합니다.

를 사용하면 자동화를 활용하여 모니터링 데이터에 대응할 AWS수 있습니다. 예를 들어, 특정 지표가 임곗값을 넘어서면 자동화된 작업을 시작하여 문제를 해결할 수 있습니다. 또한 운영 환경에서 장애가 발생한 리소스를 진단하여 수정하는 대신, 일단 새 리소스로 대체한 다음 운영 환경이 아닌 외부에서 장애 리소스를 분석해 볼 수도 있습니다. 클라우드에서는 저렴한 비용으로 전체 시스템의 임시 버전을 설정할 수 있기 때문에 전체 복구 프로세스를 자동으로 테스트하는 것이 가능합니다.

다음은 신뢰성 고려 사항에 중점을 둔 질문입니다.

REL 9: 데이터를 어떻게 백업하나요?
데이터, 애플리케이션 및 구성을 백업하여 복구 시간 목표(RTO) 및 복구 시점 목표()에 대한 요구 사항을 충족합니다RPO.
REL 10: 워크로드를 보호하기 위해 오류 격리를 어떻게 사용하나요?
장애 격리 경계는 워크로드 내에서 발생하는 장애의 영향을 한정된 수의 구성 요소로 제한합니다. 경계 외부의 구성 요소는 장애의 영향을 받지 않습니다. 장애 격리 경계를 여러 개 사용하면 워크로드에 미치는 영향을 제한할 수 있습니다.
REL 11: 구성 요소 장애를 견딜 수 있도록 워크로드를 어떻게 설계하나요?
고가용성 및 평균 복구 시간(MTTR)이 짧은 워크로드는 복원성을 위해 설계해야 합니다.
REL 12: 신뢰성을 어떻게 테스트하나요?
프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다.
REL 13: 재해 복구(DR)를 어떻게 계획하나요?
DR 전략의 시작은 백업 및 이중화 워크로드 구성 요소를 갖추는 것입니다. RTO 및 RPO는 워크로드 복원의 목표입니다. 비즈니스 요구 사항에 따라 이러한 목표를 설정합니다. 워크로드 리소스 및 데이터의 위치와 기능을 고려하여 이러한 목표를 충족하는 전략을 구현합니다. 중단 가능성과 복구 비용도 워크로드에 대한 재해 복구 옵션을 갖추는 것이 지니는 비즈니스 가치를 파악하는 데 도움이 되는 주요 요소입니다.

정기적으로 데이터를 백업하고 백업 파일을 테스트하여 논리적 오류와 물리적 오류를 모두 복구할 수 있는지 확인합니다. 빈번한 워크로드 자동 테스트를 통해 장애 원인을 파악하고 복구 방식을 살펴보는 것이 장애 관리의 핵심입니다. 정기 일정에 따라 이 테스트를 수행하고, 중요한 워크로드 변경 이후에도 이 테스트가 시작되는지 확인해야 합니다. KPIs, 및 또한 복구 시간 목표(RTO) 및 복구 시점 목표(RPO)를 적극적으로 추적하여 워크로드의 복원력을 평가합니다(특히 장애 테스트 시나리오에서). 추적KPIs을 통해 단일 장애 지점을 식별하고 완화할 수 있습니다. 목표는 워크로드 복구 프로세스를 철저히 테스트함으로써 모든 데이터를 복구할 수 있으며 문제가 지속되더라도 고객에게 계속 서비스를 제공할 수 있다는 확신을 얻는 것입니다. 통상적인 프로덕션 프로세스와 마찬가지로 복구 프로세스도 제대로 실행해야 합니다.