2단계: 설계 및 구현

이 섹션에서는 복원력 목표를 실현하는 방법에 대해 설명합니다. 비즈니스에 가장 중요한 것을 매핑했으므로 이제 구축할 차례입니다. 혁신을 늦추지 않고 복원력을 구축하려면 어떻게 해야 하나요?

AWS 관리형 서비스를 복원력 바로 가기로 생각하세요. 인프라를 유지 관리하는 귀중한 엔지니어링 시간을 소모하는 대신 중복성을 처리하는 서비스를 사용하세요. 예를 들어 Amazon Simple Storage Service(Amazon S3. 내구성을 AWS 리전 위해에 데이터의 여러 복사본을 자동으로 저장합니다. 추가 코드나 야간 페이저 업무는 필요하지 않습니다.

핵심 애플리케이션 구성 요소는 어떤가요? 스마트한 선택은 팀의 영향을 배가할 수 있습니다. 서비스의 백본인 데이터베이스를 생각해 보세요. 자체 복제 시스템을 구축하는 대신 장애 조치를 자동으로 처리하는 Amazon Aurora를 사용하는 것이 좋습니다. 이러한 기능은 비용이 더 많이 들 수 있지만 팀의 집중력을 인프라 유지 관리에서 비즈니스 문제 해결로 전환합니다. 이 비용은 더 빠른 기능 제공과 중단 시 수익 손실을 방지하여 상쇄할 수 있습니다.

스타트업이 사용자 지정 솔루션을 구축해야 하는 경우가 있습니다. 이것이 혁신적인 스타트업의 특성입니다. 이렇게 할 때는 단순하지만 스마트하게 유지하세요. Elastic Load Balancing 및 Amazon EC2 Auto Scaling 그룹을 사용하여 여러 가용 영역에 애플리케이션을 분산합니다. 가용 영역 하나가 실패하더라도 기준 트래픽을 처리하도록 Auto Scaling 그룹 최소 용량을 설정합니다. 이를 통해 복잡한 아키텍처 패턴 없이 현지화된 장애에 대한 복원력을 제공합니다. 스타트업이 성장하고 고객이 더 높은 복원력을 요구함에 따라 더 정교한 접근 방식으로 발전할 수 있습니다.

프로덕션 및 개발 환경을 별도의에 보관하는 것이 좋습니다 AWS 계정. 빠르게 이동할 때 믹싱하고 싶지만이 경계는 안전망입니다. 이를 통해 의미 있는 실험이 프로덕션 서비스를 중단하는 것을 방지할 수 있습니다. 이를 "빠르게 움직이고 사물을 깨는" 개발 문화에 대한 보험이라고 생각하십시오. 개발 과정에서 사물을 깨고 프로덕션을 안정적으로 유지합니다.

애플리케이션이 타사 서비스에 의존하는 경우 장애를 계획합니다. 결제 프로세서에 문제가 있는 경우 시스템에서 정상적으로 처리할 수 있습니까? 간단한 회로 차단기와 대체 옵션을 구축합니다. 오류 메시지를 표시하는 대신 이러한 트랜잭션을 대기열에 넣을 수 있습니다. 고객은 완벽하게 작동하지 않더라도 계속 작동했다는 점을 감사할 것입니다.

빌드할 때 문서화하되 실용적으로 유지합니다. 주요 결정의 배경이 되는 이유를 기록하는 데 집중하고 간단한 복구 플레이북을 생성합니다. 인시던트가 발생할 때 이를 준비하는 것이 중요합니다.

완벽한 복원력을 위해 구축하는 것이 아니라 적절한 복원력을 위해 구축하는 것입니다. 과다 엔지니어링 복원력에 소비되는 매시간은 고객이 요청하는 기능에 소비되지 않는 한 시간입니다. AWS 관리형 서비스를 기반으로 사용하고, 가장 중요한 곳에 대상 복원력을 추가하고, 비즈니스가 성장함에 따라 복원력을 확장할 수 있는 명확한 경로를 만듭니다.

다음 장에서는 엔지니어링 리소스를 소모하지 않고 이러한 설계 선택 사항을 검증하는 방법을 설명합니다. 스타트업의 경우 테스트는 적절한 리프트와 애플리케이션 복원력에 대한 스마트 투자여야 합니다.