애플리케이션 상태 검사

애플리케이션 상태 검사 (Application status checks)

애플리케이션 상태 검사는 Amazon EC2에서 실행 중인 애플리케이션의 성능과 상태를 모니터링하는 데 도움을 줘요. 애플리케이션 상태 검사를 사용하면 구성 가능한 경로와 포트에서 애플리케이션을 모니터링해 애플리케이션 상태 손상을 감지하고 대응할 수 있어요. 예를 들어 애플리케이션 상태 검사를 사용해 웹 서버가 예상 포트에서 수신 대기 중이고 새 연결을 수락하고 있는지 확인할 수 있어요.

애플리케이션 상태 검사는 구성 가능한 경로와 포트에서 애플리케이션의 HTTP 및 HTTPS 응답을 모니터링해요. 60초마다 실행되며 Amazon EC2 Auto Scaling과 통합되므로 애플리케이션이 손상된 인스턴스를 자동으로 교체할 수 있어요.

주제 (Topics)

  • 애플리케이션 상태 검사 작동 방식
  • 애플리케이션 상태 검사 시작하기
  • 구성 옵션
  • 기본 설정
  • Amazon EC2 Auto Scaling 통합
  • 배포, 제자리 패치, 교체 처리
  • 새 애플리케이션 상태 검사 테스트
  • 고급 네트워킹
  • 모범 사례
  • 문제 해결
  • 애플리케이션 상태 검사 모니터링
  • 보안 및 권한
  • 요금
  • 할당량

애플리케이션 상태 검사 작동 방식 (How application status checks work)

애플리케이션 상태 검사는 60초마다 인스턴스의 네트워크 포트에서 수신 대기 중인 엔드포인트에 HTTP 또는 HTTPS 요청을 보내요. AWS는 응답 코드를 구성한 상태 코드 매처(status code matcher)와 비교해요. 검사는 연속된 실패 요청 수 후에 손상(impaired)으로 표시되고, 연속된 성공 요청 수 후에 다시 정상(healthy)으로 표시돼요. 두 횟수 모두 기본값은 2이며 구성할 수 있어요. 자세한 내용은 평가 임계값을 참고하세요.

참고 애플리케이션 상태 검사는 HTTP/2를 통해 상태 검사 요청을 보내요. HTTPS 프로토콜 검사는 서버 인증서를 검증하지 않아요.

재부팅 중에는 애플리케이션이 상태 검사 요청에 응답할 수 없으므로 인스턴스를 다시 사용할 수 있을 때까지 애플리케이션 상태 검사가 실패를 보고해요.

네트워크 아키텍처 (Network architecture)

애플리케이션 상태 검사는 Amazon EC2 애플리케이션 상태 검사 서비스에서 시작돼요. 인스턴스에 도달하기 위해 AWS는 VPC에 관리형 탄력적 네트워크 인터페이스(ENI)를 만들어요. AWS는 연결된 인스턴스가 있는 소스 서브넷과 보안 그룹 조합당 ENI를 하나 만들어요. AWS는 애플리케이션 상태 검사가 처음으로 해당 조합을 필요로 할 때 관리형 ENI를 만들고, 더 이상 필요로 하는 애플리케이션 상태 검사가 없으면 제거해요. 관리형 ENI는 인스턴스 ENI 한도에 포함되지 않지만, 계정의 리전당 네트워크 인터페이스 할당량에는 포함되며 이 할당량은 가용 영역별로 적용돼요. 자세한 내용은 Amazon VPC 할당량을 참고하세요.

기본적으로 Amazon EC2는 이 설정이 제공되기 전에 관리형 리소스가 없었던 계정의 콘솔 및 API 목록 작업에서 이러한 관리형 네트워크 인터페이스를 숨겨요. 표시 여부를 변경하려면 관리형 리소스 표시 설정을 참고하세요.

AWS는 연결된 인스턴스 중 소스 서브넷과 보안 그룹 조합 각각에 대해 관리형 네트워크 인터페이스를 하나 만들어요. 관리형 인터페이스 수는 모니터링되는 인스턴스가 사용하는 서로 다른 서브넷·보안 그룹 조합 수에 따라 늘어나요. 모니터링되는 인스턴스를 더 적은 서브넷·보안 그룹 조합으로 통합하면 관리형 인터페이스 수가 줄어들어요. 예를 들어 단일 보안 그룹을 모두 사용하는 2개 서브넷에 걸쳐 있는 200개 인스턴스는 관리형 인터페이스 2개를 만들어요. 같은 200개 인스턴스가 그 2개 서브넷에 걸쳐 3개 보안 그룹을 사용하면 최대 6개의 관리형 인터페이스를 만들어요. 각 인터페이스는 하나의 서브넷·보안 그룹 조합에 해당해요.

애플리케이션 상태 검사는 VPC 내의 프라이빗 관점에서 인스턴스에 도달해요. 범위(scope)는 검사가 시작되는 위치를 설명하며 인스턴스 IP 주소의 속성이 아니에요. AWS는 VPC 내 서브넷에 관리형 ENI를 만들고 프라이빗 네트워크 경로를 통해 인스턴스에 도달해요.

AWS 관리형 네트워크 경로를 사용하면 상태 검사 트래픽이 대상 인스턴스와 같은 가용 영역(로컬 영역 대상의 경우 부모 가용 영역)에 있는 AWS 관리형 Amazon EC2 인스턴스에서 시작돼요. 트래픽은 AWS 내부 네트워크를 통해 이동하며 공용 인터넷을 경유하지 않아요. 자세한 내용은 Amazon Web Services 웹 사이트의 Amazon VPC FAQ를 참고하세요.

고객 관리형 네트워크 경로를 사용하면 소스 서브넷을 직접 선택하므로 대상과 다른 가용 영역에서 검사를 실행할 수 있어요. 자세한 내용은 가용 영역 간 모니터링을 참고하세요.

AWS 관리형 및 고객 관리형 네트워크 경로 (AWS managed and customer-managed network paths)

애플리케이션 상태 검사는 상태 검사 ENI의 소스 서브넷·보안 그룹과 대상 인스턴스의 대상 서브넷·보안 그룹을 누가 선택하는지 결정하는 두 가지 온보딩 모드를 지원해요.

  • AWS 관리형 네트워크 경로 — AWS가 상태 검사 ENI의 소스 서브넷·보안 그룹과 대상 인스턴스의 대상 서브넷·보안 그룹을 선택해요.
  • 고객 관리형 네트워크 경로 — 상태 검사 ENI의 소스 서브넷·보안 그룹과 대상 인스턴스의 대상 서브넷·보안 그룹을 직접 지정해요. 상태 검사 트래픽이 시작되는 서브넷과 보안 그룹을 제어해야 할 때, 예를 들어 VPC에 엄격한 네트워크 분리, 방화벽 규칙, 또는 애플리케이션 엔드포인트에 도달할 수 있는 소스를 제한하는 규정 준수 요구 사항이 있을 때 고객 관리형 네트워크 경로를 사용하세요.

생성 명령에 --health-check-paths 매개변수를 포함할지 생략할지에 따라 모드를 선택해요. --health-check-paths 매개변수를 생략하면 AWS가 소스·대상 서브넷과 보안 그룹을 선택해요(AWS 관리형 네트워크 경로). --health-check-paths 매개변수를 포함하면 직접 관리해요(고객 관리형 네트워크 경로).

IP 버전 (IP version)

각 애플리케이션 상태 검사는 단일 IP 버전(IPv4 또는 IPv6)과 연결돼요. IPv4와 IPv6 모두로 인스턴스를 모니터링하려면 별도의 애플리케이션 상태 검사 두 개를 만들고 둘 다 인스턴스에 연결하세요.

IPv4와 IPv6 모두 검사가 VPC 내에서 인스턴스에 도달해요.

검사 상태 값 (Check status values)

각 개별 검사는 다음 상태 중 하나를 보고해요:

  • passed — 검사가 성공적으로 완료됨
  • failed — 검사가 실패함. 응답에는 애플리케이션이 반환한 HTTP 상태 코드가 포함돼요. 해석 및 해결 지침은 문제 해결을 참고하세요.
  • initializing — 검사가 아직 첫 평가를 완료하지 못함
  • insufficient-data — 검사가 결과를 결정할 만큼 충분한 데이터를 받지 못함
  • not-applicable — 검사가 인스턴스와 연결되어 있지 않음

인스턴스에 대해 보고되는 전체 애플리케이션 상태는 모든 개별 검사 결과를 집계해요. 전체 상태는 다음 중 하나예요:

  • ok — 모든 검사가 통과됨
  • impaired — 하나 이상의 검사가 실패함
  • initializing — 하나 이상의 검사가 아직 첫 평가를 완료하지 못함
  • insufficient-data — 하나 이상의 검사가 불충분한 데이터를 보고함
  • not-applicable — 연결된 모든 애플리케이션 상태 검사가 집계에서 제외됨
  • suppressed — 인스턴스에 대한 애플리케이션 상태 검사 평가가 억제됨

집계 (Aggregation)

각 애플리케이션 상태 검사를 인스턴스의 전체 상태에 포함하거나 제외하도록 표시할 수 있어요. 기본적으로 검사는 포함돼요.

  • included — 검사가 인스턴스의 전체 상태에 기여하며 Amazon EC2 Auto Scaling이 이를 사용해요.
  • excluded — 검사는 개별 상태를 보고하지만 인스턴스의 전체 상태에는 기여하지 않으며 Amazon EC2 Auto Scaling이 사용하지 않아요. 이 설정을 사용해 전체 상태에 영향을 주거나 Amazon EC2 Auto Scaling 교체를 유발하지 않고 프로덕션에서 새 검사를 검증하세요. 기존 프로덕션 워크로드에 검사를 추가할 때 권장되는 워크플로이며, 새 애플리케이션 상태 검사 테스트를 참고하세요.

애플리케이션 상태 검사 시작하기 (Get started with application status checks)

사전 준비 (Prerequisites)

애플리케이션 상태 검사를 만들기 전에 다음이 있는지 확인하세요:

  • 모니터링하려는 인스턴스가 있는 VPC
  • 구성할 포트와 HTTP 경로에서 HTTP 또는 HTTPS 요청에 응답할 수 있는 각 인스턴스의 애플리케이션 엔드포인트
  • 애플리케이션 상태 검사가 사용하는 소스 보안 그룹의 검사 포트에서 인바운드 트래픽을 허용하는 각 대상 인스턴스의 보안 그룹. 보안 및 권한을 참고하세요.

1단계: 애플리케이션 구성 (Configure your application)

검사를 만들 때 지정할 포트와 HTTP 경로에서 HTTP 또는 HTTPS 요청에 응답하도록 애플리케이션 엔드포인트를 구성하세요. 애플리케이션이 정상임을 나타내려면 상태 코드 매처에 포함된 응답 코드를 반환하세요.

대상 인스턴스의 보안 그룹이 애플리케이션 상태 검사가 사용하는 소스 보안 그룹의 검사 포트에서 인바운드 트래픽을 허용하는지 확인하세요. 관리형 네트워크 경로의 경우 AWS가 검사 생성 시 소스 보안 그룹을 제공해요. 고객 관리형 네트워크 경로의 경우 검사 생성 시 소스 보안 그룹을 직접 지정해요.

2단계: 검사 정의 만들기 (Create a check definition)

AWS CLI를 사용해 애플리케이션 상태 검사를 만드세요.

콘솔 (Console)

  • Amazon EC2 콘솔(https://console.aws.amazon.com/ec2/)을 엽니다.
  • 탐색 창의 인스턴스(Instances) 아래에서 애플리케이션 상태 검사(Application status checks)를 선택하세요.
  • 애플리케이션 상태 검사 만들기(Create application status check)를 선택하세요.
  • 상태 검사 로직(Health check logic) 아래에서 다음을 구성하세요:
    • Protocol: HTTP 또는 HTTPS를 선택하세요.
    • Port: 애플리케이션이 수신 대기하는 포트를 입력하세요.
    • Path(선택 사항): 요청할 HTTP 경로를 입력하세요(예: /healthcheck).
    • IP version: IPv4 또는 IPv6를 선택하세요.
    • Device index: 검사할 네트워크 인터페이스 디바이스 인덱스. 기본값은 0.
  • 컨트롤 및 임계값(Controls and thresholds) 아래에서 시간 초과(Timeout)를 설정하고 선택적으로 상태 코드 매처(Status code matcher), 실패 임계값(Failure threshold), 성공 임계값(Success threshold), 초기화 유예 기간(Initialization grace period)을 설정하세요. 검사 간격은 60초로 고정돼요.
  • 집계(Aggregation) 아래에서 검사가 전체 애플리케이션 상태에 기여하고 Amazon EC2 Auto Scaling을 구동하게 하려면 포함(Included)을, 전체 상태에 영향을 주지 않고 검사를 보고하려면 제외(Excluded)를 선택하세요.
  • 상태 검사 경로(Health check paths) 아래에서 Amazon EC2가 상태 검사 네트워크 인터페이스를 인스턴스의 서브넷에 배치하게 하려면 네트워크 경로를 지정하지 않음(Do not specify network paths)(권장/기본값)을 유지하거나, 소스 서브넷, 보안 그룹, 대상을 직접 정의하려면 네트워크 경로 지정(Specify network paths)(고급)을 선택하세요.
  • (선택 사항) 이름(Name) 태그 및 기타 태그(Tags)를 추가하세요.
  • 애플리케이션 상태 검사 만들기(Create application status check)를 선택하세요.

AWS CLI

AWS 관리형 네트워크 경로를 사용하려면 --health-check-paths 매개변수를 생략하고 AWS가 소스·대상 서브넷과 보안 그룹을 선택하게 하세요.

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200"

고객 관리형 네트워크 경로를 사용하려면 --health-check-paths 매개변수를 포함하세요. 각 상태 검사 경로에는 소스(상태 검사 ENI의 서브넷과 보안 그룹)와 하나 이상의 대상(대상 인스턴스의 서브넷과 보안 그룹)이 포함돼요.

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --health-check-paths '[{"Source":{"SubnetId":"subnet-111","SecurityGroupId":"sg-aaa"},"Destinations":[{"SubnetId":"subnet-222","SecurityGroupId":"sg-bbb"}]}]'

3단계: 검사를 인스턴스와 연결 (Associate the check with instances)

모니터링하려는 인스턴스와 검사를 인스턴스 ID 또는 태그로 연결하세요.

콘솔 (Console)

  • 탐색 창의 인스턴스(Instances) 아래에서 애플리케이션 상태 검사(Application status checks)를 선택하고 검사를 선택하세요.
  • 상태 검사 연결 관리(Manage status check associations)를 선택한 뒤 리소스 ID로 연결 관리(Manage associations by resource ID) 또는 태그로 연결 관리(Manage associations by tags)를 선택하세요.
  • Auto Scaling 그룹의 모든 인스턴스와 연결하려면 태그로 연결 관리(Manage associations by tags)를 선택하고 태그 키로 aws:autoscaling:groupName을, 값으로 Auto Scaling 그룹 이름을 입력하세요.
  • 연결(Associate)을 선택하세요.

AWS CLI

인스턴스 ID로:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

태그로:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --target-tag-associations Key=Environment,Value=production

Auto Scaling 그룹의 모든 인스턴스와 연결하려면 aws:autoscaling:groupName 시스템 태그를 사용하세요:

aws ec2 associate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --target-tag-associations Key=aws:autoscaling:groupName,Value=my-asg

연결 및 연결 해제 작업은 인스턴스별 성공·실패 결과를 반환해요. 일부 인스턴스를 연결할 수 없으면(예: 검사가 이미 연결된 경우) 해당 인스턴스가 실패 결과에 이유와 함께 표시돼요.

4단계: 결과 보기 (View results)

인스턴스별 애플리케이션 상태를 확인하세요.

콘솔 (Console)

  • Amazon EC2 콘솔(https://console.aws.amazon.com/ec2/)을 엽니다.
  • 탐색 창에서 인스턴스(Instances)를 선택하세요.
  • 인스턴스를 선택한 뒤 상태 및 경보(Status and alarms) 탭을 선택하세요.
  • 애플리케이션 상태 검사(Application status checks) 아래에서 전체 상태와 각 연결된 검사의 개별 상태를 검토하세요.

AWS CLI

aws ec2 describe-application-status \
        --instance-ids i-0123456789abcdef0

응답에는 전체 애플리케이션 상태와, 각 연결된 검사의 검사 상태 및 실패한 검사의 경우 애플리케이션이 반환한 HTTP 상태 코드가 포함돼요. 예시 응답:

{
        "ApplicationStatuses": [
            {
                "InstanceId": "i-0123456789abcdef0",
                "ApplicationStatus": {
                    "Status": "ok",
                    "Details": [
                        {
                            "ApplicationStatusCheckId": "asc-1234567890abcdef0",
                            "Status": "passed",
                            "Reason": {
                                "Code": "ResponseCodeMatched",
                                "StatusCode": 200,
                                "Protocol": "HTTP"
                            }
                        }
                    ]
                }
            }
        ]
    }

검사 정의(인스턴스별 상태가 아닌)를 보려면 describe-application-status-checks를 사용하세요. 이 명령은 프로토콜, 포트, HTTP 경로, 상태 코드 매처 설정 등 애플리케이션 상태 검사의 구성을 반환해요.

구성 옵션 (Configuration options)

애플리케이션 상태 검사는 여러 구성 매개변수를 수락해요. 이 섹션에서는 매개변수 이름만으로는 동작이 명확하지 않은 매개변수를 설명해요. 전체 매개변수 목록과 유효성 검사 규칙은 Amazon EC2 API Reference의 CreateApplicationStatusCheck 및 AssociateApplicationStatusCheck를 참고하세요.

평가 임계값 (Evaluation thresholds)

  • FailureThreshold — 검사가 손상으로 표시되기 전의 연속 실패 요청 수. 기본값: 2.
  • SuccessThreshold — 검사가 다시 정상으로 표시되기 전의 연속 성공 요청 수. 기본값: 2.
  • Timeout — 요청이 실패로 기록되기 전에 응답을 기다리는 초 수. 강제 시간 초과로 적용돼요. 애플리케이션이 이 창 안에 응답하지 않으면 최종 응답과 무관하게 요청이 실패로 기록돼요. 기본값: 6. 유효 범위: 1-30.

시작 유예 기간 (Startup grace period)

  • InitializationGracePeriodSeconds — 인스턴스가 시작된 후 AWS가 검사 평가를 시작하기 전에 기다리는 초 수. 검사가 시작되기 전에 애플리케이션이 수신 대기를 시작할 시간을 주려면 이 매개변수를 사용하세요. 유예 기간이 너무 짧으면 Amazon EC2 Auto Scaling이 애플리케이션이 준비되기 전에 새 인스턴스를 교체할 수 있어요. 기본값: 300. 유효 범위: 1~600.

IP 범위 (IP scope)

  • IpScope — 애플리케이션 상태 검사는 프라이빗 범위를 사용해요. 검사는 VPC 내에서 실행돼요. IPv4의 경우 인스턴스의 프라이빗 IP 주소에 해당해요. IPv6의 경우 AWS는 주소를 공용 또는 프라이빗으로 분류하지 않아요. 검사는 모든 IPv6 주소를 수락하고 VPC 내에서 평가해요.

디바이스 인덱스 (Device index)

  • DeviceIndex — AWS가 상태 검사에 대해 평가하는 인스턴스의 네트워크 디바이스 인덱스. 인스턴스의 기본 네트워크 디바이스가 검사하려는 디바이스가 아닐 때 변경하세요. 기본값: 0.

집계, IP 버전, 상태 검사 경로(소스·대상 서브넷과 보안 그룹)는 이 페이지 앞부분의 각 섹션에서 다뤄요.

기본 설정 (Default settings)

AWS 관리형 네트워크 경로를 사용하면 애플리케이션 상태 검사는 다음 기본값을 사용해요.

설정 기본값
검사 간격(Check interval) 60초(고정, 구성 불가)
실패 임계값(Failure threshold) 연속 실패 2회
성공 임계값(Success threshold) 연속 성공 2회
시간 초과(Timeout) 6초
상태 코드 매처(Status code matcher) 200
HTTP 경로(HTTP path) /
IP 버전(IP version) ipv4
IP 범위(IP scope) private
디바이스 인덱스(Device index) 0
초기화 유예 기간(Initialization grace period) 300초
집계(Aggregation) included
소스 서브넷·보안 그룹(Source subnets and security groups) AWS 관리

Amazon EC2 Auto Scaling 통합 (Amazon EC2 Auto Scaling integration)

Amazon EC2 Auto Scaling은 검사가 집계에 포함된 경우 전체 애플리케이션 상태가 손상(impaired)으로 보고되는 인스턴스를 자동으로 종료하고 교체해요. 애플리케이션 상태 검사를 그룹의 인스턴스와 연결하는 것 외에 Auto Scaling 그룹 구성이 필요하지 않아요.

Amazon EC2 Auto Scaling은 개별 검사 상태가 아닌 인스턴스의 전체 상태를 사용해요. 제외(excluded)로 표시된 검사는 Amazon EC2 Auto Scaling 작업을 구동하지 않아요. 억제(suppressed) 상태의 검사도 Amazon EC2 Auto Scaling 작업을 구동하지 않아요.

애플리케이션 상태 검사가 시작되기 전에 새 인스턴스가 시작될 시간을 주려면 검사의 InitializationGracePeriodSeconds 매개변수를 사용하세요. 유예 기간이 너무 짧으면 새 인스턴스가 트래픽을 제공할 준비가 되기 전에 Amazon EC2 Auto Scaling에 의해 종료·교체될 수 있어요.

검사의 InitializationGracePeriodSeconds는 인스턴스가 시작된 후 검사가 애플리케이션 평가를 시작하기 전까지의 시간을 설정해요. 애플리케이션 시작 시간을 포함하도록 설정해서 애플리케이션이 아직 시작 중일 때 검사가 손상으로 보고하지 않게 하세요. Auto Scaling 그룹의 상태 검사 유예 기간은 별개예요. 인스턴스가 서비스에 들어간 후 실패한 상태 검사로 Amazon EC2 Auto Scaling이 인스턴스를 종료하기까지의 시간을 설정해요.

Amazon EC2 Auto Scaling이 상태 검사를 사용하는 방법에 대한 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 'Auto Scaling 그룹 인스턴스의 상태 검사' 및 'Auto Scaling 그룹과 함께 애플리케이션 상태 검사 사용'을 참고하세요.

배포, 제자리 패치, 교체 처리 (Handling deployment, in-place patching, and replacements)

배포, 제자리 패치, 기타 유지 관리 작업은 애플리케이션을 일시적으로 중지하거나 다시 시작할 수 있어요. 그 시간 동안 애플리케이션이 상태 검사 요청에 응답할 수 없으므로 애플리케이션 상태 검사가 실패를 보고해요. 인스턴스가 애플리케이션 상태 검사가 집계에 포함된 Auto Scaling 그룹에 있으면 예상된 중단임에도 Amazon EC2 Auto Scaling이 이러한 인스턴스를 종료·교체할 수 있어요.

옵션 A: 검사 억제 (Suppress the check)

기간을 아는 제한된 유지 관리 창에는 억제(suppression)를 사용하세요. 억제는 인스턴스 수준에서 적용돼요. 기간을 지정하거나, 억제를 비활성화할 때까지 검사를 억제하려면 생략할 수 있어요.

AWS CLI

aws ec2 enable-application-status-check-suppression \
        --instance-ids i-0123456789abcdef0 \
        --duration-seconds 3600

응답은 각 인스턴스에 대해 억제가 시작된 시점과 종료될 시점을 반환해요. 부분 성공이 가능해요. 일부 인스턴스가 억제되지 않고 이유와 함께 응답에 나타날 수 있어요.

억제 창이 만료되기 전에 검사를 재개하려면:

aws ec2 disable-application-status-check-suppression \
        --instance-ids i-0123456789abcdef0

억제된 동안 인스턴스의 전체 애플리케이션 상태는 suppressed를 보고해요. Amazon EC2 Auto Scaling은 억제된 인스턴스에 대해 작동하지 않아요.

옵션 B: 검사를 집계에서 제외 (Exclude the check from aggregation)

검사가 계속 평가하고 개별 상태를 보고하되 전체 상태에 영향을 주거나 Amazon EC2 Auto Scaling 작업을 유발하지 않게 하려면 검사의 집계 설정을 excluded로 설정하세요. 이는 새 검사 버전을 롤아웃하거나 교체 위험 없이 변경을 검증하는 등 장기 시나리오와, 운영 영향 없이 텔레메트리를 계속하려는 경우에 유용해요. 자세한 내용은 집계를 참고하세요.

옵션 C: 검사 연결 해제 (Disassociate the check)

더 장기적이거나 무기한 제거에는 연결 해제를 사용하세요.

aws ec2 disassociate-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --instance-ids i-0123456789abcdef0

태그로 연결했다면 인스턴스에서 태그를 제거해 연결을 해제하세요. 연결 해제 후 인스턴스의 전체 애플리케이션 상태는 not-applicable을 보고해요.

배포 지침 (Deployment guidance)

배포는 억제가 필요한 가장 흔한 유지 관리 시나리오예요. 배포 도구에 사전 배포 후크(pre-deployment hook)와 사후 배포 후크(post-deployment hook)가 있으면 억제를 사용하세요. 배포가 시작되기 전에 검사를 억제하고 배포가 완료된 후에 억제를 비활성화할 수 있어요.

일반적인 패턴은 다음과 같아요:

  • 사전 배포 후크에서 인스턴스에 대해 enable-application-status-check-suppression을 예상 배포 창을 포함하는 기간과 함께 호출하세요.
  • 배포를 수행하세요.
  • 사후 배포 후크에서 인스턴스에 대해 disable-application-status-check-suppression을 호출하세요.

배포 도구에 후크가 없다면 배포를 호출하는 CI/CD 파이프라인에서 억제를 구동하세요.

새 애플리케이션 상태 검사 테스트 (Testing a new application status check)

인스턴스 수준 모니터링에 기여하기 전에 프로덕션에서 새 애플리케이션 상태 검사를 검증할 수 있어요. 검사를 만들 때 집계 설정을 excluded로 설정한 뒤 예상 상태와 HTTP 응답 코드를 보고하는지 확인하세요. 준비가 되면 설정을 included로 변경해 검사가 인스턴스의 전체 상태에 기여하고 Amazon EC2 Auto Scaling과 통합되게 하세요.

  • 집계 설정을 excluded로 설정해 검사를 만드세요.
aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --aggregation excluded
  • 검사를 테스트 인스턴스 또는 프로덕션 플릿의 일부와 연결하세요.
  • 검사가 초기 평가를 완료할 수 있도록 최소 두 번의 검사 간격(약 2분)을 기다리세요.
  • describe-application-status를 사용해 검사가 예상 상태와 HTTP 응답 코드를 보고하는지 확인하세요.
aws ec2 describe-application-status \
        --instance-ids i-0123456789abcdef0
  • 검사가 예상대로 보고하면 집계 설정을 included로 업데이트해 검사가 인스턴스의 전체 상태에 기여하고 Amazon EC2 Auto Scaling 작업을 구동하게 하세요.
aws ec2 modify-application-status-check \
        --application-status-check-id asc-1234567890abcdef0 \
        --aggregation included

고급 네트워킹 (Advanced networking)

애플리케이션 상태 검사는 지정하거나(AWS가 선택) 소스 서브넷·보안 그룹의 관리형 ENI에서 시작돼요. 단일 소스 구성이 제공하는 것보다 더 높은 가용성이 필요한 워크로드나 로컬 영역 또는 Outposts에서 실행되는 워크로드의 경우 다음 패턴을 고려하세요.

가용 영역 간 모니터링 (Cross-Availability Zone monitoring)

가용 영역 중복을 위해 둘 이상의 가용 영역에서 상태 검사를 실행할 수 있어요. 고객 관리형 네트워크 경로를 사용하면 --health-check-paths 매개변수로 소스가 서로 다른 두 가용 영역에 있어 같은 대상 인스턴스에 도달하는 상태 검사 경로를 정의할 수 있어요. 두 가용 영역에서 모니터링하면 한 가용 영역을 사용할 수 없게 되어도 인스턴스에 대한 상태 보고가 계속 유지돼요.

다음 예시는 소스가 서로 다른 가용 영역에 있고 둘 다 같은 대상 인스턴스에 도달하는 두 상태 검사 경로로 검사를 만들어요.

aws ec2 create-application-status-check \
        --protocol https \
        --port 443 \
        --path "/health" \
        --status-code-matcher "200" \
        --health-check-paths '[{"Source":{"SubnetId":"subnet-source-az1","SecurityGroupId":"sg-healthcheck"},"Destinations":[{"SubnetId":"subnet-app-az1","SecurityGroupId":"sg-app"}]},{"Source":{"SubnetId":"subnet-source-az2","SecurityGroupId":"sg-healthcheck"},"Destinations":[{"SubnetId":"subnet-app-az2","SecurityGroupId":"sg-app"}]}]'

로컬 영역 (Local Zones)

AWS 로컬 영역에서 실행되는 인스턴스의 경우 관리형 탄력적 네트워크 인터페이스(ENI)는 로컬 영역이 아닌 부모 AWS 리전에 있어요. 부모 리전과 로컬 영역 인스턴스 사이의 상태 검사 트래픽은 로컬 영역 서비스 링크를 통과하며, 추가 데이터 전송 요금이 발생할 수 있어요.

모범 사례 (Best practices)

  • 상태 엔드포인트를 해당 인스턴스에서 실행되는 애플리케이션의 상태를 반영하도록 설계하세요. 엔드포인트가 애플리케이션 자체를 기준으로 상태를 반환하면 Amazon EC2 Auto Scaling은 진정으로 손상된 인스턴스만 교체해요. 엔드포인트의 응답이 데이터베이스나 다운스트림 서비스 같은 공유 리소스에도 의존하면 해당 리소스의 문제로 여러 인스턴스에서 한 번에 검사가 실패할 수 있어요. 이는 플릿 전반의 교체를 유발할 수 있어요. 상태 검사 엔드포인트 작성에 대한 지침은 Amazon Builders' Library의 '상태 검사 구현'을 참고하세요.
  • 상관된 실패로부터 보호하세요. 포함된 검사가 Amazon EC2 Auto Scaling 교체를 구동해요. 여러 인스턴스에서 한 번에 실패하는 검사는 교체의 물결을 유발할 수 있어요. Auto Scaling 그룹에 인스턴스 유지 관리 정책을 설정해 동시에 교체되는 인스턴스 수를 제한하세요. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서의 '인스턴스 유지 관리 정책'을 참고하세요.
  • 손상된 인스턴스 수에 대해 경보를 설정하세요. 플릿 전반의 StatusCheckFailed_Application 메트릭에 Amazon CloudWatch 경보를 만드세요. 여러 인스턴스에서 갑자기 증가하면 개별 인스턴스 장애가 아닌 공유 종속성을 나타내며, 교체가 연쇄되기 전에 대응할 시간을 줘요. 자세한 내용은 애플리케이션 상태 검사 모니터링을 참고하세요.
  • 네트워크 인터페이스 할당량 내에 머무르세요. 애플리케이션 상태 검사는 리전당 네트워크 인터페이스 할당량에 포함되는 관리형 네트워크 인터페이스를 만들어요. AWS는 이 할당량을 가용 영역별로 적용해요. 플릿이 커져도 할당량에 도달하지 않도록 사용량을 모니터링하세요. 도달하면 AWS가 새 인터페이스를 만들 수 없어요. 관련 할당량 경보 지침은 할당량을 참고하세요.
  • 상태 검사 권한을 변경 통제 대상으로 취급하세요. 애플리케이션 상태 검사를 만들고, 수정하고, 삭제하고, 연결하고, 연결 해제하고, 억제하는 IAM 작업은 인스턴스 가용성에 영향을 줄 수 있어요. 이러한 작업은 Amazon EC2 Auto Scaling 교체를 구동하는 것을 결정해요. ec2:CreateApplicationStatusCheck, ec2:AssociateApplicationStatusCheck, ec2:ModifyApplicationStatusCheck, ec2:EnableApplicationStatusCheckSuppression 같은 작업을 일반적인 Amazon EC2 액세스의 일부로 부여하지 말고 변경 통제 대상으로 취급하세요. 전체 작업 목록은 Amazon EC2 API Reference를 참고하세요.

문제 해결 (Troubleshooting)

애플리케이션 상태 검사가 손상(impaired)을 보고하는데 애플리케이션이 정상이라고 예상한다면 다음 각 항목을 확인하세요:

  • 인스턴스 도달 가능성 — 인스턴스의 인스턴스(Instance) 및 시스템(System) 상태 검사가 ok인지 확인하세요.
  • 보안 그룹 인바운드 규칙 — 대상 인스턴스의 보안 그룹이 애플리케이션 상태 검사가 사용하는 소스 보안 그룹의 검사 포트에서 인바운드 트래픽을 허용해야 해요. AWS 관리형 네트워크 경로의 경우 AWS가 소스 보안 그룹을 제공해요. 고객 관리형 네트워크 경로의 경우 소스로 지정한 보안 그룹을 사용하세요.
  • 호스트 방화벽 — 인스턴스의 호스트 수준 방화벽(iptables, Windows 방화벽, 타사 호스트 방화벽)이 검사 포트에서 인바운드 트래픽을 허용해야 해요.
  • 애플리케이션 엔드포인트 — 애플리케이션이 구성한 포트와 경로에서 수신 대기해야 해요. 인스턴스에서 로컬 요청으로 확인하세요(curl http://localhost:PORT/PATH).
  • 프로토콜 불일치 — 검사가 HTTPS로 구성되었는데 엔드포인트가 HTTP만 제공한다면(또는 그 반대라면) 모든 호출이 실패해요.
  • 상태 코드 매처 — 애플리케이션의 실제 응답 코드가 구성한 상태 코드 매처에 포함되어 있는지 확인하세요.
  • 네트워크 경로 — 고객 관리형 네트워크 경로를 구성했다면 소스 서브넷·보안 그룹이 대상 서브넷으로의 연결이 있는지 확인하세요. VPC Reachability Analyzer를 사용해 네트워크 경로를 추적하세요.
  • 사용 가능한 ENI 할당량 — AWS는 계정에서 소스 서브넷·보안 그룹 조합 각각에 대해 관리형 탄력적 네트워크 인터페이스(ENI)를 만들어요. 계정이 가용 영역별로 적용되는 리전당 네트워크 인터페이스 할당량에 도달하지 않았는지 확인하세요. 이 할당량에 도달하면 AWS가 관리형 ENI를 만들 수 없고 검사가 실행될 수 없어요. 자세한 내용은 Amazon VPC 할당량을 참고하세요.

이유 코드 (Reason codes)

describe-application-status 응답에는 각 검사에 대한 이유가 포함돼요. 이유에는 애플리케이션이 반환한 HTTP 상태 코드(숫자)와 검사에 사용된 프로토콜이 포함돼요. 반환된 상태 코드가 상태 코드 매처에 포함되어 있으면 검사는 passed로, 그렇지 않으면 failed로 표시돼요.

이유에는 이유 코드와, HTTP 수준 결과의 경우 프로토콜 및 반환된 HTTP 상태 코드도 포함돼요. 이유에는 다음 필드가 있어요:

  • Code — 애플리케이션 상태 검사 결과의 이유 코드. 다음 값 중 하나:

    • ResponseCodeMatched: 상태 검사가 반환한 HTTP 상태 코드가 구성된 StatusCodeMatcher와 일치함.
    • ResponseCodeMismatch: 상태 검사가 반환한 HTTP 상태 코드가 구성된 StatusCodeMatcher와 일치하지 않음.
    • ConnectionTimeout: 대상으로의 연결 시간이 초과됨.
    • ResponseTimeout: 대상의 응답을 기다리는 동안 상태 검사 시간이 초과됨.
    • ConnectionRefused: 대상이 상태 검사 연결을 거부함.
    • ConnectionReset: 응답을 받기 전에 상태 검사 연결이 재설정됨.

    ResponseCodeMatched 및 ResponseCodeMismatch의 경우 StatusCode 필드에 반환된 HTTP 상태 코드가, Protocol 필드에 상태 검사에 사용된 프로토콜이 포함돼요. ConnectionTimeout, ResponseTimeout, ConnectionRefused, ConnectionReset 같은 연결 오류의 경우 StatusCode 및 Protocol 필드는 없어요.

  • Protocol — 상태 검사에 사용된 프로토콜. HTTP 또는 HTTPS 중 하나.

  • StatusCode — 상태 검사가 반환한 HTTP 상태 코드.

반환된 HTTP 상태 코드를 사용해 검사가 실패한 이유를 식별하세요. 몇 가지 일반적인 예:

HTTP 상태 코드 일반적인 의미 일반적인 해결책
200 애플리케이션이 성공 응답을 반환함. 없음. 대개 정상 상태.
301, 302 애플리케이션이 리디렉션을 반환함. 상태 검사 호출은 리디렉션을 따라가지 않아요. 상태 검사 경로를 리디렉션의 대상으로 지정하거나, 정상으로 간주한다면 상태 코드 매처에 리디렉션 코드를 추가하세요.
401, 403 애플리케이션이 인증을 요구하거나 상태 검사 경로에 대한 액세스를 거부함. 상태 검사 경로를 인증 없이 구성하거나, 자격 증명이 필요하지 않은 경로에서 상태 검사를 제공하세요.
404 구성된 상태 검사 경로를 애플리케이션에서 찾지 못함. 경로가 애플리케이션이 제공하는 라우트와 일치하는지 확인하세요.
500 애플리케이션이 내부 서버 오류를 반환함. 인스턴스의 애플리케이션 로그를 조사하세요.
502, 503, 504 애플리케이션에 도달할 수 있지만 업스트림 또는 용량 문제를 보고함. 애플리케이션 상태, 종속성, 용량을 조사하세요. 애플리케이션이 시작 중에 이러한 코드를 반환하면 InitializationGracePeriodSeconds를 늘리세요.

전체 ApplicationStatusReason 구조는 Amazon EC2 API Reference의 ApplicationStatusReason을 참고하세요.

흔한 실수 (Common mistakes)

  • 보안 그룹이 검사 포트에서 상태 검사 소스의 인바운드 트래픽을 허용하지 않음.
  • 애플리케이션이 127.0.0.1에 바인딩되어 네트워크 인터페이스에서 수신 대기하지 않음.
  • 상태 검사 경로가 성공 응답 대신 리디렉션(301, 302)을 반환하고 상태 코드 매처에 리디렉션 코드가 포함되지 않음.
  • 검사가 HTTPS로 구성되었지만 애플리케이션이 HTTP만 제공함(또는 그 반대).
  • 애플리케이션 시작 시간이 InitializationGracePeriodSeconds 값보다 길어서 Amazon EC2 Auto Scaling이 준비되기 전에 인스턴스를 교체함.

애플리케이션 상태 검사 모니터링 (Monitor application status checks)

애플리케이션 상태 검사를 세 가지 방법으로 모니터링할 수 있어요:

  • Amazon CloudWatch — StatusCheckFailed_Application 메트릭은 인스턴스의 전체 애플리케이션 상태를 반영하며 경보를 구동할 수 있어요. 이 메트릭은 집계 설정이 included인 연결된 검사에 대해 인스턴스별로 집계돼요. CloudWatch는 또한 각 연결된 검사에 대해 StatusCheckFailed_Application_application-status-check-id라는 이름의 검사별 메트릭을 게시해요.
  • describe-instance-status — 인스턴스의 다른 상태 정보와 함께 전체 애플리케이션 상태를 반환해요.
  • describe-application-status — 각 연결된 검사의 개별 상태와 애플리케이션이 반환한 HTTP 상태 코드를 포함한 상세한 인스턴스별 결과를 반환해요.

경보 중심 자동화에는 CloudWatch 메트릭을 사용하세요. 인스턴스 상태를 이미 쿼리할 때는 describe-instance-status를 사용하세요. 상세한 검사별 가시성에는 describe-application-status를 사용하세요.

보안 및 권한 (Security and permissions)

AWS는 서비스 연결 역할을 통해 애플리케이션 상태 검사에 사용되는 네트워크 인터페이스를 만들고 관리해요. 서비스가 이러한 ENI를 만들기 위한 IAM 설정은 필요하지 않아요. 서비스 연결 역할은 EC2ApplicationStatusChecksServiceRolePolicy AWS 관리 정책을 사용해요.

애플리케이션 상태 검사를 직접 만들고, 연결하고, 설명하고, 삭제하고, 억제하려면 IAM 사용자 또는 역할에 해당하는 Amazon EC2 권한이 필요해요. 전체 작업 목록은 Amazon EC2 API Reference를 참고하세요.

인스턴스의 보안 그룹은 구성한 포트에서 상태 검사 소스 보안 그룹의 인바운드 트래픽을 허용해야 해요. AWS 관리형 네트워크 경로의 경우 AWS가 소스 보안 그룹을 제공해요. 고객 관리형 네트워크 경로의 경우 소스로 지정한 보안 그룹을 사용하세요.

요금 (Pricing)

애플리케이션 상태 검사는 다음 구성 요소에 대해 청구돼요:

  • 관리형 탄력적 네트워크 인터페이스(ENI)당 가용 영역별 시간당 $0.01.
  • 표준 Amazon CloudWatch 요금이 애플리케이션 상태 검사 메트릭에 적용돼요.

할당량 (Quotas)

애플리케이션 상태 검사는 AWS 서비스 할당량의 적용을 받아요. 할당량 이름, 기본값, 설명은 AWS 일반 참조(General Reference)의 'Amazon EC2 엔드포인트 및 할당량'을 참고하세요.

관리형 네트워크 인터페이스에 영향을 주는 AWS 서비스 할당량 외에도 애플리케이션 상태 검사에는 다음 서비스 할당량이 있어요. Service Quotas 콘솔에서 사용량을 보고 증가를 요청할 수 있어요.

이 할당량에서 대상(target)은 하나의 상태 검사가 모니터링하는 단일 인스턴스예요. 둘 이상의 상태 검사가 인스턴스를 모니터링하면 각 인스턴스·상태 검사 쌍이 별도의 대상으로 계산돼요. 연결(association)은 상태 검사와 연결하는 단일 태그 규칙 또는 단일 인스턴스 ID예요. 각 규칙 또는 인스턴스 ID는 해석되는 인스턴스 수와 무관하게 하나의 연결로 계산돼요.

할당량 기본값 조정 가능
계정당 상태 검사(Health checks per account) 50 예, 자동
상태 검사당 연결(Associations per health check) 50 예, 자동
계정당 연결(Associations per account) 200 예, 자동
계정당 대상(Targets per account) 5,000 예, 요청 시

대부분의 할당량 증가는 자동으로 승인돼요. 계정당 대상(Targets per account) 증가는 요청과 수동 승인이 필요해요.

중요 계정의 대상 수가 계정당 대상(Targets per account) 할당량을 초과하면 한도를 초과한 대상은 모니터링되지 않고 애플리케이션 상태를 보고하지 않아요. 모니터링 공백을 피하려면 대상 수를 할당량 안에 유지하거나 증가를 요청하세요.

애플리케이션 상태 검사 할당량 사용량에 Amazon CloudWatch 경보를 만들어 할당량에 도달하기 전에 알림을 받을 것을 권장해요. Service Quotas는 CloudWatch의 AWS/Usage 네임스페이스에 사용량 메트릭을 게시하며, 이를 사용해 경보를 만들 수 있어요.

더 알아보기 (Learn more)