Amazon EC2 인스턴스 상태 확인(Status checks)

Amazon EC2 인스턴스 상태 확인(Status checks)

상태 확인으로 인스턴스가 애플리케이션을 실행하지 못하게 할 수 있는 문제가 있는지 빠르게 판단할 수 있어요. 이 절에서 네 가지 유형의 상태 확인을 살펴볼게요.

출처: 문서

본문

상태 확인으로 인스턴스가 애플리케이션을 실행하지 못하게 할 수 있는 문제가 있는지 빠르게 판단할 수 있어요. Amazon EC2는 네 가지 유형의 상태 확인을 제공해요: system(시스템), instance(인스턴스), attached EBS(연결된 EBS), application(애플리케이션). 시스템, 인스턴스, 연결된 EBS 상태 확인은 Amazon EC2가 관리하며 모든 인스턴스에서 자동으로 실행돼요. 애플리케이션 상태 확인은 옵트인이며 인스턴스에서 실행되는 애플리케이션의 HTTP 또는 HTTPS 응답을 모니터링해요. 모든 상태 확인의 결과는 Amazon EC2 콘솔, AWS CLI, AWS SDK에서 볼 수 있어요.

상태 확인은 매분 수행되며 pass 또는 fail 상태를 반환해요. 모든 확인이 통과하면 인스턴스의 전체 상태는 OK예요. 하나 이상의 확인이 실패하면 전체 상태는 impaired예요. 시스템, 인스턴스, 연결된 EBS 상태 확인은 Amazon EC2가 관리하며 비활성화하거나 삭제할 수 없어요. 애플리케이션 상태 확인은 옵트인이며 직접 만들고, 연결하고, 관리해요.

상태 확인이 실패하면 상태 확인에 해당하는 CloudWatch 지표가 증가해요. 자세한 내용은 Status check metrics를 참고하세요. 이러한 지표를 사용해 상태 확인 결과에 따라 트리거되는 CloudWatch 경보를 만들 수 있어요. 예를 들어 특정 인스턴스에서 상태 확인이 실패하면 경고하는 경보를 만들 수 있어요. 자세한 내용은 Create CloudWatch alarms for Amazon EC2 instances that fail status checks을 참고하세요.

또한 Amazon EC2 인스턴스를 모니터링하고 기본 문제로 인해 인스턴스가 impaired 상태가 되면 자동으로 복구하는 Amazon CloudWatch 경보를 만들 수 있어요. 자세한 내용은 Automatic instance recovery를 참고하세요.

상태 확인 유형

네 가지 유형의 상태 확인이 있어요.

시스템 상태 확인

시스템 상태 확인은 인스턴스가 실행되는 AWS 시스템을 모니터링해요. 이 확인은 AWS의 개입이 필요한 인스턴스의 기본 문제를 감지해요. 시스템 상태 확인이 실패하면 AWS가 문제를 고칠 때까지 기다리거나 직접 해결할 수 있어요. Amazon EBS 백업 인스턴스의 경우 인스턴스를 직접 중지·시작할 수 있으며, 대부분의 경우 인스턴스가 새 호스트로 마이그레이션돼요. 인스턴스 스토어 백업 인스턴스(Linux 인스턴스에서만 지원)의 경우 인스턴스를 종료하고 교체할 수 있어요. 참고로 인스턴스 스토어 볼륨은 임시적이며 인스턴스가 중지되면 모든 데이터가 손실돼요.

시스템 상태 확인이 실패할 수 있는 문제의 예는 다음과 같아요.

  • 네트워크 연결 손실
  • 시스템 전원 손실
  • 물리 호스트의 소프트웨어 문제
  • 네트워크 도달 가능성에 영향을 주는 물리 호스트의 하드웨어 문제

시스템 상태 확인이 실패하면 StatusCheckFailed_System 지표가 증가해요.

베어 메탈 인스턴스

베어 메탈 인스턴스에서 재시작을 수행하면 시스템 상태 확인이 일시적으로 fail 상태를 반환할 수 있어요. 인스턴스가 사용 가능해지면 시스템 상태 확인이 pass 상태를 반환해야 해요.

인스턴스 상태 확인

인스턴스 상태 확인은 개별 인스턴스의 소프트웨어와 네트워크 연결을 모니터링해요. Amazon EC2는 네트워크 인터페이스(NIC)에 ARP(address resolution protocol) 요청을 보내 인스턴스의 상태를 확인해요. 이 확인은 수리하려면 여러분의 개입이 필요한 문제를 감지해요. 인스턴스 상태 확인이 실패하면 일반적으로 직접 문제를 해결해야 해요(예: 인스턴스 재부팅이나 인스턴스 구성 변경).

참고

네트워크 구성을 위해 systemd-networkd를 사용하는 최근 Linux 배포판은 이전 배포판과 다르게 상태 확인을 보고할 수 있어요. 부팅 프로세스 중 이 유형의 네트워크는 더 일찍 시작되어 인스턴스 상태에도 영향을 줄 수 있는 다른 시작 작업보다 먼저 완료될 수 있어요. 네트워크 가용성에 의존하는 상태 확인은 다른 작업이 완료되기 전에 정상 상태를 보고할 수 있어요.

인스턴스 상태 확인이 실패할 수 있는 문제의 예는 다음과 같아요.

  • 실패한 시스템 상태 확인
  • 잘못된 네트워킹 또는 시작 구성
  • 메모리 고갈
  • 손상된 파일 시스템
  • 호환되지 않는 커널
  • 재부팅 중에는 인스턴스가 다시 사용 가능해질 때까지 인스턴스 상태 확인이 실패를 보고할 수 있어요.

인스턴스 상태 확인이 실패하면 StatusCheckFailed_Instance 지표가 증가해요.

베어 메탈 인스턴스

베어 메탈 인스턴스에서 재시작을 수행하면 인스턴스 상태 확인이 일시적으로 fail 상태를 반환할 수 있어요. 인스턴스가 사용 가능해지면 인스턴스 상태 확인이 pass 상태를 반환해야 해요.

연결된 EBS 상태 확인

연결된 EBS 상태 확인은 인스턴스에 연결된 Amazon EBS 볼륨이 도달 가능하고 I/O 작업을 완료할 수 있는지 모니터링해요. StatusCheckFailed_AttachedEBS 지표는 인스턴스에 연결된 EBS 볼륨 중 하나 이상이 I/O 작업을 완료할 수 없으면 장애(impairment)를 나타내는 이진 값이에요. 이 상태 확인은 컴퓨팅 또는 Amazon EBS 인프라의 기본 문제를 감지해요. 연결된 EBS 상태 확인 지표가 실패하면 AWS가 문제를 해결할 때까지 기다리거나, 영향을 받는 볼륨 교체 또는 인스턴스 중지·재시작 같은 조치를 취할 수 있어요.

연결된 EBS 상태 확인이 실패할 수 있는 문제의 예는 다음과 같아요.

  • EBS 볼륨의 기본이 되는 스토리지 하위 시스템의 하드웨어 또는 소프트웨어 문제
  • EBS 볼륨의 도달 가능성에 영향을 주는 물리 호스트의 하드웨어 문제
  • 인스턴스와 EBS 볼륨 사이의 연결 문제

StatusCheckFailed_AttachedEBS 지표를 사용해 워크로드의 복원력을 개선할 수 있어요. 이 지표를 사용해 상태 확인 결과에 따라 트리거되는 Amazon CloudWatch 경보를 만들 수 있어요. 예를 들어 장기적인 영향이 감지되면 보조 인스턴스나 가용 영역으로 장애 조치할 수 있어요. 또는 EBS CloudWatch 지표로 각 연결된 볼륨의 I/O 성능을 모니터링해 장애 볼륨을 감지하고 교체할 수 있어요. EBS 상태 확인이 장애를 나타내고 워크로드가 연결된 EBS 볼륨에 I/O를 보내지 않는다면 인스턴스를 중지·시작해 새 호스트로 이동하세요. 이렇게 하면 EBS 볼륨의 도달 가능성에 영향을 주는 기본 호스트 문제를 해결할 수 있어요. 자세한 내용은 Amazon CloudWatch metrics for Amazon EBS를 참고하세요.

또한 Amazon EC2 Auto Scaling 그룹을 구성해 연결된 EBS 상태 확인 실패를 감지한 다음 영향받는 인스턴스를 새 인스턴스로 교체할 수 있어요. 자세한 내용은 Amazon EC2 Auto Scaling User Guide의 Monitor and replace Auto Scaling instances with impaired Amazon EBS volumes을 참고하세요.

참고

연결된 EBS 상태 확인 지표는 Nitro 인스턴스에서만 사용할 수 있어요.

애플리케이션 상태 확인

애플리케이션 상태 확인을 사용해 Amazon EC2 인스턴스에서 실행되는 애플리케이션의 네트워크 도달 가능성과 가용성을 모니터링해요. 애플리케이션 상태 확인으로 애플리케이션 수준에서 HTTP와 HTTPS 응답을 모니터링할 수 있어요. 애플리케이션 상태 확인은 연결한 인스턴스에서만 실행돼요.

각 애플리케이션 상태 확인을 구성해 애플리케이션 엔드포인트에서 HTTP 경로를 요청하고 정상 응답을 나타내는 응답 코드를 정의해요.

애플리케이션 재시작이나 배포 중에는 애플리케이션 상태 확인을 억제해 예상 가동 중단 동안 오탐(false-positive) 실패를 피할 수 있어요. 자세한 내용은 Handling deployment, in-place patching, and replacements을 참고하세요.

애플리케이션 상태 확인이 실패할 수 있는 문제의 예는 다음과 같아요.

  • 애플리케이션 프로세스가 충돌했거나 응답을 멈춤
  • 애플리케이션이 내부 애플리케이션 서비스 오류나 다른 문제를 나타내는 HTTP 응답 코드를 반환
  • 애플리케이션 포트에 도달할 수 없음
  • 소프트웨어 또는 기본 하드웨어 문제로 인스턴스가 실패해 응답하지 않게 됨

애플리케이션 상태 확인이 실패하면 StatusCheckFailed_Application 지표가 증가해요.

애플리케이션 상태 확인 구성에 대한 정보는 Application status checks를 참고하세요.

더 알아보기