서비스 모니터링 for Lambda, Kubernetes

Jaeminst·2022년 5월 7일

서비스 모니터링

람다를 모니터링 하려는 경우, 메트릭을 활용해 어떤 질문이 나올 수 있을까요?

람다의 트리거에 SQS가 연결되어 있다면 이벤트를 보낼 수 없었던 횟수를 추적합니다.
람다는 초기 버스트 제한을 도달 후, 분당 500개의 속도로 확장됩니다.
아래의 블로그를 참조해 볼 때 30000RPS에 도달가능하다고 합니다. (어려움)
https://www.serverlessguru.com/blog/scaling-aws-lambda-to-30k-request-per-second
ProvisionedConcurrentExecutions – 프로비저닝된 동시성을 사용한 동시 실행
ProvisionedConcurrencyUtilization - 사용 중인 프로비저닝된 동시성의 비율입니다. 예:
(ProvisionedConcurrentExecutions / 할당된 프로비저닝된 동시성의 총량)
ProvisionedConcurrencyInvocations - 프로비저닝된 동시성을 사용하는 호출 수
ProvisionedConcurrencySpilloverInvocations - 프로비저닝된 동시성을 초과하는 호출 수
버스트 동시성 할당량
https://docs.aws.amazon.com/lambda/latest/dg/invocation-scaling.html
3000 – 미국 서부(오레곤), 미국 동부(버지니아 북부), 유럽(아일랜드)
1000 – 아시아 태평양(도쿄), 유럽(프랑크푸르트), 미국 동부(오하이오)
500 – 기타 지역
lambda 비용 Provisioned
함수를 실행하는 데 걸리는 시간, 각 함수에 할당된 메모리 양, 함수에 대한 요청 수를 기준
메모리 사용량
람다의 비용에 큰 영향을 끼침.
람다함수를 초기화하는 데 걸린 시간(즉, 콜드 스타트)
프로비저닝된 동시성을 사용하여 초기화 지연 시간을 줄이도록 Lambda를 구성
네트워크 지연과 같은 요인, 실행 임계값에 도달하려는 시점
함수의 기간 또는 실행 시간을 모니터링하면 비용을 관리하고 최적화할 수 있는(또는 최적화해야 하는) 함수를 결정할 수 있습니다.
하나를 처리하기 전에 기다려야 하는 시간
처리되기 전에 배치에 특정 수의 레코드가 있는지 확인하려는 경우
단, Lambda의 페이로드 제한을 초과하지 않아야 합니다.

레퍼런스(Lambda 키 메트릭)를 읽고, 어떤 질문을 해결할 수 있는지 알아봅시다.
(힌트: 레퍼런스 문서에서 how many, how much, how long 으로 검색해보세요.)

how many:

Lambda가 배달 못한 편지 대기열에 이벤트를 보낼 수 없었던 횟수를 추적합니다.
이 메트릭이 증가하면 함수의 권한에 문제가 있거나 다운스트림 서비스가 제한될 수 있습니다.

초기 버스트 동안 처리할 수 있는 요청 수에는 제한이 있습니다.
해당 제한에 도달하면 사용 가능한 모든 동시성이 소진될 때까지 함수가 분당 500개의 인스턴스 속도로 확장됩니다.

애플리케이션에 중요한 기능이 있는 경우 예약된 동시성을 할당할 수 있습니다.
이렇게 하면 함수가 들어오는 요청을 처리하기에 충분한 동시 실행이 있는지 확인하는 데 도움이 됩니다.
또는 처리하는 요청 수를 제한하려는 경우 함수에 대한 동시성을 예약할 수 있습니다.
스로틀을 모니터링하면 기능에 대한 동시성 제한에 여전히 도달하고 있는지(그리고 어디에서) 확인하는 데 도움이 됩니다.

how much:

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

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

how long:

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

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

Lambda는 배치에 하나 이상의 레코드가 있는 즉시 배치를 처리하기 때문에 배치 창을 추가하여 Lambda가 하나를 처리하기 전에 기다려야 하는 시간(최대 5분)을 지정할 수 있습니다. 이는 처리되기 전에 배치에 특정 수의 레코드가 있는지 확인하려는 경우에 유용할 수 있습니다. 단, Lambda의 페이로드 제한을 초과하지 않아야 합니다.

쿠버네티스에 어떤 파드가 Pending 상태에 머물러있다면, 어떤 계층부터 살펴보아야 할까요?

이 경우는 파드가 Running 상태인데 잘 작동하지 않는 경우랑은 어떻게 다른가요? (서비스는 연결되어 있다고 가정합니다)

파드 디버깅

https://kubernetes.io/ko/docs/tasks/debug-application-cluster/debug-pod-replication-controller/

파드 디버깅의 첫 번째 단계는 파드를 살펴 보는 것이다. 다음의 명령어를 사용하여 파드의 현재 상태와 최근 이벤트를 점검한다.

kubectl describe pods ${POD_NAME}

파드 내부 컨테이너의 상태를 확인한다. 모두 Running 상태인가? 최근에 재시작 되었는가?

파드의 상태에 따라 디버깅을 계속한다.

파드가 pending 상태로 유지

파드가 Pending 상태로 멈춰 있는 경우는, 노드에 스케줄 될 수 없음을 의미한다.
일반적으로 이것은 어떤 유형의 리소스가 부족하거나 스케줄링을 방해하는 다른 요인 때문이다.
상단의 kubectl describe ... 명령의 결과를 확인하자.
파드를 스케줄 할 수 없는 이유에 대한 스케줄러의 메세지가 있어야 한다.

이유는 다음과 같다.

부족한 리소스

사용자 클러스터의 CPU 나 Memory의 공급이 소진되었을 수 있다. 이 경우 몇 가지 방법을 시도할 수 있다.

클러스터에 노드를 더 추가하기.
pending 상태인 파드를 위한 공간을 확보하기 위해 불필요한 파드 종료하기
파드가 노드보다 크지 않은지 확인한다. 예를 들어 모든 노드가 cpu:1 의 용량을 가지고 있을 경우, cpu: 1.1 을 요청하는 파드는 절대 스케줄 될 수 없다.

사용자는 kubectl get nodes -o <format> 명령으로 노드의 용량을 점검할 수 있다. 다음은 필요한 정보를 추출하는 몇 가지 명령의 예이다.

kubectl get nodes -o yaml | egrep '\sname:|cpu:|memory:'
kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, cap: .status.capacity}'

리소스 쿼터 기능은 사용할 수 있는 전체 리소스의 양을 제한하도록 설정할 수 있다. 네임스페이스와 함께 사용하면, 한 팀이 모든 리소스를 점유하는 것을 방지할 수 있다.

파드가 waiting 상태로 유지

파드가 Waiting 상태에서 멈춘 경우, 워커 노드에 스케줄 되었지만, 해당 장비에서 사용할 수 없다.
거듭 강조하지만, kubectl describe ... 의 정보는 유익하게 사용되어야 한다.
Waiting 파드의 가장 일반적인 원인은 이미지를 가져오지 못하는 경우이다.

파드가 손상(crashing)되었거나 양호하지 않을(unhealthy) 경우

일단 사용자의 파드가 스케줄 되면, 구동중인 파드 디버그하기에 기술된 메서드를 디버깅에 사용할 수 있다.

레플리케이션컨트롤러 디버깅

레플리케이션컨트롤러는 매우 간단하다.
이 오브젝트는 파드를 만들거나 만들 수 없는 경우뿐이다.
만약 파드를 만들 수 없는 경우, 위의 지침을 참조하여 파드를 디버그한다.

사용자는 kubectl describe rc ${CONTROLLER_NAME} 을 사용하여 레플리케이션 컨트롤러와 관련된 이벤트를 검사할 수도 있다.

동작 중인 파드 디버그

https://kubernetes.io/ko/docs/tasks/debug-application-cluster/debug-running-pod/

노드에서 동작 중인(혹은 크래시된) 파드를 디버그하는 방법에 대해 알아보자.

여러분의 파드는 이미 스케줄링 되어 동작하고 있을 것이다.
만약 파드가 아직 동작중이지 않다면, 애플리케이션 트러블슈팅을 참고한다.
일부 고급 디버깅 과정에서는 해당 파드가 어떤 노드에서 동작하고 있는지 알아야 하고, 해당 노드에서 쉘 명령어를 실행시킬 수 있어야 한다.
kubectl을 사용하는 일반적인 디버깅 과정에서는 이러한 접근 권한이 필요하지 않다.

파드의 로그 확인하기

먼저, 확인하고자 하는 컨테이너의 로그를 확인한다.

kubectl logs ${POD_NAME} ${CONTAINER_NAME}

만약 컨테이너가 이전에 크래시 되었다면, 다음의 명령을 통해 컨테이너의 크래시 로그를 살펴볼 수 있다.

kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}

exec를 통해 컨테이너 디버깅하기

만약 컨테이너 이미지에 디버깅 도구가 포함되어 있다면, kubectl exec을 통해 특정 컨테이너에서 해당 명령들을 실행할 수 있다. (리눅스나 윈도우 OS를 기반으로 만들어진 이미지에는 대부분 디버깅 도구를 포함하고 있다.)

kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}

예를 들어, 동작 중인 카산드라 파드의 로그를 살펴보기 위해서는 다음과 같은 명령을 실행할 수 있다.

kubectl exec cassandra -- cat /var/log/cassandra/system.log

kubectl exec에 -i와 -t 옵션을 사용해서 터미널에서 접근할 수 있는 쉘을 실행시킬 수도 있다. 예를 들면 다음과 같다.

kubectl exec -it cassandra -- sh

여러가지 컨테이너 디버깅

임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기
임시 디버그 컨테이너는 kubectl exec로는 충분하지 않을 때 적합하다.
파드의 복제본을 이용해서 디버깅하기
컨테이너 이미지가 쉘을 포함하고 있지 않거나, 애플리케이션이 컨테이너 시작에서 크래시가 발생한다면 kubectl debug를 이용하면 된다.
명령어를 변경하며 파드의 복제본 생성하기
디버그 플래그를 추가하기 위해서나 애플리케이션이 크래시 되는 경우 debug명령어에 --copy-to=myapp-debug플래그를 추가하면 된다.
컨테이너 이미지를 변경하며 파드의 복제본 생성하기
kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu명령으로 컨테이너를 복제하고 이미지를 변경하여 디버깅 컨테이너를 생성한다.
노드의 쉘을 사용해서 디버깅하기
만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아 호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다.