기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Elastic Beanstalk의 향상된 상태 보고 및 모니터링
이 섹션에서는 Elastic Beanstalk Enhanced Health 기능의 여러 기능을 설명합니다.
확장 상태 보고는 사용자 환경에서 AWS Elastic Beanstalk가 환경의 리소스에 대한 추가 정보를 수집할 수 있도록 허용하는 기능입니다. Elastic Beanstalk는 수집된 정보를 분석하여 전반적인 환경 상태를 잘 파악하고 애플리케이션에 문제를 일으키는 원인을 확인합니다.
상태 색상이 작동되는 방식이 변경된 것 외에도 확장 상태는 상태 서술자를 통해 환경이 노란색이나 빨간색일 때 문제의 심각도를 나타냅니다. 현재 상태에 대한 자세한 내용을 보려면 상태 페이지에서 원인 버튼을 선택하여 자세한 상태 정보를 확인할 수 있습니다.
환경에서 실행 중인 Amazon EC2 인스턴스에 대한 자세한 상태 정보를 제공하기 위해 Elastic Beanstalk에는 확장 상태를 지원하는 각 플랫폼 버전에 대한 Amazon Machine Image(AMI)의 상태 확인 에이전트가 포함됩니다. 상태 확인 에이전트는 모니터링한 웹 서버 로그와 시스템 측정치를 Elastic Beanstalk 서비스로 전달합니다. Elastic Beanstalk는 이러한 측정치와 Elastic Load Balancing 및 Amazon EC2 Auto Scaling의 데이터를 분석하여 전반적인 환경 상태를 파악합니다.
Elastic Beanstalk는 환경 리소스에 대한 정보를 수집하고 제공하는 것 외에도, 다양한 오류 조건에 대한 환경 리소스를 모니터링하고 알림을 통해 오류를 피하고 구성 문제를 해결합니다. 환경 상태에 영향을 주는 요소로는 애플리케이션에서 처리된 각 요청 결과, 인스턴스 운영 체제의 측정치, 가장 최근의 배포 상태 등이 있습니다.
Elastic Beanstalk 콘솔의 환경 개요 페이지 또는 Elastic Beanstalk 명령줄 인터페이스(EB CLI)의 eb 상태 명령을 사용하여 실시간으로 상태를 확인할 수 있습니다. 사용자 지정 측정치에 따라 Elastic Beanstalk에서 수집한 확장 상태 보고에 대한 정보를 Amazon CloudWatch에 게시하도록 환경을 구성하여, 환경과 인스턴스 상태를 시간에 따라 기록하고 추적할 수 있습니다. 사용자 지정 측정치에 대한 CloudWatch 요금EnvironmentHealth
를 제외한 모든 측정치에 적용되며 무료입니다.
Windows 플랫폼 노트
Windows Server 환경에 대한 확장 상태 보고를 비활성화할 경우, IIS 로깅 구성
또한 환경의 모든 인스턴스에서 Elastic Beanstalk 상태 확인 에이전트 Windows 서비스를 비활성화하거나 중지하면 안 됩니다. 인스턴스에서 확장된 상태 정보를 수집해 보고하려면 이 서비스가 활성화되어 실행 중이어야 합니다.
Elastic Beanstalk에서 처음으로 환경을 생성할 때 필요한 역할을 생성하라는 메시지가 표시되고 기본적으로 향상된 상태 보고가 활성화됩니다. 계속해서 확장 상태 보고의 작동법에 대한 자세한 내용을 확인하거나 Elastic Beanstalk 확장 상태 보고 활성화 단원을 참조하여 바로 사용해 보세요.
주제
- Elastic Beanstalk 상태 확인 에이전트
- 인스턴스 및 환경 상태를 파악하는 요소
- 상태 확인 규칙 사용자 지정
- 향상된 상태 역할
- 확장된 상태 권한 부여
- 향상된 상태 이벤트
- 업데이트, 배포 및 조정 중 향상된 상태 보고 행동
- Elastic Beanstalk 확장 상태 보고 활성화
- 환경 관리 콘솔을 통해 향상된 상태 모니터링
- 상태 색상 및 상태
- 인스턴스 지표
- 환경에 대해 향상된 상태 규칙 구성
- 환경에 대한 Amazon CloudWatch 사용자 지정 측정치 게시
- Elastic Beanstalk API로 확장 상태 보고 사용
- 향상된 상태 로그 형식
- 알림 및 문제 해결
Elastic Beanstalk 상태 확인 에이전트
Elastic Beanstalk 상태 확인 에이전트는 환경의 각 Amazon EC2 인스턴스에서 실행되는 데몬 프로세스(또는 Windows 환경에서의 서비스)로, 운영 체제와 애플리케이션 수준의 상태 측정치를 모니터링하고 문제를 Elastic Beanstalk로 보고합니다. 상태 확인 에이전트는 각 플랫폼의 버전 2.0부터 모든 플랫폼 버전에 포함되어 있습니다.
상태 확인 에이전트는 CPU 부하, HTTP 코드, 지연 시간 등 Amazon EC2 Auto Scaling 및 Elastic Load Balancing에서 기본 상태 보고 시 CloudWatch에 게시하는 것과 비슷한 측정치를 보고합니다. 그러나 상태 확인 에이전트는 기본 상태 보고에 비해 세부 수준 및 빈도를 상세히 표시하여 Elastic Beanstalk로 바로 보고합니다.
기본 상태에서 이 측정치는 5분마다 게시되며 환경 관리 콘솔에 그래프로 모니터링화할 수 있습니다. 확장 상태에서 Elastic Beanstalk 상태 확인 에이전트는 10초마다 Elastic Beanstalk로 측정치를 보고합니다. Elastic Beanstalk는 상태 확인 에이전트에서 제공하는 측정치를 사용하여 각 환경 인스턴스의 상태를 확인하고, 다른 요소와 결합하여 전반적인 환경 상태를 파악합니다.
전반적인 환경 상태는 Elastic Beanstalk 콘솔의 환경 개요 페이지에서 실시간으로 확인할 수 있으며 Elastic Beanstalk에 의해 60초마다 CloudWatch에 게시됩니다. 상태 확인 에이전트에서 보고한 상세 측정치는 eb health 명령을 사용하여 EB CLI에서 실시간으로 확인할 수 있습니다.
추가 요금을 내면 각 인스턴스와 환경 수준 측정치를 60초마다 CloudWatch에 게시하도록 선택할 수 있습니다. 이후 CloudWatch에 게시된 측정치를 사용하여 환경 관리 콘솔에 모니터링 그래프를 만들 수 있습니다.
확장 상태 보고는 CloudWatch에 확장 상태 측정치를 게시하도록 선택한 경우에만 요금이 부과됩니다. 확장 상태를 사용할 때 확장 상태 측정치를 게시하도록 선택하지 않더라도 기본 상태 측정치를 무료로 게시할 수 있습니다.
상태 확인 에이전트에 의해 보고된 측정치의 자세한 내용은 인스턴스 지표 단원을 참조하세요. CloudWatch에 확장 상태 측정치를 게시하는 방법에 대한 자세한 내용은 환경에 대한 Amazon CloudWatch 사용자 지정 측정치 게시 단원을 참조하세요.
인스턴스 및 환경 상태를 파악하는 요소
Elastic Load Balancing 상태 확인 및 리소스 모니터링을 포함한 기본적인 상태 보고 시스템 확인 외에도, Elastic Beanstalk 확장 상태 보고는 환경 내 인스턴스 상태에 대한 추가 데이터를 수집합니다. 이에는 운영 체제 측정치, 서버 로그 및 배포와 업데이트를 비롯한 지속적인 환경 운영 상태가 포함됩니다. Elastic Beanstalk 상태 보고 서비스는 사용 가능한 모든 리소스의 정보를 통합하고 분석하여 전반적인 환경 상태를 파악합니다.
작업 및 명령
애플리케이션의 새 버전 배포와 같이 환경에서 작업을 수행할 때, Elastic Beanstalk는 환경 상태에 영향을 미치는 다양한 변경 사항을 적용합니다.
예를 들어 애플리케이션의 새 버전을 여러 인스턴스를 실행하는 환경에 배포하는 경우, EB CLI로 환경 상태를 모니터링할 때 다음과 유사한 메시지가 표시될 수 있습니다.
id status cause
Overall Info Command is executing on 3 out of 5 instances
i-bb65c145 Pending 91 % of CPU is in use. 24 % in I/O wait
Performing application deployment (running for 31 seconds)
i-ba65c144 Pending Performing initialization (running for 12 seconds)
i-f6a2d525 Ok Application deployment completed 23 seconds ago and took 26 seconds
i-e8a2d53b Pending 94 % of CPU is in use. 52 % in I/O wait
Performing application deployment (running for 33 seconds)
i-e81cca40 Ok
이 예제에서 전반적인 환경 상태는 Ok
이며 이 상태의 원인은 인스턴스 다섯 중 세 개에서 명령이 실행 중이기 때문입니다. 환경에서 인스턴스 세 개는 대기 중 상태이며, 진행 중인 작업을 나타냅니다.
작업이 완료되면 Elastic Beanstalk는 작업에 대한 추가 정보를 보고합니다. 예를 들어 Elastic Beanstalk는 애플리케이션의 새 버전으로 이미 업데이트된 인스턴스에 대한 다음 정보를 표시합니다.
i-f6a2d525 Ok Application deployment completed 23 seconds ago and took 26 seconds
인스턴스 상태 정보에는 최근 각 환경 인스턴스로의 배포에 대한 세부 정보도 있습니다. 각 인스턴스는 배포 ID와 상태를 보고합니다. 배포 ID는 애플리케이션의 새 버전을 배포하거나 환경 변수 등 온인스턴스 구성 옵션에 대한 설정을 변경할 때마다 하나씩 늘어나는 정수입니다. 배포 정보를 사용하여 롤링 배포를 실패한 경우 애플리케이션의 잘못된 버전을 실행하는 인스턴스를 파악할 수 있습니다.
Elastic Beanstalk는 여러 차례의 상태 확인에서 성공적으로 이루어진 작업 및 기타 상태 확인에 대한 정보 메시지를 원인 열에 표시하지만, 무기한으로 유지하지는 않습니다. 비정상적인 환경 상태의 원인은 환경이 정상 상태로 돌아올 때까지 유지됩니다.
명령 제한 시간
Elastic Beanstalk는 인스턴스가 정상 상태로 전환되도록 허용하는 작업 시작 시간부터 명령 제한 시간을 적용합니다. 이 명령 제한 시간은 환경의 업데이트 및 배포 구성(aws:elasticbeanstalk:command 네임스페이스)에서 설정하며 기본값은 10분입니다.
롤링 업데이트 동안 Elastic Beanstalk는 작업의 각 배치마다 개별 제한 시간을 적용합니다. 이 시간 제한은 환경의 롤링 업데이트 구성(aws:autoscaling:updatepolicy:rollingupdate 네임스페이스)의 일부로 설정합니다. 롤링 업데이트 시간 제한 내 배치의 모든 인스턴스가 정상인 경우 다음 배치로 작업이 이어집니다. 그렇지 않은 경우 작업이 실패하게 됩니다.
참고
애플리케이션이 양호(OK) 상태로써 상태 확인을 통과하지 않았으나 다른 수준에서 안정적이라면, aws:elasticbeanstalk:command namespace에서 HealthCheckSuccessThreshold
옵션을 설정하여 Elastic Beanstalk에서 인스턴스가 정상이라고 판단되는 기준을 변경할 수 있습니다.
웹 서버 환경이 정상이라고 판단되려면 환경 또는 배치의 각 인스턴스는 2분이라는 시간 동안 12번의 연속 상태 확인을 통과해야 합니다. 작업자 티어 환경에서 각 인스턴스는 18번의 상태 확인을 통과해야 합니다. 명령 제한 시간을 초과하기 전에는, 상태 확인에 실패하더라도 Elastic Beanstalk가 환경의 상태를 낮추지 않습니다. 환경의 인스턴스가 명령 제한 시간 안에 정상 상태가 되는 한, 작업은 성공입니다.
HTTP 요청
환경에서 진행 중인 작업이 없는 경우 인스턴스 및 환경 상태에 대한 정보의 주요 출처는 각 인스턴스의 웹 서버 로그입니다. 전반적인 환경 상태와 인스턴스 상태를 파악하기 위하여 Elastic Beanstalk는 요청 횟수, 각 요청 결과, 각 요청이 처리되는 속도를 고려합니다.
Linux 기반 플랫폼에서 Elastic Beanstalk가 웹 서버 로그를 읽고 구문 분석하여 HTTP 요청에 대한 정보를 가져옵니다. Windows Server 플랫폼에서 Elastic Beanstalk가 IIS 웹 서버로부터 직접 이 정보를 수신합니다.
사용자의 환경에는 활성 상태의 웹 서버가 없을 수 있습니다. 예를 들어 멀티컨테이너 Docker 플랫폼에는 웹 서버가 포함되어 있지 않습니다. 다른 플랫폼에는 웹 서버가 포함되며 사용자의 애플리케이션에서 그 웹 서버를 비활성화할 수 있습니다. 이런 경우에는 Elastic Beanstalk 서비스에 상태 정보를 전달하는 데 필요한 형식으로 Elastic Beanstalk 상태 확인 에이전트에 로그를 공급하기 위한 추가적인 구성이 환경에 필요합니다. 세부 정보는 향상된 상태 로그 형식 단원을 참조하세요.
운영 체제 지표
Elastic Beanstalk는 상태 확인 에이전트가 보고한 운영 체제 측정치를 모니터링하면서 시스템 리소스에서 지속적으로 부족한 인스턴스를 파악합니다.
상태 확인 에이전트에 의해 보고된 측정치의 자세한 내용은 인스턴스 지표 단원을 참조하세요.
상태 확인 규칙 사용자 지정
Elastic Beanstalk의 확장 상태 보고는 규칙 집합을 사용하여 환경 상태를 확인합니다. 이러한 규칙의 일부는 특정 애플리케이션에 적합하지 않을 수 있습니다. 대부분의 경우 그러한 애플리케이션은 설계상 HTTP 4xx 오류를 빈번하게 반환하는 애플리케이션입니다. 기본 규칙 중 하나를 사용하는 Elastic Beanstalk는 결과적으로 오류가 발생하며, 오류 상태에 따라 환경 상태를 정상에서 경고, 성능 저하 또는 심각으로 변경합니다. 이를 올바르게 처리하기 위해 Elastic Beanstalk에서 이 규칙을 구성하고 애플리케이션 HTTP 4xx 오류를 무시할 수 있습니다. 자세한 내용은 환경에 대해 향상된 상태 규칙 구성 단원을 참조하세요.
향상된 상태 역할
확장 상태 보고에는 두 가지 역할(Elastic Beanstalk에 대한 서비스 역할 및 환경에 대한 인스턴스 프로파일)이 필요합니다. 서비스 역할을 통해 Elastic Beanstalk는 사용자를 대신해 다른 AWS 서비스와 상호 작용하여 환경의 리소스에 대한 정보를 수집할 수 있습니다. 인스턴스 프로파일을 사용하면 사용자 환경의 인스턴스가 로그를 Amazon S3에 기록하고 확장 상태 정보를 Elastic Beanstalk 서비스에 전달할 수 있습니다.
Elastic Beanstalk 콘솔 또는 EB CLI를 사용하여 Elastic Beanstalk 환경을 생성하는 경우 Elastic Beanstalk는 기본 서비스 역할을 생성하고 필요한 관리형 정책을 사용자 환경의 기본 인스턴스 프로파일에 연결합니다.
API, SDK 또는 AWS CLI를 사용하여 환경을 생성하는 경우, 이러한 역할을 미리 만든 후 환경이 생성되는 동안 확장 상태 확인을 사용하도록 지정해야 합니다. 환경에 대한 적절한 역할을 생성하는 지침은 Elastic Beanstalk 서비스 역할, 인스턴스 프로파일, 사용자 정책 단원을 참조하세요.
인스턴스 프로파일 및 서비스 역할에 대해 관리형 정책을 사용하는 것이 좋습니다. 관리형 정책은 Elastic Beanstalk가 유지 관리하는 AWS Identity and Access Management(IAM) 정책입니다. 관리형 정책을 사용하면 환경이 제대로 작동하는 데 필요한 모든 권한을 갖게 됩니다.
인스턴스 프로파일의 경우 웹 서버 계층 또는 작업자 계층 환경에 대해 각각 AWSElasticBeanstalkWebTier
또는 AWSElasticBeanstalkWorkerTier
관리형 정책을 사용할 수 있습니다. 이러한 두 관리형 인스턴스 프로파일 정책에 대한 자세한 내용은 Elastic Beanstalk 인스턴스 프로파일 관리 단원을 참조하세요.
확장된 상태 권한 부여
Elastic Beanstalk 인스턴스 프로파일 관리형 정책에는 elasticbeanstalk:PutInstanceStatistics
작업에 대한 권한이 포함되어 있습니다. 이 작업은 Elastic Beanstalk API의 일부가 아닙니다. 환경 인스턴스에서 확장된 상태 정보를 Elastic Beanstalk 서비스에 전달하기 위해 내부적으로 사용하는 다른 API의 일부입니다. 이 API는 사용자가 직접 호출하지 않습니다.
새 환경을 생성할 때, elasticbeanstalk:PutInstanceStatistics
작업에 대한 인증은 기본적으로 활성화되어 있습니다. 환경의 보안을 강화하고 상태 데이터 스푸핑을 방지하도록 이 작업에 대한 권한 부여를 활성화하는 것이 좋습니다. 인스턴스 프로파일에 관리형 정책을 사용하는 경우, 추가 구성 없이 새 환경에서 이 기능을 사용할 수 있습니다. 그러나, 관리형 정책 대신 사용자 지정 인스턴스 프로파일을 사용하는 경우 환경에 데이터 없음 상태가 표시될 수 있습니다. 이는 인스턴스에 확장된 상태 데이터를 서비스에 전달하는 작업을 수행할 권한이 없기 때문에 발생합니다.
작업을 수행할 권한을 부여하려면 인스턴스 프로파일에 다음 문을 포함합니다.
{ "Sid": "ElasticBeanstalkHealthAccess", "Action": [ "elasticbeanstalk:PutInstanceStatistics" ], "Effect": "Allow", "Resource": [ "arn:aws:elasticbeanstalk:*:*:application/*", "arn:aws:elasticbeanstalk:*:*:environment/*" ] }
이번에는 향상된 인증을 사용하지 않으려는 경우 aws:elasticbeanstalk:healthreporting:system 네임스페이스스의 EnhancedHealthAuthEnabled
옵션을 false
(으)로 설정해서 비활성화합니다. 이 옵션을 비활성화하면 앞에서 설명한 권한이 필요하지 않습니다. 인스턴스 프로파일에서 해당 내용을 제거하여 애플리케이션 및 환경에 최소 권한 액세스를 적용할 수 있습니다.
참고
이전에 EnhancedHealthAuthEnabled
에 대한 기본 설정이 false
였기 때문에 elasticbeanstalk:PutInstanceStatistics
작업에 대한 권한 부여도 기본적으로 비활성화되어 있습니다. 기존 환경에 대해 이 옵션을 활성화하려면 aws:elasticbeanstalk:healthreporting:system 네임스페이스에서 EnhancedHealthAuthEnabled
옵션을 true
로 설정합니다. 구성 파일의 옵션 설정을 사용하여 이 옵션을 구성할 수 있습니다.
향상된 상태 이벤트
환경에서 상태 간 전환이 발생할 때 확장 상태 시스템은 이벤트를 생성합니다. 다음은 정보, 확인 및 심각한 상태 간 환경 전환에 의한 이벤트 출력을 보여주는 예제입니다.
더 나쁜 상태로 전환되면 확장 상태 이벤트에 전환의 원인을 나타내는 메시지가 표시됩니다.
인스턴스 수준에서 이루어지는 상태 변경 중 일부만 Elastic Beanstalk에서 이벤트를 출력합니다. Elastic Beanstalk는 거짓 경보를 방지하기 위해 여러 번의 확인에서 문제가 지속되는 경우에만 상태 관련 이벤트를 생성합니다.
상태, 색상 및 원인을 포함한 실시간 환경 수준의 상태 정보는 Elastic Beanstalk 콘솔의 환경 개요 페이지 및 EB CLI에서 확인할 수 있습니다. EB CLI를 환경에 연결하고 eb health 명령을 실행하여, 환경의 각 인스턴스에서 실시간으로 상태를 확인할 수도 있습니다.
업데이트, 배포 및 조정 중 향상된 상태 보고 행동
확장 상태 보고를 활성화하면 구성 업데이트와 배포가 진행되는 동안 환경의 동작 방식에 영향을 미칠 수 있습니다. Elastic Beanstalk는 모든 인스턴스가 상태 확인을 지속적으로 통과한 후에야 업데이트 배치(batch)를 완료합니다. 또한 확장 상태 보고는 보다 엄격한 상태 기준을 적용하여 더 많은 요소를 모니터링하기 때문에, 기본 상태 보고의 ELB 상태 확인을 통과한 인스턴스라고 해서 확장 상태 보고를 반드시 통과한다는 보장은 없습니다. 상태 확인이 업데이트 프로세스에 어떤 식으로 영향을 미치는지에 대한 자세한 내용은 롤링 구성 업데이트 및 롤링 배포 항목을 참조하십시오.
확장 상태 보고는 Elastic 로드 밸런서에 대해 적절한 상태 확인 URL을 설정해야 하는 필요성을 강조할 수도 있습니다. 환경이 수요에 맞춰 확장되면, 새 인스턴스는 ELB 상태 확인을 충분히 통과하는 즉시 요청을 받기 시작합니다. 상태 확인 URL이 구성되지 않은 경우, 새 인스턴스에서 TCP 연결이 허용된 후 걸리는 시간은 20초에 불과합니다.
로드 밸런서가 트래픽을 수신할 수 있는 정상 상태라고 선언할 때까지 애플리케이션 시작이 완료되지 않은 경우, 수많은 요청 실패가 표시되고 이후 해당 환경에서는 상태 확인이 실패하게 됩니다. 애플리케이션에서 제공하는 경로를 이용하는 상태 확인 URL을 통해 이 문제를 방지할 수 있습니다. 상태 확인 URL에 대한 GET 요청이 200 상태 코드를 반환할 때까지 ELB 상태 확인은 통과되지 않습니다.