Classic Load Balancer의 CloudWatch 지표 - Elastic Load Balancing

Classic Load Balancer의 CloudWatch 지표

Elastic Load Balancing은 로드 밸런서와 백엔드 인스턴스에 대해 Amazon CloudWatch에 데이터 포인트를 게시합니다. CloudWatch를 사용하면 이러한 데이터 포인트에 대한 통계를 정렬된 시계열 데이터 세트로 검색할 수 있습니다. 이러한 통계를 지표라고 합니다. 지표를 모니터링할 변수로 생각하면 데이터 요소는 시간에 따른 변수의 값을 나타냅니다. 예를 들어 지정된 기간 동안 로드 밸런서에 대한 정상 EC2 인스턴스의 총 수를 모니터링할 수 있습니다. 각 데이터 요소에는 연결된 타임스탬프와 측정 단위(선택 사항)가 있습니다.

지표를 사용하여 시스템이 예상대로 수행되고 있는지 확인할 수 있습니다. 예를 들어 CloudWatch 경보를 생성하여 지정된 지표를 모니터링할 수 있으며, 지표가 허용 범위를 벗어난다고 간주되는 경우 작업(예: 이메일 주소로 알림 전송)를 시작할 수 있습니다.

Elastic Load Balancing은 요청이 로드 밸런서를 통과하는 경우에만 지표를 CloudWatch에 보고합니다. 로드 밸런서를 통과하는 요청이 있는 경우 Elastic Load Balancing은 60초 간격으로 지표를 측정하고 전송합니다. 로드 밸런서를 통과하고 있는 요청이 없는 경우나 지표에 대한 데이터가 없는 경우에는 지표가 보고되지 않습니다.

Amazon CloudWatch에 대한 자세한 내용은 Amazon CloudWatch 사용 설명서를 참조하세요.

Classic Load Balancer 지표

AWS/ELB 네임스페이스에는 다음 지표가 포함되어 있습니다.

지표 설명
BackendConnectionErrors

로드 밸런서와 등록된 인스턴스 사이에 성공적으로 구성되지 않은 연결 수. 오류 발생 시 로드 밸런서가 연결을 재시도하기 때문에 이 수가 요청 빈도를 초과할 수도 있습니다. 또한 여기에는 상태 검사와 관련된 연결 오류도 포함됩니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다. Average, MinimumMaximum 통계는 로드 밸런서 노드별로 보고될 뿐 일반적으로 유용하지는 않습니다. 하지만 Minimum과 Maximum의 차이(또는 최대와 평균 비율, 평균과 저점 비율)는 로드 밸런서 노드의 이상 여부를 판단하는 데 도움이 될 수 있습니다.

: 로드 밸런서의 인스턴스가 us-west-2a에 2개, 그리고 us-west-2b에 2개 있을 때 us-west-2a의 인스턴스 1개에 연결하려는 도중 백엔드 연결 오류가 발생하였다고 가정하겠습니다. 그러면 us-west-2a의 합산에 연결 오류가 포함되지만 us-west-2b의 합산에는 연결 오류가 포함되지 않습니다. 따라서 로드 밸런서의 합산은 us-west-2a의 합산과 일치합니다.

DesyncMitigationMode_NonCompliant_Request_Count

[HTTP 리스너] RFC 7230을 준수하지 않는 요청 수입니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다.

HealthyHostCount

로드 밸런서에 등록된 정상 상태의 인스턴스 수. 새롭게 등록된 인스턴스는 첫 번째 상태 검사를 통과해야만 정상 상태로 간주됩니다. 교차 영역 로드 밸런싱이 활성화되어 있으면 LoadBalancerName 차원의 정상 인스턴스 수가 모든 가용 영역을 통틀어 계산됩니다. 그렇지 않으면 가용 영역별로 계산됩니다.

보고 기준: 등록된 인스턴스가 있을 때

통계: 가장 유용한 통계는 AverageMaximum입니다. 이 두 가지 통계는 로드 밸런서 노드에서 결정됩니다. 단, 일부 로드 밸런서 노드에서 정상 상태로 판단되는 인스턴스라고 해도 다른 노드에서는 일시적으로 비정상으로 판단될 수도 있습니다.

: 로드 밸런서의 인스턴스가 us-west-2a에 2개, 그리고 us-west-2b에 2개 있을 때 us-west-2a에 비정상 인스턴스가 1개 있고, us-west-2b에는 비정상 인스턴스가 없다고 가정하겠습니다. 그러면 AvailabilityZone 차원에서는 us-west-2a에서 정상 인스턴스 1개와 비정상 인스턴스 1개를, 그리고 us-west-2b에서 정상 인스턴스 2개와 비정상 인스턴스 0개를 유지합니다.

HTTPCode_Backend_2XX, HTTPCode_Backend_3XX, HTTPCode_Backend_4XX, HTTPCode_Backend_5XX

[HTTP 리스너] 등록된 인스턴스에서 생성된 HTTP 응답 코드 수. 여기에 로드 밸런서에서 생성된 응답 코드 수는 포함되지 않습니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다. 단, Minimum, MaximumAverage는 모두 1입니다.

: 로드 밸런서의 인스턴스가 us-west-2a에 2개, 그리고 us-west-2b에 2개 있을 때 us-west-2a의 인스턴스 1개로 요청이 전송되어 그 결과 HTTP 500 응답이 반환되었다고 가정하겠습니다. 그러면 us-west-2a의 합산에는 이 오류 응답이 포함되지만 us-west-2b의 합산에는 포함되지 않습니다. 따라서 로드 밸런서의 합산은 us-west-2a의 합산과 일치합니다.

HTTPCode_ELB_4XX

[HTTP 리스너] 로드 밸런서에서 생성된 HTTP 4XX 클라이언트 오류 코드 수. 클라이언트 오류는 요청 형식이 잘못되었거나 불완전할 때 생성됩니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다. 단, Minimum, MaximumAverage는 모두 1입니다.

: 로드 밸런서에서 us-west-2a와 us-west-2b가 활성화되어 있을 때 클라이언트 요청에 잘못된 형식의 요청 URL이 포함되어 있다고 가정하겠습니다. 이때는 모든 가용 영역에 클라이언트 오류가 증가할 가능성이 높습니다. 그 결과, 로드 밸런서의 합산이 가용 영역의 값 합산과 일치하게 됩니다.

HTTPCode_ELB_5XX

[HTTP 리스너] 로드 밸런서에서 생성된 HTTP 5XX 서버 오류 코드 수. 여기에 등록된 인스턴스에서 생성된 응답 코드 수는 포함되지 않습니다. 이 지표는 로드 밸런서에 정상 인스턴스가 등록되어 있지 않거나, 혹은 요청 빈도가 인스턴스 용량을 초과하거나(스필오버) 또는 로드 밸런서 용량을 초과하는 경우에 보고됩니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다. 단, Minimum, MaximumAverage는 모두 1입니다.

: 로드 밸런서에서 us-west-2a와 us-west-2b가 활성화되어 있을 때 us-west-2a의 인스턴스에서 지연 시간이 높아지면서 요청에 대한 응답 속도가 느려진다고 가정하겠습니다. 그러면 us-west-2a의 로드 밸런서 노드에서 서지 대기열이 채워지고 클라이언트는 503 오류를 수신하게 됩니다. 이때 us-west-2b가 계속해서 정상적으로 응답할 수 있다면 로드 밸런서의 합산은 us-west-2a의 합산과 일치합니다.

Latency

[HTTP 리스너] 로드 밸런서가 등록된 인스턴스에 요청을 보낸 시간부터 인스턴스가 응답 헤더를 보내기 시작할 때까지의 총 경과 시간(초)입니다.

[TCP 리스너] 로드 밸런서가 등록된 인스턴스에 대한 연결을 성공적으로 설정하는 데 걸린 총 시간(초)입니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Average입니다. Maximum은 평균 시간보다 더욱 오래 걸리는 요청의 유무를 확인할 때 사용합니다. Minimum은 일반적으로 사용되지 않습니다.

: 로드 밸런서의 인스턴스가 us-west-2a에 2개, 그리고 us-west-2b에 2개 있을 때 us-west-2a의 인스턴스 1개로 전송되는 요청에서 지연 시간이 높게 발생한다고 가정하겠습니다. 이때 us-west-2a이 평균 값은 us-west-2b의 평균 값보다 높습니다.

RequestCount

지정한 주기(1분 또는 5분)에 완료된 요청 또는 연결 수

[HTTP 리스너] 등록된 인스턴스의 HTTP 오류 응답을 포함하여 수신 및 라우팅된 요청 수

[TCP 리스너] 등록된 인스턴스에 대한 연결 수

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다. Minimum, MaximumAverage는 모두 1을 반환합니다.

: 로드 밸런서의 인스턴스가 us-west-2a에 2개, 그리고 us-west-2b에 2개 있을 때 100개의 요청이 로드 밸런서에 전송된다고 가정하겠습니다. 이중 60개는 us-west-2a의 인스턴스로 각각 30개씩, 그리고 40개는 us-west-2b의 인스턴스로 각각 20개씩 전송됩니다. AvailabilityZone 차원에서는 us-west-2a의 요청 합산이 60개, us-west-2b의 요청 합산이 40개가 됩니다. 하지만 LoadBalancerName 차원에서는 요청 합산이 100개입니다.

SpilloverCount

서지 대기열이 가득 찼기 때문에 거부된 요청 총 수

[HTTP 리스너] 로드 밸런서가 HTTP 503 오류 코드를 반환합니다.

[TCP 리스너] 로드 밸런서가 연결을 종료합니다.

보고 기준: 0이 아닌 값이 있을 때

통계: 가장 유용한 통계는 Sum입니다. Average, MinimumMaximum 통계는 로드 밸런서 노드별로 보고될 뿐 일반적으로 유용하지는 않습니다.

: 로드 밸런서에서 us-west-2a와 us-west-2b가 활성화되어 있을 때 us-west-2a의 인스턴스에서 지연 시간이 높아지면서 요청에 대한 응답 속도가 느려진다고 가정하겠습니다. 그러면 us-west-2a의 로드 밸런서 노드에서 서지 대기열이 채워지고 스필오버가 발생하게 됩니다. 이때 us-west-2b가 계속해서 정상적으로 응답할 수 있다면 로드 밸런서의 합산은 us-west-2a의 합산과 일치합니다.

SurgeQueueLength

정상 인스턴스 대상으로 라우팅이 보류 중인 총 요청(HTTP 리스터) 또는 연결(TCP 리스너) 수. 대기열의 최대 크기는 1,024입니다. 대기열이 가득 찼을 때는 추가 요청 또는 연결이 거부됩니다. 자세한 내용은 SpilloverCount 섹션을 참조하세요.

보고 기준: 0이 아닌 값이 있을 때.

통계: 가장 유용한 통계는 대기 중인 최대 요청 수를 의미하는 Maximum입니다. Average 통계는 MinimumMaximum 통계와 함께 사용하여 대기 중인 요청의 범위를 확인할 때 유용합니다. 단, Sum 통계는 유용하지 않습니다.

: 로드 밸런서에서 us-west-2a와 us-west-2b가 활성화되어 있을 때 us-west-2a의 인스턴스에서 지연 시간이 높아지면서 요청에 대한 응답 속도가 느려진다고 가정하겠습니다. 그러면 us-west-2a의 로드 밸런서 노드에서 서지 대기열이 채워지고, 클라이언트는 응답 시간이 길어질 가능성이 높습니다. 이렇게 지속되면 로드 밸런서는 스필오버 가능성이 커집니다(SpilloverCount 지표 참조). 이때 us-west-2b가 계속해서 정상적으로 응답할 수 있다면 로드 밸런서의 max는 us-west-2a의 max와 일치합니다.

UnHealthyHostCount

로드 밸런서에 등록된 비정상 상태의 인스턴스 수. 상태 검사에서 구성되어 있는 비정상 임계값을 초과한 인스턴스는 비정상 상태로 간주합니다. 이후 상태 검사에서 구성되어 있는 정상 임계값을 충족하는 비정상 인스턴스는 다시 정상 상태로 간주합니다.

보고 기준: 등록된 인스턴스가 있을 때

통계: 가장 유용한 통계는 AverageMinimum입니다. 이 두 가지 통계는 로드 밸런서 노드에서 결정됩니다. 단, 일부 로드 밸런서 노드에서 정상 상태로 판단되는 인스턴스라고 해도 다른 노드에서는 일시적으로 비정상으로 판단될 수도 있습니다.

: HealthyHostCount를 참조하십시오.

다음 지표를 사용하면 Classic Load Balancer를 Application Load Balancer로 마이그레이션할 경우 비용을 예측할 수 있습니다. 단, 이 지표는 참고용일 뿐 CloudWatch 경보에 사용해서는 안 됩니다. Classic Load Balancer에 다수의 리스너가 있는 경우에는 각 리스너마다 이 지표가 집계됩니다.

이러한 예측 비용은 기본 규칙 1개와 2K 크기의 인증서로 구성된 로드 밸런서를 기준으로 합니다. 크기가 4K 이상인 인증서를 사용하는 경우 비용을 다음과 같이 추정하는 것이 좋습니다. 마이그레이션 도구를 사용하여 Classic Load Balancer를 기반으로 Application Load Balancer를 생성하고 Application Load Balancer에 대한 ConsumedLCUs 지표를 모니터링합니다. 자세한 내용은 Elastic Load Balancing 사용 설명서Classic Load Balancer 마이그레이션을 참조하세요.

지표 설명
EstimatedALBActiveConnectionCount

클라이언트에서 로드 밸런서로, 그리고 로드 밸런서에서 대상으로 동시에 연결되는 활성 TCP 연결 예측 수.

EstimatedALBConsumedLCUs

Application Load Balancer에서 사용하는 예상 로드 밸런서 용량 단위(LCU) 수입니다. 시간 단위로 사용한 LCU 수만큼 요금을 지불하면 됩니다. 자세한 내용은 Elastic Load Balancing 요금을 참조하세요.

EstimatedALBNewConnectionCount

클라이언트에서 로드 밸런서로, 그리고 로드 밸런서에서 대상으로 새롭게 구성된 TCP 연결 예측 수

EstimatedProcessedBytes

Application Load Balancer에서 처리되는 바이트 예측 수.

Classic Load Balancer의 지표 차원

Classic Load Balancer 지표를 필터링하려면 다음 차원을 사용하세요.

차원 설명
AvailabilityZone

지정한 가용 영역을 기준으로 지표 데이터를 필터링합니다.

LoadBalancerName

지정한 로드 밸런서를 기준으로 지표 데이터를 필터링합니다.

Classic Load Balancer 지표에 대한 통계

CloudWatch는 Elastic Load Balancing에서 게시한 지표 데이터 포인트를 기반으로 통계를 제공합니다. 통계는 지정한 기간에 걸친 지표 데이터 집계입니다. 통계를 요청하면 지표 이름 및 차원으로 반환된 데이터 스트림이 식별됩니다. 차원이란 지표를 고유하게 식별하는 데 도움이 되는 이름/값 쌍을 말합니다. 예를 들어 특정 가용 영역에서 시작된 로드 밸런서를 지원하는 정상 상태의 모든 EC2 인스턴스에 대한 통계를 요청할 수 있습니다.

MinimumMaximum 통계는 개별 로드 밸런서 노드가 보고한 최소 및 최대 값을 반영합니다. 예를 들어 로드 밸런서 노드가 2개라고 가정해 보겠습니다. 하나의 노드에는 HealthyHostCount이 2, Minimum이 10, Maximum가 6인 Average가 있으며 다른 노드에는 HealthyHostCount이 1, Minimum이 5, Maximum가 3인 Average가 있습니다. 따라서 로드 밸런서의 Minimum은 1, Maximum은 10, Average는 4입니다.

Sum 통계는 모든 로드 밸런서 노드의 집계 값입니다. 지표에는 기간별 보고서가 여러 개 있기 때문에 SumRequestCount, HTTPCode_ELB_XXX, HTTPCode_Backend_XXX, BackendConnectionErrorsSpilloverCount 등 모든 로드 밸런서 노드에서 집계된 지표에만 적용할 수 있습니다.

SampleCount 통계는 측정된 샘플의 수입니다. 지표는 샘플링 간격 및 이벤트를 토대로 수집이 되기 때문에 일반적으로 이 통계는 유용하지 않습니다. 예를 들어 HealthyHostCount에 대해 SampleCount는 각 로드 밸런서 노드가 보고하는 샘플 수를 기반으로 하며 정상 호스트 수는 아닙니다.

백분위 수는 데이터 세트에서 값의 상대적 위치를 나타냅니다. 소수점 두 자리까지 사용하여 백분위 수를 지정할 수 있습니다(예: p95.45). 예를 들어 95 백분위는 데이터의 95%가 이 값보다 아래에 있고 5%가 위에 있다는 것을 의미합니다. 백분위 수는 종종 이상치를 격리하는 데 사용됩니다. 예를 들어 애플리케이션이 캐시에서 오는 요청의 대다수를 1-2 ms에 처리하지만, 캐시가 비어 있는 경우에는 처리에 100 - 200 ms가 걸린다고 가정해 봅시다. 최대값은 가장 느린 경우(200 ms 정도)를 반영합니다. 평균은 데이터의 분산을 나타내지 않습니다. 백분위 수는 애플리케이션 성능을 훨씬 의미 있는 방식으로 볼 수 있습니다. Auto Scaling 트리거 또는 CloudWatch 경보로 99 백분위를 사용하면 처리에 2 ms가 넘게 걸리는 요청이 전체의 1%를 넘지 않게 할 수 있습니다.

로드 밸런서에 대한 CloudWatch 지표 보기

Amazon EC2 콘솔을 사용하여 로드 밸런서에 대한 CloudWatch 지표를 볼 수 있습니다. 이 측정치들은 모니터링 그래프로 표시됩니다. 로드 밸런서가 활성 상태로 요청을 수신 중에 있으면 모니터링 그래프에 데이터 요소가 표시됩니다.

또는 CloudWatch 콘솔을 사용하여 로드 밸런서에 대한 지표를 볼 수 있습니다.

콘솔을 사용하여 지표를 보려면
  1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

  2. 탐색 창의 Load Balancing 아래에서 로드 밸런서를 선택합니다.

  3. 로드 밸런서 이름을 선택하여 세부 정보 페이지를 엽니다.

  4. 모니터링 탭을 선택합니다.

  5. 단일 지표를 더 크게 보려면 그래프 위에 커서를 두고 Maximize 아이콘을 선택합니다. 다음과 같은 측정치를 사용할 수 있습니다.

    • 정상 호스트 - HealthyHostCount

    • 비정상 호스트 - UnHealthyHostCount

    • 평균 지연 시간 - Latency

    • 요청 - RequestCount

    • 백 엔드 연결 오류 - BackendConnectionErrors

    • 서지 대기열 길이 - SurgeQueueLength

    • 초과 수 - SpilloverCount

    • HTTP 2XX - HTTPCode_Backend_2XX

    • HTTP 3XX - HTTPCode_Backend_3XX

    • HTTP 4XX - HTTPCode_Backend_4XX

    • HTTP 5XX - HTTPCode_Backend_5XX

    • ELB HTTP 4XX - HTTPCode_ELB_4XX

    • ELB HTTP 5XX - HTTPCode_ELB_5XX

    • 예상 처리 바이트 수 - EstimatedProcessedBytes

    • 예상 ABL 소비 LCU - EstimatedALBConsumedLCUs

    • 예상 ALB 활성 연결 수 - EstimatedALBActiveConnectionCount

    • 예상 ALB 신규 연결 수 - EstimatedALBNewConnectionCount

CloudWatch 콘솔을 사용하여 지표를 보려면
  1. https://console.aws.amazon.com/cloudwatch/에서 CloudWatch 콘솔을 엽니다.

  2. 탐색 창에서 [지표(Metrics)]를 선택합니다.

  3. [ELB] 네임스페이스를 선택합니다.

  4. 다음 중 하나를 수행하십시오.

    • 지표 차원을 선택하여 로드 밸런서, 가용 영역 또는 모든 로드 밸런서의 지표를 확인합니다.

    • 모든 차원의 지표를 보려면 검색 필드에 이름을 입력합니다.

    • 단일 로드 밸런서에 대한 지표를 보려면 검색 필드에 해당되는 이름을 입력합니다.

    • 가용 영역에 대한 지표를 보려면 검색 필드에 해당되는 이름을 입력합니다.