# 신뢰성 신뢰성 신뢰성 원칙에서는 워크로드의 기능이 필요한 때에 기능을 정확하고 일관되게 수행하는 역량에 대해 다룹니다. 여기에는 전체 수명 주기에 걸쳐 워크로드를 운영 및 테스트할 수 있는 기능이 포함됩니다. 이 백서는 AWS에서 신뢰할 수 있는 워크로드를 구현하기 위한 세부적인 모범 사례 지침을 제공합니다. **Topics** + [ # 복원력을 위한 공동 책임 모델 ](shared-responsibility-model-for-resiliency.md) + [ # 설계 원칙 ](design-principles.md) + [ # 정의 ](definitions.md) + [ # 가용성 요구 사항 파악 ](understanding-availability-needs.md) # 복원력을 위한 공동 책임 모델 복원력을 위한 공동 책임 모델 보안은 AWS와 고객이 공동으로 책임을 져야 하는 영역입니다. 복원력의 일부인 재해 복구(DR) 및 가용성이 이 공동 모델에서 어떻게 작동하는지 이해해야 합니다. **AWS 책임 - 클라우드의 복원력** AWS는 AWS 클라우드에서 제공하는 모든 서비스가 실행되는 인프라의 복원력에 대한 책임이 있습니다. 이 인프라는 AWS 클라우드 서비스를 실행하는 하드웨어, 소프트웨어, 네트워킹 및 시설로 구성됩니다. AWS는 이러한 AWS 클라우드 서비스를 제공하기 위해 상업적으로 합당한 노력을 기울이며 서비스 가용성이 [AWS 서비스 수준에 관한 계약(SLA)](https://aws.amazon.com/legal/service-level-agreements/) 이상을 충족하도록 보장합니다. [AWS 글로벌 클라우드 인프라](https://aws.amazon.com/about-aws/global-infrastructure/)는 고객이 복원력이 뛰어난 워크로드 아키텍처를 구축할 수 있도록 설계되었습니다. 각 AWS 리전은 완전히 격리되어 있으며 물리적으로 격리된 인프라 파티션인 여러 [가용 영역](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones)으로 구성됩니다. 가용 영역은 워크로드 복원력에 영향을 줄 수 있는 결함을 격리하여 리전의 다른 영역에 영향을 미치지 않도록 합니다. 그러나 동시에 AWS 리전의 모든 영역은 완전히 중복된 전용 메트로 섬유를 사용하여 고대역폭과 짧은 지연 시간의 네트워킹으로 상호 연결되어 있기 때문에 영역 간에 높은 처리량과 짧은 지연 시간을 제공합니다. 영역 간의 모든 트래픽은 암호화됩니다. 네트워크 성능은 영역 간에 동기식 복제를 수행하기에 충분합니다. 하나의 애플리케이션이 여러 AZ에 파티셔닝되어 있는 경우 정전, 번개, 토네이도, 허리케인 등의 문제로부터 애플리케이션을 더 효과적으로 격리하고 보호할 수 있습니다. **고객 책임 - 클라우드의 복원력** 고객의 책임은 고객이 선택한 AWS 클라우드 서비스에 따라 결정됩니다. 서비스에 따라 복원력 책임의 일환으로서 고객이 수행해야 할 구성 작업의 양이 달라집니다. 예를 들어 Amazon Elastic Compute Cloud(Amazon EC2)와 같은 서비스를 사용하려면 고객이 필요한 모든 복원력 구성 및 관리 작업을 수행해야 합니다. Amazon EC2 인스턴스를 배포하는 고객은 [Amazon EC2 인스턴스를 여러 위치(예: AWS 가용 영역)에 배포](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)하고, Auto Scaling과 같은 서비스를 사용하여 [자가 복구를 구현](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html)하며, 인스턴스에 설치된 애플리케이션에 대한 [복원력이 뛰어난 워크로드 아키텍처 모범 사례](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)를 사용할 책임이 있습니다. Amazon S3 및 Amazon DynamoDB와 같은 관리형 서비스의 경우 AWS는 인프라 계층, 운영 체제, 플랫폼을 작동하고, 고객은 엔드포인트에 액세스하여 데이터를 저장 및 검색합니다. 백업, 버전 관리 및 복제 전략을 포함하여 데이터의 복원력을 관리할 책임은 고객에게 있습니다. AWS 리전의 여러 가용 영역에 워크로드를 배포하는 것은 하나의 가용 영역으로 문제를 격리하고 다른 가용 영역의 중복성을 사용하여 요청을 계속 처리하여 워크로드를 보호하도록 설계된 고가용성 전략의 일부입니다. 다중 AZ 아키텍처는 정전, 낙뢰, 토네이도, 지진 등과 같은 문제로부터 워크로드를 더 잘 격리하고 보호하도록 설계된 DR 전략의 일부이기도 합니다. DR 전략은 여러 AWS 리전을 사용할 수도 있습니다. 예를 들어 액티브/패시브 구성에서 액티브 리전이 더 이상 요청을 처리할 수 없는 경우 워크로드에 대한 서비스가 액티브 리전에서 DR 리전으로 장애 조치됩니다. ![\[공동 복원력 모델을 보여주는 차트.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png) AWS 서비스를 사용하여 복원력 목표를 달성할 수 있습니다. 고객은 클라우드에서 복원력을 달성하기 위해 시스템의 다음 측면을 관리할 책임이 있습니다. 특히 각 서비스에 대한 자세한 내용은 [AWS 설명서](https://docs.aws.amazon.com/index.html)를 참조하세요. **네트워킹, 할당량 및 제약 조건** + 공동 책임 모델의 이 영역에 대한 모범 사례는 [기초](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html) 페이지에 자세히 설명합니다. + 해당하는 경우 예상되는 로드 요청 증가에 따라 포함하는 서비스의 [서비스 할당량](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html) 및 제약 조건을 이해하고 규모를 조정할 수 있는 충분한 공간이 있는 아키텍처를 계획합니다. + 고가용성의 확장 가능한 중복 네트워크로 [네트워크 토폴로지](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html)를 설계합니다. **변경 관리 및 운영 복원력** + [변경 관리](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html)에는 환경에 변경 사항을 도입하고 관리하는 방법이 포함됩니다. [변경 사항을 구현](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html)하려면 애플리케이션 및 인프라에 대한 런북과 배포 전략을 구축하고 최신 상태로 유지해야 합니다. + [워크로드 리소스를 모니터링](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html)하는 탄력적인 전략에서는 기술 및 비즈니스 지표, 알림, 자동화 및 분석을 포함한 모든 구성 요소를 고려합니다. + 클라우드의 워크로드는 사용량 장애 또는 변동에 대응하여 스케일 인되는 [수요 규모의 변화](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html)에 적응해야 합니다. **관찰성 및 장애 관리** + 워크로드가 [구성 요소 장애를 견딜 수 있도록](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) 복구를 자동화하려면 모니터링을 통해 장애를 관찰해야 합니다. + [장애 관리](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html)를 위해 [데이터를 백업](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html)하고, 워크로드가 구성 요소 장애를 견딜 수 있도록 모범 사례를 적용하고, [재해 복구를 계획](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html)해야 합니다. **워크로드 아키텍처** + [워크로드 아키텍처](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html)에는 비즈니스 도메인을 중심으로 서비스를 설계하는 방법, 장애를 방지하기 위해 SOA 및 분산 시스템 설계를 적용하는 방법, 제한, 재시도, 대기열 관리, 제한 시간 및 비상 레버와 같은 기능을 구축하는 방법이 포함됩니다. + 입증된 [AWS 솔루션](https://aws.amazon.com/solutions/), [Amazon Builders Library](https://aws.amazon.com/builders-library/) 및 [서버리스 패턴](https://serverlessland.com/patterns)을 활용하여 모범 사례에 맞춰 구현을 바로 시작할 수 있습니다. + 지속적인 개선을 통해 시스템을 분산 서비스로 분해하여 더 빠르게 규모를 조정하고 혁신합니다. [AWS 마이크로서비스](https://aws.amazon.com/microservices/) 지침 및 관리형 서비스 옵션을 사용하여 변경을 도입하고 혁신하는 역량을 단순화하고 가속화합니다. **중요 인프라에 대한 지속적인 테스트** + [신뢰성 테스트](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html)는 기능, 성능, 카오스 수준에서 테스트하고, 인시던트 분석 및 게임 데이 관행을 채택하여 잘 이해되지 않은 문제를 해결하는 데 필요한 전문성을 구축함을 의미합니다. + 클라우드 올인 및 하이브리드 애플리케이션 모두에서 문제가 발생하거나 구성 요소가 중단될 때 애플리케이션이 어떻게 작동하는지 알면 중단으로부터 빠르고 신뢰할 수 있는 방식으로 복구할 수 있습니다. + 예상대로 작동하지 않을 때 시스템이 어떻게 작동하는지 이해하기 위해 반복 가능한 실험을 만들고 문서화합니다. 이러한 테스트는 전체 복원력의 효율성을 입증하고 실제 오류 시나리오에 직면하기 전에 운영 절차에 대한 피드백 루프를 제공합니다. # 설계 원칙 설계 원칙 클라우드에서는 몇 가지 원칙에 따라 신뢰성을 높일 수 있습니다. 여기서 설명하는 모범 사례와 관련하여 숙지해야 할 원칙은 다음과 같습니다. + **장애 자동 복구:** 워크로드의 핵심 성과 지표(KPI) 모니터링을 통해 임곗값을 위반하면 자동화를 실행할 수 있습니다. 이러한 KPI는 서비스의 기술적 측면이 아닌 비즈니스 가치에 기반한 측정한 값이어야 합니다. KPI를 모니터링하면 장애 추적 및 자동 알림을 지원하고, 자동화된 복구 프로세스에 따라 장애 지점을 우회하거나 복구할 수 있습니다. 보다 정교한 자동화를 구현할 경우 장애가 발생하기 전에 예측하여 해결하는 것도 가능합니다. + **복구 절차 테스트:** 온프레미스 환경에서 테스트는 워크로드가 특정 시나리오에서 작동하는 것을 증명하기 위해 시행됩니다. 일반적으로 복구 전략을 검증하기 위해 테스트하지는 않습니다. 클라우드에서는 워크로드의 장애 과정을 테스트하고 복구 절차를 검증할 수 있습니다. 자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 장애로 이어졌던 시나리오를 재현할 수 있습니다. 이 접근 방식은 장애 경로를 노출한 후 실제 장애 시나리오가 발생하기 *전에* 테스트하고 수정하여 위험을 줄일 수 있습니다. + **수평적 스케일링을 통해 전체 워크로드 가용성 증대:** 단일의 큰 리소스를 다수의 작은 리소스로 대체하여 단일 장애가 전체 워크로드에 미치는 영향을 축소합니다. 요청을 더 작은 리소스 여러 개로 분산시키면 공통의 장애 지점이 공유되지 않습니다. + **용량 추정 중지:** 워크로드에 대한 수요가 해당 워크로드의 용량을 넘어서는 리소스 부족 상태는 온프레미스 워크로드에서 흔히 발생하는 장애의 원인입니다(서비스 거부 공격의 대상). 클라우드에서는 수요 및 워크로드 사용량을 모니터링하고 리소스 추가 또는 제거를 자동화함으로써 프로비저닝 과다 또는 부족 현상 없이 최적의 수준으로 수요를 충족할 수 있습니다. 클라우드에도 제한은 있지만 할당량을 어느 정도 제어하고 관리하는 것이 가능합니다([Service Quotas 및 제약 조건 관리](manage-service-quotas-and-constraints.md) 참조). + **자동화를 통한 변경 관리**: 인프라 변경은 자동화를 통해 수행되어야 합니다. 관리가 필요한 변경에는 자동화 변경이 포함되며, 이후에 이러한 변경을 추적하고 검토할 수 있습니다. # 정의 정의 이 백서에서는 클라우드의 신뢰성에 대해 다루며 다음 4개 영역에 대한 모범 사례를 설명합니다. + 기본 + 워크로드 아키텍처 + 변경 관리 + 장애 관리 신뢰성을 달성하려면 기반부터 시작해야 합니다. 이러한 기반은 서비스 할당량과 네트워크 토폴로지로 워크로드를 수용하는 환경을 의미합니다. 분산 시스템의 워크로드 아키텍처는 장애를 예방하고 완화하도록 설계되어야 합니다. 워크로드는 수요 또는 요구 사항의 변경을 처리해야 하며, 장애를 감지하고 자동으로 복구되도록 설계되어야 합니다. **Topics** + [ # 복원력과 신뢰성의 구성 요소 ](resiliency-and-the-components-of-reliability.md) + [ # 가용성 ](availability.md) + [ # 재해 복구(DR) 목표 ](disaster-recovery-dr-objectives.md) # 복원력과 신뢰성의 구성 요소 복원력과 신뢰성의 구성 요소 클라우드에서 워크로드의 신뢰성은 몇 가지 요인에 의존하는데 가장 기본적인 요소는 *복원력*입니다. + **복원력**은 인프라 또는 서비스 중단을 복구하고, 수요에 따라 컴퓨팅 리소스를 탄력적으로 확보하고, 구성 오류나 일시적 네트워크 문제 같은 중단 사태를 완화할 수 있는 워크로드의 능력입니다. 워크로드 신뢰성에 영향을 미치는 다른 요인은 다음과 같습니다. + 운영 우수성: 변경 자동화, 장애 대응을 위한 플레이북 사용, 애플리케이션의 프로덕션 운영 준비 상태를 확인하는 운영 준비 검토(ORR)가 포함됩니다. + 보안: 악의적 행위자가 데이터 또는 인프라를 손상시켜 가용성에 영향을 주는 행위를 방지하는 조치가 포함됩니다. 예를 들어 백업을 암호화하여 데이터를 안전하게 보호합니다. + 성능 효율성: 요청 속도를 최대화하고 워크로드 지연 시간을 최소화하는 설계가 포함됩니다. + 비용 최적화: EC2 인스턴스에 대한 지출을 늘려 정적 안정성을 달성할지 추가 용량이 필요할 때 자동 규모 조정을 사용할지 여부와 같은 절충이 포함됩니다. 이 백서에서는 복원력을 중점적으로 다룹니다. 다른 네 가지 측면도 중요하며, [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/)의 각 원칙에서 다룹니다. 여기에 나오는 모범 사례의 많은 부분은 신뢰성의 그러한 측면을 다루지만 중점은 복원력입니다. # 가용성 가용성 *가용성*(*서비스 가용성*이라고도 함)은 복원력을 정량적으로 측정하는 데 일반적으로 사용되는 지표이자 목표 복원력 목표이기도 합니다. + **가용성**은 워크로드를 사용할 수 있는 시간의 비율입니다. *사용 가능*이란 용어는 필요할 때 합의된 기능을 성공적으로 수행할 수 있음을 의미합니다. 이 비율은 월, 연 또는 이후 3년과 같이 특정 기간에 걸쳐 계산됩니다. 가장 엄격한 해석을 적용할 때 가용성은 예정된 중단 및 예정되지 않은 중단을 포함하여 애플리케이션이 정상적으로 작동하지 않는 모든 시간에 감소합니다. *가용성*은 다음과 같이 정의합니다. ![\[\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/images/availability-formula.png) + 가용성은 일정 기간(대개 1개월 또는 1년)의 가동 시간 비율(예: 99.9%)입니다. + 흔히 사용되는 ‘5개의 9’는 99.999%의 가용성을 의미합니다. + 수식의 *총 시간*에서 예정된 서비스 가동 중지 시간(예: 계획된 유지 관리)을 제외하는 경우도 있습니다. 그러나 사용자가 이 기간에 서비스를 사용하고자 하므로 이것은 권장되는 방법이 아닙니다. 아래 표에는 일반적인 애플리케이션 가용성 설계 목표와 해당 목표를 충족하면서 1년 동안 허용되는 최대 중단 시간의 길이가 나와 있습니다. 이 표에는 각 가용성 계층에서 흔히 볼 수 있는 애플리케이션 유형의 예가 포함되어 있습니다. 여기에 나온 값이 이 문서 전체에서 참조됩니다. | 가용성 | 최대 사용 불가(연간) | 애플리케이션 범주 | | --- | --- | --- | | 99% | 3일 15시간 | 배치 처리, 데이터 추출, 전송 및 로드 작업 | | 99.9% | 8시간 45분 | 지식 관리, 프로젝트 추적과 같은 내부 도구 | | 99.95% | 4시간 22분 | 온라인 상거래, POS(Point of Sale) | | 99.99% | 52분 | 비디오 전송, 브로드캐스트 워크로드 | | 99.999% | 5분 | ATM 트랜잭션, 통신 워크로드 | **요청을 기반으로 가용성을 측정합니다.** ‘사용할 수 있는 시간’ 대신 성공 및 실패한 요청의 수를 세는 것이 서비스에 따라 더 용이할 수 있습니다. 그런 경우 다음 계산을 사용하면 됩니다. ![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png) 이것은 대개 1분 또는 5분 기간에 측정됩니다. 그런 다음, 이 기간의 평균에서 월간 가동 시간 비율(시간 기반 가용성 측정)을 계산할 수 있습니다. 주어진 기간에 요청이 수신되지 않으면 해당 기간의 가용성이 100%로 계산됩니다. **강한 종속성의 가용성 계산.** 대다수 시스템에서는 다른 시스템에 대한 하드 종속성이 적용됩니다. 즉, 종속 시스템이 중단되면 간접 호출 시스템도 중단됩니다. 반면 약한 종속성이 적용되는 경우에는 종속 시스템의 장애가 애플리케이션에서 보정됩니다. 이러한 강한 종속성이 적용되는 경우 간접 호출 시스템 가용성은 종속 시스템 가용성을 곱한 결과입니다. 예를 들어 99.99%의 가용성을 제공하도록 설계된 시스템에 다른 두 독립 시스템에 대한 강한 종속성이 적용되며, 두 독립 시스템의 가용성도 99.99%라면 이론적으로 해당 워크로드가 달성할 수 있는 가용성은 99.97%입니다. Availinvok × Avail*dep1* × Avail*dep2* = Availworkload 99.99% × 99.99% × 99.99% = 99.97% 따라서 가용성을 계산할 때는 종속성과 가용성 설계 목표를 파악해야 합니다. **중복 구성 요소를 사용한 가용성 계산.** 시스템에서 예를 들어 서로 다른 가용 영역의 중복 리소스 등 독립된 중복 구성 요소를 사용하는 경우 이론적으로 가용성은 100%에서 구성 요소 장애율을 곱한 값을 뺀 결과로 계산됩니다. 예를 들어 시스템이 두 독립 구성 요소를 사용하며 각 구성 요소의 가용성이 99.9%인 경우 이 종속성의 유효 가용성은 99.9999%입니다. ![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/images/image2.png) Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency)) 99.9999% = 100% − (0.1%×0.1%) *빠른 계산*: 계산에 포함된 모든 구성 요소의 가용성이 9로만 이루어진 숫자라면 9의 개수를 더하여 답을 얻으면 됩니다. 위 예에서 두 개의 중복된 독립 구성 요소는 각각 가용성을 나타내는 9가 3개이므로 결과적으로 9가 6개입니다. **종속성의 가용성 계산.** 대다수 AWS 서비스의 가용성 설계 목표를 포함하여 가용성 관련 지침을 제공하는 종속성도 있습니다. 하지만 제조업체에서 가용성 정보를 게시하지 않은 구성 요소와 같이 이 가용성이 제공되지 않는 경우 가용성을 예측할 수 있는 한 가지 방법은 **평균 고장 간격(MTBF)** 및 **평균 복구 시간(MTTR)**을 확인하는 것입니다. 예상 가용성을 계산하는 수식은 다음과 같습니다. ![\[\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png) 예를 들어 MTBF가 150일이고 MTTR이 1시간인 경우 예상 가용성은 99.97%입니다. 자세한 내용은 [ Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html)를 참조하세요. 가용성 계산에 도움을 줄 수 있습니다. **가용성에 대한 비용.** 가용성 수준을 높이도록 애플리케이션을 설계하면 일반적으로 비용이 증가하므로, 애플리케이션 설계를 시작하기 전에 실제 가용성 요구를 파악하는 것이 좋습니다. 가용성 수준이 높으면 전체 장애 시나리오에서 더 엄격한 테스트 및 확인 요구 사항이 적용됩니다. 즉, 모든 장애에서 자동으로 복구할 수 있어야 하며 시스템 운영의 모든 측면을 유사하게 구축하고 동일한 표준에 따라 테스트해야 합니다. 예를 들어 원하는 가용성 목표를 달성할 수 있도록 용량 추가 또는 제거, 업데이트된 소프트웨어 또는 구성 변경 사항 배포 또는 롤백, 시스템 데이터 마이그레이션 등을 수행해야 합니다. 원하는 가용성 수준이 매우 높으면 소프트웨어 개발 비용이 더 많이 발생하며, 그러면 시스템 배포 속도를 늦춰야 하므로 혁신을 추진하기가 어려워집니다. 따라서 표준을 철저하게 적용하고 전체 시스템 작동 수명 주기에서 적절한 가용성 목표를 고려해야 합니다. 가용성 설계 목표가 높게 설정된 상태로 작동하는 시스템에서는 종속성 선택으로 인해서도 비용이 증가할 수 있습니다. 가용성 목표를 높게 설정하면 앞에서 설명한 것과 같은 세부 투자를 진행했던 서비스에 따라 종속성으로 선택할 수 있는 소프트웨어나 서비스 세트가 줄어듭니다. 그러므로 가용성 설계 목표 수준이 높아지면 관계형 데이터베이스 등의 다목적 서비스 수는 줄이고 특별히 구축된 서비스 수는 늘리는 것이 일반적입니다. 특별히 구축된 서비스는 더 쉽게 평가/테스트/자동화할 수 있으며, 포함은 되어 있지만 사용하지는 않는 기능과 예기치 않게 상호 작용할 가능성을 줄일 수 있기 때문입니다. # 재해 복구(DR) 목표 가용성 목표 외에도 복원력 전략에는 재해 이벤트 시 워크로드를 복구하기 위한 전략에 따른 재해 복구(DR) 목표를 포함해야 합니다. 재해 복구는 자연 재해, 대규모의 기술적 장애 또는 공격 또는 오류와 같은 사람의 위협 등에 대응하여 일회성 복구 목표에 집중합니다. 이는 구성 요소 장애, 로드 스파이크, 소프트웨어 버그에 대응하여 주어진 기간의 평균 복원력을 측정하는 가용성과 다릅니다. **Recovery Time Objective(RTO)**는 조직에서 정의합니다. RTO는 서비스 중단과 서비스 복원 사이의 허용 가능한 최대 지연 시간입니다. 이는 서비스를 이용할 수 없을 때 허용 가능한 기간으로 간주되는 기간을 결정합니다. **Recovery Point Objective(RPO)**는 조직에서 정의합니다. RPO는 마지막 데이터 복구 시점 이후 허용되는 최대 시간입니다. 이에 따라 마지막 복구 시점과 서비스 중단 사이에 허용되는 데이터 손실로 간주되는 범위가 결정됩니다. ![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/latest/reliability-pillar/images/business-continuity.png) *Recovery Point Objective(RPO), Recovery Time Objective(RTO), 재해 이벤트의 관계.* RTO는 중단이 시작된 시점과 워크로드 복구 사이의 시간을 측정한다는 점에서 평균 복구 시간(MTTR)과 유사합니다. 하지만 MTTR은 일정 기간에 여러 가용성에 영향을 미치는 이벤트에 대한 평균 값이며, RTO는 *단일* 가용성에 영향을 미치는 이벤트의 목표 값 또는 최대 허용 값입니다. # 가용성 요구 사항 파악 가용성 요구 사항 파악 애플리케이션의 가용성은 대개 애플리케이션 전체의 단일 목표로 간주되는 경우가 많습니다. 하지만 자세히 살펴보면 애플리케이션이나 서비스의 특정 측면마다 가용성 요구 사항이 각기 다른 경우가 많습니다. 예를 들어 기존 데이터를 검색하기 전에 새 데이터를 수신하여 저장하는 기능이 더 중요한 시스템도 있습니다. 시스템 구성이나 환경을 변경하는 작업보다 실시간 작업을 우선적으로 처리하는 시스템도 있습니다. 그리고 특정 시간 동안에는 가용성 요구 사항이 매우 높지만 그 외의 시간에는 좀 더 오랫동안 중단되어도 되는 서비스도 있습니다. 이러한 점을 참조하여 애플리케이션 하나를 여러 구성 요소로 구분한 후 각 구성 요소의 가용성을 평가할 수 있습니다. 이렇게 하면 가장 엄격한 요구 사항에 따라 전체 시스템 엔지니어링을 진행하는 대신 특정 요구에 따라 가용성 관련 작업을 집중적으로 수행하고 경비를 중점 투입할 수 있습니다. | 권장 사항 | | --- | | 애플리케이션의 고유한 측면을 중점적으로 평가하고, 해당하는 경우 비즈니스 요구 사항을 반영하도록 가용성 및 재해 복구 설계 목표를 구분합니다. | AWS에서 서비스는 주로 ‘데이터 영역’과 ‘컨트롤 플레인’으로 구분됩니다. 데이터 영역에서는 실시간 서비스를 제공하고, 컨트롤 플레인은 환경을 구성하는 데 사용됩니다. 예를 들어 Amazon EC2 인스턴스, Amazon RDS 데이터베이스, Amazon DynamoDB 테이블 읽기/쓰기 작업은 모두 데이터 영역 작업입니다. 반면 새 EC2 인스턴스나 RDS 데이터베이스 시작 또는 DynamoDB의 테이블 메타데이터 추가/변경은 모두 컨트롤 플레인 작업으로 간주됩니다. 이러한 모든 기능에는 높은 수준의 가용성이 중요하지만, 일반적으로는 데이터 영역의 가용성 설계 목표가 컨트롤 플레인보다 높습니다. 따라서 가용성에 대한 요구 사항이 높은 워크로드는 컨트롤 플레인 작업에 대한 런타임 의존성을 피해야 합니다. 대부분의 AWS 고객은 비슷한 방식을 통해 애플리케이션을 면밀하게 평가한 다음 가용성 요구가 각기 다른 하위 구성 요소를 확인합니다. 그런 후에는 각 측면에 맞게 가용성 설계 목표를 조정하고 적절한 작업을 수행해 시스템을 엔지니어링합니다. AWS는 99.999% 이상의 가용성을 요구하는 서비스 등 다양한 가용성 설계 목표가 있는 애플리케이션을 엔지니어링하는 데 풍부한 경험을 가지고 있습니다. AWS 솔루션스 아키텍트(SA)는 가용성 목표에 적합한 설계를 생성하는 데 도움을 줄 수 있습니다. 설계 프로세스 초기에 AWS를 활용하면 가용성 목표를 더욱 효율적으로 충족할 수 있습니다. 가용성 계획은 워크로드를 시작하기 전에만 수행하는 작업이 아닙니다. 즉, 운영을 진행하면서 설계를 구체화하고, 실제 이벤트에서 정보를 파악하며, 다양한 유형의 장애 발생 시에 복구를 할 수 있도록 지속적으로 가용성을 계획해야 합니다. 그런 후에는 구현 개선을 위해 적합한 작업을 적용할 수 있습니다. 워크로드에 필요한 가용성 요구 사항은 비즈니스 요구 사항 및 중요도와 일치해야 합니다. 먼저 정의된 RTO, RPO 및 가용성을 사용하여 비즈니스 중요도 프레임워크를 정의한 다음 각 워크로드를 평가할 수 있습니다. 이러한 접근 방식을 사용하려면 워크로드 구현에 관여한 사람들이 프레임워크에 대해 잘 알고 있어야 하며, 워크로드가 비즈니스 요구 사항에 미치는 영향을 잘 알고 있어야 합니다.