이 문제는 인스턴스의 내부 구성에 관한 문제로 인해 발생하는 경우가 많습니다. 인스턴스가 응답하지 않는 경우, 이후의 복구 프로세스는 실행 중인 인스턴스 유형(EBS-Backed 또는 Instance-Store Backed)에 따라 다릅니다.
먼저 인스턴스의 콘솔 출력을 검토하여 재부팅이 인스턴스에 영향을 미친 이유가 무엇인지 확인해 봅니다. 콘솔 출력의 정보는 인스턴스 실패 원인을 파악하기에 충분한 정보를 제공해 줄 수도 있습니다.
AWS Management Console에서,
- 인스턴스를 선택합니다.
- Instance Actions 메뉴에서 View System Log를 선택합니다.
Amazon EC2 API 도구에서,
- ec2-get-console-output 명령을 실행합니다.
콘솔 출력을 보아도 무슨 내용인지 모르겠으면 아래 두 인스턴스 유형에 대해 읽어 보십시오.
Instance-Store Backed 인스턴스
인스턴스 복구
일반적으로 Instance-Store Backed 루트 디바이스를 사용하여 AMI에서 시작한 인스턴스가 부팅되지 않을 때는, 대체 인스턴스를 시작하는 것 외에는 다른 방법이 없습니다. 수정한 후에는 사용자 정의 AMI를 번들링하여 항상 실행 중인 인스턴스 구성의 백업을 만드는 것이 좋습니다. 부팅 프로세스 중에 스크립트를 다운로드하는 AMI에서 인스턴스를 실행하는 경우, 스크립트를 변경하여 콘솔 출력에 표시되는 오류를 수정할 수 있습니다.
데이터 복구
인스턴스가 종료되지 않았고 해당 하드웨어에 문제가 없는 경우 AWS Support에서 일부 데이터를 복구할 수는 있지만 일반적으로 인스턴스 스토어의 데이터 복구는 불가능합니다. 데이터 복구는 확실히 보장되는 프로세스가 아니며 완료하는 데 며칠이 걸릴 수 있으므로 AWS Support를 통한 데이터 복구 가능성을 유일한 백업 전략으로 계획하지 마십시오.
EBS-Backed 인스턴스
EBS-Backed 인스턴스를 복구하기 전에 EBS-Backed 인스턴스에서 사용할 수 있는 사전에 연결된 인스턴스 스토어(휘발성 스토어라고도 함)를 사용하고 있는지 알아야 합니다. 이 페이지의 뒷부분에 설명된 작업을 수행하면 사전에 연결된 이 인스턴스 스토어의 데이터는 손실되므로 이 정보는 반드시 기억해 두어야 합니다. 인스턴스 스토어를 사용하고 있다면, 사전에 연결된 인스턴스 스토어에 저장된 데이터의 복구 옵션에 대한 자세한 내용은 위 섹션을 참조하십시오.
인스턴스 복구
인스턴스의 루트 디바이스가 EBS-Backed 볼륨인 경우 대개 인스턴스를 중지했다가 다시 시작하면 문제가 해결됩니다. 자세한 내용은 인스턴스 중단과 시작을 참조하십시오.
제대로 부팅되지 않는 EBS-Backed 인스턴스의 루트 볼륨 오류를 수동으로 수정할 수 있는 경우도 있습니다. 오류를 수동으로 수정하는 과정은 복잡한 과정이 될 수 있으므로 시스템 관리 경험이 없으면 권장되지 않습니다. 실패한 인스턴스의 콘솔 출력을 분석한 후에 고객이 사용하는 몇몇 솔루션의 예로는 볼륨에서 fsck를 실행하거나, SELinux를 비활성화하거나, fstab 파일에서 오류를 수정하는 방법이 있습니다.
인스턴스를 중지하고 다시 시작하려면,
- 제대로 부팅되지 않는 인스턴스를 중지합니다(종료하지는 마십시오).
- 루트 EBS 볼륨을 분리합니다.
- 같은 가용 영역의 기존 인스턴스에 볼륨을 연결하여 두 번째 탑재 지점(루트 아님)을 사용하도록 합니다.
- 이전 루트 볼륨의 구성을 수정합니다.
- 볼륨을 분리하고 원래 탑재 지점에 있는 원래 인스턴스에 다시 연결합니다.
- 인스턴스를 시작합니다.
- 필요한 경우 탄력적 IP 주소를 다시 연결합니다.
IO 다시 활성화
안전을 위해 EBS 볼륨에 대한 IO 액세스가 비활성화되었을 수 있습니다. 이 경우 다음을 수행하십시오.
- 관리 콘솔의 EBS 볼륨으로 이동합니다. 볼륨의 IO가 비활성화된 경우 볼륨의 "Status Checks" 열이 "Impaired"로 표시됩니다.
- 콘솔의 볼륨 세부 정보 섹션에서 "Enable Volume IO"를 클릭하여 IO를 다시 활성화할 수 있습니다.
- fsck 또는 chkdsk와 같은 도구를 사용하여 데이터의 일관성을 확인하는 것이 좋습니다.
- 인스턴스가 응답하지 않는 경우 운영 체제에 따라 IO를 재개하면 인스턴스가 서비스를 시작할 수 있습니다.
데이터 복구
인스턴스가 EBS-Backed인 경우, 내부 구성과 관련된 문제(대부분 콘솔 출력에 자세한 정보가 표시됨)로 인해 실패했고 표준 재부팅을 수행할 수 없다면 다음 단계를 수행하여 데이터를 복구할 수 있습니다.
- 제대로 부팅되지 않는 인스턴스를 중지합니다(종료하지는 마십시오).
- 루트 EBS 볼륨을 분리합니다.
- 같은 가용 영역의 새 대체 인스턴스(가급적 이전에 번들링된 AMI에서 시작된 인스턴스)에 볼륨을 연결하여 두 번째 탑재 지점(루트 아님)을 사용하도록 합니다.
- 볼륨에서 대체 인스턴스로 데이터를 복사합니다.
추가 리소스
아키텍처를 개선하거나, 모범 사례를 파악하거나, 문제에 대비하려는 고객이 사용할 수 있는 여러 가지 리소스가 있습니다.
- 인스턴스 오류에 대비한 아키텍처를 구축하는 방법에 대한 자세한 내용은 AWS Cloud 백서의 Designing Fault-Tolerant Applications에 설명되어 있습니다.
- 사용자 정의 AMI를 번들링하여 항상 작업 중인 인스턴스 구성의 백업을 만드는 것이 좋습니다.
- Amazon EC2 사용 설명서에는 장애 극복 애플리케이션 개념에 관한 PDF가 포함되어 있습니다.
기본 호스트에 문제가 있는 경우 인스턴스가 “중지 중”인 상태에서 멈춰 있습니다. 인스턴스를 강제로 중지하면 이 문제를 해결할 수 있습니다. EC2 명령줄 도구나 AWS Management Console을 통해 중지할 수 있습니다.
명령줄 도구
ec2-stop-instances [ID] --force
AWS Management Console
인스턴스를 마우스 오른쪽 버튼으로 클릭하고 드롭다운에서 “Stop”을 선택합니다. 이때 강제 중지를 수행한다는 메시지가 표시되어야 합니다.
참고: 두 경우 모두 강제 중지 요청을 두 번 보내야 할 수도 있습니다.
인스턴스를 강제로 중지할 수 없는 경우, 대체 인스턴스를 시작할 수도 있습니다. 인스턴스 중지 문제 해결을 참조하십시오. 그래도 해결되지 않는 경우 AWS 포럼을 통해서나, AWS Support 사례를 등록하여 알려 주십시오. 문제를 빠르게 해결하려면 지원을 요청하기까지 이미 수행한 모든 단계를 알려주십시오.
평소보다 오랫동안 “종료 중”인 상태의 인스턴스는 결국 Amazon EC2 서비스 내의 자동화된 프로세스를 통해 정리됩니다. 인스턴스가 "실행 중" 상태에 있지 않은 인스턴스 시간에 대해서는 요금이 부과되지 않습니다.
인스턴스가 종료될 때까지 기다릴 수 없으면 AWS 포럼을 통해, 또는 AWS Support 사례를 등록하여 알려 주십시오. 문제를 빠르게 해결하려면 지원을 요청하기까지 이미 수행한 모든 단계를 알려주십시오.