[cloudwatch] Lambda 모니터링

🎯Lambda 모니터링

성능 지표	설명	메트릭 유형	Availability
Duration	함수 실행의 경과 시간(밀리초)	Work:Performance	CloudWatch & Logs
Billed duration	실행 시간은 100ms 블록 단위로 청구되며 블록 단위로 반올림 처리 됩니다.	Work:Performance	Logs
Memory size	함수에 할당된 메모리 양(MB)	Resource:Utilization	Logs
Max memory used	호출에 사용되는 최대 메모리 양(MB)	Resource:Utilization	Logs
Errors	함수 오류로 인해 실패한 호출 수	Work:Error	CloudWatch

관찰할 메트릭: 기간(how long)

함수의 실행 시간을 모니터링하면 비용을 관리하고 최적화하는 데 도움이 될 수 있습니다. 실행 시간에 영향을 미칠 수 있는 요소에는 콜드 스타터, 다른 서비스와의 네트워크 지연과 같은 것이 있습니다.

주의할 점은 청구 기간(Builed duration)은 가장 가까운 100ms로 반올림한 실행 시간을 측정한다는 것입니다. 예를 들어 함수의 실행 시간이 102ms인 경우 청구 기간은 200ms로 측정됩니다. 이때 할당 메모리를 적절히 증가 시키면 100ms 비용만 청구되도록 함수 실행시간을 조절할 수 있습니다.

관찰할 메트릭: 메모리(how much)

메모리는 람다의 비용을 결정하는 3가지 요소 중 하나입니다. 만약 다음 그림과 같이 함수가 최대로 사용 가능한 메모리의 일부분만 사용하는 함수의 경우 할당된 메모리 양을 조절하여 비용을 줄일 수 있습니다.

또는 함수의 실행 시간이 오래 걸리는 경우 함수가 요청을 처리하는 데 사용 가능한 메모리가 충분하지 않다는 신호로 받아들일 수 있습니다. 따라서 메모리 사용량을 모니터링하면 처리 능력과 실행 시간 간의 균형을 맞추는 데 도움이 됩니다.

관찰할 메트릭: 오류

Lambda에서 발생할 수 있는 오류에는 호출 오류와 함수 오류 두 가지 유형이 있습니다. 람다의 오류 메트릭은 함수 오류로 인해 실패한 호출 수를 계산합니다. 지표에는 다른 AWS 서비스의 호출 오류가 포함되지 않습니다.

• 호출 오류: 서비스에 함수를 호출할 수 있는 적절한 권한이 없거나 계정의 동시 실행(concurreny exection)제한에 도달한 경우가 포함될 수 있습니다.
• 함수 오류: 코드에 문제가 있거나(ex: 구문 오류, 예외 발생) 함수가 시간 초과(최대 15분)된 경우에 발생할 수 있습니다.

함수 성능을 모니터링하는 것 외에도 동시성과 다른 서비스가 함수를 호출하는 방식을 모니터링하는 것이 중요합니다. Lambda는 호출 및 동시성을 관리하기 위한 다양한 지표를 제공합니다.

호출 지표

람다는 함수를 호출하는 방법에 따라 모니터링할 지표가 다를 수 있습니다. 다음은 람다를 호출하는 방법과 각각의 방법에서 모니터링할 지표를 나타냅니다.

• 동기 (ex. ELB, API Gateway, …)
• 비동기 (ex. SES, SNS, S3, …)
• 이벤트 소스 매핑 (ex. Kinesis, DynamoDB, …)

지표	설명	메트릭 유형	Availability
Iterator age	스트림 기반 호출에 대한 지표이며 Iterator age는 배치의 마지막 레코드가 스트림(Kinesis, DynamoDB)에 기록된 시점과 Lambda가 배치를 수신한 시점 사이의 시간입니다. 이 메트릭을 통해 스트림에 기록되는 데이터의 양이 너무 많아 함수가 처리할 수 없는 경우를 알 수 있습니다.	Work:Performance	CloudWatch
Invocations	API 호출 또는 다른 AWS 서비스의 이벤트에 의해 함수가 호출된 횟수	Work:Throughput	CloudWatch
Dead-letter errors	비동기식으로 호출되거나 이벤트 소스 매핑에서 호출되는 함수는 DLQ를 사용하여 처리할 수 없고 재시도에 실패한 이벤트를 처리합니다. 이 지표는 Lambda가 DLQ에 이벤트를 보내는 횟수를 추적합니다.	Work:Error	CloudWatch

동시성 지표

기본적으로 람다는 region당 모든 람다에서 공유하는 1,000개의 동시 실행 풀을 제공합니다. 또한 각 람다당 최소 100개의 동시 실행 풀을 제공합니다.

각각의 람다는 인스턴스를 자동으로 확장하여 버스트 트래픽을 관리할 수 있지만 초기 버스트 동안 처리할 수 있는 요청 수에는 제한이 있습니다. 해당 제한에 도달하면 함수는 사용 가능한 모든 동시 실행 풀을 소진할 때까지 분당 500개의 속도로 scale됩니다.

제한은 리전당 1,000개의 동시 실행 제한 또는 Reserved Concurrency(하나 이상의 람다에 할당할 수 있는 동시 실행 풀)일 수 있습니다. 이는 통제할 수 없이 확장되어 특정 람다에서 동시성 풀을 독차지 하는 것을 예방할 수 있습니다.(람다는 예약된 동시성을 모두 사용하는 경우 예약되지 않은 풀에서 추가 동시성에 액세스할 수 없습니다.)

지표	설명	메트릭 유형	Availability
Concurrent executions	임의의 시점에서 함수에 대한 동시 실행의 합계	Work:Performance	CloudWatch
Unreserved concurrent exectuins	사용 가능한 동시 실행의 합계(사용 가능한 총 동시 실행 - 예약된 동시성)	Work:Performance	CloudWatch
Throttles	동시 실행 제한을 초과하는 호출 비율로 인해 발생하는 제한된 호출 수	Resource:Saturation	CloudWatch

예약된 동시성 활용 예:

1. 함수가 들어오는 요청을 처리하기에 충분한 동시 실행을 갖도록 하는 데 도움이 됩니다.
2. 처리하는 요청 수를 제한하려는 경우 함수에 대한 동시성을 예약할 수 있습니다.

스로틀(Throttles)

요청이 들어오면 함수는 예약되지 않은 동시성 풀 또는 예약된 동시성 풀에서 끌어와 수요를 충족하도록 확장됩니다. 풀이 소진되면 Lambda는 해당 region의 모든 기능을 조절하기 시작하고 들어오는 모든 요청을 거부합니다.

스로틀을 모니터링하면 함수의 동시성 제한에 도달하는지 확인하는 데 도움이 됩니다. 동시성 풀을 지속적으로 소진하는 경우 계쩡에서 리전당 동시 실행 한도 증가를 AWS에 요청할 수 있습니다.

프로비저닝된 동시성

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

프로비저닝된 동시성을 사용하여 이 문제를 완화할 수 있습니다. 프로비저닝된 동시성은 요청을 신속하게 처리할 수 있도록 함수를 자동으로 사전 초기화된 상태로 유지합니다.(기본적으로 람다는 약 45분 동안 컨테이너를 활성 상태로 유지하지만 해당 시간은 region 또는 VPC를 사용하는 여부에 따라 다를 수 있습니다.)

지표	설명	메트릭 유형	Availability
Provisioned concurrency spillover invocations	프로비저닝된 동시성 제한을 초과한 동시 호출 수	Work:Throughput	CloudWatch
Provisioned concurrency utilization	함수가 현재 사용 중인 총 할당 프로비저닝 동시성의 백분율	Resource:Utilization	CloudWatch
Provisioned concurrency invocations	프로비저닝된 동시성에 대한 호출 수	Work:Throughput	CloudWatch

📖출처

DataDog Blog

---

👍 개인 공부 기록용 블로그입니다. 오류나 조언이 있으시면 언제든지 댓글 혹은 메일로 남겨주시면 감사하겠습니다! 😄

맨 위로 이동하기

cloudwatch 카테고리 내 다른 글 보러가기