- Q. 람다를 모니터링 하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요? 레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다.
- 힌트: 레퍼런스 문서에서 how many, how much, how long 으로 검색해보세요.
Lambda는 기본적으로 어떤 지표를 추적합니까?
Lambda 서비스는 즉시 사용할 수 있는 기능에 대한 7개의 지표와 함께 제공된다.
호출
메트릭 은 특정 기간에 함수가 호출된 빈도를 알려줍니다.
지속 시간
측정항목 은 특정 기간 동안의 함수 런타임에 대해 알려줍니다. 가장 느린, 가장 빠른 및 평균 지속 시간으로 나눕니다.
오류 수
특정 기간에 함수가 충돌한 빈도에 대한 것입니다 . 또한 성공률이 99%인 100개의 오류는 성공률이 1%인 100개의 오류와 다른 의미를 갖기 때문에 성공률을 백분율로 포함합니다.
조절 된 지표
함수가 이미 Lambda의 동시성 제한까지 확장되었기 때문에 처리할 수 없는 함수 호출 수를 보여줍니다. 기본값은 1,000 동시 실행이지만 필요한 경우 늘릴 수 있습니다.
비동기 배달 실패
함수가 대상 또는 배달 못한 편지 대기열에 쓰려고 하지만 실패할 때 발생합니다.
반복자 연령 지표
함수가 스트림(예: Kinesis 또는 Kafka)에서 읽을 때 유용합니다. 이러한 스트림은 자주 사용되므로 업스트림 서비스는 Lambda의 매우 빠른 확장 능력에 압도되지 않습니다. 사용하는 Lambda 함수가 너무 느린 경우 데이터가 스트림에 점점 더 오래 머무르므로 반복자 연령 지표가 증가할 수 있습니다.
동시 실행 지표
특정 기간에 함수에 대해 얼마나 많은 병렬 컨테이너가 로드되는지 확인합니다. 리전 제한인 1,000에 가까워지면 기능의 성능을 개선하거나 계정에 대한 제한을 늘리는 것에 대해 AWS에 문의해야 합니다.
관찰할 측정항목: 기간 및 청구 기간
함수의 지속 시간 또는 실행 시간을 모니터링하면 비용을 관리하고 최적화할 수 있는(또는 최적화해야 하는) 함수를 결정할 수 있습니다. 느린 코드 실행은 콜드 스타트 또는 코드 복잡성의 결과일 수 있습니다. 함수가 타사 서비스 또는 기타 AWS 서비스에 의존하는 경우 네트워크 지연 시간과 같은 요인도 실행 시간에 영향을 미칠 수 있습니다. 또한 Lambda는 함수가 종료되고 시간 초과 오류가 발생하기 전에 함수를 실행할 수 있는 시간(15분)을 제한합니다. 모니터링 기간은 이 실행 임계값에 도달하려는 시점을 확인하는 데 도움이 됩니다.
관찰할 측정항목: 메모리 크기 및 사용된 최대 메모리
Lambda는 함수의 컴퓨팅 성능을 제한하지만 함수에 메모리를 할당할 수 있습니다.메모리 크기, AWS Lambda 제한 내에서 . 함수의 기간(및 청구된 기간)은 메모리 양에 따라 부분적으로 영향을 받기 때문에 메모리 사용량을 모니터링하는 것이 중요합니다. 메모리가 부족하면 실행 시간이 느려집니다. 반면에 필요한 것보다 더 많은 메모리를 할당했을 수 있습니다. 두 시나리오 모두 비용에 영향을 미치므로 메모리 사용량을 모니터링하면 처리 능력과 실행 시간 간의 균형을 맞추는 데 도움이 됩니다.
주목해야 할 지표: 배달 못한 편지 오류
비동기식으로 또는 이벤트 소스 매핑에서 호출되는 함수는 DLQ(데드-레터 큐)를 사용하여 폐기된 이벤트(처리할 수 없고 재시도에 실패한 이벤트)를 처리합니다. 그만큼 배달 못한 편지 오류이 지표는 Lambda가 배달 못한 편지 대기열로 이벤트를 보낼 수 없었던 횟수를 추적합니다. 이 측정항목이 증가하면 함수의 권한 에 문제가 있거나 다운스트림 서비스가 제한될 수 있습니다.
관찰할 측정항목: 오류
Lambda에서 발생할 수 있는 두 가지 유형의 오류(호출 및 함수)가 있습니다. 호출 오류 에는 서비스에 함수를 호출할 수 있는 적절한 권한이 없거나 계정의 동시 실행 제한에 도달한 경우가 포함될 수 있습니다. 코드에 문제가 있거나(예: 예외 발생, 구문 문제) 함수 시간이 초과되면 함수 오류가 발생할 수 있습니다. 람다의 오류메트릭은 함수 오류로 인해 실패한 호출 수를 계산합니다. 이 지표에는 다른 AWS 서비스의 호출 오류 또는 내부 서비스 오류가 포함되지 않습니다.
애플리케이션이 여러 Lambda 함수에 의존하는 경우 오류 수를 모니터링하면 문제를 일으키는 함수를 정확히 찾아내는 데 도움이 될 수 있습니다.
해결법
메모리 할당 증가
메모리 할당을 늘리면 CPU 할당이 암시적으로 증가 합니다. 이것은 당신의 기능을 더 빠르게 실행할 수 있습니다. 콜드 스타트로 인한 대기 시간을 수용하기 위해 실제 실행 시간을 줄이면 사용자 경험을 직접적으로 향상시킬 수 있습니다. 또한 이것은 DevOps 팀의 첫 번째 방어선인 더 긴 대기 시간에서 테스트하기 가장 쉬운 가설입니다.
WarmStart
지연 문제를 해결하는 또 다른 방법은 Lambda 함수에 대해 프로비저닝된 동시성 을 구매하는 것입니다. 프로비저닝된 동시성은 Lambda 서비스에 함수가 포함된 지정된 수의 컨테이너를 warm 상태로 유지하도록 요청 하므로 장기간 호출되지 않은 경우에도 이벤트에 더 빠르게 응답할 수 있습니다. 실제 워크로드가 들어오면 수백 개의 작은 Lambda 인스턴스가 강력한 전투를 위해 준비됩니다.
코드 최적화
아마도 가장 잔인한 옵션 은 개발자에게 코드를 최적화하도록 요청하는 것입니다. 이것은 반드시 실제 로직이나 기능을 변경하는 것을 포함하지는 않지만 종종 종속성을 줄이고 기능을 좀 더 가볍게 만들 수 있습니다.
또한 가능한 한 함수 본문 외부에 많은 작업을 유지하는 것이 좋습니다 . 예를 들어 API 클라이언트를 설정하거나 환경 변수에서 고정 값을 계산합니다. 이런 식으로 작업은 콜드 스타트 속도만 늦추지만 함수에 대한 후속 호출은 느려지지 않습니다.
가능하면 Node.js 및 Python 과 같은 언어를 사용하는 것이 좋습니다. C# 또는 Java 언어보다 콜드 스타트 시간이 현저히 낮기 때문입니다.
사용자 정의 런타임을 사용해 볼 수도 있습니다 . 매우 계산량이 많은 작업이 있는 경우 Rust 런타임을 사용하고 Rust에서 함수를 구현하면 상당한 비용을 절약할 수 있습니다. 특히 Lambda 함수는 밀리초 단위로 요금이 청구되기 때문에 호출 빈도가 높은 함수는 이러한 리팩터링을 통해 엄청난 이익을 얻을 수 있습니다.
https://dashbird.io/blog/lambda-metrics-monitoring-what-matters/
- Q. 쿠버네티스에 어떤 파드가 Pending 상태에 머물러있다면, 어떤 계층부터 살펴보아야 할까요? 이 경우는 파드가 Running 상태인데 잘 작동하지 않는 경우랑은 어떻게 다른가요? (서비스는 연결되어 있다고 가정합니다)
파드가 Pending 상태에 머물러있다면 Pod 디버깅을 한다.
Pod 디버깅의 첫 번째 단계는 살펴보는 것이며 다음 명령어로 Pod의 현재 상태와 최근 이벤트를 확인한다.
kubectl describe pods ${POD_NAME}
Pod에 있는 컨테이너의 상태를 확인하고 모두 Running인지 최근에 다시 재시작을 했는 지 파드(Pod)의 상태에 따라 디버깅을 계속 한다.
파드가 Pending 상태일 때
파드가 Pending 상태로 멈춰있으면 노드에 스케줄링을 할 수 없음을 의미한다. 일반적으로 스케줄링을 방해하는 자원이 부족하기 때문이다. kubectl describe ...위 명령어의 출력을 확인해야한다. 또한 파드를 스케줄링 할 수 없는 이유에 대한 스케줄러의 메시지가 있어야 하며 메세지는 다음과 같다.
- 리소스가 충분하지 않을 때 : 클러스터의 CPU 또는 메모리 공급이 고갈되었을 수 있으며 이 경우 Pod를 삭제하거나 리소스 요청을 조정하거나 클러스터에 새 노드를 추가해야한다. 자세한 내용은 컴퓨팅 리소스 문서 를 참조하세요.
- HostPort를 사용중일 때 : 파드를 HostPort에 바인딩 할 때 스케줄링 할 수 있는 공간은 한정되어있다. 대부분의 경우 HostPort가 불필요하므로 서비스 개체를 사용하여 Pod를 노출을 하고 필요한 경우 hostPortKubernetes 클러스터에 있는 노드 수만큼만 Pod를 스케줄링할 수 있다.
파드가 Wating 상태 일 때
파드가 Waiting 상태로 멈춰있으면 작업자 노드로 스케줄링 되어있지만 해당 머신에서 실행할 수 없다. 위와 마찬가지로 kubectl describe 명령어의 출력을 통해 정보를 확인해아한다. 대부분의 Waiting상태의 파드의 일반적인 원인은 이미지를 가져오지 못하는 것이며 확인해야 할 세 가지 사항이 있다.
- 이미지 이름이 올바른가?
- 이미지를 레지스트리에 푸시하였는가?
- 이미지를 수동으로 당겨서 이미지를 가져올 수 있는지 확인하여 문제가 없는 지 확인하라.
예를 들어 PC에서 Docker를 사용하는 경우 docker pull <image>.
파드가 Running 상태이지만 작동하지않을 때
파드가 예상대로 작동하지 않는 경우 파드 설명(예: mypod.yam와 같은 l로컬 시스템의 파일)에 오류가 있고 파드를 생성할 때 오류가 자동으로 무시되었을 수도 있다. 종종 파드 설명의 섹션이 잘못 중첩되거나 키 이름이 잘못 입력되어 키가 무시된다.
예를 들어 철자 command가 commnd틀리면 포드가 생성되지만 사용하려는 명령줄을 사용하지 않는다.
가장 먼저 할 일은 파드를 삭제하고 --validate옵션으로 다시 생성하는 것이다. 예를 들어, 실행 kubectl apply --validate -f mypod.yaml. command다음과 같이 철자를 틀리면 commnd다음과 같은 오류가 발생한다.
I0805 10:43:25.129850 46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973 46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
pods/mypod
다음으로 확인할 사항은 apiserver의 파드가 생성하려는 파드(예: 로컬 머신의 yaml 파일)와 일치하는지 여부이다. 예를 들어, 실행 kubectl get pods/mypod -o yaml > mypod-on-apiserver.yaml한 다음 원래 포드 설명 mypod.yaml을 apiserver에서 다시 가져온 설명과 수동으로 비교한다. mypod-on-apiserver.yaml. 일반적으로 "apiserver" 버전에는 원래 버전에 없는 일부 줄이 있다. 이것은 예상됩니다. 그러나 원본에 apiserver 버전에 없는 줄이 있는 경우 포드 사양에 문제가 있음을 나타낼 수 있습니다.
https://kubernetes.io/docs/tasks/debug/debug-application/debug-pods/