REL10-BP01 워크로드를 여러 위치에 배포
워크로드 데이터와 리소스를 여러 가용 영역에 분산하거나 필요한 경우 AWS 리전 전체에 분산합니다. 필요에 따라 이러한 위치는 다양할 수 있습니다.
AWS의 서비스 설계 관련 기본 원칙 중 하나는 기본 물리적 인프라에서 단일 장애 지점이 없어야 한다는 것입니다. 이 원칙을 준수하려면 가용 영역 여러 개를 사용하며 단일 영역에서 장애가 발생해도 복원이 가능한 소프트웨어와 시스템을 빌드해야 합니다. 마찬가지로, 시스템은 단일 컴퓨팅 노드, 단일 스토리지 볼륨 또는 단일 데이터베이스 인스턴스에서 장애가 발생하더라도 복원 가능하도록 구축됩니다. 중복 구성 요소를 사용하는 시스템을 구축할 때는 구성 요소가 독립적(AWS 리전의 경우 자율적)으로 작동해야 합니다. 중복 구성 요소를 사용한 이론적 가용성 계산에서 얻을 수 있는 이점은 이것이 사실인 경우에만 유효합니다.
가용 영역
AWS 리전은 서로 독립적으로 설계된 여러 가용 영역으로 구성됩니다. 화재, 홍수, 태풍 등의 자연 재해로 인한 상관 장애 시나리오를 방지하기 위해 각 가용 영역은 서로 멀리 떨어져 있도록 분리됩니다(물리적으로 합리적인 거리). 또한 각 가용 영역에는 독립된 물리적 인프라(다목적 전원에 대한 전용 연결, 대기 백업 전원, 독립 기계 서비스, 가용 영역 내부 및 외부의 독립된 네트워크 연결)가 포함되어 있습니다. 이 설계는 이 시스템 중 하나에서 발생한 장애가 영향을 받은 하나의 가용 영역에만 국한되도록 합니다. 가용 영역은 지리적으로는 분리되지만 같은 지역에 배치되어 높은 처리량과 낮은 지연 시간의 네트워킹이 가능합니다. 동기식으로 데이터를 복제하는 등(예: 데이터베이스 간에) 전체 AWS 리전(여러 개의 물리적으로 독립적인 데이터 센터로 구성된 모든 가용 영역에 위치함)을 워크로드에 대한 하나의 논리적 배포 대상으로 취급할 수 있습니다. 그러면 액티브/액티브 또는 액티브/대기 구성에서 가용 영역을 사용할 수 있습니다.
가용 영역은 독립적이므로 여러 영역을 사용하도록 워크로드를 설계하면 워크로드 가용성이 향상됩니다. Amazon EC2 인스턴스 데이터 영역을 비롯한 일부 AWS 서비스는 엄격한 영역 서비스로 배포되며, 전체 가용 영역과 동일한 상태로 설정됩니다. 하지만 다른 AZ의 Amazon EC2 인스턴스는 영향을 받지 않고 계속 작동합니다. 마찬가지로, 한 가용 영역에서의 장애로 인해 Amazon Aurora 데이터베이스에 장애가 발생하면 영향을 받지 않은 AZ에 있는 읽기 전용 복제본 Aurora 인스턴스가 자동으로 기본으로 승격될 수 있습니다. 반면 Amazon DynamoDB 등의 리전별 AWS 서비스는 사용자가 AZ 배치를 구성할 필요 없이 해당 서비스에 설정된 가용성 설계 목표를 달성하기 위해 내부적으로 액티브/액티브 구성에서 여러 가용 영역을 사용합니다.
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 리전은 자율적으로 작동하도록 설계되므로 다중 리전 접근 방식을 사용하려면 각 리전에 서비스의 전용 복사본을 배포해야 합니다.
다중 리전 접근법은 일회성의 대규모 이벤트가 발생할 때 복구 목표를 달성하기 위한 재해 복구 전략에 자주 사용됩니다. 이러한 전략에 대한 자세한 내용은 재해 복구(DR) 계획을 참조하세요. 그러나 여기에서는 시간 경과에 따라 평균 가동 시간 목표를 달성하는 가용성에 초점을 맞춥니다. 고가용성 목표를 위해 다중 리전 아키텍처가 일반적으로 액티브/액티브로 설계됩니다. 이때 각 서비스 복사본은 각각의 리전에서 활성 상태(요청을 지원함)입니다.
권장 사항
단일 AWS 리전 안에서 다중 AZ 전략을 사용하여 워크로드에 대한 대부분의 가용성 목표를 충족할 수 있습니다. 워크로드에서 가용성 요구 사항이 매우 높은 경우 또는 다중 리전 아키텍처를 요구하는 다른 비즈니스 목표가 있는 경우에만 다중 리전 아키텍처를 고려합니다.
AWS에서는 리전 간 서비스를 운영할 수 있는 기능을 제공합니다. 예를 들어, AWS는 Amazon Simple Storage Service(S3) 복제본, Amazon RDS 읽기 전용 복제본(Aurora 읽기 전용 복제본 포함), Amazon DynamoDB 글로벌 테이블을 사용하여 지속적인 비동기식 데이터 복제를 제공합니다. 지속적인 복제를 통해 각 액티브 리전에서 거의 즉각적으로 데이터의 버전을 사용할 수 있습니다.
AWS CloudFormation을 사용하면 인프라를 정의하고 AWS 계정 및 AWS 리전에서 일관적으로 배포할 수 있습니다. 또한 AWS CloudFormation StackSets는 한 번의 작업으로 여러 계정과 리전에 AWS CloudFormation 스택을 생성, 업데이트 또는 삭제할 수 있도록 이 기능을 확장합니다. Amazon EC2 인스턴스 배포의 경우 Amazon Machine Image(AMI)를 사용하여 하드웨어 구성 및 설치된 소프트웨어 같은 정보를 제공합니다. Amazon EC2 Image Builder 파이프라인을 구현하여 필요한 AMI를 생성하고 액티브 리전에 복사할 수 있습니다. 그렇게 하면 새로운 각 리전에 워크로드를 배포하고 스케일 아웃하는 데 필요한 모든 요소가 이 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에 연결되지 않은 경우)가 포함됩니다.
-
-
컨테이너, 인스턴스 및 함수 기반 워크로드를 여러 가용 영역에 배포합니다. 캐시를 비롯한 다중 영역 데이터 스토어를 사용합니다. ElastiCache 클러스터, VPC에서 실행할 때 AWS Lambda 함수 구성, Amazon EC2 작업, Amazon EC2 Auto Scaling의 기능을 사용합니다.
-
Auto Scaling 그룹을 배포할 때는 서로 다른 가용 영역에 있는 서브넷을 사용합니다.
-
ECS 작업 배치 파라미터를 사용하여 DB 서브넷 그룹을 지정합니다.
-
VPC에서 실행할 기능을 구성할 때 여러 가용 영역의 서브넷을 사용합니다.
-
ElastiCache 클러스터를 통해 여러 가용 영역을 사용합니다.
-
-
-
워크로드를 여러 리전에 배포해야 하는 경우 다중 리전 전략을 선택합니다. 단일 AWS 리전 내에서 다중 가용 영역 전략을 사용하여 대부분의 신뢰성 요구 사항을 충족할 수 있습니다. 비즈니스 요구 사항을 충족하는 데 필요한 경우 다중 리전 전략을 사용합니다.
-
AWS re:Invent 2018: Architecture Patterns for Multi-Region Active-Active Applications (ARC209-R2)
-
다른 AWS 리전으로 백업하면 필요할 때 데이터를 사용할 수 있다는 보장이 추가됩니다.
-
일부 워크로드의 경우 규제 요건에 따라 다중 리전 전략을 사용해야 합니다.
-
-
-
워크로드에 대해 AWS Outposts를 평가합니다. 온프레미스 데이터 센터에 대한 지연 시간이 짧아야 하거나 로컬 데이터 처리 요구 사항을 충족해야 하는 워크로드의 경우 AWS Outposts를 사용하여 온프레미스에서 AWS 인프라와 서비스를 실행합니다.
-
AWS 로컬 영역이 사용자에게 서비스를 제공하는 데 도움이 되는지 확인합니다. 짧은 지연 시간에 대한 요구 사항이 있는 경우 AWS 로컬 영역이 사용자 근처에 있는지 확인합니다. 그렇다면 이를 사용하여 해당 사용자에게 더 가까운 위치에 워크로드를 배포합니다.
리소스
관련 문서:
관련 비디오: