자동 인스턴스 복구
중요
이 섹션에서는 EC2 인스턴스에서 복구 메커니즘을 사전에 구성하는 방법을 설명합니다. 이러한 복구 메커니즘은 AWS가 시스템 상태 확인 실패를 유발하는 기본 하드웨어 또는 소프트웨어 결함을 감지할 때 인스턴스 가용성을 복원하도록 설계되었습니다. 현재 인스턴스에 액세스하는 데 문제가 있는 경우 EC2 인스턴스 문제 해결을 참조하세요.
AWS에서 기본 하드웨어 또는 소프트웨어 문제로 인해 인스턴스를 사용할 수 없다고 판단하는 경우 인스턴스 가용성을 자동으로 복원할 수 있는 두 가지 메커니즘, 즉 간소화된 자동 복구와 Amazon CloudWatch 작업 기반 복구가 있습니다. 인스턴스 가용성 복구는 인스턴스 복구라고도 합니다.
인스턴스 복구 프로세스 중에 AWS는 기본 하드웨어 또는 소프트웨어 문제가 있는 호스트에서 다른 호스트로 인스턴스를 이동하려고 시도합니다. 인스턴스 복구 프로세스가 성공하면 인스턴스가 계획되지 않은 재부팅을 한 것으로 표시됩니다. 인스턴스 복구가 발생했는지 확인할 수 있습니다.
복구 프로세스가 실패하면 기본 하드웨어 또는 소프트웨어 문제가 있는 호스트에서 인스턴스가 계속 실행될 수 있습니다. 이 경우 수동 개입이 필요합니다. 인스턴스에 더 이상 연결할 수 없거나 인스턴스 시스템 상태 확인 실패가 계속되는 경우 인스턴스를 수동으로 중지 및 시작하는 것이 좋습니다. 인스턴스를 시작하면 일반적으로 새 기본 호스트 컴퓨터로 마이그레이션됩니다. 그러나 인스턴스가 퍼블릭 IPv4 주소를 유지하는 자동 인스턴스 복구와 달리 다시 시작된 인스턴스는 탄력적 IP 주소가 없는 한 새 퍼블릭 IPv4 주소를 수신합니다.
자동 복구 메커니즘의 이점을 활용하려면 시스템 상태 확인이 실패하기 전에 인스턴스에서 미리 구성해야 합니다. 기본적으로 인스턴스를 시작하는 동안 해당 인스턴스에 대해 간소화된 자동 복구가 활성화됩니다. 선택적으로 시작 후 Amazon CloudWatch 작업 기반 복구를 구성할 수 있습니다. 이러한 메커니즘 중 하나를 구성하면 인스턴스의 복원력이 향상됩니다.
간소화된 자동 복구 및 Amazon CloudWatch 작업 기반 복구는 지원되는 인스턴스에서만 사용할 수 있습니다. 자세한 내용은 간소화된 자동 복구 활성화 요구 사항 및 CloudWatch 작업 기반 복구 활성화에 대한 요구 사항 단원을 참조하세요.
주의
AWS가 기본 하드웨어 또는 소프트웨어 문제로 인해 인스턴스를 복구하는 경우 휘발성 메모리(RAM)에 저장된 데이터가 손실되고 운영 체제의 가동 시간이 0에서 다시 시작됩니다. 또한 CloudWatch 작업 기반 복구를 사용하면 인스턴스 저장소 볼륨의 데이터도 손실됩니다. 데이터 손실을 방지하려면 중요한 데이터의 백업을 정기적으로 생성하는 것이 좋습니다. EC2 인스턴스의 백업 및 복구 모범 사례에 대한 자세한 내용은 Amazon EC2 모범 사례를 참조하세요.
자동 인스턴스 복구 메커니즘은 개별 인스턴스에 맞게 설계되었습니다. 복원력이 높은 시스템 구축에 대한 지침은 복원력 있는 시스템 구축 섹션을 참조하세요.
주제
자동 인스턴스 복구의 주요 개념
자동 인스턴스 복구는 기본 하드웨어 또는 소프트웨어 장애가 발생할 때 인스턴스 가용성을 자동으로 복원하여 EC2 인스턴스의 복원력과 신뢰성을 높이는 Amazon EC2 기능입니다.
다음은 자동 인스턴스 복구의 주요 개념입니다.
- 구성 옵션
-
두 가지 메커니즘을 구성하여 자동 인스턴스 복구를 지원할 수 있습니다.
-
간소화된 자동 복구: 기본적으로 지원되는 인스턴스에서 활성화됩니다.
-
CloudWatch 작업 기반 복구: 지원되는 인스턴스에 대한 수동 구성이 필요합니다.
-
- 시스템 상태 확인
-
시스템 상태 확인은 EC2 인스턴스가 실행되는 AWS 인프라를 자동으로 모니터링합니다.
-
시스템 상태 확인에 실패하면 AWS는 영향을 받는 인스턴스를 다른 하드웨어로 마이그레이션하려고 시도하는 자동 인스턴스 복구를 시작합니다.
-
실패한 시스템 상태 확인은 인스턴스 자체의 문제가 아니라 호스트의 하드웨어 또는 소프트웨어에 문제가 있음을 나타냅니다. 자동 인스턴스 복구는 시스템 상태 확인에 실패한 인스턴스를 복구할 수 있습니다. 그러나 인스턴스 상태 확인만 실패하면 자동 인스턴스 복구가 작동하지 않습니다.
-
인스턴스 상태 확인과 시스템 상태 확인의 차이점은 상태 확인 유형을 참조하세요.
-
- 기본 하드웨어 또는 소프트웨어 문제의 예
-
시스템 상태 확인이 실패할 수 있는 하드웨어 또는 소프트웨어 문제에는 네트워크 연결 손실, 시스템 전원 손실, 물리적 호스트의 소프트웨어 문제, 네트워크 연결성에 영향을 미치는 물리적 호스트의 하드웨어 문제 등이 있습니다.
- 복구된 인스턴스의 특성
-
복구된 인스턴스는 손실된 요소를 제외하고 원래 인스턴스와 동일합니다.
보존되는 요소:
-
인스턴스 ID
-
퍼블릭, 프라이빗 및 탄력적 IP 주소
-
인스턴스 메타데이터
-
배치 그룹
-
연결된 EBS 볼륨
-
가용 영역
손실되는 요소:
-
휘발성 메모리(RAM)에 저장된 데이터
-
인스턴스 저장소 볼륨에 저장된 데이터(CloudWatch 작업 기반 복구에만 해당)
-
운영 체제 가동 시간이 0으로 재설정됨
-
- CloudWatch를 사용하여 시스템 상태 확인 모니터링
-
CloudWatch의 StatusCheckFailed_System 지표는 시스템 상태 확인의 통과 또는 실패 여부를 나타냅니다.
지표 값:
-
0 - 시스템 상태 확인을 통과했습니다.
-
1 - 시스템 상태 확인에 실패했습니다.
-
- AWS Health Dashboard의 이벤트
-
자동 인스턴스 복구 시도 중에는 AWS가 구성된 복구 메커니즘과 그 결과에 따라 AWS Health Dashboard에 이벤트를 보냅니다.
-
간소화된 자동 복구
-
성공 이벤트:
AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_SUCCESS
-
실패 이벤트:
AWS_EC2_SIMPLIFIED_AUTO_RECOVERY_FAILURE
-
-
CloudWatch 작업 기반 복구
-
성공 이벤트:
AWS_EC2_INSTANCE_AUTO_RECOVERY_SUCCESS
-
실패 이벤트:
AWS_EC2_INSTANCE_AUTO_RECOVERY_FAILURE
-
-
간소화된 자동 복구와 CloudWatch 작업 기반 복구의 차이점
다음 표에서는 간소화된 자동 복구와 CloudWatch 작업 기반 복구의 주요 차이점을 비교합니다.
비교 요점 | 간소화된 자동 복구 | CloudWatch 작업 기반 복구 |
---|---|---|
구성 | 지원되는 인스턴스에서 기본적으로 활성화됨 | CloudWatch 경보 및 작업의 수동 구성 필요 |
유연성 | AWS에서 관리하는 복구 동작 수정 | 사용자 지정 가능한 작업 및 조건 |
Notification | AWS Health Dashboard를 통한 기본 알림 | SNS를 통한 사용자 지정 가능 알림 |
메탈 인스턴스 크기 | 제외됨 | 포함 |
인스턴스 스토어 볼륨이 시작 시에 연결됨 | 시작 시 인스턴스 저장소 볼륨을 연결하는 인스턴스에는 지원되지 않음 | 일부 인스턴스 유형에서 지원됨. 인스턴스 복구 중 인스턴스 볼륨 볼륨의 데이터가 손실됨. |
복구 시간 | 표준 복구 시도 | 간소화된 자동 복구보다 빠른 복구 시도 |
비용 | 추가 요금 없음 | CloudWatch 요금이 발생할 수 있음 |
복원력 있는 시스템 구축
간소화된 자동 복구 및 CloudWatch 작업 기반 복구는 개별 인스턴스 가용성을 유지하는 데 효과적이지만 AWS에서는 정상 인스턴스로 유입되는 트래픽을 장애 조치할 수 있는 고가용성 아키텍처를 구현할 것을 권장합니다.
이를 위해서는 Elastic Load Balancing(수신 트래픽을 여러 EC2 인스턴스에 분산) 및 Amazon EC2 Auto Scaling(수요 및 상태에 따라 인스턴스 수를 자동으로 조정)과 같은 AWS 서비스를 사용하는 것이 좋습니다.
EC2 인스턴스를 사용하여 복원력이 뛰어나고 내결함성을 갖춘 시스템을 구축하는 방법에 대한 자세한 내용은 다음 리소스를 참조하세요.
-
AWS YouTube 채널의 Back to Basics: Designing for Failure with EC2
-
AWS 아키텍처 블로그 사이트의 Disaster Recovery (DR) Architecture on AWS, Part I: Strategies for Recovery in the Cloud
-
Reliability Pillar AWS Well-Architected Framework의 REL11-BP02 정상 리소스로 장애 조치