# 장애 관리
**Topics**
+ [REL 9 데이터는 어떻게 백업합니까?](w2aac19b9c11b5.md)
+ [REL 10 장애 격리를 사용하여 워크로드를 보호하려면 어떻게 해야 합니까?](w2aac19b9c11b7.md)
+ [REL 11 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 합니까?](w2aac19b9c11b9.md)
+ [REL 12 안정성은 어떻게 테스트합니까?](w2aac19b9c11c11.md)
+ [REL 13 DR(재해 복구)를 어떻게 계획합니까?](w2aac19b9c11c13.md)
# REL 9 데이터는 어떻게 백업합니까?
RTO(복구 시간 목표) 및 RPO(복구 시점 목표)에 대한 요구 사항을 충족하도록 데이터, 애플리케이션 및 구성을 백업합니다.
**Topics**
+ [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md)
+ [REL09-BP02 백업 보안 및 암호화](rel_backing_up_data_secured_backups_data.md)
+ [REL09-BP03 자동으로 데이터 백업 수행](rel_backing_up_data_automated_backups_data.md)
+ [REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행](rel_backing_up_data_periodic_recovery_testing_data.md)
# REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현
모든 AWS 데이터 스토어는 백업 기능을 제공합니다. Amazon RDS 및 Amazon DynamoDB 등의 서비스는 추가적으로 시점 복구(PITR)를 활성화하는 자동화된 백업을 지원합니다. 따라서 현재 시간으로부터 최대 5분 전까지 원하는 시점으로 백업을 복원할 수 있습니다. 많은 AWS 서비스는 백업을 다른 AWS 리전으로 복사할 수 있는 기능을 제공합니다. AWS Backup 도구는 AWS 서비스 전체에서 데이터 보호를 중앙 집중화하고 자동화하는 기능을 제공합니다.
Amazon S3는 자체 관리형 및 AWS 관리형 데이터 소스의 백업 목적지로 사용할 수 있습니다. Amazon EBS, Amazon RDS, Amazon DynamoDB 등의 AWS 서비스는 기본적으로 백업을 생성하는 기능이 내장되어 있습니다. 서드 파티 백업 소프트웨어를 사용할 수도 있습니다.
온프레미스 데이터는 AWS 클라우드로 백업될 수 있습니다. 여기에는 [AWS Storage Gateway](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html) 또는 [AWS DataSync](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)를 사용하면 됩니다. Amazon S3 버킷은 AWS에 이 데이터를 저장하는 데 사용할 수 있습니다. Amazon S3는 [Amazon Glacier 또는 S3 Glacier Deep Archive](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/amazon-s3-glacier.html) 등의 여러 스토리지 티어를 제공하여 데이터 스토리지의 비용을 절감해 줍니다.
다른 소스에서 데이터를 재현하여 데이터 복구 요구 사항을 충족할 수 있습니다. 예: [Amazon ElastiCache 복제본 노드](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html) 또는 [RDS 읽기 전용 복제본을](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html) 사용하면 기본 데이터가 손실되었을 때 데이터를 재현할 수 있습니다. 이런 소스를 사용하여 [Recovery Point Objective(RPO) 또는 Recovery Time Objective(RTO)를](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html)충족할 수 있는 경우 백업이 필요하지 않을 수 있습니다. 또 다른 예로, Amazon EMR을 사용하는 경우 HDFS 데이터 스토어를 백업할 필요가 없습니다(S3에서 [EMR로 데이터를 재현할 수 있는 한)](https://aws.amazon.com/premiumsupport/knowledge-center/copy-s3-hdfs-emr/).
백업 전략을 선택할 때는 데이터 복구에 걸리는 시간을 고려하시기 바랍니다. 데이터를 복구하는 데 필요한 시간은 백업의 유형(백업 전략의 경우) 또는 데이터 재현 메커니즘의 복잡성에 따라 달라집니다. 이 시간은 워크로드의 RTO 이내여야 합니다.
**원하는 결과:**
데이터 소스가 식별되고 중요도에 따라 분류됩니다. 그런 다음 RPO에 따라 데이터 복구 전략을 수립합니다. 이 전략에는 데이터 소스 백업 또는 다른 소스에서 데이터를 재현하는 기능이 포함됩니다. 데이터가 손실될 경우 구현된 전략에 따라 정의된 RPO 또는 RTO 내에 복구 또는 데이터 재현이 가능합니다.
**클라우드 성숙도 단계:** Foundational
**일반적인 안티 패턴:**
+ 워크로드의 모든 데이터 소스와 그 중요도를 알지 못함
+ 중요한 데이터 소스의 백업을 생성하지 않음
+ 중요도를 기준으로 사용하지 않고 일부 데이터 소스의 백업만 생성함
+ RPO가 정의되지 않았거나 백업 주기가 RPO에 부합하지 않음
+ 백업이 필요한지 또는 데이터를 다른 소스에서 재현할 수 있는지 평가하지 않음
**이 모범 사례 수립의 이점:** 백업이 필요한 지점을 파악하고 백업 생성을 위한 메커니즘을 구현하거나 외부 소스에서 데이터를 재현할 수 있는 경우 중단 시 데이터를 복원하고 복구하는 역량이 향상됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
워크로드에 사용되는 AWS 서비스 및 리소스의 백업 기능을 숙지하고 사용합니다. 대부분의 AWS 서비스는 워크로드 데이터를 백업할 수 있는 기능을 제공합니다.
**구현 단계:**
1. **워크로드의 모든 데이터 소스를 파악합니다**. 데이터는 [데이터베이스](https://aws.amazon.com/products/databases/), [볼륨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html), [파일 시스템](https://docs.aws.amazon.com/efs/latest/ug/whatisefs.html), [로깅 시스템](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)및 [객체 스토리지와 같이 다양한 리소스에 저장될 수 있습니다](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html). 애플리케이션이 이 시나리오에서 다루지 않는 검색 기능을 사용하는 경우 **리소스** 섹션에서 **관련 문서를** 참조하여 데이터가 저장되는 다양한 AWS 서비스와 이런 서비스가 제공하는 백업 기능에 관해 알아보세요.
1. **중요도에 따라 데이터 소스를 분류합니다.**. 데이터 세트마다 워크로드의 중요도가 다르므로 복원력에 대한 요구 사항도 달라집니다. 예를 들어, 어떤 데이터는 매우 중요하며 0에 가까운 RPO가 필요하지만 어떤 데이터는 덜 중요하며 더 높은 RPO와 일부 데이터 손실을 용인할 수 있습니다. 마찬가지로, 데이터 세트마다 RTO 요구 사항이 다릅니다.
1. **AWS 또는 서드 파티 서비스를 사용하여 데이터 백업을 생성합니다**. [AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html) 은 AWS에 있는 다양한 데이터 소스의 백업을 생성할 수 있는 관리형 서비스입니다. 이런 서비스의 대부분은 백업을 생성하는 기능이 기본적으로 내장되어 있습니다. AWS Marketplace에도 이런 기능을 제공하는 솔루션이 많이 있습니다. 아래 나열된 **리소스** 에서 다양한 AWS 서비스에서 백업을 생성하는 방법에 관한 정보를 확인할 수 있습니다.
1. **백업되지 않는 데이터의 경우 데이터 재현 메커니즘을 수립합니다**. 여러 가지 이유로 다른 소스에서 재현될 수 있는 데이터는 백업하지 않기로 결정할 수 있습니다. 백업을 저장하는 데는 비용이 들기 때문에 백업을 생성하기보다는 필요할 때 다른 소스에서 데이터를 재현하는 것이 더 저렴한 상황이 있을 수도 있습니다. 또는 백업을 복원하는 작업이 다른 소스에서 데이터를 재현하는 것보다 더 오래 걸려 RTO를 준수할 수 없을 수도 있습니다. 그런 경우에는 장단점을 비교하여 데이터 복구가 필요할 때 다른 소스에서 데이터를 재현하는 방법에 대한 프로세스를 효과적으로 정의하여 수립해야 합니다. 예를 들면, Amazon S3의 데이터를 데이터 웨어하우스(예: Amazon Redshift) 또는 MapReduce 클러스터(예: Amazon EMR)로 로드한 경우 다른 소스에서 데이터를 재현할 수 있습니다. 이러한 분석 결과가 어딘가에 저장되어 있거나 재현될 수만 있다면 데이터 웨어하우스 또는 MapReduce 클러스터의 장애로 인해 데이터 손실이 발생하지 않습니다. 소스에서 복제할 수 있는 다른 예로는 캐시(예: Amazon ElastiCache) 또는 RDS 읽기 전용 복제본이 있습니다.
1. **데이터 백업 주기를 설정합니다**. 데이터 소스의 백업을 생성하는 일은 주기적으로 이루어져야 하며 빈도는 RPO에 따라 다릅니다.
**구현 계획의 작업 수준:** 보통
## 리소스
**관련 모범 사례:**
[REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md)
[REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
**관련 문서:**
+ [AWS Backup이란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS DataSync란 무엇입니까?](https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html)
+ [Volume Gateway란 무엇입니까?](https://docs.aws.amazon.com/storagegateway/latest/vgw/WhatIsStorageGateway.html)
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 스냅샷](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ [Amazon EFS 백업](https://docs.aws.amazon.com/efs/latest/ug/efs-backup-solutions.html)
+ [Amazon FSx for Windows File Server 백업](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/using-backups.html)
+ [ElastiCache for Redis의 백업 및 복원](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/backups.html)
+ [Neptune에서 DB 클러스터 스냅샷 생성](https://docs.aws.amazon.com/neptune/latest/userguide/backup-restore-create-snapshot.html)
+ [DB 스냅샷 생성](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateSnapshot.html)
+ [일정에 따라 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [리전 간 복제](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html) (Amazon S3 사용)
+ [EFS-to-EFS AWS Backup](https://aws.amazon.com/solutions/efs-to-efs-backup-solution/)
+ [Amazon S3로 로그 데이터 내보내기](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [객체 수명 주기 관리](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)
+ [DynamoDB에 대한 온디맨드 백업 및 복원](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/backuprestore_HowItWorks.html)
+ [DynamoDB의 특정 시점으로 복구](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery.html)
+ [Amazon OpenSearch Service 인덱스 스냅샷 작업](https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/es-managedomains-snapshots.html)
**관련 동영상:**
+ [AWS re:Invent 2021 - AWS를 사용한 백업, 재해 복구, 랜섬웨어 예방](https://www.youtube.com/watch?v=Ru4jxh9qazc)
+ [AWS Backup 데모: 계정 간 및 리전 간 백업](https://www.youtube.com/watch?v=dCy7ixko3tE)
+ [AWS re:Invent 2019: AWS Backup 심층 분석, ft. Rackspace 지원)(STG341)](https://youtu.be/av8DpL0uFjc)
**관련 예시:**
+ [Well-Architected 실습: Amazon S3에 대한 양방향 리전 간 복제(CRR) 구현](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
+ [Well-Architected lab: Testing Backup and Restore of Data(Well-Architected 실습: 데이터 백업 및 복원 테스트)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
+ [Well-Architected 실습: 분석 워크로드에 대한 백업 및 장애 복구로 복원](https://wellarchitectedlabs.com/reliability/200_labs/200_backup_restore_failback_analytics/)
+ [Well-Architected 실습: 재해 복구 -백업 및 복원](https://wellarchitectedlabs.com/reliability/disaster-recovery/workshop_1/)
# REL09-BP02 백업 보안 및 암호화
AWS IAM 등의 인증 및 권한 부여를 사용하여 백업에 대한 액세스를 제어하고 감지합니다. 백업의 데이터 무결성이 침해되었을 경우 암호화 기법을 사용하여 예방 및 감지합니다.
Amazon S3는 유휴 데이터 암호화를 위한 다양한 방법을 지원합니다. Amazon S3는 서버 측 암호화를 사용하여 객체를 암호화되지 않은 데이터로 수락한 다음 저장 시 암호화합니다. 클라이언트측 암호화를 사용하면 데이터가 Amazon S3로 전송되기 전에 워크로드 애플리케이션에서 데이터가 암호화됩니다. 어느 방법을 사용하든 AWS Key Management Service(AWS KMS)를 사용하여 데이터 키를 생성 및 저장하거나 사용자가 관리하는 자체 키를 제공할 수 있습니다. AWS KMS를 사용하면 IAM을 사용하여 데이터 키와 해독된 데이터에 접근할 수 있는 사용자와 접근할 수 없는 사용자에 대한 정책을 설정할 수 있습니다.
Amazon RDS의 경우 데이터베이스를 암호화하도록 선택하면 백업도 암호화됩니다. DynamoDB 백업은 항상 암호화됩니다.
**일반적인 안티 패턴:**
+ 백업과 복원 자동화에 대한 액세스 권한을 데이터에 대한 액세스 권한과 동일하게 설정
+ 백업을 암호화하지 않음
**이 모범 사례 수립의 이점:** 백업의 보안을 유지하면 데이터 변조가 방지되며, 데이터 암호화는 데이터가 실수로 노출될 경우 해당 데이터에 대한 액세스를 방지합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 각 데이터 스토어에 암호화를 사용합니다. 소스 데이터가 암호화되면 백업도 암호화됩니다.
+ RDS에서 암호화를 활성화합니다. RDS 인스턴스를 생성할 때 AWS Key Management Service를 사용하여 저장 데이터의 암호화를 구성할 수 있습니다.
+ [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ EBS 볼륨에 대해 암호화를 활성화합니다. 볼륨 생성 시 기본 암호화를 구성하거나 고유한 키를 지정할 수 있습니다.
+ [Amazon EBS 암호화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ 필수 Amazon DynamoDB 암호화를 사용합니다. DynamoDB는 모든 저장 데이터를 암호화합니다. 계정에 저장된 키를 지정하는 AWS에서 소유하는 AWS KMS 키 또는 AWS 관리형 KMS 키를 사용할 수 있습니다.
+ [저장 시 DynamoDB 암호화](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [암호화된 테이블 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ Amazon EFS에 저장된 데이터를 암호화합니다. 파일 시스템을 생성할 때 암호화를 구성합니다.
+ [Encrypting Data and Metadata in EFS(EFS의 데이터 및 메타데이터 암호화)](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ 원본 및 대상 리전에 암호화를 구성합니다. KMS에 저장된 키를 사용하여 Amazon S3에서 저장 데이터 암호화를 구성할 수 있지만 키는 리전별로 다릅니다. 복제를 구성할 때 대상 키를 지정할 수 있습니다.
+ [CRR Additional Configuration: Replicating Objects Created with Server-Side Encryption (SSE) Using Encryption Keys stored in AWS KMS(CRR 추가 구성: AWS KMS에 저장된 암호화 키를 사용하여 서버 측 암호화(SSE)로 생성된 객체 복제)](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ 백업에 액세스할 수 있는 최소 권한을 구현합니다. 보안 모범 사례에 따라 백업, 스냅샷 및 복제본에 대한 액세스를 제한합니다.
+ [보안 원칙: AWS Well-Architected](./wat.pillar.security.en.html)
## 리소스
**관련 문서:**
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Amazon EBS 암호화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)
+ [Amazon S3: 암호화를 사용하여 데이터 보호](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingEncryption.html)
+ [CRR Additional Configuration: Replicating Objects Created with Server-Side Encryption (SSE) Using Encryption Keys stored in AWS KMS(CRR 추가 구성: AWS KMS에 저장된 암호화 키를 사용하여 서버 측 암호화(SSE)로 생성된 객체 복제)](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr-replication-config-for-kms-objects.html)
+ [저장 시 DynamoDB 암호화](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/EncryptionAtRest.html)
+ [Amazon RDS 리소스 암호화](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.Encryption.html)
+ [Encrypting Data and Metadata in EFS(EFS의 데이터 및 메타데이터 암호화)](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)
+ [Encryption for Backups in AWS(AWS의 백업 암호화)](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [암호화된 테이블 관리](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/encryption.tutorial.html)
+ [보안 원칙: AWS Well-Architected](./wat.pillar.security.en.html)
**관련 예시:**
+ [Well-Architected lab: Implementing Bi-Directional Cross-Region Replication (CRR) for Amazon S3(Well-Architected 실습: Amazon S3에 대한 양방향 크로스 리전 복제(CRR) 구현)](https://wellarchitectedlabs.com/reliability/200_labs/200_bidirectional_replication_for_s3/)
# REL09-BP03 자동으로 데이터 백업 수행
Recovery Point Objective(RPO)에 정의된 정기적인 일정 또는 데이터 세트의 변경에 따라 백업이 자동으로 생성되도록 구성합니다. 적은 데이터 손실을 요구하는 중요한 데이터 세트는 자주 자동으로 백업되어야 합니다. 반면 일부 손실은 용인하는 중요도가 상대적으로 낮은 데이터의 경우 더 낮은 빈도로 백업할 수 있습니다.
AWS Backup을 사용하여 다양한 AWS 데이터 소스의 자동화된 데이터 백업을 생성할 수 있습니다. Amazon RDS 인스턴스는 5분마다 거의 지속적으로 백업할 수 있으며 Amazon S3 객체는 15분마다 거의 지속적으로 백업될 수 있으므로 백업 기록에서 특정 시점으로 시점 복구(PITR)가 가능합니다. Amazon EBS 볼륨, Amazon DynamoDB 테이블 또는 Amazon FSx 파일 시스템과 같은 다른 AWS 데이터 소스의 경우 AWS Backup은 최대 빈도 1시간 간격으로 자동화된 백업을 실행할 수 있습니다. 이러한 서비스는 네이티브 백업 기능 또한 제공합니다. 특정 시점 복구가 가능한 자동화된 백업을 제공하는 AWS 서비스에는 [Amazon DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/PointInTimeRecovery_Howitworks.html), [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIT.html)및 [Amazon Keyspaces(Apache Cassandra용)](https://docs.aws.amazon.com/keyspaces/latest/devguide/PointInTimeRecovery.html) 가 있으며, 백업 기록에서 특정 시점으로 복구될 수 있습니다. 다른 AWS 데이터 스토리지 서비스는 대부분 최대 빈도 1시간 간격으로 주기적 백업 일정을 수립하는 기능을 제공합니다.
Amazon RDS 및 Amazon DynamoDB는 특정 시점 복구를 통해 지속적 백업을 지원합니다. Amazon S3 버전 관리는 한 번 활성화화면 자동으로 수행됩니다. [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html) 를 사용하면 Amazon EBS 스냅샷의 생성, 복사, 삭제를 자동화할 수 있습니다. 또한 Amazon EBS 기반 Amazon Machine Image(AMI) 및 기본 Amazon EBS 스냅샷의 생성, 복사, 사용 중단 및 등록 취소도 자동화할 수 있습니다.
AWS Backup은 백업 자동화 및 기록을 중앙 집중식으로 볼 수 있는 완전관리형 정책 기반 백업 솔루션을 제공합니다. AWS Storage Gateway를 사용하여 클라우드뿐 아니라 온프레미스의 여러 AWS 서비스에 걸쳐 데이터 백업을 중앙 집중화하고 자동화합니다.
Amazon S3는 버전 관리에 더해 복제 기능도 제공합니다. 전체 S3 버킷을 같거나 다른 AWS 리전의 다른 버킷에 자동으로 복제할 수 있습니다.
**원하는 결과:**
정해진 주기로 데이터 소스의 백업을 생성하는 자동화된 프로세스
**일반적인 안티 패턴:**
+ 수동으로 백업 수행
+ 백업을 지원하는 리소스를 사용하지만 자동화 대상에 백업을 포함하지 않음
**이 모범 사례 수립의 이점:** 백업을 자동화하면 RPO를 기준으로 주기적으로 백업이 생성되며, 생성되지 않은 경우 알림을 보냅니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
1. **현재 수동으로 백업되는** 데이터 소스를 식별합니다. 이에 대한 가이드는 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md) 페이지를 참조합니다.
1. **워크로드의 RPO를** 결정합니다. 이에 대한 가이드는 [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md) 페이지를 참조합니다.
1. **자동화된 백업 솔루션 또는 관리형 서비스를 사용합니다**. AWS Backup은 클라우드 및 온프레미스에서 [AWS 서비스 전체의 데이터 보호를 중앙 집중화하고 자동화할 수 있는 완전관리형 서비스입니다](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup.html#creating-automatic-backups). 백업 계획은 백업할 리소스와 백업이 생성되어야 하는 빈도를 정의하는 규칙을 생성할 수 있는 AWS Backup의 기능입니다. 이 빈도는 2단계에서 설정한 RPO를 기반으로 해야 합니다. [이 WA 실습에서는](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) AWS Backup을 사용하여 자동화된 백업을 생성하는 과정을 직접 체험해 보도록 가이드를 제공합니다. 데이터를 저장하는 AWS 서비스에서는 대부분 기본적으로 백업 기능을 제공합니다. 예를 들어, RDS를 사용하여 시점 복구(PITR) 기능이 있는 자동화된 백업을 생성할 수 있습니다.
1. **온프레미스 데이터 소스 또는 메시지 대기열과 같이** 자동화된 백업 솔루션 또는 관리형 서비스에서 지원되지 않는 데이터 소스의 경우 신뢰할 수 있는 서드 파티 솔루션을 사용하여 자동화된 백업을 생성하는 것을 고려하세요. 아니면 AWS CLI 또는 SDK를 사용하여 백업 생성을 위한 자동화를 생성할 수 있습니다. AWS Lambda 함수 또는 AWS Step Functions를 사용하여 데이터 백업 생성의 로직을 정의하고 Amazon EventBridge를 사용하여 RPO(2단계에서 설정함)를 기반으로 정해진 빈도에 실행합니다.
**구현 계획의 작업 수준:** 낮음
## 리소스
**관련 문서:**
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [일정에 따라 트리거되는 EventBridge 규칙 생성](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [AWS Backup이란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
**관련 동영상:**
+ [AWS re:Invent 2019: AWS Backup 심층 분석, ft. Rackspace 지원)(STG341)](https://youtu.be/av8DpL0uFjc)
**관련 예시:**
+ [Well-Architected lab: Testing Backup and Restore of Data(Well-Architected 실습: 데이터 백업 및 복원 테스트)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행
복구 테스트를 수행하여 백업 프로세스 구현이 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)를 충족하는지 검증합니다.
AWS를 사용하면 테스트 환경을 구축하고 백업을 복원하여 RTO 및 RPO 기능을 평가하고 데이터 콘텐츠와 무결성에 대한 테스트를 실행할 수 있습니다.
또한 Amazon RDS와 Amazon DynamoDB는 PITR(특정 시점 복구)을 지원합니다. 연속 백업을 사용하면 데이터 세트를 지정된 날짜 및 시간의 상태로 복원할 수 있습니다.
**원하는 결과:** 효과적으로 정의된 메커니즘을 사용하여 백업의 데이터가 주기적으로 복구되어 워크로드에 정해진 Recovery Time Objective(RTO) 내에 복구가 가능하도록 합니다. 원본 데이터가 손상되거나 액세스가 불가능하지 않고 Recovery Point Objective(RPO)에서 허용되는 데이터 손실만 이루어진 채로 백업이 원본 데이터가 포함된 리소스로 복원되는지 확인합니다.
**일반적인 안티 패턴:**
+ 백업을 복원하지만 복원이 사용 가능한 상태인지 확인하기 위해 데이터를 쿼리하거나 검색하지 않음
+ 백업이 존재한다고 가정함
+ 시스템의 백업이 완전히 작동하며 시스템에서 데이터를 복구할 수 있다고 가정함
+ 복원 시점 또는 백업에서의 데이터 복구가 워크로드의 RTO 이내에 이루어진다고 가정함
+ 백업에 포함된 데이터가 워크로드의 RPO에 부합한다고 가정함
+ 런북을 사용하지 않거나 정해진 자동화된 절차를 벗어나 필요에 따라 복원함
**이 모범 사례 수립의 이점:** 백업의 복구를 테스트하면 데이터가 손실되거나 손상되는 것을 걱정하지 않고 필요할 때 데이터를 복원할 수 있으며, 복원 및 복구가 워크로드의 RTO 내에 이루어지도록 하며, 데이터 손실이 있는 경우 워크로드의 RPO에 부합하도록 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
백업 및 복원 기능을 테스트하면 중단 시 백업 및 복원 수행의 역량에 대한 신뢰도를 높일 수 있습니다. 주기적으로 백업을 새로운 위치에 복원하고 테스트를 실행하여 데이터의 무결성을 확인합니다. 수행해야 하는 일반적인 테스트로는
모든 데이터를 사용 가능한지, 데이터가 손상되지 않았는지, 모든 데이터에 액세스할 수 있는지, 데이터 손실이 있는 경우 워크로드의 RPO에 부합하는지 확인하는 작업이 있습니다. 이러한 테스트는 복구 메커니즘의 속도가 워크로드의 RTO에 부합할 만큼 빠른지 확인하는 데도 도움이 됩니다.
1. **데이터 소스 식별.** 현재 백업되는 데이터 소스를 식별하고 이 백업이 어디에 저장되는지 파악합니다. 구현 가이드는 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md) 항목을 참조하십시오.
1. **데이터 검증을 위한 기준 수립.** 각 데이터 소스의 데이터 검증을 위한 기준을 수립합니다. 데이터 유형마다 속성이 다르며 서로 다른 검증 메커니즘이 필요할 수 있습니다. 확신을 갖고 프로덕션에 사용하기 전에 이 데이터가 어떻게 검증될 수 있는지 고려하십시오. 데이터를 검증하는 일반적인 방법으로는 데이터 유형, 형식, 체크섬, 크기 등의 데이터 및 백업 속성을 사용하고 이러한 속성과 사용자 지정 검증 로직을 결합하는 것입니다. 예를 들어, 복원된 리소스와 백업이 생성된 당시의 데이터 소스의 체크섬 값을 비교해 볼 수 있습니다.
1. **RTO 및 RPO 설정.** 데이터 중요도에 따라 데이터 복구에 대한 RTO와 RPO를 설정합니다. 구현 가이드는 [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md) 항목을 참조하십시오.
1. **복구 기능 평가**. 백업 및 복원 전략을 검토하여 RTO 및 RPO를 충족하는지 파악하고 필요에 따라 전략을 조정합니다. 그리고 [AWS Resilience Hub를 사용하면](https://docs.aws.amazon.com/resilience-hub/latest/userguide/create-policy.html)워크로드의 평가를 실행할 수 있습니다. 이 평가를 통해 애플리케이션 구성을 복원력 정책과 비교하고 RTO 및 RPO 목표가 충족될 수 있는지 보고합니다.
1. **테스트 복원 수행.** 데이터 복원을 위해 프로덕션에서 사용되는 현재 설정된 프로세스를 사용하여 테스트 복원을 수행합니다. 이 프로세스는 원본 데이터 소스가 백업되는 방법, 백업 자체의 형식 및 스토리지 위치 또는 다른 소스에서의 데이터 재현 여부에 따라 달라집니다. 예를 들어, [AWS Backup과 같은 관리형 서비스를 사용하는 경우 이 프로세스는 새로운 리소스에 백업을 복원하는 것처럼 단순합니다](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html). AWS Elastic Disaster Recovery를 사용하는 경우 [복구 드릴을 시작할 수 있습니다](https://docs.aws.amazon.com/drs/latest/userguide/failback-preparing.html).
1. **데이터 복구 검증.** 2단계에서 데이터 검증을 위해 설정한 기준에 따라 이전 단계에서 복원된 리소스로 데이터 복구를 검증합니다. 복원되고 복구된 데이터에 백업 시 가장 최신 레코드/항목이 포함되어 있습니까? 이 데이터가 워크로드의 RPO에 부합합니까?
1. **필요한 시간 측정.** 복원 및 복구에 필요한 시간을 측정하고 이 시간을 3단계에서 설정한 RTO와 비교합니다. 프로세스가 워크로드의 RTO에 부합합니까? 예를 들어, 복원 프로세스가 시작됐을 때의 타임스탬프와 복구 검증이 완료됐을 때의 타임스탬프를 비교하여 프로세스에 걸린 시간을 계산합니다. 모든 AWS API 호출에는 타임스탬프가 찍히며 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)에서 확인할 수 있습니다. 이 정보가 복원 프로세스가 시작된 시간에 대한 세부 정보를 제공하지만 검증이 완료된 종료 타임스탬프는 검증 로직에서 기록되어야 합니다. 자동화된 프로세스를 사용하는 경우 [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) 등의 서비스를 사용하여 이 정보를 저장할 수 있습니다. 또한 많은 AWS 서비스에서 특정 작업이 발생한 시점의 타임스탬프가 기록된 정보가 표시되는 이벤트 기록을 제공합니다. AWS Backup 내에서 백업 및 복원 작업을 *작업(Job)*이라고 하며, 이 작업에는 메타데이터에 타임스탬프 정보가 포함되어 있어 복원 및 복구에 필요한 시간을 측정하는 데 사용할 수 있습니다.
1. **이해 관계자에게 알림.** 데이터 검증이 실패하거나 복원 및 복구에 필요한 시간이 워크로드에 정해진 RTO를 초과하는 경우 이해 관계자에게 알립니다. 이를 위한 자동화를 구현할 때 [예를 들면 이 실습에서](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)Amazon Simple Notification Service(Amazon SNS) 등의 서비스를 사용하여 이메일 또는 SMS로 이해 관계자에게 푸시 알림을 보낼 수 있습니다. [이 메시지를 Amazon Chime, Slack, Microsoft Teams와 같은 메시징 애플리케이션에 게시하거나](https://aws.amazon.com/premiumsupport/knowledge-center/sns-lambda-webhooks-chime-slack-teams/) 이 메시지를 사용하여 [AWS Systems Manager OpsCenter를 통해 OpsItems로 태스크를 생성할 수도 있습니다](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-creating-OpsItems.html).
1. **주기적으로 실행되도록 프로세스 자동화**. 예를 들어, AWS Lambda 또는 AWS Step Functions의 State Machine과 같은 서비스를 사용하면 복원 및 복구 프로세스를 자동화할 수 있으며, Amazon EventBridge를 사용하여 아래 아키텍처 다이어그램에서 보이는 것처럼 이 자동 워크플로를 주기적으로 트리거할 수 있습니다. 자세한 방법은 [Automate data recovery validation with AWS Backup(AWS Backup으로 데이터 복구 검증 자동화)](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)을 참조하십시오. 또한 [이 Well-Architected 실습](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/) 에서는 여기에 나온 단계 중 여러 개를 자동화하는 방법에 대한 실습을 제공합니다.
![\[자동화된 백업 및 복원 프로세스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/automated-backup-restore-process.png)
**구현 계획의 작업 수준:** 검증 기준의 복잡성에 따라 보통에서 높음
## 리소스
**관련 문서:**
+ [Automate data recovery validation with AWS Backup(AWS Backup으로 데이터 복구 검증 자동화)](https://aws.amazon.com/blogs/storage/automate-data-recovery-validation-with-aws-backup/)
+ [APN 파트너: 백업을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Backup)
+ [AWS Marketplace: 백업에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Backup)
+ [Creating an EventBridge Rule That Triggers on a Schedule(일정에 따라 트리거되는 EventBridge 규칙 생성)](https://docs.aws.amazon.com/eventbridge/latest/userguide/create-eventbridge-scheduled-rule.html)
+ [DynamoDB에 대한 온디맨드 백업 및 복원](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/BackupRestore.html)
+ [AWS Backup란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Elastic Disaster Recovery란 무엇입니까?](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
**관련 예시:**
+ [Well-Architected lab: Testing Backup and Restore of Data(Well-Architected 실습: 데이터 백업 및 복원 테스트)](https://wellarchitectedlabs.com/reliability/200_labs/200_testing_backup_and_restore_of_data/)
# 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/)
# REL 11 구성 요소 장애를 견디도록 워크로드를 설계하려면 어떻게 해야 합니까?
고가용성 및 낮은 MTTR(평균 복구 시간)이 요구되는 워크로드는 복원력을 고려하여 설계해야 합니다.
**Topics**
+ [REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 정상 리소스로 장애 조치](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 모든 계층에서 복구 자동화](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 워크로드의 모든 구성 요소를 모니터링하여 장애 감지
워크로드 상태를 지속적으로 모니터링하여 성능 저하 또는 장애가 발생하는 즉시 수동 및 자동화된 시스템을 통해 이를 인식할 수 있도록 합니다. 비즈니스 가치를 기반으로 KPI(핵심 성능 지표)를 모니터링합니다.
모든 복구 메커니즘은 문제를 신속하게 탐지하는 기능에서 시작되어야 합니다. 기술적 장애를 먼저 감지하여 해결합니다. 그러나 가용성은 비즈니스 가치를 제공하는 워크로드의 기능에 따라 결정되므로 이 요구 사항을 측정하는 핵심 성과 지표(KPI)를 탐지 및 수정 전략의 핵심 척도로 사용해야 합니다.
**일반적인 안티 패턴:**
+ 경보가 구성되지 않았기 때문에 알림 없이 중단이 발생합니다.
+ 경보가 존재하지만 대응 시간이 충분하지 않은 임계치에 있습니다.
+ 지표는 RTO(복구 시간 목표)를 충족하기에 충분한 지표가 수집되지 않는 경우가 많습니다.
+ 워크로드의 고객용 계층만 능동적으로 모니터링됩니다.
+ 기술 지표만 수집하며 비즈니스 기능 지표는 수집하지 않습니다.
+ 워크로드의 사용자 경험을 측정하는 지표가 없습니다.
**이 모범 사례 수립의 이점:** 모든 계층에서 적절한 모니터링을 사용하면 감지 시간을 단축하여 복구 시간을 줄일 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 복구 목표에 따라 구성 요소의 수집 간격을 결정합니다.
+ 모니터링 간격은 필요한 복구 속도에 따라 달라집니다. 복구 시간은 복구에 걸리는 시간에 따라 결정되므로 이 시간과 RTO(복구 시간 목표)를 고려하여 수집 빈도를 결정해야 합니다.
+ 구성 요소에 대한 세부 모니터링을 구성합니다.
+ EC2 인스턴스 및 Auto Scaling에 대한 세부 모니터링이 필요한지 결정합니다. 세부 모니터링은 1분 간격 지표를 제공하며 기본 모니터링은 5분 간격 지표를 제공합니다.
+ [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Amazon CloudWatch를 사용하여 오토 스케일링 및 인스턴스 모니터링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ RDS에 대한 향상된 모니터링이 필요한지 결정합니다. 향상된 모니터링은 RDS 인스턴스의 에이전트를 사용하여 RDS 인스턴스의 여러 프로세스 또는 스레드에 대한 유용한 정보를 가져옵니다.
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ 비즈니스 핵심 성과 지표(KPI)를 측정하는 사용자 지정 지표를 생성합니다. 워크로드는 주요 비즈니스 기능을 구현합니다. 이러한 기능은 간접 문제가 발생하는 시기를 식별하는 데 도움이 되는 KPI로 사용되어야 합니다.
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ 사용자 canary를 사용하여 사용자 경험의 장애를 모니터링합니다. 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트(‘Canary 테스트’라고도 하지만 카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다.
+ [Amazon CloudWatch Synthetics로 사용자 Canary 생성 지원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ 사용자 경험을 추적하는 사용자 지정 지표를 생성합니다. 고객의 경험을 계측할 수 있으면 소비자 경험이 저하되는 시기를 결정할 수 있습니다.
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ 워크로드의 일부가 제대로 작동하지 않는 시기를 감지하고 리소스의 크기를 자동 조정해야 하는 시점을 알려주는 경보를 설정합니다. 경보를 사용하면 대시보드에 경보를 시각적으로 표시하고, Amazon SNS 또는 이메일을 통해 알림을 전송하며, Auto Scaling을 통해 워크로드의 리소스를 스케일 업 또는 다운할 수 있습니다.
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ 지표를 시각화하는 대시보드를 생성합니다. 대시보드를 사용하면 추세, 이상값 및 기타 잠재적 문제의 지표를 시각적으로 표시하거나, 조사가 필요할 수 있는 문제를 표시할 수 있습니다.
+ [CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## 리소스
**관련 문서:**
+ [Amazon CloudWatch Synthetics로 사용자 Canary 생성 지원](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [인스턴스에 대한 세부 모니터링 활성화 또는 비활성화](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Enhanced Monitoring](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Amazon CloudWatch를 사용하여 오토 스케일링 및 인스턴스 모니터링](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [사용자 지정 지표 게시](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [CloudWatch 대시보드 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 정상 리소스로 장애 조치
리소스 장애가 발생할 경우 정상 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다.
Elastic Load Balancing, AWS Auto Scaling 등의 AWS 서비스는 리소스와 가용 영역에 걸쳐 로드를 분산하도록 도와줍니다. 따라서 남아 있는 상태가 양호한 리소스로 트래픽을 이동시켜 개별 리소스(예: EC2 인스턴스)의 장애 또는 가용 영역의 장애를 완화할 수 있습니다. 다중 리전 워크로드의 경우 이 작업이 더 복잡합니다. 예를 들어 리전 간 읽기 전용 복제본을 사용하여 데이터를 여러 AWS 리전에 배포할 수 있지만, 장애 조치가 발생할 경우 읽기 전용 복제본을 기본으로 승격하고 트래픽을 해당 위치로 지정해야 합니다. Amazon Route 53 및 AWS Global Accelerator는 AWS 리전 전체에 트래픽을 라우팅하도록 도와줍니다.
워크로드에서 Amazon S3 또는 Amazon DynamoDB와 같은 AWS 서비스를 사용하는 경우 이러한 서비스는 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생하면 AWS 컨트롤 플레인이 자동으로 정상적인 위치로 트래픽을 라우팅합니다. 데이터가 여러 가용 영역에 중복으로 저장되고 가용성이 유지됩니다. Amazon RDS의 경우 구성 옵션으로 다중 AZ를 선택해야 합니다. 그러면 장애 시 AWS가 자동으로 트래픽을 정상 인스턴스로 보냅니다. Amazon EC2 인스턴스, Amazon ECS 태스크 또는 Amazon EKS 포드의 경우에는 배포할 가용 영역을 선택합니다. 그러면 Elastic Load Balancing이 비정상 영역에서 인스턴스를 감지하고 정상적인 영역으로 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하는 경우 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수도 있습니다.
다중 리전 접근 방식(온프레미스 데이터 센터도 포함될 수 있음)의 경우 Amazon Route 53를 사용하여 인터넷 도메인을 정의하고, 트래픽이 정상적인 리전으로 라우팅되도록 상태 확인을 포함하는 라우팅 정책을 할당할 수 있습니다. 또는 AWS Global Accelerator가 제공하는 정적 IP 주소를 애플리케이션의 고정된 진입점으로 사용하고 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전의 엔드포인트로 라우팅하여 성능과 신뢰성을 개선할 수 있습니다.
AWS에서는 장애 복구를 고려한 서비스 설계 방식이 사용됩니다. 즉, 장애에서 복구하는 시간과 데이터에 대한 영향을 최소화하는 방식으로 서비스가 설계됩니다. AWS 서비스는 기본적으로 한 리전 내의 여러 복제본에 저장된 요청만 승인하는 데이터 스토어를 사용합니다. 이러한 서비스와 리소스에는 Amazon Aurora, Amazon Relational Database Service(Amazon RDS) Multi-AZ DB 인스턴스, Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service(Amazon SQS), Amazon Elastic File System(Amazon EFS) 등이 있습니다. 이러한 서비스/리소스는 셀 기반 격리와 가용 영역에서 제공되는 장애 격리 기능을 사용하도록 구성됩니다. AWS의 운영 절차에서는 자동화가 광범위하게 사용됩니다. 또한 서비스 중단 시 빠르게 복구할 수 있도록 교체 및 다시 시작 기능도 최적화됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 정상 리소스로 장애 조치합니다. 리소스 장애가 발생할 경우 정상 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다. 위치 장애(예: 가용 영역 또는 AWS 리전)의 경우, 손상되지 않은 위치의 정상 리소스로 장애 조치할 수 있는 시스템을 갖추고 있어야 합니다.
+ 워크로드에서 Amazon S3 또는 Amazon DynamoDB와 같은 AWS 서비스를 사용하는 경우 이러한 서비스는 여러 가용 영역에 자동으로 배포됩니다. 장애가 발생하면 AWS 컨트롤 플레인이 자동으로 정상적인 위치로 트래픽을 라우팅합니다.
+ Amazon RDS의 경우 구성 옵션으로 다중 AZ를 선택해야 합니다. 그러면 장애 시 AWS가 자동으로 트래픽을 정상 인스턴스로 보냅니다.
+ [Amazon RDS를 위한 고가용성(다중 AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Amazon EC2 인스턴스 또는 Amazon ECS 태스크의 경우에는 배포할 가용 영역을 선택합니다. 그러면 Elastic Load Balancing이 비정상 영역에서 인스턴스를 감지하고 정상적인 영역으로 트래픽을 라우팅합니다. Elastic Load Balancing을 사용하는 경우 온프레미스 데이터 센터의 구성 요소로 트래픽을 라우팅할 수도 있습니다.
+ 다중 리전 접근 방식(온프레미스 데이터 센터도 포함될 수 있음)의 경우 정상적인 위치의 데이터와 리소스가 계속해서 요청을 처리할 수 있는지 확인합니다.
+ 예를 들어 리전 간 읽기 전용 복제본을 사용하여 데이터를 여러 AWS 리전에 배포할 수 있지만, 기본 위치에 장애가 발생할 경우 읽기 전용 복제본을 마스터로 승격하고 트래픽을 해당 위치로 지정해야 합니다.
+ [Amazon RDS 읽기 전용 복제본 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53를 사용하여 인터넷 도메인을 정의하고 트래픽이 정상적인 리전으로 라우팅되도록 상태를 확인하는 등 라우팅 정책을 할당할 수 있습니다. 또는 AWS Global Accelerator가 제공하는 정적 IP 주소를 애플리케이션의 고정된 진입점으로 사용하고 퍼블릭 인터넷 대신 AWS 글로벌 네트워크를 사용하여 선택한 AWS 리전의 엔드포인트로 라우팅하여 성능과 신뢰성을 개선할 수 있습니다.
+ [Amazon Route 53: 라우팅 정책 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: 라우팅 정책 선택](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Amazon RDS를 위한 고가용성(다중 AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Amazon RDS 읽기 전용 복제본 개요](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Amazon ECS 태스크 배치 전략](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones(여러 가용 영역에 Kubernetes Auto Scaling 그룹 생성)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [AWS Global Accelerator란 무엇입니까?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 모든 계층에서 복구 자동화
장애가 감지되면 자동화된 기능을 사용하여 수정 작업을 수행합니다.
*재시작 기능* 은 장애를 해결하는 데 사용할 수 있는 중요한 도구입니다. 분산 시스템에서 모범 사례는 앞서 설명한 것처럼 가능한 경우 서비스를 상태 비저장으로 만드는 것입니다. 이렇게 하면 재시작 시 데이터 손실 또는 가용성이 손실되는 것을 방지할 수 있습니다. 클라우드에서는 재시작의 일부로 전체 리소스(예: EC2 인스턴스 또는 Lambda 함수)를 대체할 수 있으며 이러한 대체는 일반적으로 필수적입니다. 재시작은 그 자체로 장애를 복구할 수 있는 단순하면서도 안정적인 방법입니다. 워크로드에는 다양한 유형의 장애가 발생합니다. 장애는 하드웨어, 소프트웨어, 통신 및 작업 과정에서 발생할 수 있습니다. 서로 다른 유형의 장애를 각각 격리, 식별 및 수정하는 새로운 메커니즘을 구성하는 대신 여러 범주의 장애를 동일한 복구 전략에 매핑하는 것이 좋습니다. 인스턴스는 하드웨어 결함, 운영 체제 버그, 메모리 누수 또는 기타 원인으로 인해 장애를 경험할 수 있습니다. 이러한 장애가 발생할 경우 각 상황에 맞춰진 수정 조치를 구축하는 대신 인스턴스 장애로 처리하십시오. 인스턴스를 종료하고 AWS Auto Scaling을 통해 인스턴스를 교체합니다. 나중에 환경 외부에서 장애 발생 리소스 분석을 수행할 수 있습니다.
또 다른 예는 네트워크 요청을 다시 시작하는 기능입니다. 네트워크 시간 제한 장애와 종속성 장애(종속성이 오류를 반환함)에 대해 같은 복구 방식이 적용됩니다. 두 이벤트는 모두 시스템에 비슷한 영향을 주므로, 한 이벤트를 “특수 사례”로 처리하는 대신 지수 백오프 및 지터를 통해 제한적으로 재시도하는 비슷한 전략이 적용됩니다.
*재시작 기능* 은 복구 중심 컴퓨팅 및 고가용성 클러스터 아키텍처에 포함된 복구 메커니즘입니다.
Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda, AWS Systems Manager Automation 또는 다른 대상을 트리거하여 워크로드에 대한 맞춤형 수정 로직을 실행할 수 있습니다.
EC2 인스턴스 상태를 확인하도록 Amazon EC2 Auto Scaling을 구성할 수 있습니다. 인스턴스가 실행 중 이외의 상태이거나 시스템 상태가 손상된 경우 Amazon EC2 Auto Scaling은 해당 인스턴스를 비정상으로 간주하고 대체 인스턴스를 시작합니다. AWS OpsWorks를 사용하는 경우 OpsWorks 계층 수준에서 EC2 인스턴스의 자동 복구 기능을 구성할 수 있습니다.
대규모 교체(예: 전체 가용 영역이 손실됨)의 경우 한 번에 여러 개의 새 리소스를 확보하는 대신 정적 안정성을 통해 고가용성을 유지하는 것이 좋습니다.
**일반적인 안티 패턴:**
+ 인스턴스 또는 컨테이너에 개별적으로 애플리케이션 배포.
+ 자동 복구를 사용하지 않고 여러 위치에 배포할 수 없는 애플리케이션을 배포.
+ 자동 크기 조정 및 자동 복구로 복구하지 못한 애플리케이션을 수동으로 복구.
**이 모범 사례 수립의 이점:** 자동 복구는 워크로드를 한 번에 한 위치에만 배포할 수 있는 경우에도 평균 복구 시간을 단축하고 워크로드의 가용성을 보장합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ Auto Scaling 그룹을 사용하여 워크로드에 계층을 배포합니다. Auto Scaling은 무상태 애플리케이션에서 자가 복구를 수행하고 용량을 추가 및 제거할 수 있습니다.
+ [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ 여러 위치에 배포할 수 없고 장애 발생 시 재부팅이 허용되는 애플리케이션이 배포되어 있는 EC2 인스턴스에 자동 복구를 구현합니다. 애플리케이션을 여러 위치에 배포할 수 없는 경우 자동 복구를 사용하여 장애가 발생한 하드웨어를 교체하고 인스턴스를 다시 시작할 수 있습니다. 인스턴스 메타데이터 및 관련 IP 주소는 물론 Amazon EBS 볼륨과 Elastic File System 및 Lustre/Windows용 파일 시스템의 탑재 지점도 유지됩니다.
+ [Amazon EC2 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Amazon FSx for Lustre란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Amazon FSx for Windows File Server란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ AWS OpsWorks를 사용하는 경우 계층 수준에서 EC2 인스턴스의 자동 복구 기능을 구성할 수 있습니다.
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ 자동 크기 조정 또는 자동 복구를 사용할 수 없거나 자동 복구가 실패할 경우 AWS Step Functions 및 AWS Lambda를 사용하여 자동 복구를 구현합니다. 자동 크기 조정을 사용할 수 없고, 자동 복구를 사용할 수 없거나 자동 복구가 실패하는 경우 AWS Step Functions 및 AWS Lambda를 사용하여 복구를 자동화할 수 있습니다.
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge를 사용하면 CloudWatch 경보 또는 다른 AWS 서비스의 상태 변경과 같은 이벤트를 모니터링하고 필터링할 수 있습니다. 그런 다음 이벤트 정보를 기반으로 AWS Lambda(또는 다른 대상)를 트리거하여 워크로드에 대한 사용자 지정 수정 로직을 실행할 수 있습니다.
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances(AWS OpsWorks: 자동 복구를 사용하여 실패한 인스턴스 대체)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon EC2 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store(Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System(Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [AWS Auto Scaling 작동 방식](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Step Functions란 무엇입니까?](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Amazon FSx for Lustre란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [Amazon FSx for Windows File Server란 무엇입니까?](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**관련 동영상:**
+ [AWS의 정적 안정성: AWS re:Invent 2019: Introducing The Amazon Builders’ Library(Amazon Builders’ Library 소개)(DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**관련 예시:**
+ [Well-Architected lab: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability(Well-Architected 실습: 레벨 300: 상태 확인 구현 및 종속성 관리를 통한 안정성 개선)](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용
제어 영역은 리소스를 구성하는 데 사용되며, 데이터 영역은 서비스 제공에 사용됩니다. 일반적으로 데이터 영역은 제어 영역보다 가용성 설계 목표가 더 높으며, 일반적으로 덜 복잡합니다. 복원력에 영향을 미칠 가능성이 있는 이벤트에 대해 복구 또는 완화 대응을 구현할 때 제어 영역 작업을 사용하면 아키텍처의 전반적인 복원력이 감소될 수 있습니다. 예를 들어, Amazon Route 53 데이터 영역을 사용하면 상태 확인을 기반으로 DNS 쿼리를 안정적으로 라우팅할 수 있지만, Route 53 라우팅 정책을 업데이트할 때 컨트롤 플레인을 사용하므로 복구에 사용할 수 없습니다.
Route 53 데이터 영역은 DNS 쿼리에 응답하고 상태 확인을 수행 및 평가합니다. Route 53 데이터 영역은 전역에 배포되며 [100% 가용성 서비스 수준에 관한 계약(SLA)을 위해 설계됩니다.](https://aws.amazon.com/route53/sla/) Route 53 리소스를 생성, 업데이트, 삭제하는 데 사용하는 Route 53 관리 API 및 콘솔은 DNS를 관리할 때 필요한 강력한 일관성과 내구성을 우선시하도록 설계된 컨트롤 플레인에서 실행됩니다. 이를 위해 컨트롤 플레인은 하나의 리전(US East (N. Virginia))에 위치합니다. 두 시스템 모두 안정성이 높게 구축되었지만 컨트롤 플레인은 SLA에 포함되지 않습니다. 데이터 영역의 복원력 높은 설계가 컨트롤 플레인과 달리 가용성을 유지하는 상황이 드물게 있을 수 있습니다. 재해 복구 및 장애 조치 메커니즘에는 데이터 영역 기능을 사용하여 가능한 한 최고 수준의 신뢰성을 제공하십시오.
데이터 영역, 컨트롤 플레인, 고가용성 목표를 충족하기 위해 AWS에서 서비스를 구축하는 방법에 관한 자세한 내용은 [가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) 문서와 [Amazon Builders' Library를 참조하십시오.](https://aws.amazon.com/builders-library/)
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 재해 복구에 Amazon Route 53를 사용할 때 컨트롤 플레인이 아닌 데이터 영역을 사용합니다. Route 53 Application Recovery Controller를 사용하면 준비 상태 확인 및 라우팅 제어를 통해 장애 조치를 관리하고 조정할 수 있습니다. 이러한 기능은 애플리케이션의 장애 복구 성능을 지속적으로 모니터링하며, 이를 통해 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있습니다.
+ [What is Route 53 Application Recovery Controller?(Amazon Route 53 Application Recovery Controller란 무엇입니까?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53(Amazon Route 53를 사용하여 재해 복구 메커니즘 생성)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 1: 단일 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 2: 다중 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ 데이터 영역을 사용할 작업과 컨트롤 플레인을 사용할 작업을 파악합니다.
+ [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control(소규모 서비스 제어를 통한 분산 시스템 오버로드 방지)](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API(컨트롤 플레인 및 데이터 영역)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할)
+ [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할)
## 리소스
**관련 문서:**
+ [APN 파트너: 내결함성 자동화를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [AWS Marketplace: 내결함성에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control(소규모 서비스 제어를 통한 분산 시스템 오버로드 방지)](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [Amazon DynamoDB API(컨트롤 플레인 및 데이터 영역)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda 실행](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (컨트롤 플레인 및 데이터 영역으로 분할)
+ [AWS Elemental MediaStore Data Plane(AWS Elemental MediaStore 데이터 영역)](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 1: 단일 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 2: 다중 리전 스택)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53(Amazon Route 53를 사용하여 재해 복구 메커니즘 생성)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [What is Route 53 Application Recovery Controller?(Amazon Route 53 Application Recovery Controller란 무엇입니까?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**관련 예시:**
+ [Amazon Route 53 Application Recovery Controller 소개](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 정적 안정성을 사용하여 바이모달 동작 방지
바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보이는 것을 말합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다. 그러나 이 방법 대신 정적으로 안정적이며 한 모드에서만 작동하는 워크로드를 구축해야 합니다. 한 AZ가 제거된 경우 제거된 영역의 워크로드 로드를 처리하기에 충분한 인스턴스를 각 가용 영역에 프로비저닝한 다음 Elastic Load Balancing 또는 Amazon Route 53 상태 확인을 사용하여 손상된 인스턴스에서 로드를 이동합니다.
컴퓨팅 배포(예: EC2 인스턴스 또는 컨테이너)에서 정적 안정성은 최고의 안정성을 제공합니다. 정적 안정성은 비용 문제와 비교하여 검토되어야 합니다. 컴퓨팅 파워를 적게 프로비저닝하고 장애 발생 시 새 인스턴스를 시작하는 방법이 비용은 더 저렴합니다. 그러나 대규모 장애(예: 가용 영역 장애)의 경우 이 접근 방식은 장애가 발생하기 전에 대비하는 것이 아니라 장애가 발생할 때 대응하는 방법에 의존하기 때문에 효율성이 떨어집니다. 따라서 워크로드의 안정성 요구 사항과 비용 요구 사항을 비교해야 합니다. 사용하는 가용 영역이 많을수록 정적 안정성을 유지하는 데 필요한 추가 컴퓨팅 용량은 줄어듭니다.
![\[가용 영역에 걸친 EC2 인스턴스의 정적 안정성을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/static-stability.png)
트래픽이 전환된 후에는 AWS Auto Scaling을 사용하여 장애가 발생한 영역의 인스턴스를 비동기식으로 교체하고 정상 영역에서 인스턴스를 시작합니다.
바이모달 동작의 또 다른 예는 시스템이 전체 시스템의 구성 상태를 새로 고치려고 시도할 수 있는 네트워크 시간 제한입니다. 그러면 다른 구성 요소에 예기치 않은 로드가 더해져 해당 구성 요소에 장애가 발생하고 또 다른 예기치 않은 결과가 야기될 수 있습니다. 이 부정적인 피드백 루프는 워크로드의 가용성에 영향을 미칩니다. 대신 정적으로 안정적이며 한 모드에서만 작동하는 시스템을 구축해야 합니다. 일정한 작업을 수행하고 항상 고정된 케이던스에서 구성 상태를 새로 고치는 것이 정적으로 안정된 설계의 하나일 수 있습니다. 호출이 실패하면 워크로드는 이전에 캐시된 값을 사용하고 경보를 트리거합니다.
바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용한 솔루션처럼 보이지만 워크로드의 수요가 크게 변경되고 장애를 초래할 가능성이 높으므로 허용해서는 안 됩니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 정적 안정성을 사용하여 바이모달 동작을 방지합니다. 바이모달 동작은 워크로드가 정상 모드와 장애 모드에서 다른 동작을 보이는 것을 말합니다. 예를 들어 가용 영역에 장애가 발생할 경우 새 인스턴스를 시작하는 방법을 사용할 수 있습니다.
+ [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ 그러나 이 방법 대신 정적으로 안정적이고 한 모드에서만 작동하는 시스템을 구축해야 합니다. 한 가용 영역이 제거된 경우 제거된 영역의 워크로드 로드를 처리하기에 충분한 인스턴스를 각 영역에 프로비저닝한 다음 Elastic Load Balancing 또는 Amazon Route 53 상태 확인을 사용하여 손상된 인스턴스에서 로드를 이동합니다.
+ 바이모달 동작의 또 다른 예로 장애 발생 시 클라이언트에서 워크로드 캐시를 우회하는 것을 허용하는 동작이 있습니다. 이는 클라이언트 요구 사항을 수용하는 솔루션처럼 보이지만 워크로드의 수요가 크게 변경되고 장애를 초래할 가능성이 높으므로 허용해서는 안 됩니다.
## 리소스
**관련 문서:**
+ [Minimizing Dependencies in a Disaster Recovery Plan(재해 복구 계획의 종속성 최소화)](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [Amazon Builders' Library: 가용 영역을 사용한 정적 안정성](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**관련 동영상:**
+ [AWS의 정적 안정성: AWS re:Invent 2019: Amazon Builders’ Library 소개(DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 이벤트가 가용성에 영향을 미치는 경우 알림 전송
중대한 이벤트가 감지되면 이벤트로 인해 야기된 문제가 자동으로 해결된 경우에도 알림이 전송됩니다.
자동 복구를 사용하면 워크로드의 안정성을 유지할 수 있습니다. 그러나 자동 복구로 인해 해결해야 할 근본적인 문제가 가려질 수도 있습니다. 적절한 모니터링 및 이벤트를 구현하면 자동 복구로 해결된 문제를 포함한 문제의 패턴을 감지하여 근본 원인 문제를 해결할 수 있습니다. 장애 발생을 기준으로 Amazon CloudWatch Alarms를 트리거할 수 있으며 자동화된 복구 작업의 실행을 기준으로 트리거할 수도 있습니다. 이메일을 보내거나 Amazon SNS 통합을 사용하여 서드파티 인시던트 추적 시스템에 인시던트를 기록하도록 CloudWatch Alarms를 구성할 수 있습니다.
**일반적인 안티 패턴:**
+ 누구도 조치를 취하지 않는 경보 전송
+ 자동 복구 자동화를 수행하지만 복구가 필요한 것을 알리지 않음.
**이 모범 사례 수립의 이점:** 복구 이벤트에 대한 알림이 전송되면 자주 발생하는 문제가 무시되지 않습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 비즈니스 핵심 성과 지표(KPI)가 낮은 임계값을 초과할 때 이러한 지표에 대한 경보를 전송합니다. 비즈니스 KPI에 대해 낮은 임계값 경보를 설정하면 워크로드를 사용할 수 없거나 작동하지 않는 시기를 파악하는 데 도움이 됩니다.
+ [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ 복구 자동화를 호출하는 이벤트에 대한 경보 SNS API를 직접 호출하여 생성한 자동화를 통해 알림을 보낼 수 있습니다.
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## 리소스
**관련 문서:**
+ [정적 임계값을 기반으로 CloudWatch 경보 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon Simple Notification Service란 무엇입니까?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
# REL 12 안정성은 어떻게 테스트합니까?
프로덕션 환경의 스트레스에 대한 복원력을 가지도록 워크로드를 설계한 후 설계대로 작동하고 예상한 복원력을 제공하는지 확인할 수 있는 유일한 방법은 테스트입니다.
**Topics**
+ [REL12-BP01 플레이북을 사용하여 장애 조사](rel_testing_resiliency_playbook_resiliency.md)
+ [REL12-BP02 인시던트 사후 분석 수행](rel_testing_resiliency_rca_resiliency.md)
+ [REL12-BP03 기능 요구 사항 테스트](rel_testing_resiliency_test_functional.md)
+ [REL12-BP04 확장 및 성능 요구 사항 테스트](rel_testing_resiliency_test_non_functional.md)
+ [REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL12-BP06 정기적으로 게임 데이 진행](rel_testing_resiliency_game_days_resiliency.md)
# REL12-BP01 플레이북을 사용하여 장애 조사
잘 알려지지 않은 장애 시나리오에 일관되고 신속하게 대응할 수 있도록 플레이북에 조사 프로세스를 문서화합니다. 플레이북은 장애 시나리오에 영향을 미치는 요인을 식별하기 위해 수행되는 미리 정의된 단계입니다. 문제가 확인되거나 에스컬레이션될 때까지 각 프로세스 단계의 결과를 사용하여 다음에 수행할 단계를 결정합니다.
플레이북은 사후 대응적 조치를 효과적으로 수행하기 위해 반드시 수행해야 하는 사전 예방적 계획입니다. 플레이북에 포함되지 않은 장애 시나리오가 프로덕션 환경에서 발생할 경우 이 문제를 먼저 해결합니다(화재 진압). 그런 다음 돌아가서 문제를 해결하기 위해 취한 단계를 살펴보고 이를 사용하여 플레이북에 새 항목을 추가합니다.
플레이북은 특정 인시던트에 대응하여 사용되며 런북은 특정 결과를 달성하기 위해 사용됩니다. 런북은 일상적인 활동에 대해 사용되고, 플레이북은 일상적이지 않은 이벤트에 대응하는 데 사용되는 경우가 많습니다.
**일반적인 안티 패턴:**
+ 문제를 진단하거나 인시던트에 대응하는 프로세스를 모른 상태에서 워크로드 배포를 계획합니다.
+ 이벤트를 조사할 때 로그 및 지표를 수집할 시스템에 대한 무계획적 결정
+ 데이터를 검색할 수 있을 만큼 오래 지표 및 이벤트를 유지하지 않음
**이 모범 사례 수립의 이점:** 플레이북을 캡처하면 프로세스를 일관되게 따를 수 있습니다. 플레이북을 코드화하면 수작업으로 인한 오류 발생을 최소화할 수 있습니다. 플레이북을 자동화하면 팀원의 개입 요구 사항을 없애거나 개입을 시작할 때 추가 정보를 제공함으로써 이벤트에 대응하는 시간을 단축할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 플레이북을 사용하여 문제를 파악합니다. 플레이북은 문제 조사를 위한 문서화된 프로세스입니다. 플레이북에 프로세스를 문서화하면 장애 발생 시나리오에 일관되고 빠르게 대응할 수 있습니다. 플레이북은 적절한 기술을 보유한 팀원이 해당하는 정보를 수집하고, 장애의 잠재적 출처를 확인하고, 결함 위치를 구분하고, 발생 요인을 확인(인시던트 사후 분석 수행)하는 데 필요한 정보와 지침을 포함해야 합니다.
+ 코드로 플레이북을 구현합니다. 플레이북을 스크립트로 작성하여 작업을 코드로 수행하면 일관성을 유지하고 수동 프로세스에서 발생하는 오류를 최소화할 수 있습니다. 플레이북은 문제의 발생 요인을 식별하는 데 필요할 수 있는 다양한 단계를 나타내는 여러 스크립트로 구성할 수 있습니다. 플레이북 활동의 일부분으로 런북 활동을 트리거하거나 수행할 수도 있고, 확인된 이벤트 대응 과정에서 플레이북 실행 여부를 묻는 메시지를 표시할 수도 있습니다.
+ [AWS Systems Manager를 사용하여 운영 플레이북 자동화](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## 리소스
**관련 문서:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)
+ [AWS Systems Manager를 사용하여 운영 플레이북 자동화](https://aws.amazon.com/about-aws/whats-new/2019/11/automate-your-operational-playbooks-with-aws-systems-manager/)
+ [Amazon CloudWatch 경보 사용](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Amazon EventBridge란 무엇입니까?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [AWS Lambda란 무엇입니까?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
**관련 예시:**
+ [플레이북 및 런북으로 운영 자동화](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
# REL12-BP02 인시던트 사후 분석 수행
고객에게 영향을 주는 이벤트를 검토하고 발생 요인과 예방 조치 항목을 식별합니다. 이 정보를 사용하여 재발을 제한하거나 방지하는 완화 기능을 개발합니다. 신속하고 효과적인 대응을 위한 절차를 개발합니다. 목표 대상에 맞게 적절히 발생 요인과 수정 조치를 전달합니다. 필요한 경우 다른 관계자들에게 이러한 원인을 전달하는 방법을 마련합니다.
기존 테스트에서 문제가 발견되지 않은 이유를 평가합니다. 테스트가 아직 없는 경우 이 사례에 대한 테스트를 추가합니다.
**일반적인 안티 패턴:**
+ 발생 요인을 찾지만, 다른 잠재적 문제와 해결 방법을 계속 자세히 살펴보지는 않음
+ 인적 오류 원인만 식별하며, 인적 오류를 예방할 수 있는 교육이나 자동화는 제공하지 않음
**이 모범 사례 정립의 이점:** 인시던트 사후 분석을 수행하고 결과를 공유하면 다른 워크로드에서 동일한 발생 요인이 나타날 경우 위험을 완화할 수 있으며 인시던트가 발생하기 전에 해결하거나 자동 복구를 구현할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 인시던트 사후 분석을 위한 표준을 수립합니다. 우수한 인시던트 사후 분석은 시스템의 다른 위치에서 사용되는 아키텍처 패턴이 있는 문제에 대해 공통 솔루션을 제안할 수 있는 기회를 제공합니다.
+ 발생 요인을 솔직하게 밝히면서도 책임을 따지지 않도록 합니다.
+ 문제를 문서화하지 않으면 문제를 시정할 수 없습니다.
+ 인시던트 사후 분석에서 책임을 따지지 않으면서 제안된 시정 조치를 공정하게 평가하도록 하고 애플리케이션 팀의 솔직한 자체 평가와 협업을 유도합니다.
+ 발생 요인을 확인하는 프로세스를 사용합니다. 재발을 제한하거나 방지하기 위한 완화책을 개발하고 빠르고 효과적인 대응을 위한 절차를 개발할 수 있도록 이벤트의 발생 요인을 식별하고 문서화하는 프로세스를 마련합니다. 목표 대상에 맞게 적절히 발생 요인을 알립니다.
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
## 리소스
**관련 문서:**
+ [로그 분석이란 무엇일까요?](https://aws.amazon.com/log-analytics/)
+ [오류 수정(COE)을 개발해야 하는 이유](https://aws.amazon.com/blogs/mt/why-you-should-develop-a-correction-of-error-coe/)
# REL12-BP03 기능 요구 사항 테스트
단위 테스트와 필수 기능을 검증하는 통합 테스트 등의 기법을 사용합니다.
이러한 테스트는 구축 및 배포 작업의 일부로 자동으로 실행될 때 최상의 결과를 제공합니다. 예를 들어 개발자가 AWS CodePipeline을 사용하여 소스 리포지토리에 변경 사항을 커밋하면 CodePipeline이 변경 사항을 자동으로 감지합니다. 이러한 변경 사항이 구축되고 테스트가 실행됩니다. 테스트가 완료되면 테스트를 위해 구축된 코드가 스테이징 서버에 배포됩니다. CodePipeline은 스테이징 서버에서 통합 또는 로드 테스트와 같은 더 많은 테스트를 실행합니다. 이러한 테스트가 성공적으로 완료되면 CodePipeline은 테스트되고 승인된 코드를 프로덕션 인스턴스에 배포합니다.
또한 가장 중요한 테스트 중 하나는 고객 행동을 실행하고 시뮬레이션할 수 있는 가상 트랜잭션 테스트( *Canary 테스트라고도 하지만*카나리 배포와는 다름)입니다. 다양한 원격 위치에서 워크로드 엔드포인트에 대해 이러한 테스트를 지속적으로 실행합니다. Amazon CloudWatch Synthetics를 사용하면 엔드포인트 및 API 모니터링을 위한 [Canary를 생성](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 기능 요구 사항을 테스트합니다. 여기에는 단위 테스트와 필수 기능을 검증하는 통합 테스트가 포함됩니다.
+ [CodePipeline를 AWS CodeBuild와 함께 사용하여 코드 테스트 및 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [Continuous Delivery and Continuous Integration(지속적 전달 및 지속적 통합)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
## 리소스
**관련 문서:**
+ [APN 파트너: 지속적 통합 파이프라인 구현을 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Continuous+Integration)
+ [AWS CodePipeline Adds Support for Unit and Custom Integration Testing with AWS CodeBuild(AWS CodePipeline, AWS CodeBuild를 사용한 단위 및 맞춤형 통합 테스트 관련 지원 추가)](https://aws.amazon.com/about-aws/whats-new/2017/03/aws-codepipeline-adds-support-for-unit-testing/)
+ [AWS Marketplace: 지속적인 통합에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Continuous+integration)
+ [Continuous Delivery and Continuous Integration(지속적 전달 및 지속적 통합)](https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-continuous-delivery-integration.html)
+ [소프트웨어 테스트 자동화](https://aws.amazon.com/marketplace/solutions/devops/software-test-automation)
+ [CodePipeline를 AWS CodeBuild와 함께 사용하여 코드 테스트 및 빌드 실행](https://docs.aws.amazon.com/codebuild/latest/userguide/how-to-create-pipeline.html)
+ [Canary 사용(Amazon CloudWatch Synthetics)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
# REL12-BP04 확장 및 성능 요구 사항 테스트
워크로드가 조정 및 성능 요구 사항을 충족하는지 확인하기 위한 로드 테스트 등의 기법을 사용합니다.
클라우드에서는 워크로드에 대한 프로덕션 규모의 테스트 환경을 필요할 때 생성할 수 있습니다. 축소된 인프라에서 이러한 테스트를 실행하는 경우 관찰된 결과를 프로덕션 환경에서 발생할 것으로 생각되는 범위까지 확장해야 합니다. 실제 사용자에게 영향을 주지 않도록 주의하고 실제 사용자 데이터 및 손상된 사용 통계 또는 프로덕션 보고서와 충돌하지 않도록 테스트 데이터에 태그를 지정하면 프로덕션에서도 로드 및 성능 테스트를 수행할 수 있습니다.
테스트를 통해 기본 리소스, 조정 설정, 서비스 할당량 및 복원력 설계가 로드 조건에서 예상대로 작동하는지 확인합니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 크기 조정 및 성능 요구 사항을 테스트합니다. 로드 테스트를 수행하여 워크로드가 크기 조정 및 성능 요구 사항을 충족하는지 확인합니다.
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
+ 프로덕션 환경과 동일한 환경에 애플리케이션을 배포하고 로드 테스트를 수행합니다.
+ 코드형 인프라를 사용하여 프로덕션 환경과 최대한 유사한 환경을 구축합니다.
## 리소스
**관련 문서:**
+ [AWS에서의 분산 로드 테스트: 수천 명의 연결된 사용자 시뮬레이션](https://aws.amazon.com/solutions/distributed-load-testing-on-aws/)
+ [Apache JMeter](https://github.com/apache/jmeter?ref=wellarchitected)
# REL12-BP05 카오스 엔지니어링을 이용한 복원력 테스트
시스템이 불리한 조건에서 어떻게 반응하는지 파악하려면 프로덕션 내 환경 또는 프로덕션과 최대한 가까운 환경에서 카오스 실험을 정기적으로 실행합니다.
** 원하는 결과: **
워크로드의 복원력은 이벤트 중 워크로드의 알려진 예상 동작을 확인하는 복원력 테스트 이외에 장애 주입 실험 또는 예기치 않은 부하 발생의 형태로 카오스 엔지니어링을 적용하여 정기적으로 확인합니다. 카오스 엔지니어링과 복원력 테스트를 결합하여 구성 요소 장애 시 워크로드가 중단되지 않고, 예기치 않은 중단이 발생한 경우에도 영향을 최소화하거나 아무런 영향 없이 복구할 수 있다는 확신을 얻을 수 있습니다.
** 일반적인 안티 패턴: **
+ 복원력을 뛰어나게 설계했으나 장애 발생 시 워크로드가 전체적으로 작동하는 방식을 확인하지 않습니다.
+ 실제 조건 및 예상되는 부하에서 절대 실험하지 않습니다.
+ 실험을 코드로 처리하지 않고 개발 주기 전체에서 유지 관리하지 않습니다.
+ 카오스 실험을 CI/CD 파이프라인의 일부로 또한 배포 범위 외부에서도 실행하지 않습니다.
+ 어떤 결함을 실험할지 결정할 때 과거의 인시던트 후 분석 사용에 소홀합니다.
** 이 모범 사례 확립의 이점:** 워크로드의 복원력을 확인하기 위해 장애를 도입하면 탄력적인 설계의 복구 절차가 실제 장애 발생 시에도 잘 작동할 것으로 확신할 수 있습니다.
**이 모범 사례가 확립되지 않을 경우 노출되는 위험 수준:** 보통
## 구현 가이드
카오스 엔지니어링은 서비스 공급자, 인프라, 워크로드 및 구성 요소 수준에서 고객에게 미치는 영향을 최소화하거나 아무런 영향을 미치지 않으면서 제어되는 방식으로 실제 중단(시뮬레이션)을 지속적으로 도입할 수 있는 역량을 팀에 제공합니다. 이렇게 하면 팀이 장애로부터 배우고 워크로드의 복원력을 관찰, 측정 및 개선하고 이벤트 발생 시 알림이 전달되고 팀이 알림을 받는지 확인할 수 있습니다.
지속적으로 수행하면 카오스 엔지니어링은 해결하지 않고 두면 가용성과 운영에 부정적인 영향을 미칠 수 있는 결함을 강조해서 보여줄 수 있습니다.
**참고**
카오스 엔지니어링은 프로덕션 환경의 급변하는 조건을 견딜 수 있는 시스템의 역량을 확신하기 위해 시스템에 대해 수행하는 실험 분야입니다. [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
시스템이 중단을 견딜 수 있는 경우 카오스 엔지니어링은 자동화되어 회귀 테스트로 유지 관리해야 합니다. 이러한 방식으로 카오스 실험은 시스템 개발 수명 주기(SDLC) 및 CI/CD 파이프라인의 일부로 수행해야 합니다.
구성 요소 장애 발생 시 워크로드가 중단되지 않는지 확인하기 위해 실험의 일부로 실제 이벤트를 도입합니다. 예를 들어, Amazon EC2 인스턴스 손실 또는 기본 Amazon RDS 데이터베이스 인스턴스 장애 조치로 실험하고 워크로드가 영향을 받지 않는지(또는 최소한의 영향만 받는지) 확인합니다. 구성 요소 장애를 결합하여 가용 영역에서 중단으로 인해 발생할 수 있는 이벤트를 시뮬레이션합니다.
애플리케이션 수준 장애(예: 충돌)의 경우 메모리 및 CPU 소진 등과 같은 원인으로 시작할 수 있습니다.
간헐적 네트워크 중단으로 인한 외부 종속에 대한 [폴백 또는 장애 조치 메커니즘](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/) 을 확인하려면 구성 요소가 몇 초에서 몇 시간까지 지속될 수 있는 지정된 기간에 서드파티 제공업체에 대한 액세스를 차단하여 해당 이벤트를 시뮬레이션해야 합니다.
그 외의 모드에서 성능이 저하되면 기능이 저하되고 응답 속도가 느려져서 서비스가 일시적으로 중단되는 경우가 많습니다. 이러한 성능 저하는 대개 중요 서비스의 지연 시간 증가 및 불안정한 네트워크 연결(패킷이 삭제됨)로 인해 발생합니다. 지연 시간, 삭제된 메시지 및 DNS 장애 등과 같은 네트워킹 효과를 비롯한 장애를 사용한 실험에는 이름 확인 불가, DNS 서비스에 연결 불가 또는 종속적 서비스에 연결 설정 불가가 포함될 수 있습니다.
**카오스 엔지니어링 도구:**
AWS Fault Injection Service(AWS FIS)은(는) CD 파이프라인의 일부로 또는 파이프라인 외부에서 사용할 수 있는 장애 주입 실험을 실행하는 데 사용되는 완전관리형 서비스입니다. AWS FIS은(는) 카오스 엔지니어링 게임 데이 중 사용하기 좋습니다. Amazon EC2, Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service(Amazon EKS) 및 Amazon RDS을(를) 비롯한 여러 유형의 리소스 간에 동시 장애 발생을 지원합니다. 이러한 장애에는 리소스 종료, 강제 장애 조치, CPU 또는 메모리에 스트레스 유발, 제한, 지연 시간 및 패킷 손실이 포함됩니다. Amazon CloudWatch 경보와 통합되므로 테스트가 예상치 못한 영향을 미치는 경우 실험을 롤백하기 위해 중지 조건을 가드레일로 설정할 수 있습니다.
![\[워크로드에 장애 주입 실험을 실행할 수 있도록 AWS 리소스와 통합된 AWS Fault Injection Service을(를) 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/fault-injection-simulator.png)
장애 주입 실험을 위한 서드파티 옵션도 몇 가지 있습니다. 여기에는 오픈 소스 도구(예: [Chaos Toolkit](https://chaostoolkit.org/), [Chaos Mesh](https://chaos-mesh.org/)및 [Litmus Chaos](https://litmuschaos.io/))와 상용 옵션(예: Gremlin)이 포함됩니다. AWS에 삽입할 수 있는 장애 범위를 확장하기 위해 AWS FIS이(가) [Chaos Mesh 및 Litmus Chaos와 통합되어](https://aws.amazon.com/about-aws/whats-new/2022/07/aws-fault-injection-simulator-supports-chaosmesh-litmus-experiments/)여러 도구 간에 장애 주입 워크플로를 조정할 수 있습니다. 예를 들어, 임의로 선택된 비율의 클러스터 노드를 AWS FIS 장애 작업을 사용하여 종료하는 동안 Chaos Mesh 또는 Litmus 결함을 사용하여 포드의 CPU에 대한 스트레스 테스트를 실행할 수 있습니다.
## 구현 단계
+ 실험에 사용할 장애를 결정합니다.
워크로드 설계의 복원력을 평가합니다. 해당 설계( [Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)의 모범 사례를 사용하여 생성됨)는 중요한 종속성, 과거 이벤트, 알려진 문제 및 규정 준수 요구 사항을 기반으로 위험을 설명합니다. 복원력을 유지하기 위한 설계 요소와 완화하도록 설계된 장애를 나열합니다. 이러한 목록 작성에 대한 자세한 내용은 이전 인시던트 재발을 방지하기 위한 프로세스 생성 방법을 안내하는 [운영 준비 검토 백서](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 를 참조하세요. 장애 모드 및 영향 분석(FMEA) 프로세스는 장애의 구성 요소 수준 및 장애가 워크로드에 미치는 영향을 분석하기 위한 프레임워크를 제공합니다. FMEA는 Adrian Cockcroft가 장애 모드 및 지속적인 복원력에서 [자세히 설명합니다](https://adrianco.medium.com/failure-modes-and-continuous-resilience-6553078caad5).
+ 각 장애에 우선순위를 할당합니다.
처음에는 높음, 보통 또는 낮음 등과 같이 대략적인 분류로 시작합니다. 우선순위를 평가하려면 장애 빈도와 장애가 전체 워크로드에 미치는 영향을 고려해야 합니다.
주어진 장애의 빈도를 고려할 때 확인 가능한 경우 이 워크로드에 대한 이전 데이터를 분석합니다. 확인할 수 없는 경우에는 유사한 환경에서 실행되는 다른 워크로드의 데이터를 사용합니다.
주어진 장애의 영향을 고려할 때 장애의 범위가 클수록 일반적으로 영향도 커집니다. 또한 워크로드 설계 및 용도도 고려합니다. 예를 들어, 소스 데이터 스토어에 액세스하는 기능은 데이터 변환 및 분석을 수행하는 워크로드에 중요합니다. 이러한 경우 액세스 장애와 제한된 액세스 및 지연 시간 삽입에 대한 실험의 우선순위를 지정할 수 있습니다.
인시던트 후 분석은 장애 모드의 빈도 및 영향을 파악하기 위한 좋은 데이터 출처입니다.
할당된 우선순위를 사용하여 어떤 장애를 먼저 실험할지, 새로운 장애 주입 실험을 개발할 순서를 결정합니다.
+ 수행하는 각 실험에 대해 카오스 애플리케이션 및 지속적인 복원력 플라이휠을 따릅니다.
![\[개선, 안정 상태, 가설, 실험 실행 및 확인 단계를 보여주는 카오스 엔지니어링 및 연속 복원력 플라이휠 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/chaos-engineering-flywheel.png)
+ 안정 상태를 정상 동작을 나타내는 워크로드의 측정 가능한 출력으로 정의합니다.
예상한 대로 안정적으로 작동하면 워크로드가 안정 상태를 보이는 것입니다. 따라서 안정 상태를 정의하기 전에 워크로드가 정상인지 확인합니다. 특정 비율의 장애는 허용 가능한 한도 내에서 발생할 수 있기 때문에 안정 상태라고 해서 장애 발생 시 워크로드에 미치는 영향이 반드시 없는 것은 아닙니다. 안정 상태는 실험 중 관찰하는 기준선으로, 다음 단계에서 정의하는 가설이 예상대로 나타나지 않는 경우 이상이 있음을 강조합니다.
예를 들어, 결제 시스템의 안정 상태를 성공률 99%, 왕복 시간 500ms의 300 TPS 처리로 정의할 수 있습니다.
+ 워크로드가 장애에 반응할 방법에 대한 가설을 작성합니다.
올바른 가설은 안정 상태 유지를 위해 장애 완화에 기대되는 작동 방식을 기반으로 합니다. 가설은 워크로드가 특정 완화를 수행하도록 설계되었기 때문에 특정 유형의 장애 발생 시 시스템 또는 워크로드가 계속해서 안정 상태를 유지할 것이라고 가정합니다. 특정 유형의 장애 및 완화가 가설에 명시되어 있어야 합니다.
가설에는 다음 템플릿을 사용할 수 있습니다(하지만 다르게 표현할 수도 있음).
**참고**
만약 *특정 장애* 가 발생하면 *워크로드 명칭* 워크로드가 *비즈니스 또는 기술 지표의 영향* 을 유지하기 위한 *완화 제어 조치를 설명합니다*.
예를 들면 다음과 같습니다.
+ Amazon EKS 노드 그룹 중 20%의 노드가 종료되면 트랜잭션 생성 API가 100ms에서 요청의 99%를 계속해서 제공합니다(안정 상태). Amazon EKS 노드는 5분 이내에 복구되고 포드는 실험 시작 후 8분 이내에 트래픽을 예약하고 처리합니다. 3분 이내에 알림이 전송됩니다.
+ 단일 Amazon EC2 인스턴스 장애가 발생하면 주문 시스템의Elastic Load Balancing 상태 확인 기능이 Elastic Load Balancing에 나머지 정상 인스턴스에만 요청을 보내도록 하고 동시에 Amazon EC2 Auto Scaling에서는 장애가 발생한 인스턴스를 교체하여 서버 측(5xx) 오류의 증가율을 0.01% 미만으로 유지합니다(안정 상태).
+ 1차 Amazon RDS 데이터베이스 인스턴스에서 장애가 발생하면 공급망 데이터 컬렉션 워크로드는 장애 조치를 취하고 대기Amazon RDS 데이터베이스 인스턴스에 연결하여 데이터베이스 읽기 또는 쓰기 오류를 1분 미만으로 유지합니다(안정 상태).
+ 장애를 도입하여 실험을 실행합니다.
실험은 기본적으로 장애 발생 시 안전해야 하며 워크로드에서 허용해야 합니다. 워크로드에서 장애가 발생할 것임을 아는 경우 실험을 실행하지 마세요. known-unknowns 또는 unknown-unknowns를 찾으려면 카오스 엔지니어링을 사용해야 합니다. *Known-unknowns* 는 알고 있지만 완전히 파악하지 못한 항목이며, *unknown-unknowns* 는 알지 못할 뿐만 아니라 완전히 파악하지 못한 항목입니다. 실패할 것을 알고 있는 워크로드에 대한 실험에서는 새로운 인사이트를 얻을 수 없습니다. 실험은 주의해서 계획해야 하고 영향 범위가 명확해야 하며 예기치 못한 변동 발생 시 적용할 수 있는 롤백 메커니즘을 제공해야 합니다. 실사에서 워크로드가 실험을 통과해야 한다고 나타나면 실험을 계속 진행합니다. 장애 주입을 위한 옵션은 여러 가지가 있습니다. AWS에서의 워크로드의 경우 [AWS FIS](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html) 에서는 작업이라 부르는 미리 정의된 다양한 장애 시뮬레이션을 [해당 알림에 대한 작업이](https://docs.aws.amazon.com/fis/latest/userguide/actions.html). 또한 다음 문서를 사용하여 AWS FIS에서 실행하는 사용자 지정 작업을 정의할 수도 있습니다. [AWS Systems Manager 문서](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html).
스크립트에 워크로드의 현재 상태를 파악하는 기능이 없고, 스크립트가 로그를 내보낼 수 없고, 가능한 경우 롤백 메커니즘 및 중지 조건을 제공할 수 없는 경우에는 카오스 실험에 사용자 지정 스크립트를 사용하지 않는 것이 좋습니다.
카오스 엔지니어링을 지원하는 효율적인 프레임워크 또는 도구 세트는 실험의 현재 상태를 추적하고, 로그를 내보내고, 실험의 제어되는 실행을 지원하기 위한 롤백 메커니즘을 제공해야 합니다. 실험 시 예기치 못한 변동이 발생하는 경우 실험을 롤백하는 안전 메커니즘과 분명하게 정의된 범위가 있는 실험을 수행하도록 허용하는 AWS FIS 등과 같은 확립된 서비스로 시작합니다. AWS FIS을(를) 사용한 다양한 실험에 대해 알아보려면 [Resilient and Well-Architected Apps with Chaos Engineering lab(카오스 엔지니어링을 사용해 잘 설계된 복원력이 뛰어난 앱 실습)을 참조하세요](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US). 또한 [AWS Resilience Hub](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html) 은(는) 워크로드를 분석하여 AWS FIS에서 구현 및 실행하도록 선택할 수 있는 실험을 생성합니다.
**참고**
모든 실험에 대해 범위와 그 영향을 명확하게 이해해야 합니다. 프로덕션 환경에서 실행하기 전에 비프로덕션 환경에서 먼저 장애를 시뮬레이션하는 것이 좋습니다.
실험은 가능한 경우 제어 및 실험적 시스템 배포를 둘 다 실행하는 [카나리 배포](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db) 를 사용하여 실제 로드를 받는 프로덕션 환경에서 실행해야 합니다. 프로덕션 환경에서 처음으로 실험하는 경우 잠재적인 영향을 완화하기 위해 사용량이 적은 시간에 실험을 실행하는 것이 좋습니다. 또한 실제 고객 트래픽 사용의 위험이 너무 큰 경우에는 프로덕션 인프라에서 제어 및 실험적 배포에 대해 가상 트래픽을 사용하여 실험을 실행할 수 있습니다. 프로덕션 환경을 사용할 수 없는 경우 가급적 프로덕션 환경과 유사한 프로덕션 전 환경에서 실험을 실행합니다.
실험이 허용 가능한 제한을 벗어나 프로덕션 트래픽 또는 다른 시스템에 영향을 미치지 않도록 가드레일을 설정하고 모니터링해야 합니다. 가드레일 지표에 대해 정의한 임곗값에 도달한 경우 실험을 중지하기 위한 중지 조건을 설정합니다. 중지 조건에는 워크로드의 안정 상태에 대한 지표와 장애를 도입하는 구성 요소에 대한 지표를 포함해야 합니다. 또한 [종합 모니터링](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (사용자 canary라고도 함)은 일반적으로 사용자 프록시로 포함해야 하는 한 가지 지표입니다. [AWS FIS에 대한 중지 조건](https://docs.aws.amazon.com/fis/latest/userguide/stop-conditions.html) 은 실험 템플릿의 일부로 지원되며 템플릿당 최대 5개의 중지 조건을 사용할 수 있습니다.
카오스 원칙 중 한 가지는 실험 범위 및 그 영향을 최소화하는 것입니다.
단기적인 부정적 영향 중 일부를 허용해야 하지만 실험의 여파를 최소화하고 제한하는 것은 카오스 엔지니어의 책임이자 의무입니다.
실험 범위 및 잠재적인 영향을 확인하기 위한 방법은 먼저 비프로덕션 환경에서 실험을 수행하여 실험 중 중지 조건의 임곗값이 예상대로 활성화되고 프로덕션 환경에서 직접 실험하지 않고 관찰을 통해 예외를 포착할 수 있는지 확인하는 것입니다.
장애 주입 실험을 실행할 때 책임 당사자 모두가 알림을 잘 받았는지 확인합니다. 운영 팀, 서비스 신뢰성 팀, 고객 지원 팀 등과 같은 적절한 팀과 소통하여 실험 실행 시점과 기대하는 결과에 대해 알립니다. 이러한 팀에 통신 도구를 제공하여 부정적인 영향을 확인한 경우 실험을 실행하는 팀에 알릴 수 있도록 합니다.
워크로드와 기본 시스템을 원래 정상 상태로 복원해야 합니다. 보통, 워크로드의 탄력적인 설계는 스스로 복구됩니다. 하지만 일부 장애 설계 또는 장애가 발생한 실험에서는 워크로드를 예기치 않은 장애 상태로 둘 수 있습니다. 따라서 실험을 마치면 이 점을 인식하고 워크로드 및 시스템을 복원해야 합니다. AWS FIS를 사용하면 작업 파라미터 내에서 롤백 구성을 설정할 수 있습니다(후속 작업이라고도 함). 후속 작업은 대상을 작업 실행 전의 상태로 되돌립니다. 자동 작업(예: AWS FIS 사용)이든 수동 작업이든 상관 없이 후속 작업은 장애 감지 및 처리 방법을 설명하는 플레이북의 일부여야 합니다.
+ 가설을 확인합니다.
[Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/) 은 워크로드의 안정 상태를 확인하는 방법에 대한 다음 지침을 제공합니다.
시스템의 내부 특성보다는 시스템의 측정 가능한 결과에 중점을 둡니다. 단기간의 결과에 대한 측정값은 시스템의 안정 상태에 대한 프록시를 구성합니다. 전체 시스템의 처리량, 오류 발생률 및 지연 시간 백분위수는 모두 안정 상태 동작을 나타내는 관심 지표일 수 있습니다. 실험 중 체계적인 동작 패턴에 집중하여 카오스 엔지니어링은 시스템 작동 방식 확인이 아니라 시스템이 잘 작동하는지를 확인합니다.
이전 두 가지 예에서는 서버측(5xx) 오류 증가를 0.01% 미만으로, 데이터베이스 읽기 및 쓰기 오류를 1분 미만으로 지정한 안정 상태 지표를 포함합니다.
5xx 오류는 워크로드의 클라이언트가 직접 경험하는 장애 모드의 결과이기 때문에 좋은 지표입니다. 데이터베이스 오류 측정은 장애의 직접적인 결과이기 때문에 적절하긴 하지만 실패한 고객 요청 수 또는 고객에게 표시된 오류 수 등과 같은 클라이언트 영향 측정으로 보충해야 합니다. 또한 워크로드의 클라이언트가 직접 액세스할 수 있는 API 또는 URI에 종합 모니터(사용자 canary라고도 함)를 포함합니다.
+ 복원력을 위해 워크로드 설계를 개선합니다.
안정 상태가 유지되지 않는 경우 장애를 완화하기 위해 워크로드 설계를 어떻게 개선할 수 있는지 조사하여 [AWS Well-Architected 신뢰성 원칙](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)에 대한 모범 사례를 적용합니다. 추가 지침 및 리소스는 [AWS 빌더 라이브러리](https://aws.amazon.com/builders-library/)에서 찾을 수 있습니다. 이 라이브러리는 특히, [상태 확인 개선 방법](https://aws.amazon.com/builders-library/implementing-health-checks/) 또는 [애플리케이션 코드에서 백오프를 사용하여 재시도 채택 방법](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/)에 대한 문서를 호스트합니다.
이러한 변경 사항을 구현한 후에는 실험을 다시 실행하여(카오스 엔지니어링 프라이휠에서 점선으로 표시됨) 변경 사항의 영향을 확인합니다. 확인 단계에서 가설이 참으로 입증되면 워크로드가 안정 상태이므로 주기가 계속됩니다.
+ 실험을 정기적으로 실행합니다.
카오스 실험은 주기이고 카오스 엔지니어링의 일부로 주기적으로 실행해야 합니다. 워크로드가 실험의 가설을 충족하면 CI/CD 파이프라인의 회귀 부분으로 계속해서 실행되도록 실험을 자동화해야 합니다. 이렇게 하는 방법을 알아보려면 [AWS CodePipeline을(를) 사용하여 AWS FIS 실험을 실행하는 방법](https://aws.amazon.com/blogs/architecture/chaos-testing-with-aws-fault-injection-simulator-and-aws-codepipeline/)에 관한 블로그를 참조하세요. 이 실습은 [CI/CD 파이프라인에서 반복 AWS FIS 실험](https://chaos-engineering.workshop.aws/en/030_basic_content/080_cicd.html) 에 관한 내용으로, 직접 적용해 볼 수 있습니다.
장애 주입 실험은 게임 데이의 일부이기도 합니다( [REL12-BP06 정기적으로 게임 데이 진행](rel_testing_resiliency_game_days_resiliency.md)참조). 게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 확인합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다.
+ 실험 결과를 캡처하고 저장합니다.
장애 주입 실험의 결과는 캡처한 다음 지속해야 합니다. 나중에 실험 결과 및 추세를 분석할 수 있도록 필요한 데이터(예: 시간, 워크로드 및 조건)를 모두 포함합니다. 결과의 예에는 대시보드 스냅샷, 지표 데이터베이스의 CSV 덤프 또는 이벤트에 대해 손으로 작성한 기록, 실험에서 관찰한 내용 등이 있을 수 있습니다. [AWS FIS(으)로 기록한 실험은](https://docs.aws.amazon.com/fis/latest/userguide/monitoring-logging.html) 이러한 데이터 캡처의 일부일 수 있습니다.
## 리소스
**관련 모범 사례:**
+ [REL08-BP03 배포의 일부로 복원력 테스트 통합](rel_tracking_change_management_resiliency_testing.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
**관련 문서:**
+ [AWS Fault Injection Service란 무엇인가요?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
+ [AWS Resilience Hub란 무엇인가요?](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)
+ [Principles of Chaos Engineering(카오스 엔지니어링의 원칙)](https://principlesofchaos.org/)
+ [Chaos Engineering: Planning your first experiment(카오스 엔지니어링: 첫 번째 실험 계획)](https://medium.com/the-cloud-architect/chaos-engineering-part-2-b9c78a9f3dde)
+ [Resilience Engineering: Learning to Embrace Failure(복원력 엔지니어링: 실패를 수용하는 방법 학습)](https://queue.acm.org/detail.cfm?id=2371297)
+ [카오스 엔지니어링 스토리](https://github.com/ldomb/ChaosEngineeringPublicStories)
+ [분산 시스템의 폴백 방지](https://aws.amazon.com/builders-library/avoiding-fallback-in-distributed-systems/)
+ [카오스 실험을 위한 카나리 배포](https://medium.com/the-cloud-architect/chaos-engineering-q-a-how-to-safely-inject-failure-ced26e11b3db)
**관련 동영상:**
+ [AWS re:Invent 2020: Testing resiliency using chaos engineering(카오스 엔지니어링을 사용하여 복원력 테스트)(ARC316)](https://www.youtube.com/watch?v=OlobVYPkxgg)
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering(카오스 엔지니어링을 사용하여 복원력 개선)(DOP309-R1)](https://youtu.be/ztiPjey2rfY)
+ [AWS re:Invent 2019: Performing chaos engineering in a serverless world(서버리스 환경에서 카오스 엔지니어링 수행)(CMY301)](https://www.youtube.com/watch?v=vbyjpMeYitA)
**관련 예시:**
+ [Well-Architected lab: Level 300: Testing for Resiliency of Amazon EC2, Amazon RDS, and Amazon S3(Amazon EC2, Amazon RDS 및 Amazon S3의 복원력 테스트)](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
+ [Chaos Engineering on AWS lab(AWS에서 카오스 엔지니어링 실습)](https://chaos-engineering.workshop.aws/en/)
+ [Resilient and Well-Architected Apps with Chaos Engineering lab(카오스 엔지니어링을 사용해 잘 설계된 복원력이 뛰어난 앱 실습)을 참조하세요](https://catalog.us-east-1.prod.workshops.aws/workshops/44e29d0c-6c38-4ef3-8ff3-6d95a51ce5ac/en-US)
+ [Serverless Chaos lab(서버리스 카오스 실습)](https://catalog.us-east-1.prod.workshops.aws/workshops/3015a19d-0e07-4493-9781-6c02a7626c65/en-US/serverless)
+ [Measure and Improve Your Application Resilience with AWS Resilience Hub lab(AWS Resilience Hub를 사용하여 애플리케이션 복원력 측정 및 개선 실습)](https://catalog.us-east-1.prod.workshops.aws/workshops/2a54eaaf-51ee-4373-a3da-2bf4e8bb6dd3/en-US/200-labs/1wordpressapplab)
** 관련 도구: **
+ [AWS Fault Injection Service](https://aws.amazon.com/fis/)
+ AWS Marketplace: [Gremlin Chaos Engineering Platform](https://aws.amazon.com/marketplace/pp/prodview-tosyg6v5cyney)
+ [Chaos Toolkit](https://chaostoolkit.org/)
+ [Chaos Mesh](https://chaos-mesh.org/)
+ [Litmus](https://litmuschaos.io/)
# REL12-BP06 정기적으로 게임 데이 진행
실제 장애 시나리오에 영향을 받을 직원들과 함께 게임 데이를 정기적으로 수행하여 프로덕션에 최대한 근접한 장애 및 이벤트 대응 절차(프로덕션 환경의 장애 절차 포함)를 연습합니다. 게임 데이에서는 프로덕션 이벤트가 사용자에게 영향을 미치지 않도록 하는 조치가 시행됩니다.
게임 데이에서는 장애나 이벤트를 시뮬레이션하여 시스템, 프로세스 및 팀 대응을 테스트합니다. 게임 데이의 목적은 이례적인 이벤트 발생 시 팀이 수행해야 할 작업을 실제로 수행해보는 것입니다. 그러면 어느 분야에서 개선이 필요한지 파악하고, 조직이 이벤트에 대처하는 경험을 쌓도록 도울 수 있습니다. 팀이 대응 방법을 *체득할 수 있도록* 게임 데이를 정기적으로 진행해야 합니다.
복원력을 위한 설계가 마련되고 비 프로덕션 환경에서 이 설계를 테스트한 후에는 실전 연습을 통해 모든 구성 요소가 프로덕션에서 예상대로 작동하는지 확인합니다. 실전 연습, 특히 첫 번째 실전 연습에서는 엔지니어와 운영 팀이 모두 모여 실전 연습의 일정과 내용에 대한 정보를 숙지합니다. 런북이 준비되어 있습니다. 프로덕션 시스템에서 미리 정해진 방식으로 발생할 수 있는 장애 이벤트를 비롯한 시뮬레이션 이벤트가 실행되고 영향이 평가됩니다. 모든 시스템이 설계대로 작동할 경우 감지 및 자가 복구가 수행됩니다. 영향은 거의 없습니다. 그러나 부정적인 영향이 관찰되면 테스트가 롤백되고 워크로드 문제가 해결됩니다. 필요한 경우 런북을 사용하여 수동으로 문제를 해결합니다. 게임 데이는 프로덕션에서 수행되는 경우가 많으므로 고객의 가용성에 영향을 미치는 일이 없도록 모든 예방 조치를 취해야 합니다.
**일반적인 안티 패턴:**
+ 절차를 문서화하지만 결코 연습하지 않음
+ 테스트 연습에 비즈니스 의사 결정권자가 참여하지 않음
**이 모범 사례 수립의 이점:** 게임 데이를 정기적으로 실시하면 실제 인시던트가 발생할 때 모든 직원이 정책과 절차를 따르도록 하고 이러한 정책과 절차가 적절한지 검증할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 런북 및 플레이북을 정기적으로 실행하도록 게임 데이 수행 게임 데이에는 비즈니스 소유자, 개발 직원, 운영 직원 및 인시던트 대응 팀 등 프로덕션 이벤트에 관련된 모든 사람이 참여해야 합니다.
+ 로드 또는 성능 테스트를 실행한 다음 장애 주입을 실행합니다.
+ 런북에서 이상이 있는지 찾고 플레이북을 연습할 기회가 있는지 살펴봅니다.
+ 런북에서 벗어난 경우 해당 런북을 구체화하거나 동작을 수정합니다. 플레이북을 실행하는 경우, 사용되었어야 하는 런북을 식별하거나 새로운 런북을 만듭니다.
## 리소스
**관련 문서:**
+ [AWS 게임 데이란 무엇입니까?](https://aws.amazon.com/gameday/)
**관련 동영상:**
+ [AWS re:Invent 2019: Improving resiliency with chaos engineering(카오스 엔지니어링을 사용하여 복원력 개선)(DOP309-R1)](https://youtu.be/ztiPjey2rfY)
**관련 예시:**
+ [AWS Well-Architected 실습 - 복원력 테스트](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL 13 DR(재해 복구)를 어떻게 계획합니까?
DR 전략의 시작은 백업 및 이중화 워크로드 구성 요소를 갖추는 것입니다. [RTO 및 RPO는 워크로드 복원을 위한](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/disaster-recovery-dr-objectives.html) 목표입니다. 비즈니스 요구 사항에 따라 이러한 목표를 설정합니다. 워크로드 리소스 및 데이터의 위치와 기능을 고려하여 이러한 목표를 충족하는 전략을 구현합니다. 중단 가능성과 복구 비용도 워크로드에 대한 재해 복구 옵션을 갖추는 것이 지니는 비즈니스 가치를 파악하는 데 도움이 되는 주요 요소입니다.
**Topics**
+ [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md)
+ [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
+ [REL13-BP04 DR 사이트 또는 리전에서 구성 드리프트 관리](rel_planning_for_recovery_config_drift.md)
+ [REL13-BP05 복구 자동화](rel_planning_for_recovery_auto_recovery.md)
# REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의
워크로드에는 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)가 있습니다.
*RTO(복구 시간 목표)* 는 서비스 중단 시점과 서비스 복원 시점 간에 허용되는 최대 지연 시간으로, 서비스를 사용할 수 없는 상태로 허용되는 기간을 결정합니다.
*RPO(복구 시점 목표)* 는 마지막 데이터 복구 시점 이후 허용되는 최대 시간으로, 마지막 복구 시점과 서비스 중단 시점 사이에 허용되는 데이터 손실량을 결정합니다.
워크로드에 적절한 재해 복구(DR) 전략을 선택할 때 RTO 및 RPO 값을 고려하는 것이 중요합니다. 이 두 가지 목표는 비즈니스 차원에서 결정하고 기술 팀에서 DR 전략을 선택하여 구현할 때 사용합니다.
**원하는 결과:**
워크로드마다 비즈니스 영향에 따라 정의된 RTO 및 RPO가 할당됩니다. 워크로드는 관련 RTO와 RPO로 서비스 가용성과 용인 가능한 데이터 손실을 정의하는 사전에 정의된 티어에 할당됩니다. 그러한 티어 할당이 불가능하면 나중에 티어를 생성할 의도로 워크로드마다 맞춤형으로 할당될 수 있습니다. RTO 및 RPO는 워크로드의 재해 복구 전략 구현을 선택하기 위한 기본적인 고려 사항 중 하나로 사용됩니다. DR 전략을 선택할 때 추가로 고려해야 할 사항은 비용 제약, 워크로드 종속성, 운영 요구 사항입니다.
RTO의 경우 중단의 기간에 따른 영향을 파악합니다. 영향이 선형적인지, 비선형적인 영향이 있는지(예: 4시간 후에 다음 교대가 시작될 때까지 제조 라인을 중단시킴) 파악해야 합니다.
다음과 같은 재해 복구 매트릭스는 워크로드 중요도가 복구 목표와 어떤 연관이 있는지 파악하는 데 도움이 됩니다. (참고로 X 축과 Y 축의 실제 값은 조직의 요구 사항에 따라 맞춤화해야 합니다.)
![\[재해 복구 매트릭스를 보여주는 차트\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/disaster-recovery-matrix.png)
**일반적인 안티 패턴:**
+ 복구 목표가 정의되지 않음
+ 임의의 복구 목표 선택
+ 너무 관대하고 비즈니스 목표를 충족하지 못하는 복구 목표 선택
+ 가동 중단 시간 및 데이터 손실의 영향을 파악하지 않음
+ 워크로드 구성에서 달성할 수 없는 즉각 복구 또는 데이터 무손실과 같이 비현실적인 복구 목표 선택
+ 실제 비즈니스 목표보다 더 엄격한 복구 목표 선택. 이로 인해 워크로드에 필요한 수준 이상으로 DR 구현의 비용이 높아지고 DR 구현이 복잡해집니다.
+ 종속 워크로드와 호환되지 않는 복구 목표 선택
+ 규제 요구 사항을 고려하지 않은 복구 목표
+ 워크로드에 대한 RTO 및 RPO를 정의했으나 테스트하지 않음
**이 모범 사례 수립의 이점:** 재해 복구를 구현하는 데 기준이 될 시간 및 데이터 손실에 대한 복구 목표가 필요합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
주어진 워크로드에서 가동 중단 시간 및 데이터 손실이 비즈니스에 미치는 영향을 파악해야 합니다. 가동 중단 시간이나 데이터 손실이 커질수록 일반적으로 영향이 커지지만, 영향이 어떻게 커지는지는 워크로드 유형에 따라 다를 수 있습니다. 예를 들어, 영향이 적을 때는 가동 중단 시간을 최대 1시간까지 용인할 수 있지만 그 후에는 영향이 빠르게 증가할 수 있습니다. 비즈니스에 미치는 영향은 비용 손실(수익 손실), 고객 신뢰(평판에 미치는 영향), 운영 문제(급여 누락 또는 생산성 저하), 규제 위험 등 다양한 형태로 나타날 수 있습니다. 다음 단계를 따라 이러한 영향을 이해하고 워크로드에 RTO 및 RPO를 설정하세요.
**구현 단계**
1. 이 워크로드의 비즈니스 이해 관계자를 파악하고 이해 관계자를 관여시켜 이 단계를 구현합니다. 워크로드의 복구 목표는 비즈니스 차원의 의사 결정 사항입니다. 그런 다음 기술 팀에서 비즈니스 이해 관계자와 협력하여 이 목표를 사용해 DR 전략을 선택합니다.
**참고**
2단계와 3단계에서는 다음을 사용합니다. [구현 워크시트](#implementation-worksheet).
1. 아래 질문에 답하여 의사 결정을 내리는 데 필요한 정보를 수집합니다.
1. 조직에 워크로드 영향에 대한 중요도 범주나 티어가 있습니까?
1. 있다면 이 워크로드를 범주에 할당합니다.
1. 없다면 범주를 만듭니다. 5개 이하의 범주를 생성하고 각각의 복구 시간 목표 범위를 구체화합니다. 범주 예시로는 ‘매우 중요’, ‘높음’, ‘보통’, ‘낮음’이 있습니다. 워크로드가 각각의 범주에 어떻게 해당하는지 파악하려면 워크로드가 미션에 필수적인지, 비즈니스 차원에서 중요한지 아니면 비즈니스 추진과 큰 관련이 없는지 고려합니다.
1. 범주에 따라 워크로드 RTO와 RPO를 설정합니다. 언제나 이 단계에 들어설 때 계산한 원래의 값보다 더 엄격하게(더 낮은 RTO 및 RPO) 범주를 선택하세요. 이로 인해 값이 부적절하게 크게 변경된다면 새로운 범주를 만드는 것을 고려하세요.
1. 이 답변에 따라 RTO 및 RPO 값을 워크로드에 할당합니다. 직접 할당하거나 워크로드를 사전에 정의된 서비스 티어에 할당하면 됩니다.
1. 이 워크로드의 재해 복구 계획(DRP)을 문서화합니다. 이는 조직의 [비즈니스 연속성 계획(BCP)에](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html)포함되며, 워크로드 팀 및 이해 관계자가 액세스할 수 있는 위치에 저장합니다.
1. RTO 및 RPO와 이러한 값을 결정하는 데 사용된 정보를 기록합니다. 비즈니스에 미치는 워크로드의 영향을 평가하는 데 사용한 전략을 포함합니다.
1. 재해 복구 목표에서 추적하고 있거나 추적하려는 RTO 및 RPO 외의 다른 지표를 기록합니다.
1. 이 계획에 DR 전략 및 런북의 세부 정보를 추가합니다.
1. 그림 15와 같은 매트릭스에서 워크로드 중요도를 찾아보면 조직을 위해 사전 정의된 서비스 티어를 설정할 수 있습니다.
1. 에 따라 DR 전략(또는 DR 전략의 개념 증명)을 구현하고 나면[REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)이 전략을 테스트하여 워크로드의 실제 RTC(복구 시간 역량) 및 RPC(복구 시점 역량)를 파악합니다. 이것이 복구 목표에 부합하지 않으면 비즈니스 이해 관계자와 협력하여 목표를 조정하거나 목표에 부합하도록 DR 전략을 변경합니다.
**기본 질문**
1. 비즈니스에 심각한 영향이 미치기 전에 워크로드가 중단되어도 되는 최대 시간은 얼마입니까?
1. 워크로드가 중단되었을 때 분당 비즈니스에 발생하는 금전적 비용(직접적인 금전적 영향)을 파악합니다.
1. 이 영향은 항상 선형적이지 않다는 점을 고려합니다. 처음에는 영향이 제한적이지만 특정 시점을 지나면 영향이 빠르게 증가할 수 있습니다.
1. 비즈니스에 심각한 영향이 미치기 전에 손실되어도 되는 데이터의 최대 양은 얼마입니까?
1. 가장 중요한 데이터 스토어에 대해 이 값을 고려합니다. 다른 데이터 스토어에 대해 각각의 중요도를 파악합니다.
1. 워크로드 데이터가 손실되면 재생성할 수 있습니까? 백업 후 복원하는 것보다 재생성이 운영상 더 용이하면 워크로드 데이터를 재생성하는 데 사용되는 소스 데이터의 중요도에 따라 RPO를 선택합니다.
1. 이것이 의존하는 워크로드(다운스트림) 또는 이것에 의존하는 워크로드(업스트림)의 복구 목표 및 가용성 기대치는 얼마입니까?
1. 이 워크로드가 업스트림 종속성의 요구 사항을 충족하도록 하는 복구 목표를 선택합니다.
1. 다운스트림 종속성의 복구 기능에 따라 달성할 수 있는 복구 목표를 선택합니다. 중요하지 않은 다운스트림 종속성(다른 해결책이 있는 것)은 제외할 수 있습니다. 아니면 중요한 다운스트림 종속성으로 필요하다면 복구 기능을 개선합니다.
**추가 질문**
아래 질문을 고려하고 이 워크로드에 어떻게 적용되는지 생각하세요.
1. 중단의 유형(예: 리전, 가용 영역 등)에 따라 다른 RTO 및 RPO가 있습니까?
1. RTO/RPO가 변경될 수 있는 특정 시기(계절, 세일 이벤트, 제품 출시)가 있습니까? 그렇다면 다른 측정 방식과 시간 경계가 무엇입니까?
1. 워크로드가 중단되면 얼마나 많은 고객이 영향을 받습니까?
1. 워크로드가 중단될 경우 평판에 미치는 영향은 무엇입니까?
1. 워크로드가 중단될 경우 발생할 수 있는 운영상의 다른 영향에는 어떤 것이 있습니까? 예를 들어,이메일 시스템을 사용할 수 없게 되거나 급여 시스템에서 트랜잭션을 제출할 수 없게 되면 직원 생산성에 영향을 미칩니다.
1. 워크로드 RTO 및 RPO가 사업부 및 조직 DR 전략과 어떻게 연계됩니까?
1. 서비스 제공에 내부적으로 계약상의 의무가 있습니까? 그 의무를 이행하지 못하면 불이익이 있습니까?
1. 데이터에 대한 규제 또는 규정상의 제약은 무엇입니까?
## 구현 워크시트
구현의 2 및 3단계에 이 워크시트를 사용하세요. 필요에 따라 질문을 추가하는 등 이 워크시트를 조정할 수 있습니다.
![\[워크시트\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/worksheet.png)
**구현 계획의 작업 수준: **낮음
## 리소스
**관련 모범 사례:**
+ [REL09-BP04 백업 무결성 및 프로세스를 확인하기 위해 데이터의 주기적인 복구 수행](rel_backing_up_data_periodic_recovery_testing_data.md)
+ [REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용](rel_planning_for_recovery_disaster_recovery.md)
+ [REL13-BP03 재해 복구 구현을 테스트하여 구현 확인](rel_planning_for_recovery_dr_tested.md)
**관련 문서:**
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS에서 워크로드의 재해 복구: 클라우드에서의 복구(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS 복원력 허브로 복원력 정책 관리](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html)
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**관련 동영상:**
+ [AWS re:Invent 2018: 다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS에서 워크로드의 재해 복구](https://www.youtube.com/watch?v=cJZw5mrxryA)
# REL13-BP02 복구 목표 달성을 위해 정의된 복구 전략 사용
워크로드의 복구 목표에 부합하는 재해 복구(DR) 전략을 정의합니다. 백업 및 복원, 대기(활성/비활성), 활성/활성 등의 전략을 선택합니다.
DR 전략은 기본 위치에서 워크로드를 실행할 수 없게 되었을 때 복구 사이트에서 워크로드를 실행하는 능력에 달려 있습니다. 가장 흔한 복구 목표는 다음에서 논의한 RTO 와 RPO입니다 [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md).
하나의 AWS 리전 내에서 여러 가용 영역(AZ)에 걸친 DR 전략은 화재, 홍수, 대규모의 정전과 같은 재해 이벤트 시 피해를 완화해 줍니다. 워크로드를 특정 AWS 리전에서 실행할 수 없게 되는 흔치 않은 이벤트에 대한 예방 조치를 구현하는 것이 요구 사항이라면 여러 리전을 사용하는 DR 전략을 사용할 수 있습니다.
여러 리전에 걸쳐 DR 전략을 아키텍팅할 때 다음 전략 중 하나를 사용해야 합니다. 전략은 복잡성과 비용이 증가하고 RTO 및 RPO가 감소하는 순서로 나열되어 있습니다. *복구 리전* 이란 워크로드에 사용한 기본 리전이 아닌 다른 AWS 리전을 말합니다.
![\[DR 전략을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/disaster-recovery-strategies.png)
+ **백업 및 복구** (시간 단위 RPO, 24시간 이하의 RTO): 데이터와 애플리케이션을 복구 리전에 백업합니다. 자동화된 백업 또는 지속적인 백업을 사용하면 특정 시점 복구가 가능하여 경우에 따라서는 RPO를 5분까지 줄일 수 있습니다. 재해 이벤트 시 인프라를 배포(RTO를 단축하기 위해 인프라를 코드로 사용하여)하고, 코드를 배포하고, 백업 데이터를 복원하여 복구 리전에서 재해로부터 복구합니다.
+ **파일럿 라이트** (분 단위 RPO, 10분 단위 RTO): 코어 워크로드의 인프라 복사본을 복구 리전에 프로비저닝합니다. 데이터를 복구 리전에 복제하고 복구 리전에서 백업을 생성합니다. 데이터베이스 및 객체 스토리지 등 데이터 복제 및 백업을 지원하는 데 필요한 리소스가 항상 실행됩니다. 애플리케이션 서버 또는 서버리스 컴퓨팅과 같은 기타 요소는 배포되지 않지만 필요에 따라 필수 구성 및 애플리케이션 코드로 생성될 수 있습니다.
+ **웜 대기** (초 단위 RPO, 분 단위 RTO): 모든 기능을 갖추었지만 축소된 버전의 워크로드를 복구 리전에 항상 실행되는 상태로 유지합니다. 비즈니스 크리티컬 시스템은 완전히 복제되고 항상 실행되지만 플릿은 축소됩니다. 데이터가 복구 리전에 복제되며 실행됩니다. 복구 시기가 되면 시스템은 프로덕션 로드를 처리하기 위해 신속하게 확장됩니다. 웜 대기가 확장될수록 RTO 및 컨트롤 플레인 의존도는 낮아집니다. 완전히 확장되면 이것을 **상시 대기 방식이라고 합니다**.
+ **복수 리전(다중 사이트) 액티브/액티브** (0에 가까운 RPO, 0일 수 있는 RTO): 워크로드가 여러 AWS 리전에 배포되고 능동적으로 트래픽을 처리합니다. 이 전략을 사용하려면 리전 전체에서 데이터를 동기화해야 합니다. 서로 다른 두 개 리전에 있는 복제본에 같은 레코드를 쓸 때 나타날 수 있는 충돌을 피하거나 처리해야 하는데, 그 방법이 복잡할 수 있습니다. 데이터 복제는 데이터 동기화에 유용하며 일부 유형의 재해로부터 보호해 주지만, 솔루션에 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다.
**참고**
파일럿 라이트와 웜 대기 간의 차이를 이해하기 어려울 수 있습니다. 둘 다 복구 리전에 속한 환경과 기본 리전 자산의 복사본을 포함합니다. 차이점은 파일럿 라이트의 경우 먼저 추가 조치를 취하지 않으면 요청을 처리할 수 없지만 웜 대기는 축소된 용량 수준으로 트래픽을 즉시 처리할 수 있다는 점입니다. 파일럿 라이트를 사용하려면 서버를 켜야 하고 코어 인프라가 아닌 인프라를 추가로 배포해야 할 수 있으며 스케일 업해야 합니다. 반면 웜 대기를 사용하려면 스케일 업만 하면 됩니다. 다른 것은 이미 모두 배포되고 실행되는 상태입니다. RTO 및 RPO 요구 사항에 따라 두 전략 중에서 선택하십시오.
**원하는 결과:**
각 워크로드에 대해 워크로드가 DR 목표를 달성하도록 하는 DR 전략이 정의되고 구현되어 있습니다. 워크로드 간의 DR 전략은 재사용 가능한 패턴(예: 이전에 설명한 전략)을 활용합니다.
**일반적인 안티 패턴:**
+ DR 목표가 유사한 워크로드에 일관적이지 않은 복구 절차를 구현함
+ 재해가 발생했을 때 DR 전략이 필요에 따라 구현되도록 함
+ DR 계획이 없음
+ 복구 시 컨트롤 플레인 작업에 의존함
**이 모범 사례 정립의 이점:**
+ 정의된 복구 전략을 사용하면 공통적인 도구 및 테스트 절차를 사용할 수 있습니다.
+ 복구 전략을 정의해 두면 팀 간에 지식을 더 효율적으로 공유하고, 팀에서 소유한 워크로드에 DR을 더 쉽게 구현할 수 있습니다.
**이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준:** 높음
+ DR 전략을 계획, 구현, 테스트하지 않으면 재해 발생 시 복구 목표를 달성하지 못할 가능성이 큽니다.
## 구현 가이드
각각의 단계에서 아래 세부 정보를 확인하세요.
1. 이 워크로드의 복구 요구 사항을 충족하는 DR 전략을 결정합니다.
1. 선택한 DR 전략이 구현될 수 있는 패턴을 검토합니다.
1. 워크로드의 리소스를 평가하고 장애 조치 전에(정상 작동 시) 복구 리전에서 워크로드 리소스의 구성을 평가합니다.
1. 필요할 경우 장애 조치 시(재해 이벤트 시) 복구 리전을 어떻게 준비할지 결정하고 구현합니다.
1. 필요할 경우 장애 조치 시(재해 이벤트 시) 트래픽을 장애 조치로 어떻게 다시 라우팅할지 결정하고 구현합니다.
1. 워크로드의 장애 복구를 위한 계획을 수립합니다.
**구현 단계**
1. **이 워크로드의 복구 요구 사항을 충족하는 DR 전략을 결정합니다.**
DR 전략을 선택할 때는 가동 중단 시간과 데이터 손실을 줄이는 것(RTO 및 RPO)과 전략 구현의 비용과 복잡성을 줄이는 것 사이에서 절충해야 합니다. 필요 이상으로 엄중한 전략을 구현하지 말아야 합니다. 불필요한 비용이 발생하기 때문입니다.
예를 들어, 다음 다이어그램에서 비즈니스는 허용 가능한 최대 RTO와 서비스 복원 전략에 지출할 수 있는 비용의 한계를 결정했습니다. 비즈니스의 목표를 감안할 때 파일럿 라이트 또는 웜 대기 DR 전략이 RTO와 비용 기준을 둘 다 만족시킵니다.
![\[RTO와 비용에 따라 DR 전략을 선택하는 것을 보여주는 그래프\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/choosing-a-dr-strategy.png)
자세한 내용은 다음을 참조하세요. [비즈니스 연속성 계획(BCP)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/business-continuity-plan-bcp.html).
1. **선택한 DR 전략이 구현될 수 있는 패턴을 검토합니다.**
이 단계는 선택한 전략을 구현하는 방법을 파악하기 위한 것입니다. 전략은 AWS 리전을 기본 사이트 및 복구 사이트로 사용하여 설명되어 있습니다. 그러나 하나의 리전 내에서 DR 전략으로 가용 영역을 선택할 수도 있습니다. 그런 경우 이런 전략 중 여러 개를 활용하게 됩니다.
이어지는 단계에서는 전략을 특정 워크로드에 적용합니다.
**백업 및 복구**
*백업 및 복구* 는 구현하기가 복잡하면서도 워크로드를 복원하는 데 더 많은 시간과 노력이 들어가 RTO와 RPO가 높아지는 전략입니다. 항상 데이터의 백업을 만들어 다른 사이트(예: 다른 AWS 리전)에 복사해 두는 것이 좋습니다.
![\[백업 및 복원 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/backup-restore-architecture.png)
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part II: Backup and Restore with Rapid Recovery(AWS에서의 재해 복구(DR) 아키텍처, 파트 II: 빠른 복구와 백업 및 복원)을 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
**파일럿 라이트**
파일럿 라이트 *접근법을 사용하면* 기본 리전의 데이터를 복구 리전에 복제합니다. 워크로드 인프라에 사용되는 코어 리소스가 복구 리전에 배포되지만 기능하는 스택이 되려면 기타 리소스 및 그 종속성이 여전히 필요합니다. 예를 들어 그림 20에서는 컴퓨팅 인스턴스가 배포되지 않았습니다.
![\[파일럿 라이트 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/pilot-light-architecture.png)
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby(AWS에서의 재해 복구(DR) 아키텍처, 파트 III: 파일럿 라이트 및 웜 대기)를 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**웜 대기**
유효 *웜 대기* 접근법에서는 스케일 다운되었지만 완전히 기능하는 프로덕션 환경의 복사본이 다른 리전에 복사됩니다. 이 접근법은 파일럿 라이트의 개념을 확대하고 복구 시간이 단축됩니다. 워크로드가 다른 리전에서 상시 실행되기 때문입니다. 복구 리전이 완전한 용량으로 배포되면 이것을 *상시 대기 방식이라고 합니다*.
![\[그림 21: 웜 대기 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/warm-standby-architecture.png)
웜 대기 또는 파일럿 라이트를 사용하려면 복구 리전에서 리소스를 스케일 업해야 합니다. 필요할 때 용량을 사용 가능하도록 하려면 [EC2 인스턴스의 용량 예약을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html) 사용하는 것을 고려하세요. AWS Lambda를 사용하는 경우 [프로비저닝된 동시성이](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) 함수의 호출에 즉시 응답하도록 실행 환경을 준비합니다.
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part III: Pilot Light and Warm Standby(AWS에서의 재해 복구(DR) 아키텍처, 파트 III: 파일럿 라이트 및 웜 대기)를 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
**복수 사이트 액티브/액티브**
워크로드를 *복수 사이트 액티브/액티브* 전략의 일부로 여러 리전에서 동시에 실행할 수 있습니다. 복수 사이트 액티브/액티브는 배포된 모든 리전에서 트래픽을 받습니다. 고객은 DR과 다른 이유를 이 전략을 선택할 수 있습니다. 이 전략은 가용성을 높이기 위해서 또는 글로벌 오디언스에게 워크로드를 배포하는 경우(사용자에게 엔드포인트를 가까이 가져가거나 해당 리전의 오디언스에게 현지화된 스택을 배포하기 위해) 사용될 수 있습니다. DR 전략으로, 워크로드가 배포된 AWS 리전 중 하나에서 지원되지 않는다면 해당 리전이 철수되며 가용성을 유지하는 데 나머지 리전이 사용됩니다. 복수 사이트 액티브/액티브는 DR 전략 중 운영 측면에서 가장 복잡하며 비즈니스 요구 사항에 따라 필요한 경우에만 선택해야 합니다.
![\[복수 사이트 액티브/액티브 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-site-active-active-architecture.png)
이 전략에 대한 자세한 내용은 [Disaster Recovery (DR) Architecture on AWS, Part IV: Multi-site Active/Active(AWS의 재해 복구(DR) 아키텍처, 파트 IV: 복수 사이트 액티브/액티브)를 참조하세요](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iv-multi-site-active-active/).
**데이터 보호를 위한 기타 관행**
모든 전략에서 데이터 재해를 완화해야 합니다. 지속적인 데이터 복제는 일부 유형의 재해로부터 보호해 주지만, 전략에 저장된 데이터의 버전 관리 또는 특정 시점 복구 옵션이 포함되지 않은 이상 데이터 손상 또는 중단으로부터 보호해 주지는 않습니다. 복구 사이트에서 복제된 데이터를 백업하여 복제본 외에도 특정 시점 백업을 생성해야 합니다.
**하나의 AWS 리전에서 여러 가용 영역(AZ) 사용**
하나의 리전에서 여러 개의 AZ를 사용하면 DR 구현에서 위 전략 중 여러 요소를 사용하게 됩니다. 먼저, 그림 23에서처럼 여러 개의 AZ를 사용하여 고가용성(HA) 아키텍처를 생성해야 합니다. 이 아키텍처는 [Amazon EC2 인스턴스와 마찬가지로 복수 사이트 액티브/액티브 접근법을 사용합니다.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-availability-zones) 및 [Elastic Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones) 는 여러 AZ에 배포되어 요청을 처리하는 리소스가 있습니다. 이 아키텍처는 상시 대기 방식도 보여주는데, 기본 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 인스턴스에 장애가 발생하면(또는 AZ 자체에 장애가 발생하면) 대기 인스턴스가 기본으로 승격됩니다.
![\[그림 23: 다중 AZ 아키텍처를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/wellarchitected/2022-03-31/framework/images/multi-az-architecture2.png)
이 HA 아키텍처 외에도 워크로드를 실행하는 데 필요한 모든 데이터의 백업을 추가해야 합니다. 이것은 하나의 영역에만 제한된 [Amazon EBS 볼륨](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volumes.html) 또는 [Amazon Redshift 클러스터와 같은 데이터에 특히 중요합니다](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html). AZ에 장애가 발생하면 이 데이터를 다른 AZ에 복원해야 합니다. 가능하다면 추가적인 보호 조치로 데이터 백업을 다른 AWS 리전에 복사해야 합니다.
단일 리전, 다중 AZ DR보다 일반적이지 않은 대안은 [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack(Amazon Route 53 Application Recovery Controller를 사용하여 복원력이 높은 애플리케이션 구축, 파트 1: 단일 리전 스택) 블로그 게시물에 설명되어 있습니다](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/). 여기에 나오는 전략은 리전의 작동 방식처럼 AZ 간에 가능한 한 많은 격리를 유지하기 위한 것입니다. 이 대안을 사용하면 액티브/액티브 또는 액티브/패시브 접근법 중에서 선택할 수 있습니다.
참고: 일부 워크로드에는 상주 요구 사항이 적용됩니다. 현재 하나의 AWS 리전만 있는 근처 워크로드에 상주 요구 사항이 적용되는 경우 복수 리전이 비즈니스 요구 사항에 적합하지 않을 수 있습니다. 다중 AZ 전략은 대부분의 재해로부터 안전하게 보호해 줍니다.
1. **워크로드의 리소스를 평가하고 장애 조치 전에(정상 작동 시) 복구 리전에서 워크로드 리소스의 구성을 평가합니다.**
인프라 및 AWS 리소스의 경우 [AWS CloudFormation](https://aws.amazon.com/cloudformation) 등의 코드형 인프라 또는 Hashicorp Terraform과 같은 서드 파티 도구를 사용하세요. 한 번의 작업으로 여러 개의 계정과 리전에 배포하려면 [AWS CloudFormation StackSets를 사용하면 됩니다](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html). 복수 사이트 액티브/액티브 및 상시 대기 방식 전략의 경우 복구 리전에 배포된 인프라의 리소스는 기본 리전의 리소스와 같습니다. 파일럿 라이트 및 웜 대기 전략의 경우 배포된 인프라가 프로덕션으로 사용되려면 추가 조치가 필요합니다. CloudFormation [파라미터](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/parameters-section-structure.html) 및 [조건부 로직을 사용하면](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/intrinsic-function-reference-conditions.html)배포된 스택이 액티브인지 대기인지 하나의 템플릿으로 제어할 수 있습니다. 그러한 CloudFormation 템플릿의 예시는 [이 블로그 게시물에 있습니다](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
모든 DR 전략에서 AWS 리전 내에 데이터 소스가 백업되어야 하며 그러한 백업은 복구 리전에 복사됩니다. [AWS Backup](https://aws.amazon.com/backup/) 은 해당 리소스의 백업을 구성, 예약, 모니터링할 수 있는 중앙 집중화된 보기를 제공합니다. 파일럿 라이트, 웜 대기, 복수 사이트 액티브/액티브의 경우 기본 리전의 데이터를 복구 리전의 [Amazon Relational Database Service(Amazon RDS)](https://aws.amazon.com/rds) DB 인스턴스 또는 [Amazon DynamoDB](https://aws.amazon.com/dynamodb) 테이블 등의 데이터 리소스에 복제해야 합니다. 그래야 이런 데이터 리소스가 복구 리전에서 실행되고 요청을 처리할 준비가 됩니다.
AWS 서비스가 전체 리전에서 작동하는 원리를 자세히 알아보려면 [AWS 서비스로 다중 리전 애플리케이션 생성 블로그 시리즈를 참조하세요](https://aws.amazon.com/blogs/architecture/tag/creating-a-multi-region-application-with-aws-services-series/).
1. **필요할 경우 장애 조치 시(재해 이벤트 시) 복구 리전을 어떻게 준비할지 결정하고 구현합니다.**
복수 사이트 액티브/액티브의 경우 장애 조치는 한 리전을 철수하고 나머지 액티브 리전에 의존하는 것입니다. 일반적으로 이러한 리전은 트래픽을 받을 준비가 되어 있습니다. 파일럿 라이트 및 웜 대기 전략의 경우 복구 조치로 그림 20의 EC2 인스턴스와 같은 누락된 리소스와 기타 누락된 리소스를 배포해야 합니다.
위에 설명된 모든 전략에서 데이터베이스의 읽기 전용 인스턴스를 기본 읽기/쓰기 인스턴스로 승격해야 합니다.
백업 및 복원의 경우 백업에서 데이터를 복원하면 해당 데이터에 대해 EBS 볼륨, RDS DB 인스턴스, DynamoDB 테이블 등의 리소스가 생성됩니다. 또한 인프라와 배포 코드를 복원해야 합니다. AWS Backup을 사용하여 복구 리전에서 데이터를 복원할 수 있습니다. 참조 [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md) 를 참조하세요. 인프라 재구축에는 필요한 [Amazon Virtual Private Cloud(Amazon VPC)](https://aws.amazon.com/vpc)서브넷 및 보안 그룹 외에도 EC2 인스턴스 등의 리소스를 생성하는 작업이 필요합니다. 이러한 복원 작업의 대부분은 자동화할 수 있습니다. 방법은 [이 블로그 게시물에 있습니다](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-ii-backup-and-restore-with-rapid-recovery/).
1. **필요할 경우 장애 조치 시(재해 이벤트 시) 트래픽을 장애 조치로 어떻게 다시 라우팅할지 결정하고 구현합니다.**
이 장애 조치 작업은 자동 또는 수동으로 시작할 수 있습니다. 상태 확인 또는 경보를 기반으로 자동으로 시작된 장애 조치는 신중하게 사용해야 합니다. 불필요한 장애 조치(거짓 경보)는 비가용성 및 데이터 손실과 같은 비용을 발생시키기 때문입니다. 따라서 수동으로 시작된 장애 조치를 자주 사용합니다. 이 경우, 버튼을 누르는 것처럼 수동으로 시작할 수 있도록 여전히 장애 조치를 위한 단계는 자동화해야 합니다.
AWS 서비스를 사용할 때는 몇 가지 트래픽 관리 옵션이 있습니다. 옵션 중 하나는 다음을 사용하는 것입니다. [Amazon Route 53](https://aws.amazon.com/route53). Amazon Route 53를 사용하면 하나 또는 그 이상의 AWS 리전에서 여러 개의 IP 엔드포인트를 하나의 Route 53 도메인 이름과 연결할 수 있습니다. 수동으로 시작된 장애 조치를 구현하기 위해서는 트래픽을 복구 리전으로 다시 라우팅하기 위해 가용성이 높은 데이터 영역 API를 제공하는 [Amazon Route 53 Application Recovery Controller를](https://aws.amazon.com/route53/application-recovery-controller/)사용할 수 있습니다. 장애 조치를 구현할 때 데이터 영역 작업을 사용하고 다음에 설명된 대로 컨트롤 플레인 작업은 피하세요 [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md).
이 옵션 및 다른 옵션에 대한 자세한 내용은 [재해 복구 백서의 이 섹션을 참조하세요](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html#pilot-light).
1. **워크로드의 장애 복구를 위한 계획을 수립합니다.**
장애 복구는 재해 이벤트가 수그러든 후 워크로드 작업을 기본 리전으로 돌려놓는 것입니다. 인프라 및 코드를 기본 리전에 프로비저닝하는 작업은 일반적으로 처음 사용된 것과 같은 단계를 따르며 코드형 인프라 및 코드 배포 파이프라인을 사용합니다. 장애 복구의 어려운 점은 데이터 스토어 복원과 작동하는 복구 리전에서 그 일관성을 확보하는 것입니다.
장애 조치된 상태에서는 복구 리전에서 데이터베이스가 실행되고 복구 리전에 최신 데이터가 있게 됩니다. 이때 목표는 복구 리전에서 기본 리전으로 재동기화하여 최신 상태를 확보하는 것입니다.
일부 AWS 서비스에서는 이 작업이 자동으로 이루어집니다. 만약 [Amazon DynamoDB 글로벌 테이블을](https://aws.amazon.com/dynamodb/global-tables/)사용한다면 기본 리전의 테이블을 사용할 수 없게 되어도 온라인 상태로 돌아오면 DynamoDB가 보류 중인 쓰기 작업의 전파를 재개합니다. 만약 [Amazon Aurora 글로벌 데이터베이스를](https://aws.amazon.com/rds/aurora/global-database/) 사용하고 [관리형 계획 장애 조치를](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database-disaster-recovery.html#aurora-global-database-disaster-recovery.managed-failover)사용한다면 Aurora 글로벌 데이터베이스의 기존 복제 토폴로지가 유지됩니다. 따라서 기본 리전에 있는 이전의 읽기/쓰기 인스턴스가 복제본이 되고 복구 리전에서 업데이트를 수신합니다.
이 작업이 자동화되지 않는 경우 기본 리전에서 복구 리전의 데이터베이스의 복제본으로 데이터베이스를 다시 구축해야 합니다. 이때 이전의 기본 데이터베이스가 삭제되고 새로운 복제본이 생성되는 경우가 많습니다. 예를 들어, 계획 장애 조치를 사용하는 Amazon Aurora 글로벌 데이터베이스에서 이 작업을 수행하는 방법을 *알아보려면* 다음 실습을 참조하세요. [글로벌 데이터베이스 장애 복구](https://awsauroralabsmy.com/global/failback/).
장애 조치 이후에 계속해서 복구 리전에서 실행이 가능하다면 이 리전을 새로운 기본 리전으로 만드는 것을 고려하세요. 이전의 기본 리전을 복구 리전으로 만들려면 위의 단계를 모두 따르면 됩니다. 일부 조직에서는 예약된 교체를 수행하여 기본 및 복구 리전을 주기적으로(예: 3개월마다) 교체합니다.
장애 조치 및 장애 복구가 필요한 모든 단계는 팀의 모든 멤버가 사용할 수 있는 플레이북에 유지 관리해야 하며 주기적으로 검토해야 합니다.
**구현 계획의 작업 수준:**높음
## 리소스
**관련 모범 사례:**
+ [REL09-BP01 백업해야 하는 모든 데이터 확인 및 백업 또는 소스에서 데이터 재현](rel_backing_up_data_identified_backups_data.md)
+ [REL11-BP04 복구 중 컨트롤 플레인이 아닌 데이터 영역 사용](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL13-BP01 가동 중단 시간 및 데이터 손실 시의 복구 목표 정의](rel_planning_for_recovery_objective_defined_recovery.md)
**관련 문서:**
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud(AWS에서 워크로드의 재해 복구: 클라우드에서의 복구)(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [클라우드에서의 재해 복구 옵션](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html)
+ [Build a serverless multi-region, active-active backend solution in an hour(한 시간 내에 서버리스 다중 리전, 활성/활성 백엔드 솔루션 구축)](https://read.acloud.guru/building-a-serverless-multi-region-active-active-backend-36f28bed4ecf)
+ [Multi-region serverless backend — reloaded(다중 리전 서버리스 백엔드 - 다시 로드됨)](https://medium.com/@adhorn/multi-region-serverless-backend-reloaded-1b887bc615c0)
+ [RDS: 리전 간 읽기 전용 복제본 복제](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.XRgn)
+ [Route 53: DNS 장애 조치 구성](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)
+ [S3: 리전 간 복제](https://docs.aws.amazon.com/AmazonS3/latest/dev/crr.html)
+ [AWS Backup란 무엇입니까?](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html)
+ [Route 53 Application Recovery Controller란 무엇입니까?](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [AWS Elastic Disaster Recovery](https://docs.aws.amazon.com/drs/latest/userguide/what-is-drs.html)
+ [HashiCorp Terraform: 시작하기 - AWS](https://learn.hashicorp.com/collections/terraform/aws-get-started)
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
**관련 동영상:**
+ [AWS에 있는 워크로드의 재해 복구](https://www.youtube.com/watch?v=cJZw5mrxryA)
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS Elastic Disaster Recovery 시작하기 \$1 Amazon Web Services](https://www.youtube.com/watch?v=GAMUCIJR5as)
**관련 예시:**
+ [AWS Well-Architected 실습 - 재해 복구](https://wellarchitectedlabs.com/reliability/disaster-recovery/) - DR 전략을 설명하는 워크숍 시리즈
# REL13-BP03 재해 복구 구현을 테스트하여 구현 확인
복구 사이트로의 장애 조치를 주기적으로 테스트하여 적절한 작업이 수행되고 RTO 및 RPO를 준수하는지 확인합니다.
거의 사용되지 않는 복구 경로를 개발하는 것은 피해야 할 패턴입니다. 읽기 전용 쿼리에 사용되는 보조 데이터 스토어를 예로 들 수 있습니다. 데이터 스토어에 데이터를 쓸 때 기본 스토어에서 장애가 발생하면 보조 데이터 스토어로 장애 조치를 진행할 수 있습니다. 이 장애 조치를 자주 테스트하지 않으면 보조 데이터 스토어의 기능에 대한 가정이 잘못될 수 있습니다. 예를 들어 마지막으로 테스트했을 때는 보조 용량이 충분했지만 이 시나리오에서는 더 이상 로드를 모두 처리하지 못할 수도 있습니다. 경험에 따르면 자주 테스트하는 경로만이 유일하게 작동하는 오류 복구 방법입니다. 이러한 이유로 인해 복구 경로를 적게 갖는 것이 가장 좋습니다. 복구 패턴을 설정하고 정기적으로 테스트할 수 있습니다. 복잡하거나 중요한 복구 경로가 있는 경우 해당 복구 경로의 작동을 확신하기 위해 프로덕션 환경에서 해당 장애를 정기적으로 수행해야 합니다. 앞에서 설명한 예의 경우에는 필요 여부에 관계없이 대기 스토어로 정기 장애 조치를 수행해야 합니다.
**일반적인 안티 패턴:**
+ 프로덕션 환경에서 장애 조치를 수행하지 않음
**이 모범 사례 수립의 이점:** 재해 복구 계획을 정기적으로 테스트하면 필요할 때 제대로 작동하도록 보장하고 팀이 전략 실행 방법을 숙지하고 있는지 확인할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 높음
## 구현 가이드
+ 복구가 가능하도록 워크로드를 설계합니다. 주기적으로 복구 경로를 테스트합니다. 복구 중심 컴퓨팅(ROC)은 복구를 개선하는 시스템의 특성을 식별합니다. 이러한 특성에는 격리 및 중복성, 변경 사항을 롤백하는 시스템 전체 기능, 상태 모니터링 및 확인 기능, 진단 제공 기능, 자동 복구, 모듈식 설계 및 재시작 기능이 포함됩니다. 지정된 시간에 지정한 상태로 복구를 수행할 수 있도록 복구 경로에 대해 실습하십시오. 이 복구 과정에 런북을 사용하여 문제를 문서화하고 다음 테스트 전에 해결 방법을 찾습니다.
+ [The Berkeley/Stanford recovery-oriented computing project(Berkeley/Stanford 복구 중심 컴퓨팅 프로젝트)](http://roc.cs.berkeley.edu/)
+ CloudEndure Disaster Recovery를 사용하여 DR 전략을 구현 및 테스트합니다.
+ [Testing the Disaster Recovery Solution with CloudEndure(CloudEndure를 통해 재해 복구 솔루션 테스트)](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [AWS로의 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
## 리소스
**관련 문서:**
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud(AWS에서 워크로드의 재해 복구: 클라우드에서의 복구)(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [Testing the Disaster Recovery Solution with CloudEndure(CloudEndure를 통해 재해 복구 솔루션 테스트)](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Testing_the_Distaster_Recovery_Solution/Testing_the_Disaster_Recovery_Solution.htm)
+ [The Berkeley/Stanford recovery-oriented computing project(Berkeley/Stanford 복구 중심 컴퓨팅 프로젝트)](http://roc.cs.berkeley.edu/)
+ [AWS Fault Injection Simulator란 무엇입니까?](https://docs.aws.amazon.com/fis/latest/userguide/what-is.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
+ [AWS re:Invent 2019: Backup-and-restore and disaster-recovery solutions with AWS(AWS의 백업 및 복원과 재해 복구 솔루션)(STG208)](https://youtu.be/7gNXfo5HZN8)
**관련 예시:**
+ [AWS Well-Architected 실습 - 복원력 테스트](https://wellarchitectedlabs.com/reliability/300_labs/300_testing_for_resiliency_of_ec2_rds_and_s3/)
# REL13-BP04 DR 사이트 또는 리전에서 구성 드리프트 관리
DR 사이트 또는 리전에 필요한 인프라, 데이터 및 구성이 갖추어져 있는지 확인합니다. 예를 들어 AMI와 Service Quotas가 최신 상태인지 확인합니다.
AWS Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록합니다. 이 서비스를 사용하면 드리프트를 감지하고, [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 을 트리거하여 드리프트를 수정한 후, 경보를 생성할 수 있습니다. AWS CloudFormation은 배포된 스택의 드리프트를 추가로 감지할 수 있습니다.
**일반적인 안티 패턴:**
+ 기본 위치에서 구성을 생성하거나 인프라를 변경할 때 복구 위치에서 업데이트에 실패함
+ 기본 및 복구 위치에서 잠재적 제한(예: 서비스의 차이)을 고려하지 않음
**이 모범 사례 수립의 이점:** DR 환경이 기존 환경과 일치하는지 확인하면 완전한 복구를 보장할 수 있습니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 배포 파이프라인이 기본 사이트와 백업 사이트 모두에 제공되는지 확인합니다. 애플리케이션을 프로덕션에 배포하기 위한 배포 파이프라인은 개발 및 테스트 환경을 포함하여 지정된 모든 재해 복구 전략 위치에 배포해야 합니다.
+ AWS Config를 활성화하여 잠재적 드리프트 위치를 추적합니다. AWS Config 규칙을 사용하여 재해 복구 전략을 실행하고 드리프트가 감지되면 알림을 생성하는 시스템을 구축합니다.
+ [AWS Config 규칙에 따른 규정 미준수 AWS 리소스 문제 해결](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ AWS CloudFormation을 사용하여 인프라를 배포합니다. AWS CloudFormation은 CloudFormation 템플릿에 명시된 내용과 실제로 배포된 항목 사이의 드리프트를 감지할 수 있습니다.
+ [AWS CloudFormation: 전체 CloudFormation 스택의 드리프트 감지](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
## 리소스
**관련 문서:**
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS CloudFormation: 전체 CloudFormation 스택의 드리프트 감지](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/detect-drift-stack.html)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS에서 워크로드의 재해 복구: 클라우드에서의 복구(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
+ [AWS에서 인프라 구성 관리 솔루션을 구현하려면 어떻게 해야 합니까?](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/?ref=wellarchitected)
+ [AWS Config 규칙에 따른 규정 미준수 AWS 리소스 문제 해결](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
**관련 동영상:**
+ [AWS re:Invent 2018: 다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴(ARC209-R2)](https://youtu.be/2e29I3dA8o4)
# REL13-BP05 복구 자동화
AWS 또는 서드 파티 도구를 사용하여 시스템 복구를 자동화하고 트래픽을 DR 사이트 또는 리전으로 라우팅합니다.
구성된 상태 확인에 따라 Elastic Load Balancing 및 AWS Auto Scaling과 같은 AWS 서비스를 사용하여 정상 상태인 가용 영역에 로드를 분산하고, Amazon Route 53 및 AWS Global Accelerator와 같은 서비스를 사용하여 정상 상태인 AWS 리전으로 로드를 라우팅할 수 있습니다. Amazon Route 53 Application Recovery Controller를 사용하면 준비 상태 확인 및 라우팅 제어 기능을 통해 장애 조치를 관리하고 조정할 수 있습니다. 이러한 기능은 애플리케이션의 장애 복구 성능을 지속적으로 모니터링하므로 이를 통해 여러 AWS 리전, 가용 영역 및 온프레미스에서 애플리케이션 복구를 제어할 수 있습니다.
기존의 물리적 또는 가상 데이터 센터 또는 프라이빗 클라우드의 워크로드의 경우 [AWS Elastic Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)를(AWS Marketplace를 통해 제공) 사용하면 조직에서 AWS에 자동화된 재해 복구 전략을 설정할 수 있습니다. CloudEndure는 AWS에서 교차 리전/교차 AZ 재해 복구도 지원합니다.
**일반적인 안티 패턴:**
+ 자동 장애 조치와 자동 장애 복구를 동일하게 구현하면 장애가 발생할 때 플래핑을 유발할 수 있습니다.
**이 모범 사례 수립의 이점:** 자동 복구는 수작업으로 인한 오류 발생 가능성을 없앰으로써 복구 시간을 단축합니다.
**이 모범 사례가 수립되지 않을 경우 노출되는 위험의 수준:** 보통
## 구현 가이드
+ 복구 경로를 자동화합니다. 짧은 복구 시간이 요구되는 고가용성 시나리오에서는 인간의 판단 및 수작업을 사용할 수 없습니다. 모든 상황에서 시스템이 자동으로 복구되어야 합니다.
+ 자동 장애 조치 및 장애 복구를 위해 CloudEndure Disaster Recovery를 사용합니다. CloudEndure Disaster Recovery는 시스템(운영 체제, 시스템 상태 구성, 데이터베이스, 애플리케이션 및 파일 포함)을 대상 AWS 계정과 원하는 리전의 저렴한 스테이징 영역으로 지속적으로 복제합니다. 재해가 발생할 경우 몇 분 만에 수천 대의 시스템을 자동으로 완전히 프로비저닝된 상태로 시작하도록 CloudEndure Disaster Recovery에 지시할 수 있습니다.
+ [Performing a Disaster Recovery Failover and Failback(재해 복구를 위한 조치 및 절차 수행)](https://docs.cloudendure.com/Content/Configuring_and_Running_Disaster_Recovery/Performing_a_Disaster_Recovery_Failover/Performing_a_Disaster_Recovery_Failover.htm)
+ [CloudEndure Disaster Recovery](https://aws.amazon.com/cloudendure-disaster-recovery/)
## 리소스
**관련 문서:**
+ [APN 파트너: 재해 복구를 지원할 수 있는 파트너](https://aws.amazon.com/partners/find/results/?keyword=Disaster+Recovery)
+ [AWS 아키텍처 블로그: 재해 복구 시리즈](https://aws.amazon.com/blogs/architecture/tag/disaster-recovery-series/)
+ [AWS Marketplace: 재해 복구에 사용할 수 있는 제품](https://aws.amazon.com/marketplace/search/results?searchTerms=Disaster+recovery)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS로의 CloudEndure Disaster Recovery](https://aws.amazon.com/marketplace/pp/B07XQNF22L)
+ [Disaster Recovery of Workloads on AWS: Recovery in the Cloud(AWS에서 워크로드의 재해 복구: 클라우드에서의 복구)(AWS 백서)](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
**관련 동영상:**
+ [AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications(다중 리전 액티브-액티브 애플리케이션을 위한 아키텍처 패턴)(ARC209-R2)](https://youtu.be/2e29I3dA8o4)