이 문서는 업데이트 중입니다. 그 동안 일부 콘텐츠가 정확하지 않을 수 있습니다.

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

장애 모드에 대해서 생각하기

가용성이 높은 응용 프로그램 또는 시스템을 설계할 때는 장애가 발생할 수 있는 구성 요소, 구성 요소 장애가 시스템에 미치는 영향, 구성 요소 오류의 영향을 완화 또는 제거하기 위해 구현할 수 있는 메커니즘을 고려해야 합니다. 애플리케이션이 단일 서버, 단일 랙 또는 단일 데이터 센터에서 실행되나요? 서버, 랙 또는 데이터 센터에 일시적 또는 영구적 장애가 발생하면 어떻게 되나요? 네트워킹과 같은 중요한 하위 시스템이나 애플리케이션 자체에 장애가 발생하면 어떻게 되나요? 이러한 것들이 장애 모드입니다.

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

장애 모드 1: 네트워크

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

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

연결 해제 이벤트 중에 Outpost에서 실행되는 인스턴스는 계속 실행되며 Outpost Local Gateway()를 통해 온프레미스 네트워크에서 액세스할 수 있습니다LGW. 로컬 워크로드 및 서비스가 해당 리전의 서비스를 사용하는 경우 로컬 워크로드 및 서비스가 손상되거나 실패할 수 있습니다. Outpost가 리전에서 연결 해제된 동안 요청(예: Outpost에서 인스턴스 시작 또는 중지), 제어 영역 작업 및 서비스 원격 측정(예: CloudWatch 지표)을 변경하면 실패합니다.

장애 모드 2: 인스턴스

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

EC2 Auto Scaling 그룹과 같은 자동화된 메커니즘을 사용하여 실패한 인스턴스를 새 인스턴스로 교체할 수 있습니다. 인스턴스 자동 복구는 나머지 서버에 충분한 여유 용량이 있는 경우 서버 장애로 인해 장애가 발생한 인스턴스를 다시 시작할 수 있습니다.

장애 모드 3: 컴퓨팅

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

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

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

장애 모드 4: 랙 또는 데이터 센터

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

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

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

실패 모드 5: AWS 가용 영역 또는 리전

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

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

AWS AZ 및 리전 장애의 영향을 완화하기 위해 각각 다른 AZ 또는 리전에 고정된 여러 Outpost를 배포할 수 있습니다. 그런 다음 AWS 현재 설계하고 배포하는 데 사용하는 유사한 메커니즘과 아키텍처 패턴을 많이 사용하여 분산 다중 Outpost 배포 모델에서 작동하도록 워크로드를 설계할 수 있습니다.