Metric
서비스 모니터링에서 “메트릭(metric)”은 시스템 또는 애플리케이션의 상태나 동작을 측정하기 위해 사용되는 측정 항목을 의미합니다. 메트릭은 서비스의 성능, 가용성, 사용량 등과 관련된 데이터를 수집하여 분석하고, 시스템의 건강 상태나 문제점을 식별하는 데 도움을 줍니다.
일반적으로 메트릭은 시간에 따른 변화를 추적하기 위해 정기적으로 수집되며, 이를 통해 서비스의 동작을 모니터링하고 성능 지표를 계산할 수 있습니다. 예를 들어, 웹 서비스의 메트릭에는 응답 시간, 요청 처리율, 오류율 등이 포함될 수 있습니다.
메트릭 데이터는 모니터링 시스템에 의해 수집되며, 일반적으로 시계열 데이터베이스 또는 모니터링 도구에 저장됩니다. 이러한 데이터를 시각화하고 경고를 생성하여 시스템의 상태를 실시간으로 확인하고 문제를 예방하거나 조치할 수 있습니다.
메트릭은 서비스의 건강 상태를 이해하고 개선하기 위해 중요한 역할을 합니다. 적절한 메트릭을 수집하고 분석함으로써 서비스의 성능 최적화, 장애 대응, 용량 계획 등에 도움을 줄 수 있습니다.
Microsoft : 시간이 지남에 따라 보고된 숫자 측정값
Google : 일정 기간 동안 추적되는 상태 값
AWS : 시스템 성능에 대한 데이터
메트릭 한눈에 보기
| 컴퓨팅 유닛 관련 메트릭 | 요청/응답 관련 메트릭 | 스케일링 관련 메트릭 | |
|---|---|---|---|
| k8s | - CPU 사용량 (utilization)- 메모리 사용량- 네트워크 in/out- 디스크 사용량(노드 및 파드 별) | - etcd latency- ingress- 요청 개수- 요청 latency- 에러율 | - 디플로이먼트 상황 |
| ECS | - CPU 사용량- 메모리 사용량- 네트워크 in/out(클러스터 및 서비스 별) | 해당 사항 없음 (ALB와 사용하여 분석해야 함) | - 서비스 개수- (원하는/실행 중인/보류 중인) 작업 개수- 컨테이너 인스턴스 개수 |
| EC2 | - CPU 사용량- 네트워크 in/out- 네트워크 패킷 in/out- 디스크 읽기/쓰기 (바이트), 작업 개수- CPU 크레딧 사용량, 밸런스 | - 상태 검사 실패 횟수 | 해당 사항 없음 |
| Lambda | 해당 사항 없음 | - 호출 개수- 실행 시간- 에러 개수 및 성공률- throttles- async delivery failures- IteratorAge | - 동시 실행 횟수 |
| ALB | 해당 사항 없음 | - 대상 응답 시간- 요청 개수- 응답 코드 개수 (2xx, 4xx, 5xx)- 대상 연결 오류- 거부된 연결 개수 합계- 대상 TLS 협상 오류- 클라이언트 TLS 협상 오류- 활성 연결 개수- 새 연결 개수- 처리된 바이트- 사용된 Load Balancer 용량 단위 | 해당 사항 없음 |
Lambda는 인프라 리소스를 관리하므로 CPU 사용량과 같은 일반적인 시스템 지표를 캡처할 수 없습니다. 대신 Lambda는 함수가 사용될 때 함수의 성능과 효율성을 보고합니다.
서버리스 아키텍처를 모니터링할 때 요청 및 기타 서비스가 함수와 상호 작용하는 방식과 함수가 요청에 응답하도록 구성되는 방식
AWS Lambda Metric
1. Lambda 사용률 및 성능
Cloud Watch 로그 예제Oneline : REPORT RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9 Duration: 72.51 ms Billed Duration: 100 ms Memory Size: 128 MB Max Memory Used: 58 MB Init Duration: 2.04 ms
Multiline : REPORT
RequestId: f1d3fc9a-4875-4c34-b280-a5fae40abcf9
Duration: 72.51 ms
Billed Duration: 100 ms
Memory Size: 128 MB
Max Memory Used: 58 MB
Init Duration: 2.04 ms| Name | Description | Metric type | 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 |
| Init Duration | 함수 초기화 경과 시간 |
Duration 과 Billed Durataion Metric을 확인하여 Lambda 비용을 절약할 수 있다.
함수의 Duration은 메모리 양에 부분적으로 영향을 받기 때문에 메모리 사용량을 모니터링하는 것이 중요합니다.
Duration이 102ms이지만 청구 기간(비용 지불)은 200ms인 경우, 기간이 일정하다면(예: 약 102ms) 기간(및 청구 기간)을 줄이기 위해 메모리를 더 추가할 수 있습니다.
예를 들어 함수의 메모리를 192MB로 늘리고 기간이 98ms로 떨어지면 청구 기간은 100ms가 됩니다. 청구 기간 동안 200ms 블록 대신 100ms 블록에 있기 때문에 요금이 적게 부과 됩니다.
AWS Lambda의 과금은 요청 요금과 컴퓨팅 요금의 합으로 계산됩니다.
– 요청 요금 = 함수를 호출한 총 요청 수– 컴퓨팅 요금 = 사용자가 업로드한 코드를 실행한 시간을 계산
메모리를 더 추가해도 비용이 추가되는데?
콘텐츠 디스커버리 플랫폼인 데이블 사에서 AWS Lambda에서 메모리 설정값과 CPU 파워의 관계에 대해서 관련 실험을 했던 내용이 아래 링크인 블로그로 게시된 글을 참고 했습니다.
AWS Lambda에서 메모리 설정값과 CPU 파워의 관계
필요로 하는 메모리 크기와 사용하는 응용에 따라 다르겠지만,일반적으로 메모리의 크기에 상관없이 사용하는 비용이 거의 같다 라고 결과가 나왔으며 Pay-per-use에 맞게 메모리 양을 조절해야 합니다.
Lambda에서 발생할 수 있는 Errors
- 서비스에 함수를 호출할 수 있는 적절한 권한이 없는 경우
- 계정의 동시 실행 제한에 도달한 경우
애플리케이션이 여러 Lambda 함수에 의존하는 경우 오류 수를 모니터링하면 어떤 함수가 문제를 일으키는지 정확히 파악하는 데 도움이 될 수 있습니다. 또한 함수 성능을 모니터링하는 것 외에도 동시성과 다른 서비스가 함수를 호출하는 방식을 모니터링하는 것이 중요합니다.
2. Lambda Invoke Metric
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Iterator age | 스트림에 대해 처리된 레코드의 각 배치에 대한 마지막 레코드의 경과 시간(밀리초) | Work: Performance | CloudWatch |
| Invocations | API 호출 또는 다른 AWS 서비스의 이벤트 응답에 의해 함수가 호출된 횟수 | Work: Throughput | CloudWatch |
| Dead-letter errors | Lambda가 함수의 배달 못한 편지 대기열로 이벤트를 보낼 수 없었던 횟수 | Work: Error | CloudWatch |
Invocations Metric을 확인하여 Lambda 수행 방식 개선
함수가 여러 지역에 있는 경우 호출 횟수를 사용하여 함수가 효율적으로 사용되는지 확인할 수 있습니다. 예를 들어 어떤 함수가 가장 자주 호출되는지 빠르게 확인하고 대기 시간을 개선하기 위해 리소스를 이동하거나 로드 밸런싱을 수정해야 하는지 평가할 수 있습니다.
3. Concurrency Metric
Lambda가 동시에 실행됬을 때의 Metric이며 기본적으로 Lambda는 해당 지역의 모든 기능에서 공유하는 지역당 1,000개의 동시 실행한다. 이때 Lambda를 동시에 사용할 수 있고 예약되어 있는 범위를 reserve concurrency(예약된 동시성) pool 라고 한다.
동시성을 예약하지 않은 함수에 대해
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Concurrent executions | 동시 실행 수 | Work: Performance | CloudWatch |
| Unreserved concurrent executions | 함수 풀에서 사용 가능한 총 동시성 | Work: Performance | CloudWatch |
| Throttles | 동시 실행 제한을 초과하는 호출 비율로 인해 발생하는 제한된 호출 수 | Resource: Saturation | CloudWatch |
Lambda에 요청이 들어오면 reserved 또는 unreserved concurrency pool 에서 끌어와 수요를 충족하도록 확장됩니다. 만약 소진을 전부 하게 되면 해당 지역에 있는 Lambda는 모든 기능을 조절하기 시작하고 들어오는 모든 요청을 거부합니다. 이 상황을 예방하기 위해 임계치를 설정하여 알림을 설정 할 수 있다.
4. Provisioned concurrency metric
Provisioned concurrency??
Serverless의 Cold Start의 문제점인 코드가 실행하는데까지 Delay가 되는 부분을 보완하기 위해 즉시 응답할 수 있게 해당 인스턴스를 초기화해두고 대기하는 상태 즉, Warm Start로 대기하는 상태이다 하지만 이는 요청이 없더라도 리소스를 사용하는것이므로 비용이 발생하게 된다.
| Name | Description | Metric type | Availability |
|---|---|---|---|
| Provisioned concurrency spillover invocations | 프로비저닝된 함수가 동시에 처리할 수 있는 요청 수 제한을 초과했을때 동시 호출 수 | Work: Throughput | CloudWatch |
| Provisioned concurrency utilization | 함수가 현재 사용 중인 총 할당 프로비저닝 동시성의 백분율 | Resource: Utilization | CloudWatch |
| Provisioned concurrency invocations | 프로비저닝된 동시성에 대한 호출 수 | Work: Throughput | CloudWatch |
Provisioned concurrency spillover invocations
함수가 할당된 프로비저닝된 동시에 처리할 수 있는 요청수를 초과하는지 보여줍니다. 이 경우 함수가 프로비저닝되지 않은 동시성에서 실행되기 시작하여 콜드 스타트 가능성이 높아집니다.
Provisioned concurrency utilization
기능이 프로비저닝된 동시성을 효율적으로 사용하고 있는지 확인할 수 있습니다.
