3단계: 평가 및 테스트

복원력이 뛰어난 기반을 구축했지만 실제로 작동하는지 어떻게 알 수 있나요? 제품 시장 적합성을 입증하기 위해 레이싱할 때 복원력을 테스트하는 것은 고급스러울 수 있습니다. 그러나 기능 개발을 방해하지 않고 이를 수행할 수 있는 스마트한 방법이 있습니다. 이 장에서는 스타트업의 속도에 맞는 린하고 실용적인 테스트를 설명합니다.

로 시작하여 초기 아키텍처 평가 도구로 AWS Resilience Hub생각하십시오. 아키텍처의 복원력 기반에 대한 유용한 기준 검토를 제공합니다. 이를 통해 일반적인 구성 패턴과 잠재적 단일 장애 지점을 확인하여 기본 인프라 설정이 복구 목표에 부합하는지 평가할 수 있습니다. 여러 가용 영역 구성 누락 또는 불완전한 백업 정책과 같은 명백한 격차에 플래그를 지정할 수 있습니다. Resilience Hub는 사려 깊은 아키텍처 검토와 중요한 경로의 대상 테스트를 보완하지만 대체하지는 않습니다.

문서화된 복구 목표를 검증하려면 개발 환경에서 AWS Backup에서 월별 복원 테스트를 예약합니다. 엔지니어링 시간이 필요하지만 실제 인시던트 발생 시 백업 검색이 작동하지 않는 것보다 저렴할 수 있습니다. 단위 테스트 또는 코드 검토 실행과 같은 정기적인 개발 주기의 일부로 만듭니다. 목표는 완벽하지 않고 필요할 때 복구할 수 있다는 확신입니다.

스타트업이 성장하고 고객의 의존도가 높아지면 테스트 게임의 수준을 점진적으로 높일 수 있습니다. 새 기능을 배포할 때 파이프라인에 기본 복원력 검사를 포함합니다. 를 사용하여 간단한 카오스 실험을 시도합니다AWS Fault Injection Service. 사전 프로덕션 환경에서 시작하고 작게 시작합니다. 프로덕션 실험을 고려하기 전에 애플리케이션이 개발 중에 지연된 API 응답을 처리하는 방법을 테스트합니다. 신뢰도가 높아지면 이러한 테스트를 점진적으로 확장하되 항상 사전 프로덕션에서 먼저 검증합니다. 스타트업의 경우 프로덕션 환경에서 사물을 깨는 것은 의도적으로 수행하지 않으면 충분히 위험합니다.

키는 밸런스입니다. 테스트에 소비되는 매시간은 새로운 기능을 구축하는 데 소비되지 않는 한 시간입니다. 그러나 몇 가지 전략적 테스트는 고객의 신뢰를 잃는 종류의 중단을 방지할 수 있습니다. 에서 제공하는 자동화된 도구를 사용하여 과중한 작업을 AWS 수행하고 고객에게 가장 중요한 테스트에 집중합니다. 이를 통해 혁신을 늦추지 않고 애플리케이션의 복원력에 대한 신뢰를 구축할 수 있습니다.

다음 장에서는 시작 규모에 따라이 기반을 발전시키는 방법을 살펴봅니다.