기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 컴퓨팅
의 Amazon EC2 용량은 무한해 AWS 리전 보이지만 Outposts의 용량은 유한합니다. Outposts 배포의 컴퓨팅 용량을 계획하고 관리할 책임은 귀하에게 있습니다.
**Topics**
+ [
# 용량 계획
](capacity-planning.md)
+ [
# 용량 관리
](capacity-management.md)
+ [
# 인스턴스 배치
](instance-placement.md)
# 용량 계획
의 Amazon EC2 용량은 무한해 AWS 리전 보이지만 Outposts의 용량은 유한합니다. 이는 주문된 컴퓨팅 용량의 총 볼륨에 의해 제한됩니다. Outposts 배포의 컴퓨팅 용량을 계획하고 관리할 책임은 귀하에게 있습니다. N\$1M 가용성 모델을 지원하려면 충분한 컴퓨팅 용량을 주문해야 합니다. 여기서 N은 필요한 서버 수이고 M은 서버 장애를 수용하기 위해 프로비저닝된 예비 서버 수입니다. N\$11 및 N\$12가 가장 일반적인 가용성 수준입니다.
각 호스트(`C5`, `M5``R5`, 등)는 단일 EC2 인스턴스 패밀리를 지원합니다. EC2 컴퓨팅 서버에서 인스턴스를 시작하려면 먼저 각 서버가 제공할 [EC2 인스턴스 크기를](https://aws.amazon.com/ec2/instance-types/) 지정하는 슬롯 레이아웃을 제공해야 합니다.는 요청된 슬롯 레이아웃으로 각 서버를 AWS 구성합니다.
호스트는 모든 슬롯이 동일한 인스턴스 크기(예: 슬롯 48`m5.large`개)이거나 인스턴스 유형(예: 4`m5.large`, 4, `m5.xlarge`3, `m5.2xlarge`1 `m5.4xlarge`및 1`m5.8xlarge`개)이 혼합된 이기종 슬롯인 경우 균일 슬롯이 될 수 있습니다. 이러한 슬롯 구성의 시각화는 다음 세 그림을 참조하세요.
![\[m5.24xlarge 호스트 컴퓨팅 리소스를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-server-resources.png)
![\[48m5.large 슬롯에 동종 슬롯이 있는 m5.24xlarge 호스트를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-slotted-into-48-m5-large-slots.png)
![\[슬롯 4개m5.large, 4개, 3개m5.xlarge, m5.2xlarge1개 m5.4xlarge및 1개에 이기종으로 m5.8xlarge 슬롯된 m5.24xlarge 호스트를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-slotted-into-different-x5-slots.png)
전체 호스트 용량을 슬롯화할 필요가 없습니다. 할당되지 않은 용량을 사용할 수 있는 호스트에 슬롯을 추가할 수 있습니다. 용 용량 관리 APIs 또는 UIs를 사용하고 새 용량 작업을 AWS Outposts 생성하여 슬롯 레이아웃을 수정할 수 있습니다. 자세한 내용은 랙 사용 설명서의 [용량 관리를 AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-capacity.html) 참조하세요. *AWS Outposts * 실행 중인 인스턴스가 특정 슬롯을 차지하는 동안 새 슬롯 레이아웃을 적용할 수 없는 경우 새 용량 작업을 완료하기 위해 특정 인스턴스를 종료하거나 다시 시작해야 할 수 있습니다. `CreateCapacityTask` API를 사용하면 표시된 Outpost ID에 있어야 하는 각 인스턴스 크기의 수를 표시할 수 있으며, 실행 중인 인스턴스로 인해 작업을 완료할 수 없는 경우는 요청을 충족하기 위해 중지해야 하는 인스턴스를 반환합니다. 이 시점에서 반환된 인스턴스 중 하나를 중지하지 않으려는 경우 선택적으로 “N” 추가 옵션을 표시하도록 지정할 수 있으며, 용량 작업 요청을 충족하기 위해 종료할 인스턴스로 제안해서는 안 되는 EC2 인스턴스 ID, EC2 인스턴스 태그, 계정 또는 서비스를 표시할 수도 있습니다. 진행하려는 옵션을 선택한 후 Dry Run 파라미터를 사용하여 제안된 변경 사항을 검증하고 구현하기 전에 잠재적 영향을 이해하는 것이 좋습니다.
모든 호스트는 Outpost의 EC2 용량 풀에 프로비저닝된 슬롯을 기여하며, 지정된 인스턴스 유형 및 크기의 모든 슬롯은 단일 EC2 용량 풀로 관리됩니다. 예를 들어 , `m5.large`, `m5.xlarge``m5.2xlarge``m5.4xlarge`, 및 슬롯이 있는 이전 이기종 `m5.8xlarge` 슬롯 호스트는 이러한 슬롯을 각 인스턴스 유형 및 크기에 대해 하나의 풀인 5개의 EC2 용량 풀에 기여합니다. 이러한 풀은 여러 호스트에 분산될 수 있으므로 워크로드 고가용성을 달성하려면 인스턴스 배치를 고려해야 합니다.
N\$1M 호스트 가용성을 위한 예비 용량을 계획할 때 호스트 슬롯 및 EC2 용량 풀을 고려하는 것이 중요합니다.는 호스트가 실패하거나 성능이 저하되는 시기를 AWS 감지하고 사이트 방문을 예약하여 실패한 호스트를 교체합니다. Outpost에서 각 인스턴스 패밀리(N\$11) 중 적어도 한 대의 서버에서 장애가 발생해도 견딜 수 있도록 EC2 용량 풀을 설계해야 합니다. 이 최소 호스트 가용성 수준에서 호스트가 실패하거나 서비스를 중단해야 하는 경우 동일한 패밀리의 나머지 호스트의 예비 슬롯에서 실패하거나 성능이 저하된 인스턴스를 다시 시작할 수 있습니다.
N\$1M 가용성에 대한 계획은 동일한 슬롯 레이아웃을 가진 동종 슬롯 호스트 또는 이기종 슬롯 호스트 그룹이 있는 경우 간단합니다. 모든 워크로드를 실행해야 하는 호스트 수(N)를 계산한 다음 장애 및 유지 관리 이벤트 중 서버 가용성 요구 사항을 충족하기 위해 (M) 호스트를 추가하면 됩니다.
다음 슬롯 구성은 NUMA 경계로 인해 사용할 수 없습니다.
+ 3 `m5.8xlarge`
+ 1 `m5.16xlarge` 및 1 `m5.8xlarge`
팀에 문의하여 계획된 AWS Outposts 랙 슬롯 구성의 AWS 계정 유효성을 검사합니다.
다음 그림에서는 4개의 `m5.24xlarge` 호스트가 동일한 슬롯 레이아웃으로 이기종 슬롯됩니다. 4개의 호스트는 5개의 EC2 용량 풀을 생성합니다. 각 풀은 최대 사용률(75%)로 실행되어이 4개의 호스트에서 실행되는 인스턴스에 대한 N\$11 가용성을 유지합니다. 호스트가 실패하면 나머지 호스트에서 실패한 인스턴스를 다시 시작할 수 있는 충분한 공간이 있습니다.
![\[EC2 호스트 슬롯, 실행 중인 인스턴스 및 슬롯 풀의 시각화를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-server-slots-and-pools.png)
호스트가 동일하게 슬롯되지 않는 보다 복잡한 슬롯 레이아웃의 경우 각 EC2 용량 풀에 대한 N\$1M 가용성을 계산해야 합니다. 다음 공식을 사용하여 실패할 수 있는 호스트(특정 EC2 용량 풀에 슬롯 기여) 수를 계산하고 나머지 호스트가 실행 중인 인스턴스를 보유하도록 허용할 수 있습니다.
![\[수식 M = (사용 가능한 풀 슬롯/최대 호스트 슬롯)\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/equation.png)
위치:
+ **poolSlotsavailable**는 지정된 EC2 용량 풀에서 사용 가능한 슬롯 수입니다(풀의 총 슬롯 수에서 실행 중인 인스턴스 수를 뺀 값).
+ **serverSlotsmax**는 호스트가 지정된 EC2 용량 풀에 기여한 최대 슬롯 수입니다.
+ **M**은 실패할 수 있지만 여전히 나머지 호스트가 실행 중인 인스턴스를 보유하도록 허용하는 호스트 수입니다.
***예:*** Outpost에는 `m5.2xlarge` 용량 풀에 슬롯을 기여하는 호스트 3개가 있습니다. 첫 번째는 슬롯 4개, 두 번째는 슬롯 3개, 세 번째 호스트는 슬롯 2개를 제공합니다. Outpost의 `m5.2xlarge` 인스턴스 풀의 총 용량은 슬롯 9개(4 \$1 3 \$1 2)입니다. Outpost에는 실행 중인 `m5.2xlarge` 인스턴스가 4개 있습니다. 실패해도 나머지 호스트가 실행 중인 인스턴스를 전달하도록 허용할 수 있는 호스트 수는 몇 개입니까?
![\[세 가지 방정식\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/equations.png)
***답변:*** 호스트 중 하나를 잃어버린 후에도 실행 중인 인스턴스를 나머지 호스트에 계속 보유할 수 있습니다.
## 컴퓨팅 용량 계획을 위한 권장 사례
+ Outpost의 각 EC2 용량 풀에 N\$1M 중복성을 제공하도록 컴퓨팅 용량의 크기를 조정합니다.
+ 동종 또는 동일한 이기종 슬롯 서버를 위한 N\$1M 서버를 배포합니다.
+ 각 EC2 용량 풀의 N\$1M 가용성을 계산하고 각 풀이 가용성 요구 사항을 충족하는지 확인합니다.
# 용량 관리
Amazon CloudWatch 지표를 통해 AWS Management Console 및에서 Outpost EC2 인스턴스 풀 사용률을 모니터링할 수 있습니다. Outpost의 슬롯 레이아웃을 검색하거나 변경하려면 Enterprise Support에 문의하세요.
동일한 [인스턴스 자동 복구](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) 및 [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) 메커니즘을 사용하여 서버 장애 및 유지 관리 이벤트의 영향을 받는 인스턴스를 복구하거나 교체할 수 있습니다. Outpost 용량을 모니터링하고 관리하여 서버 장애를 수용할 수 있을 만큼 충분한 예비 용량을 항상 사용할 수 있도록 해야 합니다. [https://aws.amazon.com/blogs/compute/managing-your-aws-outposts-capacity-using-amazon-cloudwatch-and-aws-lambda/](https://aws.amazon.com/blogs/compute/managing-your-aws-outposts-capacity-using-amazon-cloudwatch-and-aws-lambda/) 블로그 게시물에서는 AWS CloudWatch를 결합하고 Outpost 용량을 관리 AWS Lambda 하여 인스턴스 가용성을 유지하는 방법을 보여주는 실습 자습서를 제공합니다.
![\[Amazon CloudWatch 및를 사용한 AWS Outposts 용량 관리를 보여주는 다이어그램 AWS Lambda\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/managing-outposts-capacity.png)
용량 예약은 다중 계정 환경에서 사용하여 단일 계정 또는 여러 계정이 포함된 AWS 조직 단위(OU)에서 Outpost 컴퓨팅 용량을 사용하는 양을 제어할 수 있습니다. Amazon EC2 on Outposts에 대한 용량 예약은 물론 Amazon Elastic Kubernetes Service(EKS, Amazon Elastic Container Service(ECS) 및 Amazon Elastic Map Reduce(EMR) AWS 서비스 와 같은 지원되는 Outposts를 생성할 수 있습니다. 용량 예약은 Outpost 소유자 계정의 AWS Resource Access Manager (AWS RAM)를 통해 생성되고 계정에 공유됩니다. [EC2 용량 예약 공유를 사용하여 AWS Outposts 랙에서 컴퓨팅 할당량 생성](https://aws.amazon.com/blogs/compute/creating-computing-quotas-on-aws-outposts-rack-with-ec2-capacity-reservation-sharing/)에서는 용량 관리를 위해 Outpost를 사용하여 용량 예약을 구현하기 위한 실습 자습서와 추가 지침을 제공합니다.
![\[용량 예약 공유 프로세스 1~4단계를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-36-capacity-reservation-sharing-process-steps-1-4.png)
![\[용량 예약 공유 프로세스 5~6단계를 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/page-37-capacity-reservation-sharing-process-steps-5-6.png)
## 컴퓨팅 용량 관리를 위한 권장 사례
+ Auto Scaling 그룹에서 EC2 인스턴스를 구성하거나 인스턴스 자동 복구를 사용하여 장애가 발생한 인스턴스를 다시 시작합니다.
+ Outpost 배포의 용량 모니터링을 자동화하고 용량 경보에 대한 알림 및 자동 응답(선택 사항)을 구성합니다.
+ 용량 예약을 사용하여 AWS 조직 내 다른 계정에 공유되는 컴퓨팅 용량의 양을 세밀하게 제어할 수 있습니다.
# 인스턴스 배치
Outpost에는 컴퓨팅 호스트 수가 한정되어 있습니다. 애플리케이션이 추가 구성 없이 Outposts에 여러 관련 인스턴스를 배포하는 경우 인스턴스는 동일한 호스트 또는 동일한 랙의 호스트에 배포될 수 있습니다. 오늘날에는 동일한 인프라에서 관련 인스턴스를 실행할 때 발생하는 위험을 줄이기 위해 인스턴스를 배포하는 데 사용할 수 있는 세 가지 메커니즘이 있습니다.
**다중 Outpost 배포** - 리전의 다중 AZ 전략과 마찬가지로 Outpost를 별도의 데이터 센터에 배포하고 특정 Outpost에 애플리케이션 리소스를 배포할 수 있습니다. 이를 통해 원하는 Outpost(논리적 랙 세트)에서 인스턴스를 실행할 수 있습니다. Direct VPC Routing을 사용한 여러 Outpost 간 [VPC 내 통신](https://aws.amazon.com/about-aws/whats-new/2023/08/aws-outposts-rack-intra-vpc-communication-multiple-outposts/)은 Outpost 로컬 게이트웨이(LGW)를 사용하여 Outpost의 서브넷 간에 경로를 생성하는 동일한 VPC 내의 여러 Outpost에 워크로드를 분산하는 데 사용할 수 있는 또 다른 전략입니다. 다중 Outpost 전략을 사용하여 랙 및 데이터 센터 장애 모드를 방지할 수 있으며, Outpost가 별도의 AZ 또는 리전에 고정되어 있는 경우 AZ 또는 리전 장애 모드에 대한 보호 기능도 제공할 수 있습니다. 다중 Outpost 아키텍처에 대한 자세한 내용은 [대규모 장애 모드](larger-failure-modes.md)를 참조하세요.
**Outposts의 Amazon EC2 배치 그룹**(단일 Outpost 다중 랙 인스턴스 배치) - 계정[에서 생성한 Outposts에 배치 그룹을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups-outpost.html) 생성할 수 있습니다. 이렇게 하면 사이트의 Outposts에서 기본 하드웨어에 인스턴스를 분산시킬 수 있습니다. Outpost에 분산 전략이 있는 배치 그룹을 생성할 때, 배치 그룹이 호스트나 랙에 인스턴스를 분산하도록 선택할 수 있습니다.
분산 배치 그룹은 랙 또는 호스트 간에 단일 인스턴스를 분산하여 상관관계가 있는 장애 가능성을 줄이는 간단한 방법을 제공합니다. Outpost에 호스트가 있는 만큼만 그룹에 배포할 수 있습니다.
![\[랙 3개가 있는 Outpost의 EC2 분산 배치 그룹을 보여주는 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-spread-placement-group.png)
파티션 배치 그룹을 사용하여 여러 랙에 인스턴스를 분산할 수도 있습니다. 자동 배포를 사용하여 그룹 내 파티션에 인스턴스를 분산하거나 선택한 대상 파티션에 인스턴스를 배포할 수 있습니다. 대상 파티션에 인스턴스를 배포하면 선택한 리소스를 동일한 랙에 배포하고 다른 리소스는 랙 전체에 분산할 수 있습니다. 예를 들어 랙이 3개인 논리적 Outpost가 있는 경우 세 개의 파티션으로 구성된 파티션 배치 그룹을 만들면 랙 전체에 리소스를 분배할 수 있습니다.
![\[랙 3개가 있는 Outpost의 EC2 파티션 배치 그룹을 나타낸 다이어그램\]](http://docs.aws.amazon.com/ko_kr/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-partition-placement-groups.png)
**크리에이티브 서버 슬롯팅** - 단일 랙 Outpost가 있거나 Outpost에서 사용 중인 서비스가 배치 그룹을 지원하지 않는 경우, 크리에이티브 슬롯팅을 사용하여 인스턴스가 동일한 물리적 서버에 배포되지 않도록 할 수 있습니다. 관련 인스턴스의 EC2 인스턴스 크기가 동일한 경우 서버 슬롯을 지정하여 각 서버에 구성된 해당 크기의 슬롯 수를 제한해서 슬롯을 서버 전체에 분산시킬 수 있습니다. 서버 슬롯팅은 단일 서버에서 실행할 수 있는 해당 크기의 인스턴스 수를 제한합니다.
그림 13에 표시된 슬롯팅 레이아웃을 예로 들어 보겠습니다. 애플리케이션이이 슬롯 레이아웃으로 구성된 Outpost에 `m5.4xlarge` 인스턴스 3개를 배포해야 하는 경우 EC2는 각 인스턴스를 별도의 서버에 배치하며 슬롯 구성이 변경되어 서버의 추가 `m5.4xlarge` 슬롯이 열리지 않는 한 이러한 인스턴스가 동일한 서버에서 실행될 가능성은 없습니다.
## 컴퓨팅 인스턴스 배치에 대한 권장 사례
+ [Outposts의 Amazon EC2 배치 그룹을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups-outpost.html) 사용하여 단일 논리적 Outpost 내의 랙 간 인스턴스 배치를 제어할 수 있습니다.
+ Outpost를 하나의 중형 또는 대형 Outpost 랙으로 주문하는 대신 용량을 두 개의 소형 또는 중형 랙으로 분할하여 랙에 인스턴스를 분산하는 EC2 배치 그룹 기능을 활용할 수 있도록 하세요.
+ Outposts의 Amazon EC2 배치 그룹을 사용하여 EKS 노드 그룹, EKS 로컬 클러스터용 컨트롤 플레인 노드 및 [ECS 작업](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)의 배치에 영향을 미칠 수 있습니다.
+ VPC 내 통신을 사용하여 동일한 VPC 내의 여러 Outpost에 워크로드를 분산합니다.