lambda 모니터링 주요 메트릭

• 람다를 모니터링하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요? 레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다. (힌트: 레퍼런스 문서에서 how many, how much, how long으로 검색해 보세요.)

lambda 개념
 : AWS Lambda는 인프라 리소스(예: 서버 용량, 네트워크, 보안 패치)를 프로비저닝 하거나 유지 관리할 필요 없이 서버리스 애플리케이션을 구축할 수 있는 컴퓨팅 서비스입니다

 

Lambda 호출 방식
 AWS Lambda는 event drivent architecture입니다. 즉, Amazon API Gateway의 API 호출 또는 DynamoDB 테이블 변경과 같은 다른 서비스의 이벤트에 대한 응답으로 트리거 됩니다.

 

Lambda 모니터링
AWS Lambda는 인프라 리소스를 관리하므로 CPU 사용량과 같은 일반적인 시스템 지표를 캡처할 수 없습니다. 
대신 Lambda는 함수가 사용될 때 함수의 성능과 효율성을 보고합니다.

Lambda를 효과적으로 모니터링하려면 함수가 사용되는 방식과 효율적으로 실행하는 데 필요한 리소스 유형을 이해해야 합니다.
서버리스 아키텍처를 모니터링할 때 요청 및 기타 서비스가 함수와 상호 작용하는 방식과 함수가 요청에 응답하도록 구성되는 방식을 염두에 두어야 합니다.

AWS는 함수를 실행하는 데 걸리는 시간, 각 함수에 할당된 메모리 양, 함수에 대한 요청 수를 기준으로 요금을 부과합니다.
즉, 예를 들어 함수가 서비스 또는 네트워크 중단이 발생하는 API 서비스를 호출하고 응답을 기다려야 하는 경우 비용이 빠르게 증가할 수 있습니다.

Lambda는 병목 현상과 오류를 식별하고 비용을 관리할 수 있는 지표를 제공합니다
 - 기능 활용 및 성능
 - 호출
 - 동시성
 - 프로비저닝 된 동시성

 

동시성

Lambda 함수가 주어진 시간에 처리하는 요청 수를 동시성이라고 합니다.
Lambda는 들어오는 요청 수에 따라 기능을 자동으로 확장합니다.
 1. 서비스가 처음으로 함수를 호출하면 Lambda는 이벤트를 처리하기 위해 함수의 새 인스턴스를 생성합니다.
 2. 서비스가 이벤트를 처리하는 동안 함수를 다시 호출하면 Lambda는 다른 인스턴스를 생성합니다.
  > 이 주기는 들어오는 요청을 처리하기에 충분한 함수 인스턴스가 있거나 함수가 동시성 제한에 도달하여 제한될 때까지 계속됩니다.

 > 기능이 한 번에 처리할 수 있는 요청 수를 관리하기 위해 예약 또는 프로비저닝된 동시성을 구성할 수 있습니다. 

 

호출

요청을 처리하기 위해 Lambda 함수를 호출하는 몇 가지 방법이 있습니다.
함수를 호출하는 서비스에 따라 들어오는 요청을 처리하기 위해 일정량의 동시성을 예약해야 할 수 있습니다.
한 서비스가 일반적으로 다른 서비스보다 더 많은 트래픽을 처리하는 경우 들어오는 요청을 보다 효율적으로 처리하기 위해 동시성 구성을 쉽게 조정할 수 있습니다

 

모니터링할 주요 AWS Lambda 지표

기능 사용률 및 성능 지표

Lambda는 함수의 사용률 및 성능 지표를 자동으로 추적합니다. 이 데이터를 모니터링하면 기능을 최적화하고 비용을 관리하는 데 도움이 됩니다.

 > 초기화 기간 지표 에 초점을 맞추지는 않겠지만 측정 항목, 즉 Lambda 함수를 초기화하는 데 걸린 시간을 이해하는 것이 중요합니다. 함수가 초기화하는 데 지속적으로 오랜 시간이 걸리는 경우(즉, 빈번한 콜드 스타트 ​​), 프로비저닝 된 동시성을 사용하여 초기화 대기 시간을 줄이도록 Lambda를 구성할 수 있습니다.

 

관찰할 메트릭: 기간 및 청구 기간

함수의 기간 또는 실행 시간을 모니터링하면 비용을 관리하고 최적화할 수 있는(또는 최적화해야 하는) 함수를 결정하는 데 도움이 될 수 있습니다.
느린 코드 실행은 콜드 스타트 ​​또는 코드 복잡성의 결과일 수 있습니다.
기능이 타사 서비스 또는 기타 AWS 서비스에 의존하는 경우 네트워크 지연 시간과 같은 요인도 실행 시간에 영향을 미칠 수 있습니다.
Lambda는 또한 함수가 종료되고 시간 초과 오류가 발생하기 전에 함수가 실행될 수 있는 시간(15분)을 제한합니다. 
모니터링 기간은 이 실행 임계값에 도달하려는 시기를 확인하는 데 도움이 됩니다.

기간은 함수의 각 호출 실행 시간을 측정하는 반면 청구 기간은 가장 가까운 100ms로 반올림한 실행 시간을 측정합니다.
함수의 기간을 청구 기간과 비교하여 실행 시간을 줄이고 비용을 낮출 수 있는지 확인할 수 있습니다.

 

REPORT RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9	Duration: 102.25 ms	Billed Duration: 200 ms	Memory Size: 128 MB	Max Memory Used: 58 MB	Init Duration: 2.04 ms	

함수의 기간은 102ms이지만 청구 기간(비용 지불)은 200ms입니다. 기간이 일정하다면(예: 약 102ms) 기간(및 청구 기간)을 줄이기 위해 메모리를 더 추가할 수 있습니다. 예를 들어 함수의 메모리를 192MB로 늘리고 기간이 98ms로 떨어지면 청구 기간은 100ms가 됩니다. 청구 기간 동안 200ms 블록 대신 100ms 블록에 있기 때문에 요금이 적게 부과됩니다.

 > 이 두 지표를 모니터링하면 특히 수백 개의 기능에서 대량의 요청을 관리하는 경우 비용을 관리하는 데 도움이 될 수 있습니다.

 

관찰할 지표: 사용된 메모리 크기 및 최대 메모리

Lambda는 함수의 컴퓨팅 성능을 제한하지만 함수에 대한 메모리 또는 메모리 크기를 AWS Lambda 제한 내에서 할당할 수 있습니다.
함수의 기간(및 청구 기간)은 메모리 양에 부분적으로 영향을 받기 때문에 메모리 사용량을 모니터링하는 것이 중요합니다.
메모리가 부족하면 실행 시간이 느려집니다. 반면에 필요한 것보다 더 많은 메모리를 할당했을 수 있습니다.
 > 메모리 사용량을 모니터링하면 처리 능력과 실행 시간 간의 균형을 맞추는 데 도움이 됩니다.

 

REPORT RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9	Duration: 20.21 ms	Billed Duration: 100 ms	Memory Size: 512 MB	Max Memory Used: 58 MB	Init Duration: 2.04 ms	

 > 함수가 사용 가능한 메모리의 일부만 사용함( max memory used )을 볼 수 있습니다.

 > 이 문제가 지속적으로 발생하는 경우 함수에 할당된 메모리 양을 조정하여 비용을 줄일 수 있습니다.

함수의 실행 시간이 예상보다 오래 걸리는 경우 함수가 요청을 처리하는 데 사용 가능한 메모리가 충분하지 않음을 나타낼 수 있습니다. 
함수의 메모리 사용량은 지속적으로 메모리 크기에 도달합니다.

 

관찰할 메트릭: 오류

Lambda에서 발생할 수 있는 오류에는 호출과 함수의 두 가지 유형이 있습니다.
호출 오류에는 서비스에 함수를 호출할 수 있는 적절한 권한이 없거나 계정의 동시 실행 제한에 도달한 경우가 포함될 수 있습니다.
함수 오류는 코드에 문제가 있거나(예: 예외 발생, 구문 문제) 함수가 시간 초과된 경우에 발생할 수 있습니다. 
> Lambda의 오류 메트릭은 함수 오류로 인해 실패한 호출 수를 계산합니다.
※ 지표에는 다른 AWS 서비스의 호출 오류 또는 내부 서비스 오류가 포함되지 않습니다.

 > 애플리케이션이 여러 Lambda 함수에 의존하는 경우 오류 수를 모니터링하면 어떤 함수가 문제를 일으키는지 정확히 파악하는 데 도움이 될 수 있습니다.

 

 > 함수 성능을 모니터링하는 것 외에도 동시성과 다른 서비스가 함수를 호출하는 방식을 모니터링하는 것이 중요합니다.

 

호출 지표

동기식, 비동기식 또는 스트림을 통해 함수를 호출할 수 있습니다.
호출 방법에 따라 모니터링할 메트릭이 다를 수 있습니다.

다음에는 각 유형에 대해 살펴보겠습니다.

 

동기적으로

Lambda 함수를 동기식으로 호출하는 서비스에는 AWS ELB, Amazon API Gateway 및 Amazon Alexa가 포함됩니다. 
이러한 서비스는 Lambda가 함수에 직접 전달하는 이벤트를 생성하고 결과를 다시 서비스로 전달하기 전에 함수가 실행될 때까지 기다립니다.
이는 애플리케이션 워크플로의 다음 단계로 이동하기 전에 함수 결과가 필요한 경우에 유용합니다.

오류가 발생하면 원래 Lambda에 이벤트를 보낸 AWS 서비스가 호출을 다시 시도합니다.

 

비동기적으로

함수를 비동기식으로 호출할 수 있는 AWS 서비스에는 Amazon Simple Email Service(SES), Amazon Simple Notification Service(SNS) 또는 Amazon S3가 포함됩니다. 
이러한 서비스는 Lambda를 호출하고 Lambda가 대기열에 추가할 이벤트를 즉시 전달합니다.
비동기식 호출은 Lambda가 요청 처리를 완료할 때까지 기다릴 필요가 없기 때문에 서비스에 대한 대기 시간을 줄이는 데 도움이 될 수 있습니다.
대신 Lambda가 이벤트를 대기열에 추가했다는 확인을 받는 즉시 다음 요청으로 이동할 수 있습니다.

이벤트가 대기되면 Lambda가 나머지를 처리합니다. 시간 초과 또는 함수 코드 문제로 인해 함수가 오류를 반환하는 경우 Lambda는 이벤트를 삭제하기 전에 이벤트 처리를 최대 2회 재시도합니다.

Lambda는 또한 함수가 이벤트를 처리하기에 충분한 동시성을 가지고 있지 않은 경우 대기열에 이벤트를 반환하고 오류를 발생시킬 수 있습니다.

실패 원인을 분석하기 위해 폐기된 이벤트를 배달 못한 편지 대기열 (DLQ)로 보내도록 Lambda를 구성할 수 있습니다.

 

이벤트 소스 매핑

또한 이벤트 소스 매핑을 사용하여 Amazon Kinesis 또는 DynamoDB와 같은 AWS 서비스를 구성하여 Lambda 함수의 트리거 역할을 하는 데이터 스트림 또는 대기열을 생성할 수 있습니다. 

 Lambda의 이벤트 소스 매핑은 스트림의 샤드 에서 이벤트 또는 레코드의 배치를 읽은 다음 처리를 위해 해당 배치(이벤트 배치 라고 함)를 함수로 보냅니다.

기본적으로 함수가 오류를 반환하고 일괄 처리를 처리할 수 없는 경우 일괄 처리가 성공하거나 일괄 처리의 레코드가 만료될 때까지 일괄 처리를 다시 시도합니다.

재시도 횟수와 레코드의 최대 보존 기간을 배치로 구성할 수 있습니다. 이렇게 하면 레코드를 처리할 때 함수가 중단되지 않습니다.

 -> Lambda 함수를 동기식, 비동기식 또는 데이터 스트림이나 대기열을 통해 호출하는지 여부에 관계없이 Lambda는 모든 호출을 실시간으로 모니터링하는 데 도움이 되는 지표와 로그를 생성합니다.

 

 > Lambda는 호출 유형에 관계없이 모든 함수에 대한 호출 수, 오류 및 스로틀과 같은 표준 지표를 내보냅니다.

 

Lambda는 또한 호출 유형과 함수가 오류를 처리하는 방식에 따라 다른 지표를 생성합니다.

예를 들어 스트림 기반 호출에 대한 일괄 처리된 레코드의 수명과 삭제된 이벤트가 데드-레터 대기열에 추가되지 않은 경우를 모니터링할 수 있습니다. 그리고 이러한 지표를 Lambda 로그와 연관시키면 문제에 대한 완전한 그림을 얻을 수 있습니다.

 

 

경고할 메트릭: 반복기 수명

Key metrics for monitoring AWS Lambda

Lambda는 스트림 기반 호출에 대한 반복기 수명 지표를 내보냅니다.
반복기 수명은 배치의 마지막 레코드가 스트림(예: Kinesis, DynamoDB)에 기록된 시점과 Lambda가 배치를 수신한 시점 사이의 시간입니다.
 -> 이 메트릭을 통해 스트림에 기록되는 데이터의 양이 너무 많아 함수가 처리할 수 없는 경우를 알 수 있습니다.

증가하는 것이 보이면 함수가 데이터 배치를 처리하는 데 너무 오래 걸리고 애플리케이션이 처리되지 않은 이벤트의 대규모 백로그를 구축하고 있음을 의미합니다.

 

반복기 수명을 늘릴 수 있는 몇 가지 시나리오가 있습니다.

• 함수의 긴 실행 시간
• 스트림에 샤드가 충분하지 않음
• 호출 오류
• 불충분한 배치 크기

  반복기 수명을 줄이려면 함수가 일괄적으로 레코드를 처리하는 데 걸리는 시간을 줄여야 합니다. 
 :  함수가 효율적으로 작동하기에 충분한 메모리가 없으면 기간이 길어질 수 있습니다. 함수에 더 많은 메모리를 할당하거나 함수 코드를 최적화하는 방법을 찾을 수 있습니다.

 

 함수에 충분한 메모리가 있는 경우 스트림에 들어오는 레코드의 볼륨을 관리하기에 충분한 샤드가 없을 수 있습니다. 
 : 스트림의 샤드 수를 늘려 동시성을 높이고 기능이 주어진 시간에 더 많은 요청을 처리할 수 있도록 할 수 있습니다.

 

스트림의 배치 크기를 조정하면 경우에 따라 반복기 수명을 줄이는 데 도움이 될 수도 있습니다.
 : 배치 크기는 처리를 위해 배치할 수 있는 최대 레코드 수를 결정합니다.
 : 배치가 대부분 다운스트림 호출로 구성된 경우 배치 크기를 늘리면 기능이 단일 호출에서 더 많은 레코드를 처리할 수 있으므로 처리량이 증가합니다.
 : 일괄 처리에 추가 처리가 필요한 레코드가 포함된 경우 중단된 샤드를 방지하기 위해 일괄 처리 크기를 줄여야 할 수 있습니다. 

※ 실제 배치 크기는 여전히 함수에 대해 지정한 것보다 작을 수 있습니다. 예를 들어 Lambda의 호출 페이로드 제한은 6MB입니다. 레코드의 크기가 크면 일괄 처리에 추가할 수 있는 레코드의 수가 더 적습니다.

 > Lambda는 배치에 하나 이상의 레코드가 있는 즉시 배치를 처리하므로 배치 창을 추가하여 Lambda가 하나를 처리하기 전에 대기해야 하는 시간(최대 5분)을 지정할 수 있습니다. 
 > 이는 Lambda의 페이로드 한도를 초과하지 않는 한 배치가 처리되기 전에 특정 수의 레코드를 갖도록 하려는 경우에 유용할 수 있습니다.

 

Lambda의 로그에서 추적할 수 있는 호출 오류는 함수가 이벤트를 처리하는 데 걸리는 시간에 영향을 줄 수 있습니다. 
레코드 배치에서 지속적으로 오류를 생성하는 경우 함수는 다음 배치로 계속 진행할 수 없으므로 반복기 수명이 늘어납니다.
 -> 호출 오류는 함수에 액세스 하는 스트림(예: 잘못된 권한) 또는 Lambda의 동시 실행 제한 초과 문제를 나타낼 수 있습니다.
 : 함수가 재시도 제한을 소진한 후에는 모든 실패한 이벤트를 실패 대상(예:Amazon SNS 주제 또는 Amazon SQS 대기열)으로 보낼 수 있습니다.

Lambda가 레코드를 처리할 때 다운스트림 서비스를 사용할 수 없는 경우 별도의 주제 또는 대기열에서 대기하도록 레코드를 보내는 것이 유용합니다.
 이를 통해 Lambda는 영향을 받는 레코드를 배치에서 빠르게 일시적으로 필터링하여 다른 레코드를 처리할 수 있습니다.

※ IT에서 "다운 스트림"은 중앙 서버 또는 원점에서 최종 사용자에게 또는 최종 사용자에게 데이터를 전송하는 것을 말합니다. 일반적으로 다운스트림 트래픽은 업스트림 트래픽보다 더 많은 볼륨이 있습니다. 

 

주시해야 할 메트릭: 호출

호출 수를 모니터링하면 애플리케이션 활동과 기능이 전반적으로 수행되는 방식을 이해하는 데 도움이 될 수 있습니다.
함수가 여러 지역에 있는 경우 호출 횟수를 사용하여 함수가 효율적으로 사용되는지 확인할 수 있습니다.
 -> 예를 들어 어떤 함수가 가장 자주 호출되는지 빠르게 확인하고 대기 시간을 개선하기 위해 리소스를 이동하거나 로드 밸런싱을 수정해야 하는지 평가할 수 있습니다. 
 
Lambda@Edge
 와 같은 서비스는 고객에게 더 가까운 리전에서 코드를 자동으로 실행하여 대기 시간을 개선할 수 있습니다.

호출이 갑자기 감소하면 함수 또는 연결된 AWS 서비스에 문제가 있음을 나타낼 수 있습니다.
추가 문제 해결을 위해 이 드롭을 Lambda 로그와 같은 다른 데이터 포인트와 연관시킬 수 있습니다.

 

주의해야 할 메트릭: 데드 레터 오류

비동기식으로 호출되거나 이벤트 소스 매핑에서 호출되는 함수는 DLQ(배달 못한 편지 대기열)를 사용하여 삭제된 이벤트, 즉 처리할 수 없고 재시도에 실패한 이벤트를 처리합니다.

배달 못한 편지 오류 지표는 Lambda가 배달 못한 편지 대기열에 이벤트를 보낼 수 없는 횟수를 추적합니다.
이 측정항목이 증가하면 함수의 권한에 문제가 있거나 다운스트림 서비스가 제한될 수 있습니다

 

동시성 지표

모니터링 동시성은 과잉 프로비저닝된 기능을 관리하고 애플리케이션 트래픽 흐름을 지원하도록 기능을 확장하는 데 도움이 될 수 있습니다.
기본적으로 Lambda는 해당 지역의 모든 기능에서 공유하는 지역당 1,000개의 동시 실행 풀을 제공합니다.
또한 Lambda는 항상 모든 기능에 대해 항상 최소 100개의 동시 실행을 사용할 수 있는 리전별 동시성 풀이 필요합니다.
함수는 인스턴스를 자동으로 확장하여 트래픽 버스트를 관리할 수 있지만 초기 버스트 동안 처리할 수 있는 요청 수에는 제한이 있습니다.

 

함수가 예약된 동시성을 모두 사용하는 경우 예약되지 않은 풀에서 추가 동시성에 액세스 할 수 없습니다. 
 -> 특정 기능이 정기적으로 다른 기능보다 더 많은 동시성을 필요로 한다는 것을 알고 있는 경우 특히 유용합니다.

 

 

경고할 메트릭: 동시 실행

함수는 동시에 여러 프로세스를 실행하거나 동시에 실행할 수 있습니다. 
 ->  이 메트릭을 모니터링하면 기능이 풀의 모든 동시성을 사용하는 시기를 추적할 수 있습니다.
 -> 이 메트릭이 특정 임계값에 도달하면 알리는 경고를 생성할 수도 있습니다.

 > 위의 예에서 특정 함수에 대한 실행이 급증하는 것을 볼 수 있습니다.

 > 앞에서 언급했듯이 공통 실행 풀에서 동시성을 예약하여 함수의 동시 실행을 제한할 수 있습니다.

 > 함수가 너무 많은 요청을 동시에 처리하지 않도록 해야 하는 경우에 유용할 수 있습니다.

 

관찰할 지표: 예약되지 않은 동시 실행

계정에서 사용 가능한 총 동시 실행 수와 동일한 예약되지 않은 동시 실행을 추적할 수도 있습니다.
 > 함수에 대해 동시성을 예약한 경우 이 지표는 사용 가능한 총 동시 실행에서 예약된 동시성을 뺀 값과 같습니다.
 > 예약되지 않은 동시 실행 지표를 동시 실행 지표와 비교하여 더 많은 워크로드 중에 함수가 나머지 동시성 풀을 소진하는 시기를 모니터링할 수 있습니다.

 

위의 그래프는 예약되지 않은 동시성의 급증과 사용 가능한 대부분의 동시성을 사용하는 하나의 함수를 보여줍니다.
 > 이는 함수에 너무 많은 요청을 보내는 업스트림 서비스 때문일 수 있습니다. 
 > 다른 기능이 효율적으로 작동하기에 충분한 동시성을 확보하기 위해 이 기능에 대한 동시성을 예약할 수 있습니다. 

  > 그러나 Lambda는 예약된 동시성을 모두 사용하는 경우 함수를 조절한다는 점에 유의하십시오.

 

경고할 메트릭: 스로틀

요청이 들어오면 함수는 예약되지 않은 동시성 풀(예약된 동시성이 없는 경우) 또는 예약된 동시성 풀(사용 가능한 경우)에서 끌어와 수요를 충족하도록 확장됩니다.
 -> 풀이 소진되면 Lambda는 해당 지역의 모든 기능을 조절하기 시작하고 들어오는 모든 요청을 거부합니다.
 -> 기능의 용량과 효율성을 사전에 모니터링할 수 있도록 기능 제한에 대해 경고해야 합니다.

지속적인 제한은 기능이 처리할 수 있는 것보다 더 많은 요청이 있고 기능에 대한 용량이 충분하지 않음을 나타낼 수 습니다.
 -> 애플리케이션에 중요한 기능이 있는 경우 예약된 동시성을 할당할 수 있습니다.
 -> 이렇게 하면 함수가 들어오는 요청을 처리하기에 충분한 동시 실행을 갖도록 하는 데 도움이 됩니다.
 -> 또는 처리하는 요청 수를 제한하려는 경우 함수에 대한 동시성을 예약할 수 있습니다.
 -> 스로틀을 모니터링하면 함수의 동시성 제한에 여전히 도달하는지(그리고 어디에서) 확인하는 데 도움이 됩니다.
 -> 동시성 풀을 지속적으로 소진하는 경우 계정에서 리전당 동시 실행 한도 증가를 요청할 수 있습니다.

함수가 호출된 방식에 따라 Lambda는 스로틀의 실패를 다르게 처리합니다.
예를 들어 Lambda는 동기 소스(예: API 게이트웨이)에서 제한된 요청을 재시도하지 않습니다.
함수의 동시성을 관리할 때 이 점을 염두에 두는 것이 중요합니다.

 

프로비저닝 된 동시성 지표

Lambda는 필요할 때만 함수 코드를 실행하므로 한동안 함수를 사용하지 않으면 추가 대기 시간(콜드 스타트)이 나타날 수 있습니다.
 -> 이는 Lambda가 새 컨테이너를 초기화하고 모든 비활성 함수에 대해 패키징 된 종속성을 프로비저닝해야 하므로 초기화할 때마다 몇 초의 대기 시간이 추가될 수 있기 때문입니다.

Lambda는 약 45분 동안 컨테이너를 활성 상태로 유지하지만 해당 시간은 지역 또는 VPC를 사용하는지 여부에 따라 다를 수 있습니다.

함수의 시작 시간이 긴 경우(예: 많은 수의 종속성이 있는 경우) 요청의 대기 시간이 길어질 수 있습니다
 -> 특히 Lambda가 급증하는 요청을 지원하기 위해 새 인스턴스를 초기화해야 하는 경우에는 더욱 그렇습니다.
 -> 프로비저닝 된 동시성을 사용하여 이 문제를 완화할 수 있습니다.
       -> 프로비저닝된 동시성은 요청을 신속하게 처리할 수 있도록 함수를 자동으로 사전 초기화된 상태로 유지합니다.

-> 함수에 충분한 수준의 프로비저닝된 동시성을 할당하면 콜드 스타트가 발생할 가능성을 줄이는 데 도움이 됩니다.

  > 이는 하루 중 특정 시간 동안 트래픽 폭증을 경험하는 애플리케이션(예: 음식 배달 애플리케이션)에 중요할 수 있습니다.

  >  Auto Scaling을 사용하여 예상되는 트래픽 급증을 충족하는 대상 추적을 구성할 수도 있습니다.

 

 

경고할 메트릭: 프로비저닝된 동시성 스필오버 호출

프로비저닝 된 동시성 스필오버 호출지표는 함수가 할당된 프로비저닝된 동시성 수준을 초과하는지 보여줍니다.
 -> 이 경우 함수가 프로비저닝 되지 않은 동시성에서 실행되기 시작하여 콜드 스타트 ​​가능성이 높아집니다.

 > 함수가 프로비저닝 된 동시성 수준을 지속적으로 초과하는 경우 해당 함수에 대한 구성을 조정해야 할 수 있습니다.

 > 모든 별칭 및 버전에서 프로비저닝된 동시성 수준은 예약된 동시성 풀의 크기를 초과할 수 없습니다(구성한 경우).

 

주시해야 할 지표: 프로비저닝된 동시성 사용률

프로비저닝된 동시성 사용률을 모니터링하면 기능이 프로비저닝된 동시성을 효율적으로 사용하고 있는지 확인할 수 있습니다.
 -> 사용 가능한 프로비저닝된 동시성(사용률 임계값)을 모두 사용하는 기능에는 추가 동시성이 필요할 수 있습니다.
 -> 사용률이 지속적으로 낮은 경우 함수를 과도하게 프로비저닝 했을 수 있습니다. 비용을 관리하기 위해 해당 기능에 대해 프로비저닝 된 동시성을 비활성화하거나 줄일 수 있습니다.

 

주시해야 할 메트릭: 프로비저닝된 동시성 호출

호출 지표는 프로비저닝 되지 않은 동시성 및 프로비저닝 된 동시성(후자가 구성된 경우)을 사용하는 총 호출 수를 추적합니다. 
 ->프로비저닝 된 동시성 호출 메트릭은 프로비저닝된 동시성에서 실행되는 모든 호출만 추적합니다.
 -> 호출 메트릭과 마찬가지로 프로비저닝된 동시성 호출의 갑작스러운 감소는 함수 또는 업스트림 서비스에 문제가 있음을 나타낼 수 있습니다.

 

분산 추적 및 APM으로 Lambda 모니터링

서버리스 기능으로 구축된 애플리케이션은 여러 개의 더 작은 구성 요소로 나뉩니다. 
Lambda 함수를 별도로 모니터링하면 요청이 서버리스 아키텍처의 구성 요소 간에 이동할 때 요청 경로에 대한 완전한 가시성을 제공하지 않습니다.
애플리케이션 및 연결된 AWS 서비스의 병목 현상을 식별할 수 있는 기능을 추적하여 성능에 대한 귀중한 통찰력을 얻을 수 있습니다.

 

[출처] https://www.datadoghq.com/blog/key-metrics-for-monitoring-aws-lambda/#metric-to-watch-dead-letter-errors

Key metrics for monitoring AWS Lambda