리소스 과다 사용으로 인해 상태 확인에 실패한 EC2 Linux 인스턴스와 관련된 문제를 해결하려면 어떻게 해야 합니까?

6분 분량

더 이상 사용 가능한 리소스가 없기 때문에 Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스 상태 확인에 실패했습니다.

간략한 설명

다음과 같은 이유로 리소스 사용량 때문에 인스턴스의 상태 확인에 실패할 수 있습니다.

인스턴스의 CPU 사용률이 100%에 근접하고 인스턴스에 커널을 실행할 컴퓨팅 용량이 충분하지 않습니다.
루트 디바이스가 100% 꽉 차서 다른 프로세스를 완료하거나 시작할 수 없습니다.
인스턴스에서 실행되는 프로세스가 메모리를 전부 소진하여 커널 실행을 허용하지 않습니다.

해결 방법

중요: 인스턴스를 중지하고 시작하기 전에 다음 작업을 수행하십시오.

Amazon Elastic Block Store(Amazon EBS) 볼륨의 스냅샷을 생성합니다.
참고: 인스턴스가 인스턴스 저장소를 지원하거나 데이터가 포함된 인스턴스 저장소 볼륨을 보유하는 경우 인스턴스를 중지하면 Amazon EC2에서 해당 데이터를 삭제합니다.
Amazon EC2 Auto Scaling 그룹에서 인스턴스를 일시적으로 제거합니다.
참고: Amazon EC2 Auto Scaling 그룹에 속한 인스턴스를 중지하면 축소 보호 설정에 따라 인스턴스가 종료될 수 있습니다. Amazon EMR, AWS CloudFormation 또는 AWS Elastic Beanstalk를 사용하여 시작하는 인스턴스는 Auto Scaling 그룹에 속할 수 있습니다.
인스턴스를 중지해도 인스턴스가 종료되지 않도록 하려면 인스턴스 종료 동작을 중지로 설정합니다.

인스턴스를 중지하고 시작하여 커널에서 실행 중인 프로세스를 강제로 중지하도록 합니다. 이는 리소스를 운영 체제(OS)에 반환하는 임시 솔루션입니다. 과다 사용 문제를 해결하려면 다음 조치를 취하여 근본 원인을 해결하십시오.

참고: 인스턴스를 중지하고 시작할 때 인스턴스의 퍼블릭 IP 주소가 변경됩니다. 퍼블릭 IP 주소 대신 탄력적 IP 주소를 사용하여 외부 트래픽을 인스턴스로 라우팅하는 것이 가장 좋습니다.

인스턴스의 CloudWatch CPU 지표 확인

인스턴스의 Amazon CloudWatch CPUUtilization 지표가 100%이거나 거의 100%에 가까운지 확인합니다. 그렇다면 인스턴스를 재부팅하여 인스턴스를 정상 상태로 되돌립니다. 재부팅 후에도 문제가 계속 발생하면 인스턴스의 CPU 요구 사항이 해당 인스턴스 유형이 제공하는 것보다 높은 것입니다.

이 문제를 해결하려면 CPU 가용성이 더 높은 인스턴스 유형으로 변경하십시오.

인스턴스가 성능 버스트 가능 인스턴스(예: T2, T3 또는 T3a)라면 CPUCreditBalance 지표를 확인합니다. 크레딧 잔액이 0에 가까울 경우 Amazon EC2는 인스턴스 CPU를 제한합니다. 인스턴스의 크레딧 사양을 표준으로 설정한 경우 무제한으로 사양을 변경하십시오.

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

"No space left on device" 또는 "Out of memory" 같은 오류가 있는지 시스템 로그를 확인합니다.

"No space left on device" 오류 해결

나열된 폴더가 포함된 파일 시스템이 가득 차면 다음 예와 비슷한 오류가 나타납니다.

"OSError: [Error 28] No space left on device '/var/lib/'"

위 예제에서는 /var/lib가 가득 찼습니다.

스페이스를 확보하려면 EC2 직렬 콘솔을 사용하여 지원되는 Nitro 기반 인스턴스 유형 및 지원되는 베어 메탈 인스턴스에 연결합니다. 그런 다음 불필요한 파일을 삭제합니다. EC2 직렬 콘솔을 사용할 때는 인스턴스에 연결하는 데 기능적 연결이 필요하지 않습니다.

이전에 EC2 직렬 콘솔을 사용한 적이 없다면 사전 요구 사항을 준수해야 합니다. 인스턴스에 연결할 수 없고 아직 직렬 콘솔에 대한 액세스를 구성하지 않은 경우 EC2 직렬 콘솔을 사용할 수 없습니다.

EC2 직렬 콘솔을 사용할 수 없는 경우 다음 단계를 완료하여 복구 인스턴스를 시작하고 불필요한 파일을 제거하십시오.

가상 프라이빗 클라우드(VPC)에서 새 복구 인스턴스를 시작합니다. 상태 확인에 실패한 인스턴스와 동일한 Amazon Machine Image(AMI) 및 동일한 가용 영역을 사용합니다.
참고: 원본 인스턴스와 동일한 가용 영역에 있고 동일한 AMI를 사용하는 기존 인스턴스를 사용할 수도 있습니다.
원본 인스턴스를 중지합니다.
/dev/xvda 또는 /dev/sda1과 같은 Amazon Elastic Block Store(Amazon EBS) 루트 볼륨을 원본 인스턴스와 분리합니다. 루트 볼륨의 디바이스 이름을 기록해 두십시오.
복구 인스턴스에 /dev/sdf 보조 디바이스로 볼륨을 연결합니다.
SSH를 사용하여 복구 인스턴스에 연결합니다.
복구 인스턴스에 연결한 볼륨의 마운트 지점 디렉터리를 생성하려면 다음 명령을 실행합니다.
```
sudo mkdir /rescue
```
참고: /rescue를 마운트 지점 디렉터리 이름으로 대체하십시오.
루트 사용자로 다음 명령을 실행하여 올바른 디바이스 이름을 확인합니다.
```
sudo -i
# lsblk
```
참고: 복구 인스턴스에 연결된 디바이스는 디바이스 이름이 다를 수 있습니다.
볼륨을 새 디렉터리에 마운트하려면 다음 명령을 실행합니다.
```
sudo mount /dev/xvdf1 /rescue
```
참고: dev/xvdf1을 루트 볼륨의 디바이스 이름으로, /rescue를 마운트 지점 디렉터리 이름으로 대체하십시오. 위 명령을 실행할 때 오류가 발생하면 Amazon EBS 볼륨을 마운트할 수 없는 이유는 무엇입니까?를 참조하십시오.

가장 많은 스페이스를 차지하는 파일을 식별하려면 다음 명령을 실행합니다.

du -shcm /rescue/var/lib/* |sort -n

스페이스를 확보하려면 필요하지 않은 대용량 파일을 삭제하십시오.
복구 인스턴스에서 보조 디바이스를 마운트 해제하려면 다음 명령을 실행합니다.

sudo umount /rescue

참고: /rescue를 마운트 지점 디렉터리 이름으로 대체하십시오.
마운트 해제 작업이 실패하면 복구 인스턴스를 중지하거나 재부팅하십시오. 그런 다음 위 명령을 다시 실행합니다. 복구 인스턴스에서 보조 볼륨을 분리합니다. /dev/xvda 또는 /dev/sda1 루트 볼륨으로 원본 인스턴스에 루트 볼륨을 연결합니다. 인스턴스를 시작한 다음 인스턴스가 응답하는지 확인합니다.

여전히 사용 가능한 스토리지가 충분하지 않은 경우 다음 단계를 완료하여 루트 EBS 볼륨의 크기를 조정하십시오.

EBS 볼륨 크기 수정을 요청합니다.
이전 섹션의 1~8단계에 따라 복구 인스턴스를 시작합니다.
Linux 파일 시스템을 확장합니다.

"Out of memory" 오류 해결

인스턴스의 메모리가 부족하면 다음과 같은 오류가 발생합니다.

"Out of memory: kill process"

인스턴스의 메모리가 부족하면 커널의 메모리가 부족해져 Amazon EC2에서 메모리를 확보하기 위해 다른 프로세스를 종료합니다. 문제 해결 단계는 Out of memory: kill process를 참조하십시오.

메모리 로그를 확인하려면 이전 섹션의 1~8단계에 따라 복구 인스턴스를 시작하십시오. 그런 다음 Linux 배포를 기반으로 다음 명령을 실행하여 로그에서 "out of memory" 메시지를 검색합니다.

Amazon Linux 2(AL2):

sudo grep -i -r 'out of memory' /var/log/

Amazon Linux 2023(AL2023):

sudo journalctl -p err | grep -i "out of memory"

-또는-

sudo dmesg | grep -i "out of memory"

페이지 할당 실패 문제 해결

커널 메모리 할당자가 할당 요청에 실패하면 "page allocation failure" 오류가 발생합니다.

이 문제를 해결하려면 인스턴스를 더 큰 인스턴스 유형으로 업그레이드하는 것이 가장 좋습니다. 또는 임시 인스턴스 스토어 볼륨을 사용하는 인스턴스의 경우 스왑 파일 또는 하드 드라이브 파티션을 사용하여 인스턴스에 스왑 스토리지를 추가하여 메모리 부족 문제를 줄일 수 있습니다.

참고: 인스턴스는 RAM이 가득 차면 스왑 공간을 사용합니다. RAM 용량이 적은 인스턴스에 스왑 공간을 사용할 수 있습니다. 그러나 스왑 공간으로 RAM 추가 용량을 대체할 수는 없습니다. 스왑 공간은 인스턴스의 하드 드라이브에 있기 때문에 RAM보다 성능이 느립니다. 더 많거나 더 빠른 메모리를 원하면 인스턴스 크기를 늘려야 합니다.

atop을 사용하여 리소스 문제 조사 및 예방

atop 모니터링 도구를 사용하여 시스템 장애가 발생하기 전에 문제를 일으킬 수 있는 리소스 사용 패턴 및 프로세스를 식별하십시오. atop 도구를 사용하면 시스템을 지속적으로 모니터링하고 문제를 해결할 수 있습니다.

참고: atop 도구는 설치된 후에만 데이터를 로깅합니다. atop 도구를 설치하기 전의 과거 성능 데이터는 검색할 수 없습니다.

atop 도구를 사용하여 다음 리소스를 확인하십시오.

장애 발생 시 **/var/log/atop/**에서 과거 데이터를 확인하여 시스템과 프로세스를 분석합니다.
많은 리소스를 소비하는 프로세스를 찾아봅니다.
장애를 일으킨 메모리, CPU 및 디스크 사용 패턴을 확인합니다.