[C171] 람다를 모니터링 하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요? 레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다. (힌트: 레퍼런스 문서에서 how many, how much, how long 으로 검색해보세요.)
📌 정리
- 람다를 모니터링 하는경우 메트릭을 이용하여 아래와 같은 문제를 해결할 수 있다.
👉 성능 및 함수의 사용성 지표
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Duration | The elapsed time for a function’s execution, in milliseconds | Work: Performance | CloudWatch & Logs |
| Billed duration | Execution time billed in 100 ms blocks, rounded up to the next full block | Work: Performance | Logs |
| Memory size | The amount of memory that is allocated to a function, in megabytes | Resource: Utilization | Logs |
| Max memory used | The maximum amount of memory used for an invocation, in megabytes | Resource: Utilization | Logs |
| Errors | The number of failed invocations due to function errors | Work: Error | CloudWatch |
✅ Function utilization and performance metrics
Lambda 함수를 초기화하는 데 걸린 시간을 추적하여 함수가 초기화하는 데 지속적으로 오랜 시간이 걸리는 경우(즉, 잦은 콜드 스타트) 프로비저닝된 동시성 을 사용하여 초기화 지연 시간을 줄이도록 Lambda를 구성할 수 있다.
✅ duration and billed duration
함수의 지속 시간 또는 실행 시간을 모니터링하면 비용을 관리하고 최적화할 수 있는(또는 최적화해야 하는) 함수를 결정할 수 있다.
Lambda는 함수가 종료되고 시간 초과 오류가 발생하기 전에 함수를 실행할 수 있는 시간(15분)을 제한합니다.
모니터링 기간은 이 실행 임계값에 도달하려는 시점을 확인하는 데 도움이 됩니다.
함수의 지속시간이 102ms일 경우 청구를 위한 비용을 결정하는 시간은 200ms가 되지만, 지속시간이 일정한 경우 메모리를 추가해서 100ms 이하로 줄이면 청구기간은 100ms가 되어 요금을 줄일 수 있다.
✅ memory size and max memory used
Lambda는 함수의 컴퓨팅 성능을 제한하지만 함수에 메모리를 할당할 수 있다.
함수의 기간(및 청구된 기간)은 메모리 양에 따라 부분적으로 영향을 받기 때문에 메모리 사용량을 모니터링하는 것이 중요한 지표가 된다.
메모리 사용량을 모니터링하면 처리 능력과 실행 시간 간의 균형을 맞추는 데 도움이 된다
- 시나리오
- 메모리가 부족하면 실행 시간이 느려진다.
- 필요한 것보다 더 많은 메모리를 할당했을 수 있다.
✅ errors
함수 오류로 인해 실패한 호출 수를 추적한다.
코드에 문제가 있거나(예: 예외 발생, 구문 문제) 함수 시간이 초과되면 함수 오류가 발생할 수 있습니다.
애플리케이션이 여러 Lambda 함수에 의존하는 경우 오류 수를 모니터링하면 문제를 일으키는 함수를 정확히 찾아내는 데 도움이 될 수 있다
👉 호출
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Iterator age | The age of the last record for each batch of processed records for a stream, in milliseconds | Work: Performance | CloudWatch |
| Invocations | The number of times a function was invoked by either an API call or an event response from another AWS service | Work: Throughput | CloudWatch |
| Dead-letter errors | The number of times Lambda was not able to send an event to a function’s dead-letter queue | Work: Error | CloudWatch |
동기, 비동기 또는 스트림을 통해 함수를 호출할 수 있습니다.
호출 방법에 따라 모니터링할 메트릭이 다를 수 있습니다.
동기적
- 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가 요청 처리를 마칠 때까지 기다릴 필요가 없기 때문에 서비스에 대한 대기 시간을 줄이는 데 도움이 될 수 있습니다.
이벤트 소스 매핑
Amazon Kinesis 또는 DynamoDB와 같은 AWS 서비스를 구성하여 Lambda 함수에 대한 트리거 역할을 하는 데이터 스트림 또는 대기열을 생성할 수 있습니다.
✅ iterator age
배치의 마지막 레코드가 스트림(예: Kinesis, DynamoDB)에 작성된 시점과 Lambda가 배치를 수신한 시점 사이의 시간입니다.
이 메트릭을 사용하면 스트림에 기록되는 데이터 양이 함수가 처리하기에 너무 많은 경우를 알 수 있습니다. 증가하는 것을 보면 함수가 일괄 데이터를 처리하는 데 너무 오래 걸리고 애플리케이션이 처리되지 않은 이벤트의 큰 백로그를 구축하고 있음을 의미합니다.
iterator age를 늘릴 수 있는 몇 가지 시나리오가 있습니다.
- 함수에 대한 긴 실행 시간
- 스트림에 샤드가 충분하지 않음
- 호출 오류
- 불충분한 배치 크기
✅ invocations
호출 수를 모니터링하면 애플리케이션 활동과 기능이 전반적으로 수행되는 방식을 이해하는 데 도움이 될 수 있습니다.
함수가 여러 지역에 있는 경우 호출 횟수를 사용하여 함수가 효율적으로 사용되는지 확인할 수 있습니다.
호출이 갑자기 감소하면 함수 또는 연결된 AWS 서비스에 문제가 있음을 나타낼 수 있습니다.
이 하락을 Lambda 로그와 같은 다른 데이터 포인트와 연관시켜 추가 문제를 해결할 수 있습니다.
✅ dead-letter errors
비동기식으로 또는 이벤트 소스 매핑에서 호출되는 함수는 DLQ(데드-레터 큐)를 사용하여 폐기된 이벤트(처리할 수 없고 재시도에 실패한 이벤트)를 처리합니다.
배달 못한 편지 오류 지표는 Lambda가 배달 못한 편지 대기열로 이벤트를 보낼 수 없었던 횟수를 추적합니다.
이 측정항목이 증가하면 함수의 권한 에 문제가 있거나 다운스트림 서비스가 제한될 수 있습니다.
👉 동시성
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Concurrent executions | The sum of concurrent executions for a function at any point in time | Work: Performance | CloudWatch |
| Unreserved concurrent executions | The total concurrency left available in the pool for functions | Work: Performance | CloudWatch |
| Throttles | The number of throttled invocations caused by invocation rates exceeding concurrent execution limits | Resource: Saturation | CloudWatch |
동시성을 모니터링하면 초과 프로비저닝된 기능을 관리하고 기능을 확장하여 애플리케이션 트래픽의 흐름을 지원할 수 있습니다.
기본적으로 Lambda는 리전당 1,000개의 동시 실행 풀을 제공하며, 이 풀은 해당 리전의 모든 함수에서 공유합니다.
특정 함수가 다른 함수보다 더 많은 동시성을 정기적으로 필요로 한다는 것을 알고 있는 경우 특히 유용합니다.
함수가 너무 많은 요청을 처리하고 다운스트림 서비스를 압도하지 않도록 동시성을 예약할 수도 있습니다.
✅ concurrent executions
이 메트릭을 모니터링하면 함수가 풀의 모든 동시성을 사용하는 시점을 추적할 수 있습니다.
이 메트릭이 특정 임계값에 도달하면 알림을 생성할 수도 있습니다.
✅ unreserved concurrent executions
계정에서 사용 가능한 총 동시 실행 수와 동일합니다.
함수에 대해 동시성을 예약한 경우 이 메트릭은 사용 가능한 총 동시 실행에서 예약된 동시성을 뺀 것과 같습니다.
예약되지 않은 동시 실행 메트릭을 동시 실행 메트릭과 비교하여 더 많은 워크로드 동안 함수가 나머지 동시성 풀을 소진하는 시기를 모니터링할 수 있습니다.
✅ throttles
요청이 들어오면 예약되지 않은 동시성 풀(예약된 동시성이 없는 경우) 또는 예약된 동시성 풀(사용 가능한 경우)에서 가져옴으로써 함수가 수요를 충족하도록 확장됩니다.
풀이 소진되면 Lambda는 해당 지역의 모든 기능을 조절하기 시작하고 들어오는 모든 요청을 거부합니다.
기능 제한에 대해 경고해야 기능의 용량과 효율성을 사전에 모니터링할 수 있습니다.
👉 프로비저닝된 동시성 사용량
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Provisioned concurrency spillover invocations | The number of concurrent invocations that went over the provisioned concurrency limit | Work: Throughput | CloudWatch |
| Provisioned concurrency utilization | The percentage of its total allocated provisioned concurrency a function is currently using | Resource: Utilization | CloudWatch |
| Provisioned concurrency invocations | The number of invocations on provisioned concurrency | Work: Throughput | CloudWatch |
Lambda는 필요할 때만 함수 코드를 실행하기 때문에 함수를 한동안 사용하지 않으면 추가 지연 시간(콜드 스타트)이 나타날 수 있습니다.
이는 Lambda가 새 컨테이너를 초기화하고 비활성 기능에 대한 패키지 종속성을 프로비저닝해야 하기 때문입니다.
이로 인해 초기화마다 몇 초의 지연 시간이 추가될 수 있습니다.
Lambda는 약 45분 동안 컨테이너를 활성 상태로 유지하지만 해당 시간은 지역이나 VPC를 사용하는 경우에 따라 다를 수 있습니다.
함수의 시작 시간이 긴 경우(예: 종속성이 많은 경우) 요청 지연 시간이 길어질 수 있습니다. 특히 Lambda가 요청 버스트를 지원하기 위해 새 인스턴스를 초기화해야 하는 경우에 그렇습니다. 프로비저닝된 동시성을 사용하여 이를 완화할 수 있습니다. 이 동시성은 함수가 요청을 신속하게 처리할 수 있도록 미리 초기화된 기능을 자동으로 유지합니다.
✅ provisioned concurrency spillover invocations
기능이 할당된 프로비저닝된 동시성 수준을 초과하는지 여부를 보여줍니다.
이 경우 함수는 프로비저닝되지 않은 동시성에서 실행을 시작하여 콜드 스타트의 가능성을 높입니다.
기능이 프로비저닝된 동시성 수준을 지속적으로 초과하는 경우 해당 기능에 대한 구성을 조정해야 할 수 있습니다.
모든 별칭 및 버전에서 프로비저닝된 동시성 수준은 예약된 동시성 풀(구성한 경우)의 크기를 초과할 수 없습니다.
✅ provisioned concurrency utilization
함수가 프로비저닝된 동시성을 효율적으로 사용하고 있는지 확인할 수 있습니다.
사용 가능한 프로비저닝된 동시성을 모두 사용하는 함수(활용 임계값)는 추가 동시성이 필요할 수 있습니다.
사용률이 지속적으로 낮으면 기능을 과도하게 프로비저닝했을 수 있습니다.
비용을 관리하기 위해 해당 기능에 대해 프로비저닝된 동시성을 비활성화하거나 줄일 수 있습니다.
✅ provisioned concurrency invocations
호출 메트릭은 프로비저닝되지 않은 동시성 과 프로비저닝된 동시성 을 사용하는 총 호출 수를 추적합니다 (후자가 구성된 경우). 그만큼 프로비저닝된 동시성 호출 메트릭은 프로비저닝된 동시성에서 실행되는 모든 호출만 추적합니다. 호출 메트릭과 마찬가지로 프로비저닝된 동시성 호출이 갑자기 감소하면 함수 또는 업스트림 서비스에 문제가 있음을 나타낼 수 있습니다.
✅ 참조 레퍼런스
