AWS EC2 인스턴스 부팅 시 발생하는 “Instance Reachability Check Failed” 오류는 인스턴스 내부의 운영체제(OS) 수준에서 심각한 문제가 발생하여 인스턴스 자체에 아무런 접근(SSH, RDP 등)이 불가능해진 상태임을 의미합니다. 이는 AWS 인프라 측의 문제(시스템 상태 체크 실패)가 아닌, 사용자가 직접 관리하는 OS 또는 애플리케이션 리소스 측의 문제(인스턴스 상태 체크 실패)를 명확히 나타내는 오류입니다. 따라서 이 오류를 해결하려면 인스턴스에 직접 접근할 수 없는 상황에서도 문제의 근본 원인을 정확히 진단하고, 적절한 복구 절차를 수행해야 합니다.
AWS EC2 인스턴스 부팅 시 발생하는 “Instance Reachability Check Failed” 오류는 인스턴스 내부의 운영체제(OS) 수준에서 심각한 문제가 발생하여 인스턴스 자체에 아무런 접근(SSH, RDP 등)이 불가능해진 상태임을 의미합니다. 이는 AWS 인프라 측의 문제(시스템 상태 체크 실패)가 아닌, 사용자가 직접 관리하는 OS 또는 애플리케이션 리소스 측의 문제(인스턴스 상태 체크 실패)를 명확히 나타내는 오류입니다. 따라서 이 오류를 해결하려면 인스턴스에 직접 접근할 수 없는 상황에서도 문제의 근본 원인을 정확히 진단하고, 적절한 복구 절차를 수행해야 합니다.
1. Reachability Check 실패의 주요 원인
Instance Reachability Check는 AWS가 인스턴스의 하이퍼바이저를 통해 OS가 부팅되고 네트워크에 응답하는지를 확인하는 과정입니다. 실패는 주로 다음 네 가지 문제 때문에 발생합니다.
- 부트 볼륨(Root Volume) 손상: 파일 시스템 오류, 디스크 I/O 오류 또는 부트 로더 손상으로 인해 OS가 정상적으로 부팅되지 못한 경우입니다.
- 시스템 리소스 고갈: 부팅 시 메모리(RAM)나 CPU 리소스가 과도하게 사용되어 시스템 응답이 멈춘 경우입니다. (예: 시작 시 과도한 서비스 실행)
- 네트워크 설정 오류: 인스턴스 내 OS 수준에서 네트워크 인터페이스 설정이 잘못되어 네트워크 연결이 끊기거나 차단된 경우입니다. (예:
ifcfg파일 오류, 잘못된 정적 IP 설정) - 운영체제 문제: 커널 패닉(Kernel Panic), 서비스 충돌 또는 시스템 업데이트 실패 등으로 OS가 응급 모드에 갇힌 경우입니다.
2. 해결 전략: 복구 인스턴스를 통한 부트 볼륨 복구
인스턴스에 직접 접근할 수 없으므로, 원본 인스턴스의 부트 볼륨(Root Volume)을 분리하여 정상적인 다른 인스턴스(복구 인스턴스)에 마운트한 후 파일 시스템을 수정하는 것이 표준 해결 방법입니다.
부트 볼륨은 컴퓨터를 켜서 운영 체제가 실행될 수 있도록 하는 데 필요한 시스템 파일들을 저장하는 공간입니다.
단계 1: 문제의 부트 볼륨 식별 및 분리
- 원본 인스턴스 중지: Reachability Check가 실패한 인스턴스를 “중지(Stop)”합니다. (강제 종료(Terminate)가 아님)
- 부트 볼륨 분리: EC2 콘솔에서 중지된 인스턴스를 선택하고 스토리지 탭으로 이동합니다. 루트 디바이스(예:
/dev/sda1또는/dev/xvda)로 지정된 EBS 볼륨 ID를 확인합니다. 해당 볼륨을 인스턴스에서 “볼륨 분리(Detach Volume)”합니다.
단계 2: 복구 인스턴스에 마운트 및 수정
- 복구 인스턴스 준비: 문제의 볼륨과 동일한 가용 영역(AZ)에 새로운 EC2 인스턴스(복구 인스턴스)를 시작합니다. (동일한 OS 계열(Linux to Linux, Windows to Windows)을 선택하는 것이 작업에 편리합니다.)
- 볼륨 연결: 분리한 문제의 부트 볼륨을 복구 인스턴스에 보조 볼륨으로 연결합니다. 장치 이름은
/dev/sdf나/dev/sdg와 같이 OS가 루트 볼륨으로 인식하지 않는 이름으로 지정합니다. - 파일 시스템 검사 (리눅스):
- 복구 인스턴스에 SSH로 접속하여 볼륨을 마운트합니다. (
sudo mount /dev/xvdf1 /mnt) - 볼륨을 마운트하기 전에 파일 시스템 손상이 의심되면,
e2fsck -f /dev/xvdf1명령을 사용하여 파일 시스템 오류를 수정할 수 있습니다.
- 복구 인스턴스에 SSH로 접속하여 볼륨을 마운트합니다. (
- 네트워크 설정 복구:
- 마운트된 볼륨 내에서 손상된 네트워크 설정 파일(예:
/mnt/etc/network/interfaces또는/mnt/etc/sysconfig/network-scripts/ifcfg-eth0)을 찾아 정적 IP 설정을 제거하고 DHCP로 변경합니다. (가장 흔한 IP 충돌 원인 해결) - 커널 패닉이 의심되면
/mnt/var/log/messages또는/mnt/var/log/syslog를 확인하여 부팅 시퀀스의 오류를 분석합니다.
- 마운트된 볼륨 내에서 손상된 네트워크 설정 파일(예:
단계 3: 볼륨 재연결 및 테스트
- 볼륨 분리: 복구 인스턴스에서 문제의 볼륨을 “언마운트(unmount)”한 후, EC2 콘솔에서 “볼륨 분리”합니다.
- 원본 인스턴스에 연결: 이 볼륨을 원래의 문제 인스턴스에 다시 루트 디바이스 이름으로 연결합니다. (예:
/dev/sda1) - 인스턴스 시작: 문제 인스턴스를 “시작(Start)”합니다.
3. 부수적인 진단 및 해결 방법
위의 표준 복구 절차가 복잡하거나 불가능할 경우, 다른 방법으로 접근을 시도할 수 있습니다.
- 시스템 로그 확인: 인스턴스를 중지하기 전에 EC2 콘솔에서 모니터링 탭의 “인스턴스 설정” -> “시스템 로그 가져오기(Get System Log)”를 클릭합니다. 이 로그는 부팅 과정을 텍스트로 보여주며, 커널 패닉이나 특정 서비스 오류 메시지를 통해 문제의 정확한 원인을 진단할 수 있습니다.
- 새 인스턴스로 교체: 복구 시간이 촉박하고 데이터 유실이 크지 않은 경우, 문제 인스턴스 대신 해당 AMI(최신 Snapshot)로 새로운 인스턴스를 시작하여 즉시 서비스를 재개합니다. (단, 설정 문제가 AMI 자체에 있었다면 새 인스턴스도 같은 문제를 겪을 수 있습니다.)
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.
답글 남기기