# 정의
이 백서에서는 클라우드의 신뢰성에 대해 다루며 다음 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는 *단일* 가용성에 영향을 미치는 이벤트의 목표 값 또는 최대 허용 값입니다.