기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

엣지의 복원력

신뢰성 원칙은 워크로드가 의도한 기능을 예상대로 올바르고 일관되게 수행할 수 있는 능력을 포함합니다. 여기에는 수명 주기 동안 워크로드를 운영하고 테스트하는 기능이 포함됩니다. 이러한 의미에서 엣지에서 복원력이 뛰어난 아키텍처를 설계할 때는 먼저 해당 아키텍처를 배포하는 데 사용할 인프라를 고려해야 합니다. 다음 다이어그램과 같이 AWS 로컬 영역 Outpost에서 AWS Outposts Outpost로, Outpost에서 Local Zone으로, Local Zone에서 Local Zone으로 3가지 조합을 사용하여 구현할 수 있습니다. AWS 엣지 서비스를 기존 온프레미스 인프라 또는와 결합하는 등 복원력이 뛰어난 아키텍처에 대한 다른 가능성이 있지만 AWS 리전이 가이드는 하이브리드 클라우드 서비스 설계에 적용되는 이러한 세 가지 조합에 중점을 둡니다.

인프라 고려 사항

에서 서비스 설계의 핵심 원칙 AWS중 하나는 기본 물리적 인프라에서 단일 장애 지점을 방지하는 것입니다. 이 원칙 AWS 때문에 소프트웨어와 시스템은 여러 가용 영역을 사용하며 단일 영역의 장애에 대해 복원력이 있습니다. 엣지에서는 로컬 영역 및 Outpost를 기반으로 하는 인프라를 AWS 제공합니다. 따라서 인프라 설계의 복원력을 보장하는 중요한 요소는 애플리케이션의 리소스가 배포되는 위치를 정의하는 것입니다.

로컬 영역

로컬 영역은 서브넷 및 EC2 인스턴스와 같은 영역 AWS 리소스의 배치 위치로 선택할 수 AWS 리전있으므로 해당 영역 내의 가용 영역과 유사하게 작동합니다. 그러나 이들은에 위치하지 AWS 리전않고 현재 AWS 리전 존재하지 않는 대규모 인구, 산업 및 IT 센터에 가깝습니다. 그럼에도 불구하고 로컬 영역의 로컬 워크로드와에서 실행 중인 워크로드 간에 높은 대역폭의 보안 연결을 유지합니다 AWS 리전. 따라서 지연 시간이 짧은 요구 사항을 위해 로컬 영역을 사용하여 사용자에게 더 가깝게 워크로드를 배포해야 합니다.

Outpost

AWS Outposts 는 AWS 인프라, AWS 서비스, APIs 및 도구를 데이터 센터로 확장하는 완전관리형 서비스입니다. 에서 사용되는 것과 동일한 하드웨어 인프라 AWS 클라우드 가 데이터 센터에 설치됩니다. 그런 다음 Outpost가 가장 가까운에 연결됩니다 AWS 리전. Outposts를 사용하여 지연 시간이 짧거나 로컬 데이터 처리 요구 사항이 있는 워크로드를 지원할 수 있습니다.

상위 가용 영역

각 로컬 영역 또는 Outpost에는 상위 리전(홈 리전이라고도 함)이 있습니다. 상위 리전은 AWS 엣지 인프라(Outpost 또는 로컬 영역)의 컨트롤 플레인이 고정되는 곳입니다. 로컬 영역의 경우 상위 리전은 로컬 영역의 기본 아키텍처 구성 요소이며 고객이 수정할 수 없습니다.는 온프레미스 환경 AWS 클라우드 으로 AWS Outposts 확장되므로 주문 프로세스 중에 특정 리전 및 가용 영역을 선택해야 합니다. 이 선택은 Outpost 배포의 컨트롤 플레인을 선택한 AWS 인프라에 고정합니다.

엣지에서 고가용성 아키텍처를 개발하는 경우 VPC를 확장할 수 있도록 Outpost 또는 로컬 영역과 같은 이러한 인프라의 상위 리전이 동일해야 합니다. 이 확장 VPC는 이러한 고가용성 아키텍처를 생성하기 위한 기반입니다. 복원력이 뛰어난 아키텍처를 정의할 때는 상위 리전과 서비스가 고정될(또는 고정될) 리전의 가용 영역을 검증해야 합니다. 다음 다이어그램에 설명된 대로 두 Outpost 사이에 고가용성 솔루션을 배포하려면 두 개의 서로 다른 가용 영역을 선택하여 Outpost를 고정해야 합니다. 이를 통해 컨트롤 플레인 관점에서 다중 AZ 아키텍처를 사용할 수 있습니다. 하나 이상의 로컬 영역을 포함하는 고가용성 솔루션을 배포하려면 먼저 인프라가 고정되는 상위 가용 영역을 검증해야 합니다. 이를 위해 다음 명령을 사용합니다 AWS CLI .

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

이전 명령의 출력:

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

이 예제에서는 마이애미 로컬 영역(us-east-1d-mia-1a1)이 us-east-1d-az2 가용 영역에 고정되어 있습니다. 따라서 엣지에서 복원력이 뛰어난 아키텍처를 생성해야 하는 경우 보조 인프라(Outpost 또는 로컬 영역)가 이외의 가용 영역에 고정되어 있는지 확인해야 합니다us-east-1d-az2. 예를 들어 us-east-1d-az1는 유효합니다.

다음 다이어그램은 가용성이 높은 엣지 인프라의 예를 제공합니다.

네트워킹 고려 사항

이 섹션에서는 엣지에서의 네트워킹, 주로 엣지 인프라에 액세스하기 위한 연결에 대한 초기 고려 사항을 설명합니다. 서비스 링크에 복원력이 뛰어난 네트워크를 제공하는 유효한 아키텍처를 검토합니다.

로컬 영역에 대한 복원력 네트워킹

로컬 영역은 Amazon S3 및 Amazon RDS와 같은 모든 리전 서비스를 원활하게 사용할 수 있는 여러 개의 안전하고 중복된 고속 링크를 통해 상위 리전에 연결됩니다. 온프레미스 환경 또는 사용자에서 로컬 영역으로의 연결을 제공할 책임은 사용자에게 있습니다. 선택한 연결 아키텍처(예: VPN 또는 AWS Direct Connect)에 관계없이 기본 링크에서 장애가 발생할 경우 애플리케이션 성능에 영향을 주지 않도록 네트워크 링크를 통해 달성해야 하는 지연 시간은 동일해야 합니다. AWS Direct Connect를 사용하는 경우 해당 복원력 아키텍처는 AWS Direct Connect 복원력 권장 사항에 설명된 AWS 리전대로에 액세스하기 위한 아키텍처와 동일합니다. 그러나 대부분의 경우 국제 로컬 영역에 적용되는 시나리오가 있습니다. 로컬 영역이 활성화된 국가에서는 단일 AWS Direct Connect PoP만 있으면 AWS Direct Connect 복원력에 권장되는 아키텍처를 생성할 수 없습니다. 단일 AWS Direct Connect 위치에만 액세스할 수 있거나 단일 연결 이상의 복원력이 필요한 경우 AWS 블로그 게시물 온프레미스에서 로 고가용성 연결 활성화에 설명된 AWS Direct Connect대로 Amazon EC2에서 VPN 어플라이언스를 생성할 수 있습니다. AWS 로컬 영역

Outposts의 복원력 네트워킹

로컬 영역과 달리 Outposts에는 로컬 네트워크에서 Outposts에 배포된 워크로드에 액세스하기 위한 중복 연결이 있습니다. 이 중복성은 두 개의 Outpost 네트워크 디바이스(ONDs. 각 OND에는 로컬 네트워크에 대한 1Gbps, 10Gbps, 40Gbps 또는 100Gbps의 광섬유 연결이 두 개 이상 필요합니다. 이러한 연결은 더 많은 링크를 확장 가능하게 추가할 수 있도록 링크 집계 그룹(LAG)으로 구성해야 합니다.

이 연결에 대한 자세한 내용은 AWS Outposts 설명서의 Outpost 랙에 대한 로컬 네트워크 연결을 참조하세요.

최적의 경험과 복원력을 위해는에 대한 서비스 링크 연결에 최소 500Mbps(1Gbps가 더 좋음)의 중복 연결을 사용할 것을 AWS권장합니다 AWS 리전. 서비스 링크에 AWS Direct Connect 또는 인터넷 연결을 사용할 수 있습니다. 이 최소값을 사용하면 EC2 인스턴스를 시작하고, EBS 볼륨을 연결하고, Amazon EKS AWS 서비스, Amazon EMR 및 CloudWatch 지표와 같은 액세스를 수행할 수 있습니다.

다음 다이어그램은 고가용성 프라이빗 연결을 위한이 아키텍처를 보여줍니다.

다음 다이어그램은 고가용성 퍼블릭 연결을 위한이 아키텍처를 보여줍니다.

ACE 랙을 사용하여 Outpost 랙 배포 규모 조정

집계, 코어, 엣지(ACE) 랙은 AWS Outposts 다중 랙 배포에 중요한 집계 지점 역할을 하며, 랙 3개를 초과하는 설치 또는 향후 확장 계획에 주로 권장됩니다. 각 ACE 랙에는 10Gbps, 40Gbps 및 100Gbps 연결을 지원하는 4개의 라우터가 있습니다(100Gbps가 최적임). 각 랙은 최대 4개의 업스트림 고객 디바이스에 연결하여 중복성을 극대화할 수 있습니다. ACE 랙은 최대 10kVA의 전력을 소비하고 최대 705파운드의 무게를 갖습니다. 주요 이점으로는 물리적 네트워킹 요구 사항 감소, 광섬유 케이블 업링크 감소, VLAN 가상 인터페이스 감소 등이 있습니다.는 VPN 터널을 통해 원격 측정 데이터를 통해 이러한 랙을 AWS 모니터링하고 설치 중에 고객과 긴밀하게 협력하여 적절한 전력 가용성, 네트워크 구성 및 최적의 배치를 보장합니다. ACE 랙 아키텍처는 배포 규모에 따라 가치를 높이고 연결을 효과적으로 간소화하는 동시에 대규모 설치에서 복잡성과 물리적 포트 요구 사항을 줄입니다.  자세한 내용은 AWS 블로그 게시물 Scaling AWS Outposts rack deployments with ACE Rack을 참조하세요.

Outpost 및 로컬 영역에 인스턴스 배포

Outpost와 로컬 영역에는 컴퓨팅 서버 수가 한정되어 있습니다. 애플리케이션이 여러 관련 인스턴스를 배포하는 경우 이러한 인스턴스는 다르게 구성되지 않는 한 동일한 서버 또는 동일한 랙의 서버에 배포될 수 있습니다. 기본 옵션 외에도 서버 간에 인스턴스를 분산하여 동일한 인프라에서 관련 인스턴스를 실행할 위험을 완화할 수 있습니다. 파티션 배치 그룹을 사용하여 여러 랙에 인스턴스를 배포할 수도 있습니다. 이를 스프레드 랙 분산 모델이라고 합니다. 자동 배포를 사용하여 그룹의 파티션 간에 인스턴스를 분산하거나 선택한 대상 파티션에 인스턴스를 배포합니다. 대상 파티션에 인스턴스를 배포하면 선택한 리소스를 동일한 랙에 배포하는 동시에 다른 리소스를 랙에 배포할 수 있습니다. 또한 Outposts는 호스트 수준에서 워크로드를 분산할 수 있는 분산 호스트라는 또 다른 옵션을 제공합니다. 다음 다이어그램은 스프레드 랙 및 스프레드 호스트 배포 옵션을 보여줍니다.

의 Amazon RDS 다중 AZ AWS Outposts

Outposts에서 다중 AZ 인스턴스 배포를 사용하는 경우 Amazon RDS는 두 Outposts에 두 개의 데이터베이스 인스턴스를 생성합니다. 각 Outpost는 자체 물리적 인프라에서 실행되며 고가용성을 위해 리전의 여러 가용 영역에 연결됩니다. 고객 관리형 로컬 연결을 통해 두 개의 Outpost가 연결되면 Amazon RDS는 기본 데이터베이스 인스턴스와 대기 데이터베이스 인스턴스 간의 동기식 복제를 관리합니다. 소프트웨어 또는 인프라에 장애가 발생하는 경우 Amazon RDS는 자동으로 대기 인스턴스를 기본 역할로 승격하고 DNS 레코드를 업데이트하여 새 기본 인스턴스를 가리킵니다. 다중 AZ 배포의 경우 Amazon RDS는 하나의 Outpost에 기본 DB 인스턴스를 생성하고 다른 Outpost에 있는 대기 DB 인스턴스에 데이터를 동기식으로 복제합니다. Outposts의 다중 AZ 배포는의 다중 AZ 배포 AWS 리전와 같이 작동하지만 다음과 같은 차이점이 있습니다.

Amazon RDS on Outposts에서 지원되는 모든 버전의 MySQL 및 PostgreSQL에 다중 AZ 배포를 사용할 수 있습니다. 다중 AZ 배포에는 로컬 백업이 지원되지 않습니다.

다음 다이어그램은 Amazon RDS on Outposts 다중 AZ 구성의 아키텍처를 보여줍니다.

장애 조치 메커니즘

로드 밸런싱 및 자동 조정

Elastic Load Balancing(ELB)은 실행 중인 모든 EC2 인스턴스에 수신 애플리케이션 트래픽을 자동으로 분산합니다. ELB는 단일 인스턴스가 압도되지 않도록 트래픽을 최적으로 라우팅하여 수신 요청을 관리하는 데 도움이 됩니다. Amazon EC2 Auto Scaling 그룹에서 ELB를 사용하려면 Auto Scaling 그룹에 로드 밸런서를 연결합니다. 이렇게 하면 그룹으로 들어오는 모든 웹 트래픽에 대한 단일 연락 지점 역할을 하는 로드 밸런서에 그룹이 등록됩니다. Auto Scaling 그룹에서 ELB를 사용하는 경우 로드 밸런서에 개별 EC2 인스턴스를 등록할 필요가 없습니다. Auto Scaling 그룹에서 시작되는 인스턴스가 로드 밸런서에 자동으로 등록됩니다. 마찬가지로 Auto Scaling 그룹에 의해 종료된 인스턴스는 로드 밸런서에서 자동으로 등록 취소됩니다. Auto Scaling 그룹에 로드 밸런서를 연결한 후 ELB 지표(예: 대상당 Application Load Balancer 요청 수)를 사용하여 수요 변동에 따라 그룹의 인스턴스 수를 조정하도록 그룹을 구성할 수 있습니다. 선택적으로 Amazon EC2 Auto Scaling이 이러한 상태 확인을 기반으로 비정상 인스턴스를 식별하고 교체할 수 있도록 Auto Scaling 그룹에 ELB 상태 확인을 추가할 수 있습니다. 대상 그룹의 정상 호스트 수가 허용보다 낮은 경우 알려주는 Amazon CloudWatch 경보를 생성할 수도 있습니다.

다음 다이어그램은 Application Load Balancer가에서 Amazon EC2의 워크로드를 관리하는 방법을 보여줍니다 AWS Outposts.

다음 다이어그램은 로컬 영역의 Amazon EC2에 대한 유사한 아키텍처를 보여줍니다.

DNS 장애 조치를 위한 Amazon Route 53

여러 HTTP 또는 메일 서버와 같이 동일한 기능을 수행하는 리소스가 두 개 이상 있는 경우 Amazon Route 53을 구성하여 리소스의 상태를 확인하고 정상 리소스만 사용하여 DNS 쿼리에 응답할 수 있습니다. 예를 들어 웹 사이트 example.com가 두 서버에서 호스팅된다고 가정해 보겠습니다. 한 서버는 로컬 영역에 있고 다른 서버는 Outpost에 있습니다. 해당 서버의 상태를 확인하고 현재 정상 상태인 서버만 사용하여에 대한 DNS 쿼리example.com에 응답하도록 Route 53를 구성할 수 있습니다. 별칭 레코드를 사용하여 ELB 로드 밸런서와 같은 선택한 AWS 리소스로 트래픽을 라우팅하는 경우 리소스의 상태를 평가하고 정상인 리소스로만 트래픽을 라우팅하도록 Route 53을 구성할 수 있습니다. 리소스의 상태를 평가하도록 별칭 레코드를 구성할 때 해당 리소스에 대한 상태 확인을 생성할 필요가 없습니다.

다음 다이어그램은 Route 53 장애 조치 메커니즘을 보여줍니다.

Amazon Route 53 Resolver 의 AWS Outposts

Amazon Route 53 Resolver는 Outpost 랙에서 사용할 수 있습니다. Outposts에서 직접 로컬 DNS 확인을 온프레미스 서비스 및 애플리케이션에 제공합니다. 로컬 Route 53 Resolver 엔드포인트를 사용하면 Outposts와 온프레미스 DNS 서버 간의 DNS 확인도 가능합니다. Outposts의 Route 53 Resolver는 온프레미스 애플리케이션의 가용성과 성능을 개선하는 데 도움이 됩니다.

Outposts의 일반적인 사용 사례 중 하나는 공장 장비, 고주파 거래 애플리케이션 및 의료 진단 시스템과 같은 온프레미스 시스템에 대한 지연 시간이 짧은 액세스가 필요한 애플리케이션을 배포하는 것입니다.

Outposts에서 로컬 Route 53 Resolver를 사용하도록 옵트인하면 상위 항목에 대한 연결이 AWS 리전 끊어지더라도 애플리케이션 및 서비스는 로컬 DNS 확인의 이점을 계속 누릴 수 있습니다. 또한 로컬 해석기는 쿼리 결과가 Outpost에서 로컬로 캐싱되고 제공되므로 DNS 확인 지연 시간을 줄이는 데 도움이 되므로 상위 항목으로의 불필요한 왕복이 제거됩니다 AWS 리전. 프라이빗 DNS를 사용하는 Outposts VPCs의 애플리케이션에 대한 모든 DNS 확인은 로컬에서 제공됩니다. https://docs.aws.amazon.com/managedservices/latest/userguide/set-dns.html

이 시작은 로컬 해석기를 활성화하는 것 외에도 로컬 해석기 엔드포인트도 활성화합니다. Route 53 Resolver 아웃바운드 엔드포인트를 사용하면 Route 53 Resolver가 온프레미스 네트워크와 같이 관리하는 DNS 해석기에 DNS 쿼리를 전달할 수 있습니다. 반대로 Route 53 Resolver 인바운드 엔드포인트는 VPC 외부에서 수신한 DNS 쿼리를 Outposts에서 실행 중인 Resolver로 전달합니다. 이를 통해 VPC 외부에서 프라이빗 Outposts VPC에 배포된 서비스에 대한 DNS 쿼리를 전송할 수 있습니다. 인바운드 및 아웃바운드 엔드포인트에 대한 자세한 내용은 Route 53 설명서의 VPCs와 네트워크 간의 DNS 쿼리 해결을 참조하세요.