# REL 10 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까?
장애 격리 경계는 워크로드 내부 장애의 영향을 제한된 수의 구성 요소로 제한합니다. 경계 외부의 구성 요소는 장애가 발생하더라도 영향을 받지 않습니다. 다수의 장애 격리 경계를 사용하여 워크로드에 미치는 영향을 제한할 수 있습니다.
**Topics**
+ [REL10-BP01 워크로드를 여러 위치에 배포](rel_fault_isolation_multiaz_region_system.md)
+ [REL10-BP02 다중 위치 배포에 적합한 위치 선택](rel_fault_isolation_select_location.md)
+ [REL10-BP03 단일 위치로 제약된 구성 요소의 복구 자동화](rel_fault_isolation_single_az_system.md)
+ [REL10-BP04 격벽 아키텍처를 사용하여 영향 범위 제한](rel_fault_isolation_use_bulkhead.md)
# REL10-BP01 워크로드를 여러 위치에 배포
워크로드 데이터와 리소스를 여러 가용 영역에 분산하거나 필요한 경우 AWS 리전 전체에 분산합니다. 필요에 따라 다양한 위치를 사용할 수 있습니다.
AWS의 서비스 설계 관련 기본 원칙 중 하나는 기본 물리적 인프라에서 단일 장애 지점이 없어야 한다는 것입니다. 이 원칙을 준수하려면 가용 영역 여러 개를 사용하며 단일 영역에서 장애가 발생해도 복원이 가능한 소프트웨어와 시스템을 구축해야 합니다. 마찬가지로, 시스템은 단일 컴퓨팅 노드, 단일 스토리지 볼륨 또는 단일 데이터베이스 인스턴스에서 장애가 발생하더라도 복원 가능하도록 구축됩니다. 중복 구성 요소를 사용하는 시스템을 구축할 때는 구성 요소가 독립적(AWS 리전의 경우 자율적)으로 작동해야 합니다. 중복 구성 요소를 사용한 이론적 가용성 계산에서 얻을 수 있는 이점은 이것이 사실인 경우에만 유효합니다.
**가용 영역(AZ)**
AWS 리전은 서로 독립적으로 설계된 여러 개의 가용 영역으로 구성됩니다. 화재, 홍수, 태풍 등의 자연 재해로 인한 상관 장애 시나리오를 방지하기 위해 각 가용 영역은 물리적으로 유의미하게 떨어져 있도록 분리됩니다. 또한 각 가용 영역에는 독립된 물리적 인프라(다목적 전원에 대한 전용 연결, 대기 백업 전원, 독립 기계 서비스, 가용 영역 내/외부의 독립 네트워크 연결)가 포함되어 있습니다. 이 설계는 이 시스템 중 하나에서 발생한 장애가 영향을 받은 하나의 가용 영역에만 국한되도록 합니다. 가용 영역은 지리적으로는 분리되지만 같은 지역에 배치되어 높은 처리량과 낮은 지연 시간의 네트워킹이 가능합니다. 동기식으로 데이터를 복제하는 등(예: 데이터베이스 간에) 전체 AWS 리전(여러 개의 물리적으로 독립적인 데이터 센터로 구성된 모든 가용 영역의 AWS 리전)을 워크로드의 하나의 논리적 배포 대상으로 취급할 수 있습니다. 그러면 액티브/액티브 또는 액티브/대기 구성에서 가용 영역을 사용할 수 있습니다.
가용 영역은 서로 독립되어 있으므로 워크로드가 여러 영역을 사용하도록 아키텍팅된 경우 워크로드 가용성이 높아집니다. 일부 AWS 서비스(Amazon EC2 인스턴스 데이터 영역 포함)는 해당 서비스가 위치한 가용 영역과 운명을 같이하는 엄격한 영역별 서비스로 배포됩니다. 그러나 다른 가용 영역에 있는 Amazon EC2 인스턴스는 영향을 받지 않고 계속해서 작동합니다. 마찬가지로, 한 가용 영역에서의 장애로 인해 Amazon Aurora 데이터베이스에 장애가 발생하면 영향을 받지 않은 가용 영역에 있는 읽기 전용 복제본 Aurora 인스턴스가 자동으로 기본으로 승격될 수 있습니다. 반면 Amazon DynamoDB 등의 리전별 AWS 서비스는 사용자가 가용 영역 배치를 구성할 필요 없이 해당 서비스에 설정된 가용성 설계 목표를 달성하기 위해 내부적으로 액티브/액티브 구성에서 여러 가용 영역을 사용합니다.
![\[3개의 가용 영역에 배포된 다중 계층 아키텍처를 보여주는 다이어그램. Amazon S3와 Amazon DynamoDB는 항상 자동으로 다중 AZ에 유지됩니다. 또한 ELB는 3개 영역 모두에 배포됩니다.\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-tier-architecture.png)
AWS 컨트롤 플레인에서는 대개 전체 리전(여러 가용 영역) 내의 리소스를 관리하는 기능이 제공되지만, Amazon EC2, Amazon EBS 등의 특정 컨트롤 플레인에는 단일 가용 영역으로 결과를 필터링하는 기능도 있습니다. 이처럼 결과가 필터링되면 요청은 지정된 가용 영역에서만 처리되므로 다른 가용 영역이 중단될 가능성이 낮아집니다. 이 AWS CLI 예시는 us-east-2c 가용 영역에서만 Amazon EC2 인스턴스 정보를 가져오는 것을 보여줍니다.
```
AWS ec2 describe-instances --filters Name=availability-zone,Values=us-east-2c
```
*AWS 로컬 영역*
AWS 로컬 영역은 서브넷 및 EC2 인스턴스와 같은 영역 단위 AWS 리소스에 대한 배치 위치로 선택될 수 있다는 점에서 해당 AWS 리전 내의 가용 영역과 유사하게 작동합니다. 이러한 로컬 영역은 연결된 AWS 리전이 아니라 현재 AWS 리전이 없는 대규모 인구, 산업 및 IT 센터에 가까운 곳에 위치한다는 점에서 특별합니다. 그럼에도 불구하고 로컬 영역의 로컬 워크로드와 AWS 리전에서 실행 중인 워크로드 간에는 고대역폭의 안전한 연결이 유지됩니다. 지연 시간이 짧아야 하는 요구 사항을 충족하기 위해 사용자에게 더 가까운 위치에 워크로드를 배포하려면 AWS 로컬 영역을 사용해야 합니다.
**Amazon 글로벌 엣지 네트워크**
Amazon 글로벌 엣지 네트워크는 전 세계 도시의 엣지 로케이션으로 구성됩니다. Amazon CloudFront는 이 네트워크를 사용하여 최종 사용자에게 더 짧은 지연 시간으로 콘텐츠를 전송합니다. AWS Global Accelerator를 사용하면 이러한 엣지 로케이션에 워크로드 엔드포인트를 생성하여 사용자와 가까운 AWS 글로벌 네트워크로의 온보딩을 제공할 수 있습니다. Amazon API Gateway는 CloudFront 배포를 사용하여 엣지 최적화 API 엔드포인트를 활성화함으로써 가장 가까운 엣지 로케이션을 통한 클라이언트 접근을 가속화합니다.
*AWS 리전*
AWS 리전은 자율적으로 작동하도록 설계되므로 다중 리전 접근 방식을 사용하려면 각 리전에 서비스의 전용 복사본을 배포해야 합니다.
다중 리전 접근법은 일회성의 대규모 이벤트가 발생할 때 복구 목표를 달성하기 위한 *재해 복구* 전략에 자주 사용됩니다. 이러한 전략에 대한 자세한 내용은 [https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html) 을 참조하십시오. 그러나 여기에서는 시간 경과에 따라 평균 업타임 목표를 달성하는 *가용성*에 집중합니다. 목표가 고가용성인 경우 다중 리전 아키텍처가 일반적으로 액티브/액티브로 설계됩니다. 여기에서 각 서비스 복사본은 각각의 리전에서 액티브(요청을 서비스함)입니다.
**추천**
단일 AWS 리전 안에서 다중 AZ 전략을 사용하여 대부분의 워크로드에 대한 가용성 목표를 충족할 수 있습니다. 워크로드에 매우 높은 가용성 요구 사항이 있는 경우 또는 다중 리전 아키텍처를 요구하는 다른 비즈니스 목표가 있는 경우에만 다중 리전 아키텍처를 고려하십시오.
AWS는 교차 리전에서 서비스를 운영할 수 있는 기능을 제공합니다. 예를 들어, AWS는 Amazon Simple Storage Service(Amazon S3) 복제본, Amazon RDS 읽기 전용 복제본(Aurora 읽기 전용 복제본 포함), Amazon DynamoDB 글로벌 테이블을 사용하여 지속적인 비동기식 데이터 복제를 제공합니다. 지속적인 복제본을 통해 각 액티브 리전에서 거의 즉시 데이터의 버전을 사용할 수 있습니다.
AWS CloudFormation을 사용하면 인프라를 정의하고 AWS 계정 및 AWS 리전 전체에 일관적으로 배포할 수 있습니다. 또한 AWS CloudFormation StackSets는 한 번의 작업으로 여러 계정과 리전에 AWS CloudFormation 스택을 생성, 업데이트, 삭제할 수 있도록 이 기능을 확장합니다. Amazon EC2 인스턴스 배포의 경우 AMI(Amazon Machine Image)를 사용하여 하드웨어 구성 및 설치된 소프트웨어 같은 정보를 제공합니다. 필요한 AMI를 생성하고 이것을 액티브 리전에 복사하는 Amazon EC2 Image Builder 파이프라인을 구현할 수 있습니다. 그렇게 하면 이 *Golden AMI에* 새로운 각 리전에 워크로드를 배포하고 스케일 아웃하는 데 필요한 모든 것이 포함됩니다.
트래픽을 라우팅하기 위해 Amazon Route 53 및 AWS Global Accelerator에서 모두 어떤 사용자가 어떤 액티브 리전 엔드포인트로 이동하는지를 결정하는 정책을 정의할 수 있습니다. Global Accelerator를 사용하면 트래픽 다이얼을 설정하여 각 애플리케이션 엔드포인트로 이동하는 트래픽의 비율을 제어할 수 있습니다. Route 53는 이 비율 접근법과 함께 지리 근접 및 지연 시간 기반 접근법 등 여러 정책을 지원합니다. Global Accelerator는 AWS 엣지 서버의 광범위한 네트워크를 자동으로 활용하여 트래픽이 가능한 한 빨리 AWS 네트워크 백본을 사용하도록 온보딩함으로써 요청 지연 시간을 단축합니다.
이런 기능은 모두 각 리전의 자율성을 보존하도록 작동합니다. 이 방식의 예외는 Amazon CloudFront 및 Amazon Route 53와 같이 글로벌 엣지 제공 기능을 제공하는 서비스와 AWS Identity and Access Management(IAM) 서비스용 컨트롤 플레인 등의 몇 가지뿐입니다. 대부분의 서비스는 전적으로 단일 리전 내에서 작동합니다.
**온프레미스 데이터 센터**
온프레미스 데이터 센터에서 실행되는 워크로드의 경우 가능하면 하이브리드 환경을 설계합니다. AWS Direct Connect는 온프레미스에서 AWS로 연결되는 전용 네트워크 연결을 제공하므로 두 환경에서 모두 워크로드를 실행할 수 있습니다.
또 다른 옵션은 AWS Outposts를 사용하여 온프레미스에서 AWS 인프라 및 서비스를 실행하는 것입니다. AWS Outposts는 AWS 인프라, AWS 서비스, API 및 도구를 온프레미스 데이터 센터로 확장하는 완전관리형 서비스입니다. AWS 클라우드에서 사용되는 것과 동일한 하드웨어 인프라가 데이터 센터에 설치됩니다. AWS Outposts는 가장 가까운 AWS 리전에 연결됩니다. 그런 다음에는 AWS Outposts를 사용하여 지연 시간이 짧아야 하거나 로컬 데이터 처리 요구 사항이 있는 워크로드를 지원할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 다중 가용 영역 및 AWS 리전을 선택합니다. 워크로드 데이터와 리소스를 여러 가용 영역에 분산하거나 필요한 경우 AWS 리전 전체에 분산합니다. 필요에 따라 다양한 위치를 사용할 수 있습니다.
+ 리전별 서비스는 가용 영역 전체에 배포됩니다.
+ 여기에는 Amazon S3, Amazon DynamoDB, AWS Lambda(VPC에 연결되지 않은 경우)가 포함됩니다.
+ 컨테이너, 인스턴스 및 함수 기반 워크로드를 여러 가용 영역에 배포합니다. 캐시를 비롯한 다중 영역 데이터 스토어를 사용합니다. VPC에서 실행할 때 EC2 Auto Scaling, ECS 태스크 배치, AWS Lambda 함수 구성의 기능 및 ElastiCache 클러스터를 사용합니다.
+ Auto Scaling 그룹을 배포할 때는 서로 다른 가용 영역에 있는 서브넷을 사용합니다.
+ [예: 가용 영역 전반에 인스턴스 분산](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Amazon VPC에서 리소스에 액세스하도록 AWS Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ Auto Scaling 그룹을 배포할 때는 서로 다른 가용 영역에 있는 서브넷을 사용합니다.
+ [예: 가용 영역 전반에 인스턴스 분산](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ ECS 작업 배치 파라미터를 사용하여 DB 서브넷 그룹을 지정합니다.
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ VPC에서 실행할 기능을 구성할 때 여러 가용 영역의 서브넷을 사용합니다.
+ [Amazon VPC에서 리소스에 액세스하도록 AWS Lambda 함수 구성](https://docs.aws.amazon.com/lambda/latest/dg/vpc.html)
+ ElastiCache 클러스터를 통해 여러 가용 영역을 사용합니다.
+ [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ 워크로드를 여러 리전에 배포해야 하는 경우 다중 리전 전략을 선택합니다. 단일 AWS 리전 내에서 다중 가용 영역 전략을 사용하여 대부분의 신뢰성 요구 사항을 충족할 수 있습니다. 비즈니스 요구 사항을 충족하는 데 필요한 경우 다중 리전 전략을 사용합니다.
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ 다른 AWS 리전으로 백업하면 필요할 때 데이터를 사용할 수 있다는 보장이 추가됩니다.
+ 일부 워크로드의 경우 규제 요건에 따라 다중 리전 전략을 사용해야 합니다.
+ 워크로드의 AWS Outposts를 평가합니다. 온프레미스 데이터 센터에 대한 지연 시간이 짧아야 하거나 로컬 데이터 처리 요구 사항을 충족해야 하는 워크로드의 경우 AWS Outposts를 사용하여 온프레미스에서 AWS 인프라와 서비스를 실행합니다.
+ [AWS Outposts란 무엇입니까?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
+ AWS 로컬 영역이 사용자에게 서비스를 제공하는 데 도움이 되는지 확인합니다. 짧은 지연 시간에 대한 요구 사항이 있는 경우 AWS 로컬 영역이 사용자 근처에 있는지 확인합니다. 그렇다면 이를 사용하여 해당 사용자에게 더 가까운 위치에 워크로드를 배포합니다.
+ [AWS 로컬 영역 FAQ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
## 리소스
**관련 문서:**
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS 로컬 영역 FAQ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [리전 및 가용 영역 선택](https://docs.aws.amazon.com/AmazonElastiCache/latest/UserGuide/RegionsAndAZs.html)
+ [예: 가용 영역 전반에 인스턴스 분산](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#arch-AutoScalingMultiAZ)
+ [전역 테이블: DynamoDB를 사용한 다중 리전 복제](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
+ [Amazon Aurora 글로벌 데이터베이스 사용](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html)
+ [Creating a Multi-Region Application with AWS Services(AWS 서비스로 다중 리전 애플리케이션 생성) 블로그 시리즈](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS Outposts란 무엇입니까?](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Innovation and operation of the AWS global network infrastructure(AWS 글로벌 네트워크 인프라 혁신 및 운영)(NET339)](https://youtu.be/UObQZ3R9_4c)
# REL10-BP02 다중 위치 배포에 적합한 위치 선택
## 원하는 결과
고가용성을 위해서는 그림 10에 나온 것과 같이 가능하면 언제나 워크로드 구성 요소를 여러 개의 가용 영역(AZ)에 배포하세요. 복원력에 대한 요구 사항이 매우 높은 워크로드의 경우 다중 리전 아키텍처에 대한 옵션을 신중하게 평가하세요.
![\[다른 AWS 리전에 백업되고 복원력이 있는 다중 AZ 데이터베이스 배포를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-az-architecture.png)
## 일반적인 안티 패턴
+ 다중 AZ 아키텍처로 요구 사항을 충족할 수 있는데 다중 리전 아키텍처로 설계함
+ 복원력과 다중 위치 요구 사항이 구성 요소 간에 다를 경우 애플리케이션 구성 요소 간의 종속성을 고려하지 않음
## 이 모범 사례 수립의 이점
복원력을 위해서는 방어 계층을 구축하는 접근 방식을 사용해야 합니다. 하나의 계층은 다중 AZ를 사용하여 가용성이 높은 아키텍처를 구축함으로써 더 작고 더 일반적인 장애를 예방하고 또 다른 방어 계층은 만연한 자연 재해와 리전 수준의 장애와 같은 드문 이벤트를 예방하도록 설계합니다. 이 두 번째 계층에는 애플리케이션이 여러 AWS 리전에 분산되도록 하는 아키텍팅이 포함됩니다.
+ 99.5% 가용성과 99.99% 가용성의 차이는 월간 3.5시간이 넘습니다. 워크로드가 여러 가용 영역에 있는 경우 워크로드의 예상 가용성은 최대 99.99%에 그치게 됩니다.
+ 워크로드를 여러 가용 영역에서 실행하면 전력, 냉각기, 네트워킹에서의 장애와 화재나 홍수와 같은 대부분의 자연 재해로 인한 장애를 격리할 수 있습니다.
+ 워크로드에 다중 리전 전략을 구현하면 한 나라의 광범위한 지역에 영향을 미치는 만연한 자연 재해나 리전 전체에 발생한 기술적 장애로부터 워크로드를 보호할 수 있습니다. 다중 리전 아키텍처를 구현하는 일은 매우 복잡할 수 있으며 대개 대부분의 워크로드에는 필요하지 않다는 점을 참고하시기 바랍니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
가용 영역 한 곳의 중단이나 일부 소실에 따른 재해 이벤트의 경우 단일 AWS 리전 내 다중 가용 영역에 고가용성 워크로드를 구현하면 자연 재해와 기술 재해의 위험을 완화하는 데 도움이 됩니다. 각 AWS 리전은 여러 가용 영역으로 구성되며, 각 가용 영역은 상당히 멀리 떨어진 다른 영역에 발생한 장애의 영향을 받지 않습니다. 그러나 서로 상당히 멀리 떨어진 여러 가용 영역 구성 요소가 소실될 위험이 있는 재해 이벤트의 경우 리전 전체에 영향을 주는 장애를 완화하는 재해 복구 옵션을 구현해야 합니다. 매우 높은 복원력을 요구하는 워크로드(핵심 인프라, 건강 관련 애플리케이션, 금융 시스템 인프라 등)의 경우 다중 리전 전략이 필요할 수 있습니다.
## 구현 단계
1. 워크로드를 평가하고 복원력에 대한 요구 사항을 다중 가용 영역 접근법(단일 AWS 리전)으로 충족할 수 있는지, 아니면 다중 리전 접근법이 필요한지 결정합니다. 이런 요구 사항을 충족하기 위해 다중 리전 아키텍처를 구현하면 복잡성이 가중되므로 사용 사례와 요구 사항을 신중하게 고려해야 합니다. 복원력 요구 사항은 단일 AWS 리전을 사용하여 대부분 충족할 수 있습니다. 여러 리전을 사용해야 하는지 결정할 때는 다음과 같은 요구 사항을 고려하세요.
1. **재해 복구(DR)**: 가용 영역 한 곳의 중단이나 일부 소실에 따른 재해 이벤트의 경우 단일 AWS 리전 내 다중 가용 영역에 고가용성 워크로드를 구현하면 자연 재해와 기술 재해의 위험을 완화하는 데 도움이 됩니다. 서로 상당히 멀리 떨어진 여러 가용 영역 구성 요소가 소실될 위험이 있는 재해 이벤트의 경우, 자연 재해를 완화하거나 리전 전체에 영향을 주는 기술적 장애를 완화하는 여러 리전에 걸친 재해 복구를 구현해야 합니다.
1. **고가용성(HA)**: 다중 리전 아키텍처(각 리전에 여러 개의 가용 영역 사용)를 사용하여 99.99% 이상의 가용성을 달성할 수 있습니다.
1. **스택 현지화**: 전 세계 사용자를 대상으로 워크로드를 배포할 때는 다양한 AWS 리전에 현지화된 스택을 배포하여 해당 리전의 사용자에게 제공할 수 있습니다. 언어, 통화, 저장되는 데이터의 유형이 현지화의 대상이 될 수 있습니다.
1. **사용자에 대한 근접성:** 전 세계 사용자에게 워크로드를 배포할 때는 최종 사용자에게 가까운 AWS 리전에 스택을 배포하여 지연 시간을 단축할 수 있습니다.
1. **데이터 레지던시**: 일부 워크로드에는 특정 사용자의 데이터가 특정 국가의 국경 내에 남아 있어야 한다는 데이터 레지던시 요구 사항이 적용됩니다. 해당 규제에 따라 해당 국경 내의 AWS 리전에 전체 스택을 배포할지, 데이터만 배포할지 선택할 수 있습니다.
1. AWS 서비스에서 제공하는 다중 AZ 기능의 예는 다음과 같습니다.
1. EC2 또는 ECS를 사용하여 워크로드를 보호하기 위해 컴퓨팅 리소스 앞에 Elastic Load Balancer를 배포합니다. 그런 다음 Elastic Load Balancing가 비정상 영역의 인스턴스를 탐지하고 정상 영역으로 트래픽을 라우팅하는 솔루션을 제공합니다.
1. [Application Load Balancers 시작하기](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancer-getting-started.html)
1. [Network Load Balancer 시작하기](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html)
1. 로드 밸런싱을 지원하지 않는 상용 기성품 소프트웨어를 실행하는 EC2 인스턴스의 경우 다중 AZ 재해 복구 방법론을 구현하여 일종의 내결함성을 달성할 수 있습니다.
1. [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
1. Amazon ECS 태스크의 경우 세 개의 가용 영역에 균등하게 서비스를 배포하여 가용성과 비용의 균형을 달성합니다.
1. [Amazon ECS 가용성 모범 사례 \$1 컨테이너](https://aws.amazon.com/blogs/containers/amazon-ecs-availability-best-practices/)
1. Aurora Amazon RDS가 아닌 경우 구성 옵션으로 다중 AZ를 선택할 수 있습니다. 기본 데이터베이스 인스턴스가 실패하면 Amazon RDS가 자동으로 대기 데이터베이스를 승격하여 다른 가용 영역의 트래픽을 수신하도록 합니다. 다중 리전 읽기 전용 복제본도 복원력을 향상하기 위해 생성할 수 있습니다.
1. [Amazon RDS 다중 AZ 배포](https://aws.amazon.com/rds/features/multi-az/)
1. [다른 AWS 리전에 읽기 전용 복제본 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.XRgn.html)
1. AWS 서비스에서 제공하는 다중 리전 기능의 예는 다음과 같습니다.
1. 서비스에서 자동으로 다중 AZ 가용성이 제공되는 Amazon S3 워크로드의 경우 다중 리전 배포가 필요하다면 다중 리전 액세스 포인트를 고려하세요.
1. [Amazon S3에서의 다중 리전 액세스 포인트](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiRegionAccessPoints.html)
1. 서비스에서 자동으로 다중 AZ 가용성이 제공되는 DynamoDB 테이블의 경우 기존 테이블을 글로벌 테이블로 쉽게 변환하여 다중 리전의 이점을 누릴 수 있습니다.
1. [단일 리전 Amazon DynamoDB 테이블을 글로벌 테이블로 변환](https://aws.amazon.com/blogs/aws/new-convert-your-single-region-amazon-dynamodb-tables-to-global-tables/)
1. 워크로드에 Application Load Balancers 또는 Network Load Balancer가 선행된다면 AWS Global Accelerator를 사용하여 정상 엔드포인트가 포함된 다중 리전으로 트래픽을 이동시킴으로써 애플리케이션의 가용성을 향상합니다.
1. [AWS Global Accelerator의 표준 액셀러레이터 엔드포인트 - AWS Global Accelerator(amazon.com)](https://docs.aws.amazon.com/global-accelerator/latest/dg/about-endpoints.html)
1. AWS EventBridge를 사용하는 애플리케이션의 경우 교차 리전 버스를 사용하여 이벤트를 선택한 다른 리전에 전달하는 방법을 고려해 보세요.
1. [AWS 리전 간에 Amazon EventBridge 이벤트 전송 및 수신](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-cross-region.html)
1. Amazon Aurora 데이터베이스의 경우 여러 AWS 리전에 걸친 Aurora 글로벌 데이터베이스를 고려하세요. 기존 클러스터를 수정하여 새로운 리전을 추가할 수도 있습니다.
1. [Amazon Aurora 글로벌 데이터베이스 시작하기](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-getting-started.html)
1. 워크로드에 AWS Key Management Service(AWS KMS) 암호화 키가 포함되어 있는 경우 다중 리전 키가 애플리케이션에 적합한지 고려하세요.
1. [AWS KMS의 다중 리전 키](https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html)
1. 다른 AWS 서비스 기능의 경우 [AWS 서비스로 다중 리전 애플리케이션 생성에 대한 블로그 시리즈를 참고하세요.](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
**구현 계획의 작업 수준: **보통에서 높음
## 리소스
**관련 문서:**
+ [AWS 서비스로 다중 리전 애플리케이션 생성 시리즈](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/)
+ [AWS의 재해 복구(DR) 아키텍처, 파트 IV: 다중 사이트 액티브/액티브](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/)
+ [AWS 글로벌 인프라](https://aws.amazon.com/about-aws/global-infrastructure)
+ [AWS 로컬 영역 FAQ](https://aws.amazon.com/about-aws/global-infrastructure/localzones/faqs/)
+ [AWS의 재해 복구(DR) 아키텍처, 파트 I: 클라우드에서의 복구 전략](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [클라우드마다 다른 재해 복구](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-is-different-in-the-cloud.html)
+ [전역 테이블: DynamoDB를 사용한 다중 리전 복제](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html)
**관련 동영상:**
+ [AWS re:Invent 2018: 다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [Auth0: 자동 장애 조치를 통해 매월 15억 건 이상의 로그인으로 확장할 수 있는 다중 리전 고가용성 아키텍처 사용](https://www.youtube.com/watch?v=vGywoYc_sA8)
**관련 예시:**
+ [AWS의 재해 복구(DR) 아키텍처, 파트 I: 클라우드에서의 복구 전략](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/)
+ [DTCC, 온프레미스에서 수행할 수 있는 수준 이상의 복원력 달성](https://aws.amazon.com/solutions/case-studies/DTCC/)
+ [Expedia Group, 다중 리전 다중 가용 영역 아키텍처를 전용 DNS 서비스와 함께 사용하여 애플리케이션의 복원력 강화](https://aws.amazon.com/solutions/case-studies/expedia/)
+ [Uber: 다중 리전 Kafka용 재해 복구](https://eng.uber.com/kafka/)
+ [Netflix: 다중 리전 복원력을 위한 액티브/액티브 전략 사용](https://netflixtechblog.com/active-active-for-multi-regional-resiliency-c47719f6685b)
+ [Atlassian 클라우드를 위한 데이터 레지던시를 구축하는 방법](https://www.atlassian.com/engineering/how-we-build-data-residency-for-atlassian-cloud)
+ [Intuit TurboTax, 두 개의 리전에서 실행](https://www.youtube.com/watch?v=286XyWx5xdQ)
# REL10-BP03 단일 위치로 제약된 구성 요소의 복구 자동화
워크로드의 구성 요소를 단일 가용 영역 또는 온프레미스 데이터 센터에서만 실행해야 하는 경우 정의된 복구 목표 내에서 워크로드를 완전히 재구축할 수 있는 기능을 구현해야 합니다.
기술적 제약으로 인해 워크로드를 여러 위치에 배포하는 모범 사례를 따를 수 없다면 복원력을 달성할 수 있는 대체 경로를 구현해야 합니다. 이러한 경우를 위해 필요한 인프라를 다시 생성하고, 애플리케이션을 다시 배포하고, 필요한 데이터를 다시 생성하는 기능을 자동화해야 합니다.
예를 들어 Amazon EMR은 지정된 클러스터의 모든 노드를 동일한 가용 영역에서 시작합니다. 동일한 영역에서 클러스터를 실행하면 데이터 접근 속도가 빨라져 작업 흐름의 성능이 개선되기 때문입니다. 워크로드 복원력에 이 구성 요소가 필요한 경우 클러스터와 해당 데이터를 다시 배포할 수 있어야 합니다. 또한 Amazon EMR의 경우 다중 AZ를 사용하는 것 이외의 방법으로 중복성을 프로비저닝해야 합니다. 다음을 프로비저닝할 수 있습니다. [다중 노드](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-ha-launch.html). 그리고 [EMRFS(EMR 파일 시스템)](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-fs.html)를 사용하면 EMR의 데이터를 Amazon S3에 저장한 다음 여러 가용 영역 또는 AWS 리전에 걸쳐 복제할 수 있습니다.
Amazon Redshift와 마찬가지로 클러스터는 기본적으로 사용자가 선택한 AWS 리전 내에서 임의로 선택된 가용 영역에 프로비저닝됩니다. 모든 클러스터 노드는 동일한 영역에 프로비저닝됩니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 자가 복구를 구현합니다. 가능한 경우 자동 크기 조정을 사용하여 인스턴스 또는 컨테이너를 배포합니다. 자동 크기 조정을 사용할 수 없는 경우 EC2 인스턴스에 대한 자동 복구를 사용하거나 Amazon EC2 또는 ECS 컨테이너 수명 주기 이벤트를 기반으로 자가 복구 자동화를 구현합니다.
+ 단일 인스턴스 IP 주소, 프라이빗 IP 주소, 탄력적 IP 주소 및 인스턴스 메타데이터가 필요하지 않은 인스턴스 및 컨테이너 워크로드에 Auto Scaling 그룹을 사용합니다.
+ [EC2 Auto Scaling이란 무엇일까요?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
+ [서비스 자동 크기 조정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ 시작 구성 사용자 데이터를 사용하여 대부분의 워크로드를 자가 복구할 수 있는 자동화를 구현할 수 있습니다.
+ 단일 인스턴스 ID 주소, 프라이빗 IP 주소, 탄력적 IP 주소 및 인스턴스 메타데이터가 필요한 워크로드에 EC2 인스턴스 자동 복구를 사용합니다.
+ [인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ 자동 복구는 인스턴스 장애가 감지될 때 SNS 주제로 복구 상태 알림을 전송합니다.
+ 자동 크기 조정 또는 EC2 복구를 사용할 수 없는 경우 EC2 인스턴스 수명 주기 이벤트 또는 ECS 이벤트를 사용하여 자가 복구를 자동화합니다.
+ [EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [Amazon ECS 이벤트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ 이벤트를 사용하여 필요한 프로세스 로직에 따라 구성 요소를 복구하는 자동화를 호출합니다.
## 리소스
**관련 문서:**
+ [Amazon ECS 이벤트](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html)
+ [EC2 Auto Scaling 수명 주기 후크](https://docs.aws.amazon.com/autoscaling/ec2/userguide/lifecycle-hooks.html)
+ [인스턴스 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [서비스 자동 크기 조정](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)
+ [EC2 Auto Scaling이란 무엇일까요?](https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
# REL10-BP04 격벽 아키텍처를 사용하여 영향 범위 제한
이 패턴은 선박의 격벽처럼 장애를 소수의 요청 또는 클라이언트 하위 집합으로 제한하여 손상된 요청 수를 제한하고 대부분의 요청은 오류 없이 계속될 수 있도록 합니다. 데이터에 대한 격벽은 종종 파티션으로 불리며 서비스에 대한 격벽은 셀이라고 합니다.
그리고 *셀 기반 아키텍처*에서 각 셀은 서비스의 완전한 독립 인스턴스이며 최대 크기가 고정되어 있습니다. 로드가 증가하면 셀을 추가하는 방법으로 워크로드 규모를 늘립니다. 파티션 키는 수신 트래픽에서 요청을 처리할 셀을 결정하는 데 사용됩니다. 모든 장애는 장애가 발생한 단일 셀로 제한되므로 다른 셀은 오류 없이 계속되고 손상된 요청의 수가 제한됩니다. 따라서 셀 간의 상호 작용을 최소화하고 각 요청에서 복잡한 매핑 서비스를 실행할 필요가 없도록 적절한 파티션 키를 식별하는 것이 중요합니다. 복잡한 매핑을 실행해야 하는 서비스에서는 문제가 매핑 서비스로 이전될 뿐이며, 셀 간 상호 작용을 수행해야 하는 서비스에서는 셀 간에 종속 관계가 형성되므로 상호 작용을 통해 개선 가능한 가용성의 수준도 낮아집니다.
![\[셀 기반 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/cell-based-architecture.png)
Colm MacCarthaigh의 AWS 블로그 게시물에 Amazon Route 53에서 [https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation/) 개념을 사용하여 고객 요청을 샤드로 격리하는 방법이 설명되어 있습니다. 이 사례에서 샤드는 2개 이상의 셀로 구성됩니다. 고객(또는 리소스 또는 격리하려는 대상)의 트래픽은 파티션 키에 따라 할당된 샤드로 라우팅됩니다. 샤드당 2개씩 8개의 셀이 있고 샤드 4개에 고객이 나누어져 있는 경우 문제가 발생하면 25%의 고객이 영향을 받게 됩니다.
![\[전통 샤드로 나뉜 서비스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/service-divided-into-traditional-shards.png)
셔플 샤딩을 사용하면 각각 두 개의 셀로 구성된 가상 샤드를 만들고 고객을 이러한 가상 샤드 중 하나에 할당합니다. 문제가 발생하면 전체 서비스의 1/4이 손실될 수 있지만 이 방식의 고객 또는 리소스 할당은 셔플 샤딩의 영향 범위가 25%보다 크게 낮아짐을 의미합니다. 8개의 셀에는 2개 셀로 구성된 28개의 고유한 조합이 있습니다. 즉, 28개의 셔플 샤드(가상 샤드)가 가능합니다. 고객이 수백 또는 수천 명이고 각 고객을 셔플 샤드에 할당하는 경우 문제의 영향 범위는 1/28에 불과합니다. 이는 일반 샤딩보다 7배 더 뛰어난 수치입니다.
![\[셔플 샤드로 나뉜 서비스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/service-divided-into-shuffle-shards.png)
샤드는 셀 외에 서버, 대기열 또는 기타 리소스에도 사용될 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 격벽 아키텍처를 사용합니다. 이 패턴은 선박의 격벽처럼 장애를 소수의 요청 또는 사용자 하위 집합으로 제한하여 손상된 요청 수를 제한하고 대부분의 요청은 오류 없이 계속될 수 있도록 합니다. 데이터에 대한 격벽은 종종 파티션으로 불리며 서비스에 대한 격벽은 셀이라고 합니다.
+ [Well-Architected lab: Fault isolation with shuffle sharding(Well-Architected 실습: 셔플 샤딩으로 장애 격리)](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)
+ [셔플 샤딩: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
+ [AWS re:Invent 2018: AWS가 장애의 영향 범위를 최소화하는 방법(ARC338)](https://youtu.be/swQbA4zub20)
+ 워크로드에 대한 셀 기반 아키텍처를 평가합니다. 셀 기반 아키텍처에서 각 셀은 서비스의 완전한 독립 인스턴스이며 최대 크기가 고정되어 있습니다. 로드가 증가하면 셀을 추가하는 방법으로 워크로드 규모를 늘립니다. 파티션 키는 수신 트래픽에서 요청을 처리할 셀을 결정하는 데 사용됩니다. 모든 장애는 장애가 발생한 단일 셀로 제한되므로 다른 셀은 오류 없이 계속되고 손상된 요청의 수가 제한됩니다. 따라서 셀 간의 상호 작용을 최소화하고 각 요청에서 복잡한 매핑 서비스를 실행할 필요가 없도록 적절한 파티션 키를 식별하는 것이 중요합니다. 복잡한 매핑을 실행해야 하는 서비스에서는 문제가 매핑 서비스로 이전될 뿐이며, 셀 간 상호 작용을 수행해야 하는 서비스에서는 개별 셀의 독립성 수준이 낮아지므로 셀의 자율성이 유지되는 경우 개선 가능한 가용성의 수준도 낮아집니다.
+ Colm MacCarthaigh의 AWS 블로그 게시물에 Amazon Route 53에서 셔플 샤딩 개념을 사용하여 고객 요청을 샤드로 격리하는 방법이 설명되어 있습니다.
+ [Shuffle Sharding: Massive and Magical Fault Isolation(셔플 샤딩: 마법 같은 대규모 장애 격리)](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
## 리소스
**관련 문서:**
+ [Shuffle Sharding: Massive and Magical Fault Isolation(셔플 샤딩: 마법 같은 대규모 장애 격리)](https://aws.amazon.com/blogs/architecture/shuffle-sharding-massive-and-magical-fault-isolation)
+ [Amazon Builders' Library: 셔플 샤딩을 사용한 워크로드 격리](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding/)
**관련 동영상:**
+ [AWS re:Invent 2018: AWS가 장애의 영향 범위를 최소화하는 방법(ARC338)](https://youtu.be/swQbA4zub20)
+ [셔플 샤딩: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=1373)
**관련 예시:**
+ [Well-Architected lab: Fault isolation with shuffle sharding(Well-Architected 실습: 셔플 샤딩으로 장애 격리)](https://wellarchitectedlabs.com/reliability/300_labs/300_fault_isolation_with_shuffle_sharding/)