EC2 Linux 인스턴스가 리소스 과다 사용으로 인해 인스턴스 상태 확인에 실패했습니다. 이 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

인스턴스가 리소스 과다 사용으로 인해 상태 확인에 실패할 수 있는 몇 가지 이유가 있습니다. 다음은 리소스 과다 사용으로 인해 상태 확인이 실패할 수 있는 가장 일반적인 세 가지 이유입니다.

• 인스턴스의 CPU 사용률이 거의 100%에 도달했으며 인스턴스의 컴퓨팅 용량이 부족하여 커널을 실행할 수 없습니다.
• 루트 디바이스가 100% 꽉 찼기 때문에 다른 프로세스가 완료되거나 시작되지 않습니다.
• 인스턴스에서 실행 중인 프로세스가 모든 메모리를 사용하므로 커널이 실행되지 않습니다.

해결 방법

Amazon CloudWatch CPU 사용률 지표 확인

인스턴스의 CloudWatch 지표를 확인합니다. CPU 사용률이 100%에 도달했거나 100%에 근접한 경우 다음 옵션을 사용하여 문제를 해결합니다.

• 인스턴스를 재부팅하여 정상 상태로 되돌립니다.
  참고: 인스턴스 CPU 요구 사항이 현재 인스턴스 유형이 제공할 수 있는 것보다 높으면 재부팅 후 문제가 다시 발생합니다.
• CPU 요구 사항에 맞는 인스턴스 유형으로 인스턴스를 변경해 보세요.
• 인스턴스가 버스트 가능 성능 인스턴스(T2, T3 또는 T3a)인 경우 인스턴스의 지표를 나열하여 CPUCreditBalance를 확인합니다. CloudWatch 콘솔 또는 AWS Command Line Interface(AWS CLI)를 사용하여 지표를 나열할 수 있습니다.
  크레딧 잔고가 0에 가까우면 인스턴스 CPU가 조절될 수 있습니다. 크레딧 사양이 인스턴스에서 표준으로 설정된 경우 사양을 무제한으로 변경할 수 있습니다. 크레딧 사양 변경에 대한 자세한 내용은 성능 순간 확장 가능 인스턴스의 크레딧 사양 수정을 참조하세요.

참고: AWS CLI 명령을 실행할 때 오류가 발생하는 경우 최신 버전의 AWS CLI를 사용하고 있는지 확인하세요.

인스턴스의 시스템 로그에 오류가 있는지 확인

시스템 로그에 No space left on device(디바이스에 남은 공간 없음) 또는 **Out of memory(메모리 부족)**라는 오류가 있는지 확인합니다.

디바이스에 남은 공간 없음 오류

인스턴스의 시스템 로그에 ‘OSError: [Errno 28] No space left on device '/var/lib/’와 유사한 오류가 나타나면 나열된 폴더가 포함된 파일 시스템이 가득 찬 것입니다. (이 예에서는 /var/lib가 폴더입니다.)

다음 방법 중 하나를 사용하여 파일 시스템의 공간을 확보할 수 있습니다.

방법 1: EC2 직렬 콘솔 사용

Linux용 EC2 직렬 콘솔을 활성화한 경우 이 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형의 문제를 해결할 수 있습니다. 직렬 콘솔을 사용하면 부팅 문제, 네트워크 구성 및 SSH 구성 문제를 해결할 수 있습니다. 직렬 콘솔은 작동 중인 네트워크 연결 없이 인스턴스에 연결됩니다. Amazon EC2 콘솔 또는 AWS CLI를 사용하여 직렬 콘솔에 액세스할 수 있습니다.

직렬 콘솔을 사용하기 전에 계정 수준에서 액세스 권한을 부여합니다. 그런 다음 IAM 사용자에게 액세스 권한을 부여하는 AWS Identity and Access Management(IAM) 정책을 생성합니다. 또한 직렬 콘솔을 사용하는 모든 인스턴스에는 암호 기반 사용자가 한 명 이상 포함되어야 합니다. 인스턴스에 연결할 수 없고 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 방법 2: 복구 인스턴스 사용의 지침을 따릅니다. Linux용 EC2 직렬 콘솔 구성에 대한 자세한 내용은 EC2 직렬 콘솔에 대한 액세스 구성을 참조하세요.

방법 2: 복구 인스턴스 사용

경고: 인스턴스를 중지하고 시작하기 전에 다음을 이해해야 합니다.

• 사용하는 인스턴스가 인스턴스 스토어 지원 인스턴스이거나 데이터가 포함된 인스턴스 스토어 볼륨이 있으면 인스턴스를 중지할 때 데이터가 손실됩니다. 자세한 내용은 인스턴스의 루트 디바이스 유형 확인을 참조하세요.
• 인스턴스가 Amazon EC2 Auto Scaling 그룹의 일부인 경우 인스턴스를 중지하면 인스턴스가 종료될 수 있습니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk를 사용하여 인스턴스를 시작한 경우 인스턴스가 AWS Auto Scaling 그룹의 일부일 수 있습니다. 이 시나리오에서 인스턴스의 종료는 Auto Scaling 그룹에 대한 인스턴스 확대 보호 설정에 따라 달라집니다. 인스턴스가 Auto Scaling 그룹의 일부인 경우, 문제 해결 단계를 시작하기 전에 Auto Scaling 그룹에서 일시적으로 인스턴스 제거합니다.
• 인스턴스를 중지하고 다시 시작하면 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 외부 트래픽을 인스턴스로 라우팅할 때에는 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하는 것이 모범 사례입니다. Amazon Route 53을 사용하는 경우 퍼블릭 IP가 변경될 때 Route 53 DNS 레코드를 업데이트해야 할 수 있습니다.

1.    손상된 인스턴스와 동일한 가용 영역에서 동일한 Amazon Machine Image(AMI)를 사용하여 Virtual Private Cloud(VPC)에서 새 EC2 인스턴스를 시작합니다. 새 인스턴스가 복구 인스턴스가 됩니다.

또는 액세스할 수 있는 기존 인스턴스가 동일한 AMI를 사용하고 손상된 인스턴스와 동일한 가용 영역에 있는 경우 이 인스턴스를 사용할 수 있습니다.

2.    손상된 인스턴스를 중지합니다.

3.    손상된 인스턴스에서 Amazon Elastic Block Store(Amazon EBS) 루트 볼륨(/dev/xvda 또는 /dev/sda1)을 분리합니다. 루트 볼륨의 디바이스 이름(/dev/xvda 또는 /dev/sda1)을 기록해 둡니다.

4.    복구 인스턴스에 보조 디바이스(/dev/sdf)로 EBS 볼륨을 연결합니다.

5.    SSH를 사용하여 복구 인스턴스에 연결합니다.

6.    복구 인스턴스에 연결된 새 볼륨의 마운트 지점 디렉터리(/rescue)를 생성합니다.

$ sudo mkdir /rescue

7.    6단계에서 생성한 디렉터리에 볼륨을 마운트합니다.

$ sudo mount /dev/xvdf1 /rescue

참고: 디바이스(/dev/xvdf1)가 다른 디바이스 이름으로 복구 인스턴스에 연결되었을 수 있습니다. lsblk 명령을 사용하여 사용 가능한 디스크 디바이스와 마운트 지점을 보고, 올바른 디바이스 이름을 확인하세요.

8.    du -h 명령을 실행하여 어떤 파일이 가장 많은 공간을 차지하는지 확인합니다.

du -h /rescue/var/lib

9.    필요에 따라 파일을 삭제하여 추가 공간을 확보합니다.

10.    unmount 명령을 실행하여 복구 인스턴스에서 보조 디바이스의 마운트를 해제합니다.

$ sudo umount /rescue

마운트 해제 작업에 실패할 경우 복구 인스턴스를 중지하거나 재부팅하여 클린 마운트 해제를 해야 할 수 있습니다.

11.    복구 인스턴스에서 보조 볼륨(/dev/sdf)을 분리합니다. 그런 다음 원본 인스턴스에 /dev/xvda(루트 볼륨)로 연결합니다.

12.    인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.

메모리 부족 오류

인스턴스의 시스템 로그에 ‘Out of memory: kill process(메모리 부족: 프로세스 중지)’ 오류가 표시되면 인스턴스의 메모리가 소진된 것입니다. 메모리가 모두 소진되면 메모리가 부족하여 커널이 실행되지 않으며 메모리를 확보하기 위해 다른 프로세스가 종료됩니다.

메모리 부족(OOM) 문제를 해결하는 방법에 대한 자세한 내용은 메모리 부족: 프로세스 중지를 참조하세요.

---

관련 정보

EC2 Linux 인스턴스에 연결할 수 없고 상태 검사 중 하나 또는 둘 다 실패하는 이유는 무엇입니까?

EC2 Linux 인스턴스의 인스턴스 유형을 변경하기 전에 수행해야 할 단계는 무엇입니까?

EC2 Windows 인스턴스에서 높은 CPU 사용률을 진단하려면 어떻게 해야 합니까?