기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 고가용성 분산 시스템 설계 AWS
이전 항목에서는 주로 워크로드의 이론적 가용성과 이를 통해 달성할 수 있는 것을 다루었습니다. 그것은 분산 시스템을 구축할 때 염두에 두어야 할 중요한 개념입니다. 그것을 통해 종속성 선택 프로세스와 중복성 구현 방법을 알 수 있습니다.
또한 MTTDMTTR, 및 MTBF 가용성과의 관계에 대해서도 살펴보았습니다. 이 항목은 이전 이론에 기반한 실용적인 지침을 소개합니다. 간단히 말해, 고가용성을 위한 엔지니어링 워크로드의 목표는 가용성을 높이거나 낮추는 것입니다MTTD. MTBF MTTR
모든 고장을 제거하는 것이 이상적이기는 하지만 현실적이지는 않습니다. 종속성이 깊이 쌓여 있는 대규모 분산 시스템에서는 고장이 발생하기 마련입니다. “모든 것은 항상 실패한다” (Werner Vogels, Amazon.comCTO, [Amazon Web Services 10년간 쌓아온 10가지 교훈](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html) 참조). “실패에 대한 법을 제정할 수는 없으므로 빠른 탐지와 대응에 집중하십시오.” (Chris Pinkham, Amazon EC2 팀 창립 멤버, [실패를 위한 ARC335 설계: 복원력 있는 시스템 설계 기반 구축](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf) 참조) AWS
이것이 의미하는 바는 고장 발생 여부를 제어할 수 없는 경우가 많다는 것입니다. 제어할 수 있는 것은 고장을 얼마나 빨리 감지하고 조치를 취하느냐입니다. 따라서 MTBF 증가는 여전히 고가용성의 중요한 구성 요소이지만 고객이 통제할 수 있는 범위 내에서 가장 중요한 변화는 감소하는 것입니다. MTTD MTTR
**Topics**
+ [감소 MTTD](reducing-mttd.md)
+ [감소 MTTR](reducing-mttr.md)
+ [증가 MTBF](increasing-mtbf.md)
# 감소 MTTD
장애를 MTTD 줄인다는 것은 장애를 최대한 빨리 발견하는 것을 의미합니다. 시간을 단축하는 MTTD 것은 관찰 가능성, 즉 워크로드의 상태를 파악하기 위해 워크로드를 계측한 방법을 기반으로 합니다. 고객은 문제 발생 시점을 사전에 식별할 수 있는 방법으로 워크로드의 중요 하위 시스템에서 *고객 경험* 지표를 모니터링해야 합니다 ([부록 1 참조). 이러한 지표에 대한 자세한 내용은 MTTR 중요 지표를](appendix-1-mttd-and-mttr-critical-metrics.md) 참조하십시오. MTTD ). 고객은 [Amazon CloudWatch Synthetics를](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 사용하여 APIs 사용자 및 콘솔을 모니터링하는 카나리아를 *생성하여* 사용자 경험을 사전에 측정할 수 있습니다. [Elastic Load Balancing (ELB) 상태 확인MTTD, Amazon Route 53 상태 확인 등과 같이 상태를](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html) [최소화하는 데 사용할 수 있는 다른 상태 점검](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html) 메커니즘도 많이 있습니다. ([Amazon Builders' Library - 상태 확인 구현](https://aws.amazon.com/builders-library/implementing-health-checks/)을 참조하세요.)
또한 모니터링을 통해 시스템 전체와 개별 하위 시스템 모두의 부분적 고장을 감지할 수 있어야 합니다. [가용성, 장애 및 지연 시간 지표는 장애 격리 경계의 차원을 지표 차원으로 CloudWatch 사용해야 합니다.](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension) 예를 들어 us-east-1 지역의 use1-az1 AZ에 있는 셀 기반 아키텍처의 일부인 단일 EC2 인스턴스가 컨트롤 플레인 하위 시스템의 일부인 워크로드 업데이트의 일부라고 가정해 보겠습니다. API 서버는 메트릭을 푸시할 때 인스턴스 ID, AZ, 지역, 이름 및 하위 시스템 이름을 차원으로 사용할 수 있습니다. API 이를 통해 관찰성을 확보하고 각 차원에 경보를 설정하여 고장을 감지할 수 있습니다.
# 감소 MTTR
장애가 발견된 후 남은 MTTR 시간은 실제 수리 또는 영향 완화에 사용됩니다. 고장을 복구하거나 완화하려면 무엇이 잘못되었는지 알아야 합니다. 이 단계에서 통찰력을 제공하는 두 가지 주요 지표 그룹이 있습니다. 바로 1/영향 평가** 지표와 2/운영 상태** 지표입니다. 첫 번째 그룹은 영향을 받은 고객, 리소스 또는 워크로드의 수 또는 비율을 측정하여 고장 발생 시 영향의 범위를 알려줍니다. 두 번째 그룹은 영향이 생긴 이유**를 식별하는 데 도움이 됩니다. 이유가 밝혀지면 운영자와 자동화가 고장에 대응하고 문제를 해결할 수 있습니다. 이러한 지표에 대한 자세한 내용은 [부록 1 MTTD 및 MTTR 중요 지표를](appendix-1-mttd-and-mttr-critical-metrics.md) 참조하십시오.
**규칙 9**
관찰 가능성과 계측은 이를 줄이는 데 매우 중요합니다. MTTD MTTR
## 고장 우회 경로
영향을 완화하는 가장 빠른 방법은 고장을 우회하는 빠른 실패 하위 시스템을 이용하는 것입니다. 이 접근 방식은 장애가 발생한 하위 시스템의 작업을 예비 MTTR 시스템으로 신속하게 전환하여 이중화를 사용하여 이를 줄입니다. 중복성은 소프트웨어 프로세스에서 EC2 인스턴스, 다중, 다중 지역에 이르기까지 다양합니다. AZs
예비 서브시스템을 사용하면 이 MTTR 값을 거의 0으로 줄일 수 있습니다. 복구 시간은 작업을 대기 스페어 부품으로 다시 라우팅하는 데 걸리는 시간에 불과합니다. 대부분의 경우 지연 시간이 최소화되며 정의된 SLA 범위 내에서 작업을 완료하여 시스템 가용성을 유지할 수 있습니다. 이로 인해 장기간 사용할 수 없게 MTTRs 되는 것이 아니라 경미하거나 심지어 감지할 수 없을 정도의 지연이 발생할 수 있습니다.
예를 들어, 서비스가 Application Load Balancer ALB () 뒤의 EC2 인스턴스를 사용하는 경우 최소 5초 간격으로 상태 확인을 구성하고 대상이 비정상으로 표시되기 전에 실패한 상태 확인을 두 번만 수행하도록 할 수 있습니다. 즉, 10초 이내에 고장을 감지하고 비정상 호스트로의 트래픽 전송을 중단할 수 있습니다. 이 경우 오류가 감지되면 바로 MTTD 완화되기 때문에 사실상 동일합니다. MTTR
이것이 바로 고가용성** 또는 지속적인 가용성** 워크로드가 달성하고자 하는 것입니다. 고장이 발생한 하위 시스템을 신속하게 탐지하여 고장이 발생한 것으로 표시하고, 트래픽 전송을 중단하고, 대신 중복된 하위 시스템으로 트래픽을 전송함으로써 워크로드의 고장을 신속하게 우회하고자 합니다.
이러한 종류의 빠른 실패 메커니즘을 사용하면 워크로드가 일시적인 오류에 매우 민감하게 반응한다는 점에 유의하세요. 제공된 예제에서 로드 밸런서 상태 확인이 종속성이나 워크플로를 테스트하지 않고(*깊은* 상태 확인이라고도 함) 인스턴스에 대해서만 얕은** 상태 또는 [활성 및 로컬**](https://aws.amazon.com/builders-library/implementing-health-checks/) 상태 확인을 수행하는지 확인하세요. 이렇게 하면 워크로드에 영향을 미치는 일시적 오류가 발생하는 동안 인스턴스를 불필요하게 교체하는 것을 방지할 수 있습니다.
고장 우회 라우팅이 성공하려면 하위 시스템의 고장 감지 기능과 관찰성이 매우 중요합니다. 영향을 받는 리소스를 비정상 또는 고장으로 표시하고 서비스를 중단하여 다른 곳으로 라우팅할 수 있도록 하려면 영향의 범위를 알아야 합니다. 예를 들어 단일 AZ에 부분적인 서비스 장애가 발생하는 경우, 계측기는 복구될 때까지 해당 AZ의 모든 리소스를 라우팅하기 위해 AZ로 지역화된 문제가 있음을 식별할 수 있어야 합니다.
고장을 우회하려면 환경에 따라 추가 도구가 필요할 수도 있습니다. 뒤에 있는 EC2 인스턴스가 있는 이전 예제를 사용하여 한 AZ의 인스턴스가 로컬 상태 확인을 통과했지만 격리된 AZ 장애로 인해 다른 AZ에 있는 데이터베이스에 연결하지 못한다고 가정해 보겠습니다. ALB 이 경우 로드 밸런서 상태 확인으로 해당 인스턴스의 서비스가 중단되지는 않습니다. [로드 밸런서에서 AZ를 제거하거나](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) 인스턴스가 상태 확인에 실패하도록 하려면 다른 자동 메커니즘이 필요합니다. 이는 영향 범위가 AZ인지 확인하는 데 따라 달라집니다. 로드 밸런서를 사용하지 않는 워크로드의 경우 특정 AZ의 리소스가 작업 단위를 수락하지 못하도록 하거나 AZ에서 용량을 완전히 제거하는 유사한 방법이 필요합니다.
중복된 하위 시스템으로의 작업 이동을 자동화할 수 없는 경우도 있습니다. 예를 들어 기술 자체에서 리더를 선택할 수 없는 기본 데이터베이스에서 보조 데이터베이스로의 장애 조치도 마찬가지입니다. 이는 [AWS 다중 리전 아키텍처](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)의 일반적인 시나리오입니다. 이러한 유형의 장애 조치를 수행하려면 어느 정도의 가동 중지가 필요하고, 즉시 되돌릴 수 없으며, 일정 기간 동안 워크로드를 중복되지 않은 상태로 둘 수 있기 때문에 의사 결정 프로세스에 인력을 두는 것이 중요합니다.
덜 엄격한 일관성 모델을 채택할 수 있는 워크로드는 다중 지역 장애 조치 자동화를 사용하여 장애를 MTTRs 우회함으로써 작업 시간을 단축할 수 있습니다. [Amazon S3 교차 리전 복제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) 또는 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) 글로벌 테이블과 같은 특성은 최종적으로 일관된 복제를 통해 다중 리전 기능을 제공합니다. 또한 이론을 고려할 때 완화된 일관성 모델을 사용하는 것이 좋습니다. CAP 상태 저장 하위 시스템에 대한 연결에 영향을 미치는 네트워크 고장 발생 시 워크로드가 일관성보다 가용성을 선택하더라도 오류 없는 응답을 제공할 수 있는데, 이는 고장을 우회하는 또 다른 방법입니다.
두 가지 전략을 사용하여 고장 우회 라우팅을 구현할 수 있습니다. 첫 번째 전략은 고장이 발생한 하위 시스템의 전체 부하를 처리할 수 있는 충분한 리소스를 사전에 프로비저닝하여 정적 안정성을 구현하는 것입니다. 이는 단일 EC2 인스턴스일 수도 있고 전체 AZ 용량일 수도 있습니다. 장애 발생 시 새 리소스를 프로비저닝하려고 하면 복구 경로의 컨트롤 플레인에 대한 종속성이 증가하고 종속성이 추가됩니다. MTTR 하지만 추가 비용이 발생합니다.
두 번째 전략은 장애가 발생한 하위 시스템의 일부 트래픽을 다른 하위 시스템으로 라우팅하고 남은 용량으로는 처리할 수 없는 [초과 트래픽이 주는 부하를 제거](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload)하는 것입니다. 이 성능 저하 기간 동안에는 새 리소스를 확장하여 고장이 발생한 용량을 대체할 수 있습니다. 이 접근 방식은 시간이 오래 MTTR 걸리고 컨트롤 플레인에 대한 종속성을 생성하지만 예비 예비 용량의 경우 비용이 적게 듭니다.
## 정상 작동이 확인된 상태로 돌아가기
복구 중에 이를 완화하는 또 다른 일반적인 방법은 워크로드를 이전의 알려진 정상 상태로 되돌리는 것입니다. 최근 변경으로 인해 고장이 발생했을 수 있는 경우 해당 변경 사항을 롤백하는 것이 이전 상태로 돌아갈 수 있는 한 가지 방법입니다.
다른 경우에는 일시적인 상황으로 인해 고장이 발생했을 수 있으며, 이 경우 워크로드를 다시 시작하여 영향을 완화할 수 있습니다. 이 두 경우를 모두 살펴보겠습니다.
배포 중에는 MTTD 옵저버빌리티와 자동화를 최소화하는 것이 MTTR 관건입니다. 배포 프로세스에서는 오류율 증가, 지연 시간 증가 또는 이상 현상이 발생하지 않는지 지속적으로 워크로드를 주시해야 합니다. 이러한 문제가 인식되면 배포 프로세스를 중단해야 합니다.
인플레이스 배포, 블루/그린 배포, 롤링 배포와 같은 다양한 [배포 전략](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html)이 있습니다. 이들 각각은 정상 작동이 확인된 상태로 되돌리기 위해 서로 다른 메커니즘을 사용할 수 있습니다. 자동으로 이전 상태로 롤백하거나, 트래픽을 다시 블루 환경으로 전환하거나, 수동 개입이 필요할 수 있습니다.
CloudFormation 스택 생성 및 업데이트 작업의 일부로 [자동 롤백하는 기능을 제공합니다](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html). [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks) CodeDeploy 블루/그린 및 롤링 배포도 지원합니다.
이러한 기능을 활용하고 성능을 최소화하려면 MTTR 이러한 서비스를 통해 모든 인프라 및 코드 배포를 자동화하는 것이 좋습니다. 이러한 서비스를 사용할 수 없는 시나리오에서는 실패한 배포를 롤백하기 AWS Step Functions 위해 [saga 패턴을](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) 구현하는 것을 고려해 보세요.
재시작**을 고려할 때는 여러 가지 접근 방식이 있습니다. 여기에는 가장 긴 작업인 서버 재부팅부터 가장 짧은 작업인 스레드 재시작까지 다양합니다. 다음은 몇 가지 재시작 접근 방식과 완료에 소요되는 대략적인 시간을 요약한 표입니다(몇 분의 큰 차이를 나타내며 정확하지는 않음).
| 장애 복구 메커니즘 | 예상 MTTR |
| --- | --- |
| 새 가상 서버 시작 및 구성 | 15분 |
| 소프트웨어 재배포 | 10분 |
| 서버 재부팅 | 5분 |
| 컨테이너 재시작 또는 실행 | 2초 |
| 새 서버리스 함수 간접 호출 | 100ms |
| 프로세스 다시 시작 | 10ms |
| 스레드 다시 시작 | 10 마이크로초 |
표를 검토해 보면 컨테이너와 서버리스 함수 (예 [AWS Lambda](https://aws.amazon.com/lambda/):) 를 사용하면 몇 가지 분명한 이점이 있습니다. MTTR 가상 시스템을 다시 시작하거나 새 가상 시스템을 시작하는 것보다 몇 배 더 빠릅니다. MTTR 하지만 소프트웨어 모듈화를 통해 장애를 격리하는 것도 유용합니다. 단일 프로세스나 스레드에 고장을 포함할 수 있는 경우 해당 고장을 복구하는 것이 컨테이너나 서버를 다시 시작하는 것보다 훨씬 빠릅니다.
일반적인 복구 접근 방식으로 1/재시작, 2/재부팅, 3/이미지 재생성/재배포, 4/바꾸기를 뒤에서부터 앞으로 시도할 수 있습니다. 하지만 재부팅 단계로 넘어가면 일반적으로 고장을 우회하는 것이 더 빠릅니다(보통 최대 3\$14분 소요). 따라서 재시작 시도 후 영향을 가장 빠르게 완화하려면 고장을 우회한 다음 백그라운드에서 복구 프로세스를 계속하여 워크로드에 용량을 반환하세요.
**규칙 10**
문제 해결이 아닌 영향 완화에 집중하세요. 정상 작동 상태로 돌아가는 가장 빠른 길을 택하세요.
## 고장 진단
진단 기간은 감지 후 수리 프로세스의 일부입니다. 이 기간은 작업자가 무엇이 잘못되었는지 판단하는 기간입니다. 이 프로세스에는 로그 쿼리, 작업 상태 지표 검토 또는 문제 해결을 위한 호스트 로그인이 포함될 수 있습니다. 이러한 모든 작업에는 시간이 필요하므로 이러한 작업을 신속하게 처리할 수 있는 도구와 런북을 만들면 시간을 줄이는 데 도움이 될 수 있습니다. MTTR
## 런북 및 자동화
마찬가지로, 무엇이 잘못되었고 어떤 조치를 취해야 워크로드가 복구될 것인지 판단한 후 작업자는 일반적으로 이를 위해 몇 가지 단계를 수행해야 합니다. 예를 들어 고장이 발생한 후 워크로드를 복구하는 가장 빠른 방법은 워크로드를 다시 시작하는 것일 수 있으며, 이 경우 순서가 정해진 여러 단계를 따라야 할 수 있습니다. 이러한 단계를 자동화하거나 운영자에게 구체적인 지침을 제공하는 런북을 활용하면 프로세스를 가속화하고 의도하지 않은 조치로 인한 위험을 줄일 수 있습니다.
# 증가 MTBF
가용성 향상의 마지막 구성 요소는 를 높이는 MTBF 것입니다. 이는 소프트웨어와 이를 실행하는 데 사용된 AWS 서비스 모두에 적용될 수 있습니다.
## 분산 시스템 확대 MTBF
이를 늘리는 MTBF 한 가지 방법은 소프트웨어의 결함을 줄이는 것입니다. 이를 달성하는 데는 몇 가지 방법이 있습니다. 고객은 [Amazon CodeGuru Reviewer와](https://aws.amazon.com/codeguru/) 같은 도구를 사용하여 일반적인 오류를 찾아 수정할 수 있습니다. 또한 소프트웨어를 프로덕션에 배포하기 전에 포괄적인 피어 코드 검토, 유닛 테스트, 통합 테스트, 회귀 테스트, 소프트웨어 부하 테스트 등을 수행해야 합니다. 테스트에서 코드 적용 범위를 늘리면 흔하지 않은 코드 실행 경로도 테스트할 수 있습니다.
작은 변경 내용을 배포하는 것도 변경의 복잡성을 줄여 예상치 못한 결과를 방지하는 데 도움이 될 수 있습니다. 각 활동을 통해 문제가 발생하기 전에 결함을 식별하고 수정할 수 있습니다.
고장을 예방하는 또 다른 방법은 [정기적인 테스트](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html)입니다. 카오스 엔지니어링 프로그램을 구현하면 워크로드 고장 방식을 테스트하고, 복구 절차를 검증하고, 프로덕션 환경에서 고장이 발생하기 전에 고장 모드를 찾아 수정하는 데 도움이 될 수 있습니다. 고객은 카오스 엔지니어링 실험 도구 세트의 일부로 [AWS Fault Injection Simulator](https://aws.amazon.com/fis/)를 사용할 수 있습니다.
내결함성은 분산 시스템에서 고장을 방지하는 또 다른 방법입니다. 빠른 실패 모듈, 지수 백오프 및 지터가 발생하는 재시도, 트랜잭션, 멱등성 등은 모두 워크로드의 내결함성을 높이는 데 도움이 되는 기법입니다.
트랜잭션은 속성을 준수하는 작업 그룹입니다. ACID 그 속성이란 다음과 같습니다.
+ **원자성**: 모든 행동이 일어나거나 전혀 일어나지 않을 것입니다.
+ **일관성**: 각 트랜잭션은 워크로드를 유효한 상태로 놔둡니다.
+ **격리**: 동시에 수행된 트랜잭션은 워크로드를 순차적으로 수행된 것과 동일한 상태로 놔둡니다.
+ **내구성**: 트랜잭션이 커밋되면 워크로드에 고장이 발생한 경우에도 모든 영향이 보존됩니다.
[지수 백오프 및 지터](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)가 있는 재시도를 통해 하이젠버그, 오버로드 또는 기타 조건으로 인한 일시적 고장을 극복할 수 있습니다. 트랜잭션이 멱등인 경우 부작용 없이 여러 번 재시도할 수 있습니다.
하이젠버그가 내결함성 하드웨어 구성에 미치는 영향을 고려한다면, 하이젠버그가 기본 하위 시스템과 중복 하위 시스템 모두에 나타날 확률은 극히 적기 때문에 크게 걱정하지 않아도 될 것입니다. (Jim Gray, “[컴퓨터가 멈추는 이유와 이에 대해 취할 수 있는 조치](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf)”, 1985년 6월, 탠덤 기술 보고서 85.7. 참조) 분산 시스템에서 우리는 소프트웨어를 사용하여 동일한 결과를 달성하고자 합니다.
하이젠버그가 간접 호출되면 소프트웨어가 잘못된 작업을 빠르게 감지하고 실패하여 다시 시도하는 게 중요합니다. 이는 방어 프로그래밍과 입력, 중간 결과 및 출력의 검증을 통해 달성됩니다. 또한 프로세스는 격리되며 다른 프로세스와 상태를 공유하지 않습니다.
이 모듈식 접근 방식을 통해 고장 발생 시 영향의 범위를 제한할 수 있습니다. 프로세스는 독립적으로 고장 납니다. 프로세스가 실패하면 소프트웨어가 “프로세스 쌍”을 사용하여 작업을 재시도해야 합니다. 즉, 새 프로세스가 실패한 프로세스를 맡을 수 있습니다. 워크로드의 안정성과 무결성을 유지하려면 각 작업을 ACID 트랜잭션으로 취급해야 합니다.
이렇게 하면 트랜잭션을 중단하고 변경 내용을 롤백하여 워크로드 상태를 손상시키지 않고 프로세스가 실패할 수 있습니다. 이렇게 하면 복구 프로세스가 정상 작동이 확인된 상태에서 트랜잭션을 재시도하고 정상적으로 재시작할 수 있습니다. 이렇게 하면 소프트웨어가 하이젠버그에 대한 내결함성을 유지할 수 있습니다.
하지만 보어버그를 방지하는 소프트웨어를 만드는 것을 목표로 삼아서는 안 됩니다. 어떤 수준의 중복성으로도 올바른 결과를 얻을 수 없으므로 워크로드가 프로덕션에 들어가기 전에 이러한 결함을 찾아 제거해야 합니다. (Jim Gray, “[컴퓨터가 멈추는 이유와 이에 대해 취할 수 있는 조치](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)”, 1985년 6월, 탠덤 기술 보고서 85.7. 참조)
이를 늘리는 MTBF 마지막 방법은 실패로 인한 영향 범위를 줄이는 것입니다. 모듈화를 통한 [장애 격리](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)를 사용하여 장애 컨테이너를 생성하는 것은 앞서 내결함성 및 장애 격리**에서 설명한 바와 같이 이를 위한 기본 방법입니다. 고장률을 줄이면 가용성이 향상됩니다. AWS 서비스를 제어 플레인 및 데이터 플레인으로 분할, [가용 영역 독립성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) (AZI), [지역 격리](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [셀 기반 아키텍처](https://www.youtube.com/watch?v=swQbA4zub20), [셔플](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) 샤딩과 같은 기술을 사용하여 장애를 격리합니다. 이러한 패턴은 고객도 사용할 수 있는 패턴이기도 합니다. AWS
예를 들어, 전체 고객 중 최대 5%에 해당하는 서비스를 제공하는 워크로드가 자신의 인프라 안의 여러 장애 컨테이너에 고객을 배치한 경우를 살펴보겠습니다. 이러한 장애 컨테이너 중 하나에서 요청의 10%에 대해 클라이언트 제한 시간을 초과하여 지연 시간이 증가하는 이벤트가 발생합니다. 이 이벤트 기간 동안 95%의 고객이 서비스를 100% 이용할 수 있었습니다. 나머지 5%의 경우 서비스를 90% 이용할 수 있는 것으로 나타났습니다. 따라서 100%의 고객에게 요청의 10%가 실패하는 대신 1 − (5% o**f** c**u**s**t**o**m**e**r**s**×10% o**f** t**h**e**i**r** r**e**q**u**e**s**t**s**) = 99.5%의 가용성이 확보됩니다(결과적으로 90%의 가용성이 보장됨).
**규칙 11**
장애 격리는 전체 장애율을 줄여 MTBF 영향의 범위를 줄이고 워크로드를 증가시킵니다.
## 종속성 증가 MTBF
AWS 의존도를 MTBF 높이는 첫 번째 방법은 [장애](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) 격리를 사용하는 것입니다. 많은 AWS 서비스가 AZ에서 격리 수준을 제공합니다. 즉, 한 AZ에서 장애가 발생해도 다른 AZ의 서비스에는 영향을 미치지 않습니다.
여러 개의 중복 EC2 인스턴스를 사용하면 하위 시스템 AZs 가용성이 향상됩니다. AZI단일 지역 내에서 스페어링 기능을 제공하여 서비스 가용성을 높일 수 있습니다. AZI
하지만 모든 AWS 서비스가 AZ 수준에서 운영되는 것은 아닙니다. 리전별 격리를 제공하는 곳도 많습니다. 이 경우, 리전 서비스에 맞게 설계된 가용성이 워크로드에 필요한 전체 가용성을 지원하지 않는 경우 다중 리전 접근 방식을 고려할 수 있습니다. 각 리전은 스페어링에 해당하는 격리된 서비스 인스턴스화를 제공합니다.
다중 리전 서비스를 더욱 쉽게 구축하는 데 도움이 되는 다양한 서비스가 있습니다. 예:
+ [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/)
+ [Amazon DynamoDB 글로벌 테이블](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) — 글로벌 데이터스토어](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS 글로벌 액셀러레이터](https://aws.amazon.com/global-accelerator/)
+ [Amazon S3 교차 리전 복제](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Amazon Route 53 애플리케이션 복구 컨트롤러](https://aws.amazon.com/route53/application-recovery-controller/)
이 문서는 다중 리전 워크로드를 구축하는 전략을 자세히 다루지는 않지만, 사용자는 원하는 가용성 목표를 달성하는 데 필요한 추가 비용, 복잡성 및 운영 관행과 함께 다중 리전 아키텍처의 가용성 이점을 비교해 봐야 합니다.
종속성을 MTBF 높이는 다음 방법은 워크로드를 정적으로 안정적으로 설계하는 것입니다. 예를 들어, 제품 정보를 제공하는 워크로드가 있다고 가정합니다. 고객이 제품을 요청하면 서비스는 외부 메타데이터 서비스에 요청하여 제품 세부 정보를 검색합니다. 그러면 워크로드가 해당 정보를 모두 고객에게 반환합니다.
하지만 메타데이터 서비스를 사용할 수 없는 경우 고객의 요청은 실패합니다. 대신 요청에 응답하는 데 사용할 메타데이터를 서비스에 로컬로 비동기적으로 가져오거나 푸시할 수 있습니다. 이렇게 하면 중요 경로에서 메타데이터 서비스에 대한 동기 직접 호출이 제거됩니다.
또한 메타데이터 서비스가 없는 경우에도 서비스를 계속 사용할 수 있으므로 가용성 계산 시 종속 항목으로 해당 서비스를 제거할 수 있습니다. 이 예는 메타데이터가 자주 변경되지 않으며 요청이 실패하는 것보다 오래된 메타데이터를 제공하는 것이 낫다는 가정을 기반으로 합니다. 또 다른 유사한 예로는 TTL 만료 후에도 데이터를 캐시에 보관하여 새로 고친 답변을 쉽게 찾을 수 없을 때 응답에 사용할 수 DNS 있는 [serve-stale을](https://www.rfc-editor.org/rfc/rfc8767) 들 수 있습니다.
종속성을 높이는 마지막 방법은 실패로 인한 영향 MTBF 범위를 줄이는 것입니다. 앞서 설명했듯이, 고장은 났는가 안 났는가로 나뉘지 않고, 얼마나 심하게 또는 경미하게 났는가로 나뉩니다. 이는 모듈화의 영향입니다. 고장은 해당 컨테이너에서 서비스를 받는 요청이나 사용자에게만 국한됩니다.
따라서 이벤트 중에 발생하는 고장이 줄어들어 영향 범위가 제한되므로 궁극적으로 전체 워크로드의 가용성이 향상됩니다.
## 일반적인 영향 원인 감소
1985년, Jim Gray는 탠덤 컴퓨터에서 연구를 진행하면서 고장이 주로 소프트웨어와 운영이라는 두 가지 요인에 의해 발생한다는 사실을 발견했습니다. (Jim Gray, “[컴퓨터가 멈추는 이유와 이에 대해 취할 수 있는 조치](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)”, 1985년 6월, 탠덤 기술 보고서 85.7. 참조) 36년이 지난 지금도 이 사실은 변함이 없습니다. 기술의 발전에도 불구하고 이러한 문제를 쉽게 해결할 수 있는 방법은 없으며 고장의 주요 원인은 변하지 않았습니다. 이 항목의 시작 부분에서 소프트웨어 고장 해결에 대해 설명했으므로 여기서는 운영과 고장 빈도 감소에 중점을 둘 것입니다.
### 안정성과 특성 비교
[분산 시스템 가용성](distributed-system-availability.md) 항목의 소프트웨어 및 하드웨어 고장률 그래프를 다시 참조하면 각 소프트웨어 릴리스마다 결함이 추가되고 있음을 알 수 있습니다. 즉, 워크로드가 변경되면 고장 위험이 높아집니다. 이러한 변경은 일반적으로 새 특성과 비슷하며 이에 따른 결과를 제공합니다. 워크로드의 가용성이 높을수록 새 특성보다 안정성이 더 좋습니다. 따라서 가용성을 개선하는 가장 간단한 방법 중 하나는 배포 빈도를 줄이거나 특성 수를 줄이는 것입니다. 배포 빈도가 높은 워크로드는 그렇지 않은 워크로드보다 본질적으로 가용성이 낮습니다. 그러나 특성을 추가하지 못한 워크로드는 고객 수요를 따라가지 못하고 시간이 지남에 따라 유용성이 떨어질 수 있습니다.
그렇다면 계속해서 혁신하고 특성을 안전하게 출시하려면 어떻게 해야 할까요? 답은 표준화입니다. 올바른 배포 방법은 무엇입니까? 배포를 어떻게 주문합니까? 테스트 표준은 무엇입니까? 스테이지 사이에 얼마나 시간을 두겠습니까? 유닛 테스트에서 소프트웨어 코드를 충분히 다루고 있나요? 표준화를 통해 이러한 질문에 대한 답을 찾고 부하 테스트를 하지 않거나, 배포 단계를 건너뛰거나, 너무 많은 호스트에 너무 빨리 배포하는 등의 문제로 인해 발생하는 문제를 예방할 수 있습니다.
표준화를 구현하는 방법은 자동화를 이용하는 것입니다. 이를 통해 사람이 실수할 가능성이 줄어들고 컴퓨터가 잘하는 일을 할 수 있게 됩니다. 즉, 매번 같은 작업을 반복해서 수행하는 거죠. 표준화와 자동화를 함께 유지하는 방법은 목표를 설정하는 것입니다. 수동 변경 없음, 조건부 인증 시스템을 통해서만 호스트 액세스API, 모든 권한에 대한 부하 테스트 작성 등과 같은 목표가 있습니다. 운영의 우수성은 문화적 규범이며 상당한 변화가 필요할 수 있습니다. 목표 대비 성과를 설정하고 추적하면 워크로드 가용성에 광범위한 영향을 미칠 문화적 변화를 주도하는 데 도움이 됩니다. [AWS Well-Architected 운영 우수성 요소](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)는 운영 우수성을 위한 포괄적인 모범 사례를 제공합니다.
### 운영자 안전
고장을 초래하는 운영 문제의 또 다른 주요 원인은 바로 사람입니다. 사람은 실수를 합니다. 잘못된 자격 증명을 사용하거나, 잘못된 명령을 입력하거나, Enter 키를 너무 빨리 누르거나, 중요한 단계를 놓칠 수 있습니다. 수동 조치를 지속적으로 취하면 오류가 발생하여 고장이 일어납니다.
운영자 오류의 주요 원인 중 하나는 혼란스럽거나 직관적이지 않거나 일관되지 않은 사용자 인터페이스입니다. Jim Gray는 또한 1985년 연구에서 “운영자에게 정보를 요청하거나 일부 기능을 수행하도록 요청하는 인터페이스는 단순하고 일관적이며 운영자 내결함성이 있어야 한다”고 언급했습니다. (Jim Gray, “[컴퓨터가 멈추는 이유와 이에 대해 취할 수 있는 조치](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf)”, 1985년 6월, 탠덤 기술 보고서 85.7. 참조) 이 통찰은 오늘날에도 여전히 유효합니다. 지난 30년 동안 업계 전반에 걸쳐 혼란스럽거나 복잡한 사용자 인터페이스, 확인이나 지침의 부재, 심지어 비우호적인 인간의 언어 때문에 운영자가 잘못된 일을 하게 된 사례는 수없이 많습니다.
**규칙 12**
운영자가 올바른 일을 쉽게 할 수 있도록 하세요.
### 과부하 방지
영향을 미치는 최종 공통 기여자는 워크로드의 실제 사용자인 고객입니다. 성공적인 워크로드는 많이 사용되는 경향이 있지만, 때로는 그 사용량이 워크로드의 확장 능력을 능가하기도 합니다. 디스크가 꽉 차거나, 스레드 풀이 고갈되거나, 네트워크 대역폭이 포화되거나, 데이터베이스 연결 한도에 도달하는 등 많은 일이 발생할 수 있습니다.
이러한 문제를 해결할 수 있는 확실한 방법은 없지만 운영 상태 지표를 통해 용량 및 활용도를 사전에 모니터링하면 이러한 고장이 발생할 수 있는 경우 조기 경고를 제공할 수 있습니다. [부하 제거](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload), [회로 차단기](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html), [지수 백오프 및 지터를 사용한 재시도](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)와 같은 기법은 영향을 최소화하고 성공률을 높이는 데 도움이 될 수 있지만 이러한 상황은 여전히 고장으로 이어집니다. 운영 상태 지표를 기반으로 하는 자동 규모 조정은 과부하로 인한 고장 빈도를 줄이는 데 도움이 될 수 있지만 사용률 변화에 충분히 신속하게 대응하지 못할 수 있습니다.
고객이 지속적으로 사용할 수 있는 용량을 확보하려면 가용성과 비용을 절충해야 합니다. 용량 부족으로 인한 가용성 중단이 발생하지 않도록 하는 한 가지 방법은 각 고객에게 할당량을 제공하고 할당된 할당량을 100% 제공하도록 워크로드 용량을 규모 조정하는 것입니다. 고객이 할당량을 초과하면 속도 제한이 발생하는데, 이는 고장이 아니며 가용성에 영향을 주지 않습니다. 또한 충분한 용량을 프로비저닝하려면 고객 기반을 면밀히 추적하고 향후 활용도를 예측해야 합니다. 이렇게 하면 고객의 과도한 소비로 인해 워크로드가 고장 시나리오로 이어지지 않도록 할 수 있습니다.
+ [Amazon Builders' Library - 부하 제거를 사용하여 과부하 방지](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library - 다중 테넌트 시스템의 공정성](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
예를 들어 스토리지 서비스를 제공하는 워크로드를 살펴보겠습니다. 워크로드의 각 서버는 초당 100건의 다운로드를 지원할 수 있고, 고객에게는 할당량 또는 초당 200건의 다운로드를 지원할 수 있으며 고객은 500명입니다. 이 같은 규모의 고객을 지원하려면 서비스가 초당 100,000건의 다운로드 용량을 제공해야 하며, 이를 위해서는 1,000대의 서버가 필요합니다. 고객이 할당량을 초과하면 속도 제한이 발생하여 다른 모든 고객에게 충분한 용량을 제공할 수 있습니다. 이것은 작업 단위를 거부하지 않고 과부하를 방지하는 한 가지 방법의 간단한 예입니다.