기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 더 큰 장애 모드
랙, 데이터 센터, 가용 영역(AZ) 또는 리전 장애와 같은 더 큰 장애 모드를 완화하도록 고가용성 아키텍처를 설계하려면 독립된 전원 및 WAN 연결을 갖춘 별도의 데이터 센터에 충분한 인프라 용량을 갖춘 여러 Outpost를 배포해야 합니다. Outpost를 한 AWS 리전 또는 여러 리전의 서로 다른 가용 영역(AZ) 에 고정합니다. 또한 동기식 또는 비동기식 데이터 복제와 워크로드 트래픽 리디렉션을 지원하려면 위치 간에 복원력이 뛰어나며 충분한 사이트 간 연결을 프로비저닝해야 합니다. 애플리케이션 아키텍처에 따라 전역적으로 사용 가능한 [Amazon Route 53](https://aws.amazon.com/route53/) DNS 및 [Outposts의 Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/outpost-resolver.html)을 사용하여 트래픽을 원하는 위치로 보내고 대규모 장애 발생 시 남은 위치로의 트래픽 리디렉션을 자동화할 수 있습니다.
# Outpost 랙 VPC 내 라우팅
AWS Outposts 랙은 [여러 Outpost에서 VPC 내 통신을](https://aws.amazon.com/blogs/compute/introducing-intra-vpc-communication-across-multiple-outposts-with-direct-vpc-routing/) 지원합니다. 두 개의 개별 논리적 Outpost에 있는 리소스는 Outpost 로컬 게이트웨이(LGW)를 사용하여 서로 분산된 동일한 VPC 내의 서브넷 간에 트래픽을 라우팅하여 서로 통신할 수 있습니다. 여러 Outpost에서 VPC 내 통신을 사용하면 로컬 LGW를 다음 홉으로 사용하여 다른 Outposts 서브넷에 보다 구체적인 경로를 추가하여 Outposts 서브넷 관련 라우팅 테이블의 로컬 라우팅을 재정의할 수 있습니다. 두 Outpost [랙 또는 Amazon EKS 클러스터에서 Amazon ECS](https://community.aws/content/2k5wK9P1oSC9I4ZzuSLWynsiJaa/extend-amazon-ecs-across-two-outposts-racks)로 두 논리적 Outpost 간에 VPC를 확장해야 하는 애플리케이션을 설계하는 데 이점을 제공할 수 있습니다. [AWS Outposts](https://aws.amazon.com/blogs/containers/deploy-an-amazon-eks-cluster-across-aws-outposts-with-intra-vpc-communication/)
![\[여러 논리적 Outpost가 있는 단일 VPC의 네트워크 경로를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-49-single-vpc-multiple-outposts.png)
리전Outposts-to-Outposts 트래픽 라우팅은 안티 패턴이므로 차단됩니다. 이러한 트래픽에는 고객 WAN을 통해 트래픽을 라우팅하는 것보다 양방향으로 송신 요금이 발생하고 지연 시간이 훨씬 길어집니다.
# Outpost 랙 VPC 간 라우팅
서로 다른 VPCs에 배포된 두 개의 개별 Outpost에 있는 리소스는 고객 네트워크를 통해 서로 통신할 수 있습니다. 이 아키텍처를 배포하면 로컬 온프레미스 및 WAN 네트워크를 통해 트래픽 Outposts-to-Outposts를 라우팅하여 대응 Outposts/VPC 서브넷으로 라우팅할 수 있습니다.
![\[여러 논리적 Outpost가 있는 여러 VPC의 네트워크 경로를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-50-multiple-vpc-multiple-outposts-networking-path.png)
더 큰 장애 모드로부터 보호하기 위한 권장 방법:
+ 여러 AZ와 리전에 고정된 여러 Outpost를 배포합니다.
+ 다중 Outpost 배포에서는 각 Outpost에 대해 별도의 VPC를 사용합니다.
# Outposts의 Route 53 Local Resolver
AWS Outposts 서비스 링크가 임시 연결 해제의 영향을 받으면 로컬 DNS 확인이 실패하여 애플리케이션과 서비스가 동일한 Outpost 랙에서 실행 중인 경우에도 다른 서비스를 검색하기가 어렵습니다. 그러나 Route 53 Resolver를 켜면 상위에 대한 연결이 끊긴 경우에도 AWS Outposts애플리케이션 및 서비스는 로컬 DNS 확인의 이점을 계속 누릴 수 있습니다 AWS 리전. 동시에 온프레미스 호스트 이름에 대한 DNS 확인을 위해 Outposts의 Route 53 Resolver는 쿼리 결과가 로컬로 캐시되고 제공되면서 지연 시간을 줄이는 동시에 Route 53 Resolver 엔드포인트와 완전히 통합됩니다.
Route 53 해석기 인바운드 엔드포인트는 VPC 외부에서 수신한 DNS 쿼리를 Outposts에서 실행되는 해석기로 전달합니다. 반대로 Route 53 Resolver 아웃바운드를 사용하면 다음 다이어그램과 같이 Route 53 Resolver가 온프레미스 네트워크에서 관리하는 DNS 해석기에 DNS 쿼리를 전달할 수 있습니다.
![\[Outposts의 Route 53 해석기를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-51-route53-resolver-outposts.png)
## Outposts의 Route 53 Resolver 고려 사항
다음을 고려하세요.
+ Outposts에서 Route 53 Resolver를 활성화해야 하며, 단일 Outposts ID로 여러 컴퓨팅 랙을 포함하는 경우에도 전체 Outposts 배포에 적용됩니다.
+ 이 기능을 활성화하려면 Outposts에 c5.xlarge, m5.large 또는 m5.xlarge의 EC2 인스턴스 4개 이상의 형태로 로컬 해석기를 배포할 수 있는 충분한 컴퓨팅 용량이 있어야 합니다.
+ 프라이빗 DNS를 사용하는 경우 필요한 Outposts VPCs와 프라이빗 호스팅 영역을 공유해야 Outposts의 Route 53 Resolver에서 레코드를 로컬로 캐싱할 수 있습니다.
+ 온프레미스 DNS와 인바운드 및 아웃바운드 엔드포인트의 통합을 활성화하려면 Outposts에 Route53 엔드포인트당 2개의 EC2 인스턴스를 배포할 수 있는 충분한 컴퓨팅 용량이 있어야 합니다.
# Outposts의 EKS 로컬 클러스터
상위 리전에서 Outposts 서비스 링크가 연결 해제되면 제어 영역이 리전에 있는 EKS 확장 클러스터로서의 서비스에 문제가 있을 수 있습니다. 과제 중 하나는 EKS 컨트롤 플레인과 작업자 노드 및 PODs. 작업자 노드와 PODs는 모두 Outposts에 상주하는 애플리케이션을 로컬에서 계속 운영 및 서비스할 수 있지만 Kubernetes 제어 플레인은 이를 비정상으로 간주하고 제어 플레인에 대한 연결이 복구될 때 교체 일정을 잡을 수 있습니다. 이로 인해 연결이 복원될 때 애플리케이션 가동 중지가 발생할 수 있습니다.
이를 간소화하기 위해 Outposts에서 전체 EKS 클러스터를 호스팅하는 옵션이 있습니다. 이 구성에서는 Kubernetes 컨트롤 플레인과 작업자 노드가 모두 Outposts 컴퓨팅 용량의 온프레미스에서 로컬로 실행됩니다. 이렇게 하면 서비스 링크 연결이 일시적으로 끊긴 경우에도 복원된 후에도 클러스터가 계속 작동합니다.
![\[Outposts의 Amazon EKS 로컬 클러스터\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-52-eks-local-cluster-outposts.png)
## EKS Local Cluster on Outposts 고려 사항
EKS 로컬 클러스터가 Outposts에 배포되는 경우 몇 가지 고려 사항이 있습니다.
+ 연결 해제 중에는 AWS 상위 리전에 대한 EC2 및 ASG API 호출에 의존하는 한 새 작업자 노드를 추가하거나 노드 그룹을 자동 조정해야 하는 클러스터 자체의 변경 사항을 실행할 수 있는 옵션이 없습니다.
+ • [eksctl AWS Outposts 지원에 나열된 로컬 클러스터에는 지원되지 않는 기능 세트가 있습니다](https://eksctl.io/usage/outposts/).