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

# 장애 모드에 대해서 생각하기
<a name="thinking-in-terms-of-failure-modes"></a>

고가용성 애플리케이션 또는 시스템을 설계할 때는 장애가 발생할 수 있는 구성 요소, 구성 요소 장애가 시스템 및 애플리케이션 [RPO/RTO](https://aws.amazon.com/blogs/mt/establishing-rpo-and-rto-targets-for-cloud-applications/) 목표에 미치는 영향, 구성 요소 장애의 영향을 완화하거나 제거하기 위해 구현할 수 있는 메커니즘을 고려해야 합니다. 애플리케이션이 단일 서버, 단일 랙 또는 단일 데이터 센터에서 실행되나요? 서버, 랙 또는 데이터 센터에 일시적 또는 영구적 장애가 발생하면 어떻게 되나요? 네트워킹과 같은 중요한 하위 시스템이나 애플리케이션 자체에 장애가 발생하면 어떻게 되나요? 이러한 것들이 장애 모드입니다.

 Outpost 및 애플리케이션 배포를 계획할 때는 이 섹션의 장애 모드를 고려해야 합니다. 다음 섹션에서는 이러한 장애 모드를 완화하여 애플리케이션 환경에 향상된 수준의 고가용성을 제공하는 방법을 검토합니다.

## 장애 모드 1: 네트워크
<a name="failure-mode-1-network"></a>

 Outpost 배포는 관리 및 모니터링을 위한 상위 리전과의 탄력적인 연결을 기반으로 합니다. 네트워크 장애는 운영자 오류, 장비 장애, 서비스 제공업체 운영 중단과 같은 다양한 장애로 인해 발생할 수 있습니다. 현장에 연결된 하나 이상의 랙으로 구성될 수 있는 Outpost는 서비스 링크를 통해 해당 리전과 통신할 수 없는 경우 연결이 끊긴 것으로 간주됩니다.

 네트워크 경로를 중복시키면 연결 해제 이벤트의 위험을 완화하는 데 도움이 될 수 있습니다. 애플리케이션 종속성과 네트워크 트래픽을 매핑하여 연결 해제 이벤트가 워크로드 운영에 미치는 영향을 이해해야 합니다. 애플리케이션 가용성 요구 사항을 충족할 수 있도록 충분한 네트워크 중복을 계획하세요.

 연결이 끊기는 경우에도 Outpost에서 실행되는 인스턴스는 계속 실행되며 Outpost 로컬 게이트웨이(LGW)를 통해 온프레미스 네트워크에서 액세스할 수 있습니다. 로컬 워크로드 및 서비스가 해당 리전의 서비스를 사용하는 경우 로컬 워크로드 및 서비스가 손상되거나 실패할 수 있습니다. Outpost가 리전과 연결이 끊어지면 변형 요청들(예: Outpost에서 인스턴스 시작 또는 중지), 컨트롤 플레인 작업, 서비스 텔레메트리(예: CloudWatch 지표)이 실패합니다. CloudWatch 지표는 단기간 네트워크 연결 해제를 위해 Outpost에서 로컬로 스풀링되며 서비스 링크 연결이 다시 설정되면 검토를 위해 리전으로 전송됩니다.

## 장애 모드 2: 인스턴스
<a name="failure-mode-2-instances"></a>

 실행 중인 서버에 문제가 있거나 인스턴스에 운영 체제 또는 애플리케이션 장애가 발생하는 경우 Amazon EC2 인스턴스가 손상되거나 실패할 수 있습니다. 애플리케이션이 이러한 유형의 장애를 처리하는 방법은 애플리케이션 아키텍처에 따라 다릅니다. 모놀리식 애플리케이션은 일반적으로 복구를 위해 애플리케이션 또는 시스템 기능을 사용하는 반면, 모듈식 서비스 지향 또는 [마이크로서비스](https://aws.amazon.com/microservices) 아키텍처는 일반적으로 서비스 가용성을 유지하기 위해 실패한 구성 요소를 대체합니다.

Amazon EC2 Auto Scaling 그룹과 같은 자동화된 메커니즘을 사용하여 실패한 인스턴스를 새 인스턴스로 교체할 수 있습니다. 인스턴스 자동 복구는 나머지 서버에서 사용 가능한 예비 용량이 충분하고 서비스 링크가 여전히 연결되어 있는 경우 서버 장애로 인해 실패한 인스턴스를 다시 시작할 수 있습니다.

## 장애 모드 3: 컴퓨팅
<a name="failure-mode-3-compute-and-storage-servers"></a>

 서버에 장애가 발생하거나 손상이 발생할 수 있으며 구성 요소 장애 및 예정된 유지 관리 작업과 같은 다양한 이유로, 일시적 또는 영구적으로 운영을 중단해야 할 수 있습니다. Outpost 랙의 서비스가 서버 장애 및 장애를 처리하는 방법은 다양하며 고객이 고가용성 옵션을 구성하는 방법에 따라 달라질 수 있습니다.

 `N+M` 가용성 모델을 지원하려면 충분한 컴퓨팅 용량을 주문해야 합니다. 이때 `N`은 필요한 용량이며 `M`은 서버 장애를 수용할 수 있도록 할당된 예비 용량입니다.

 장애가 발생한 서버에 대한 하드웨어 교체는 완전 관리형 AWS Outposts 랙 서비스의 일부로 제공됩니다.는 Outpost 배포에서 모든 서버 및 네트워킹 디바이스의 상태를 AWS 능동적으로 모니터링합니다. 물리적인 유지 관리가 필요한 경우 AWS 는 시간을 내서 현장을 방문하여 장애가 발생한 구성 요소를 교체해 드립니다. 예비 용량을 프로비저닝하면 비정상 서버를 사용하지 않고 교체하는 동안 호스트 장애에 대비하여 워크로드를 복원할 수 있습니다.

## 장애 모드 4: 랙 또는 데이터 센터
<a name="failure-mode-4-racks-or-data-centers"></a>

 랙의 완전한 전원 손실이나 냉방 손실과 같은 환경적 장애로, 또는 홍수나 지진으로 인한 데이터 센터의 물리적 손상으로 인해 랙 장애가 발생할 수 있습니다. 데이터 센터 배전 아키텍처에 결함이 있거나 표준 데이터 센터 전원 유지 관리 중에 오류가 발생하면 하나 이상의 랙 또는 전체 데이터 센터의 전력이 손실될 수 있습니다.

 동일한 캠퍼스 또는 대도시 지역 내에서 서로 독립된 여러 데이터 센터 층이나 위치에 인프라를 배포하면 이러한 시나리오를 완화할 수 있습니다.

 AWS Outposts 랙을 사용하여이 접근 방식을 취하려면 애플리케이션 가용성을 유지하기 위해 여러 개의 개별 논리적 Outpost에서 실행되도록 애플리케이션을 설계하고 배포하는 방법을 신중하게 고려해야 합니다.

## 장애 모드 5: AWS 가용 영역 또는 리전
<a name="failure-mode-5-aws-availability-zone-or-region"></a>

 각 Outpost는 AWS 리전내의 특정 가용 영역(AZ)에 고정되어 있습니다. 앵커 AZ 또는 상위 리전 내에서 장애가 발생하면 Outpost 관리 및 변형 가능성이 손실되고 Outpost와 리전 간의 네트워크 통신이 중단될 수 있습니다.

 네트워크 장애와 마찬가지로 AZ 또는 리전 장애로 인해 Outpost와 리전의 연결이 끊길 수 있습니다. Outpost에서 실행되는 인스턴스는 계속 실행되며 Outpost 로컬 게이트웨이(LGW)를 통해 온프레미스 네트워크에서 액세스할 수 있습니다. 앞서 설명한 것처럼 해당 리전의 서비스에 의존하는 경우 네트워크가 손상되거나 장애가 발생할 수 있습니다.

 AZ 및 리전 장애의 영향을 완화하기 위해 각각 다른 AWS AZ 또는 리전에 고정된 여러 Outpost를 배포할 수 있습니다. 그런 다음 현재 AWS 에서 설계 및 배포에 사용하는 유사한 [메커니즘과 아키텍처 패턴](https://docs.aws.amazon.com/whitepapers/latest/fault-tolerant-components/high-availability-building-blocks.html)을 많이 사용하여 분산 다중 Outpost 배포 모델에서 운영되도록 워크로드를 설계할 수 있습니다.

에서 실행되는 서비스의 제어 영역은 고정되는 리전에 AWS Outposts 상주하여 Amazon EC2 및 Amazon EBS와 같은 영역 서비스와 Amazon RDS, Elastic Load Balancing 및 Amazon EKS와 같은 리전 서비스 모두에 종속성을 생성합니다. Outposts에서는 [정적 안정성](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/static-stability.html) 개념에 따라 애플리케이션을 배포하여 복원력을 개선하여 플레인 장애를 제어할 수 있습니다.