[DevOps] 5/31 서비스 모니터링 발표자료

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

AWS 람다를 모니터링하기 위해 주목해야 할 메트릭은 크게 5가지로 나눌 수 있다.

 

실행시간(duration): 함수가 작동하는데 어느정도의 시간이 걸리는지 알면 함수의 전체적인 성능이 어떤지 파악할 수 있다.

 호출(Invocations): 함수가 얼마나 자주 호출되는지를 알면 애플리케이션 활동과 함수의 전체적인 성능 추이가 어떻게 되는지 파악할 수 있다. 서비스 중단이나 AWS 서비스 문제 등이 있다면 호출 횟수가 갑자기 감소하는 현상을 볼 수도 있다.

 죽은 편지 에러(Dead-letter Errors): 비동기적으로 호출되거나 이벤트 소스 맵핑에서 호출되는 함수는 처리되지 않은 이벤트를 처리하기 위해 데드-레터 큐(DLQ)를 사용하는데, 여기서 데드-레터 에러 메트릭은 람다가 이벤트를 DLQ에 보낼 수 없는 횟수를 추적한다.

 동시성(Concurrency): 동시성 메트릭을 모니터링하면 과다 프로비저닝된 함수를 관리하고, 애플리케이션 트래픽의 흐름을 지원하기 위해 함수를 확장할지 안할지를 결정할 수 있다.

 프로비저닝된 동시성(Provisioned Concurrency): 람다는 필요할 때만 코드를 실행하기 때문에, 함수가 오랜 시간 동안 사용되지 않은 경우 추가적인 대기 시간(콜드 스타트)이 발생할 수 있다는 단점이 있다. 이 문제를 해결하기 위해 프로비저닝된 동시성을 사용하여 함수를 미리 초기화하면, 미리 요청 처리 준비를 할 수 있다.

 스로틀(Throttles): 요청이 들어오면, 함수는 미리 프로비저닝된 동시성 풀 또는 그 이상에서 스케일링하여 수요를 감당한다. 이때, 동시성 풀을 전부 사용해버리면 람다는 그 지역의 모든 함수를 스로틀링하고 들어오는 모든 요청을 거부한다.

 

---

나올 수 있는 질문들

람다를 효과적으로 모니터링하려면 이러한 메트릭을 이해하고 관찰해야 한다. 그래서 각 메트릭이 어떤 정보를 제공하고 어떻게 사용되는지에 대해 알면 알수록 문제가 발생했을 때 더 적절한 대처를 할 수 있다.

 

그래서 중요 메트릭에 대해서 간단하게 알아보았으니 어떤 질문들이 나올 수 있는지 한번 생각해봤다.

 

---

 

1. 특정 함수의 실행시간이 얼마나 되는가? : 당연하게도 함수의 성능을 파악하는데 매우 중요한 지표기 때문에, 실행 시간을 직접 관찰하면서 해당 람다에 추가적인 최적화 작업이 필요한지 알아볼 수 있다.

 

2. 함수가 얼마나 호출되고 있는가? : 함수가 얼마나 자주 호출되는지를 알면 애플리케이션 활동과 함수의 전체적인 성능 추이가 어떻게 되는지 파악할 수 있다. 서비스 중단이나 AWS 서비스 문제 등이 있다면 호출 횟수가 갑자기 감소하는 현상을 볼 수도 있다. 

 

3. 데드레터 큐로 이동하지 못한 이벤트의 수(dead-letter errors)는 얼마나 되는가? : 람다가 이벤트를 DLQ로 보내는데 실패한 갯수다. 이것을 파악하면 시스템에서 문제가 발생하는 부분을 찾는데 중요한 단서로 사용할 수 있다.

 

---

 

[주제 2] 쿠버네티스에 어떤 파드가 Pending 상태에 머물러있다면, 어떤 계층부터 살펴보아야 할까요? 이 경우는 파드가 Running 상태인데 잘 작동하지 않는 경우랑은 어떻게 다른가요?

파드 상태: 'Pending' vs 'Running'

먼저, 쿠버네티스 파드의 'Pending' 상태와 'Running' 상태에 대해 이해할 필요가 있다.

'Pending' 상태는 파드가 쿠버네티스 시스템에 의해 스케줄되었지만, 아직 하나 이상의 컨테이너가 노드에 배포되지 않은 상태를 말한다. 이는 일반적으로 리소스 부족, 볼륨 마운트 문제, 허용된 톨러레이션 미달 등과 같은 이슈 때문에 발생한다.

반면에, 'Running' 상태는 모든 파드의 컨테이너가 성공적으로 스케줄링되고 시작된 상태를 의미하는데, 'Running' 상태의 파드가 정상적으로 작동하지 않는다면, 일반적으로 애플리케이션 수준의 오류나 컨테이너 실행 환경 문제 등이 원인일 가능성이 높다.

그래서 파드가 'Pending' 상태에 머물러 있는 경우와 'Running' 상태인데 잘 작동하지 않는 경우는 문제를 해결하기 위해 검사해야 하는 부분이 다르다고 볼 수 있다.

 

---

 

파드 'Pending' 상태 문제 분석

'Pending' 상태의 파드를 해결하려면 아래 요소들을 확인해봐야한다.

1. 클러스터 및 노드 상태 확인:
쿠버네티스 클러스터와 노드가 정상적으로 작동하고 있는지 확인해야 한다. kubectl get nodes 명령어를 사용하여 노드 상태를 확인할 수 있고, 충분한 리소스(CPU, 메모리, 스토리지 등)가 있는지 확인해야 한다.

2. 파드 스케줄링 및 톨러레이션 확인:
파드의 스케줄링 정책과 톨러레이션을 확인해야 한다. 노드 셀렉터, 노드 어피니티, 테인트 및 톨러레이션 등이 올바르게 설정되어 있는지 확인해주면 된다.

3. 파드 볼륨 및 컨피그맵 확인:
파드가 필요로 하는 볼륨이나 컨피그맵이 존재하는지, 올바르게 마운트되어 있는지 확인해야 한다.

4. 파드 이벤트 로그 분석:
마지막으로, 파드의 이벤트 로그를 분석해줘야한다. kubectl describe pod <파드 이름> 명령어를 사용하여 파드의 상세 정보와 이벤트 로그를 확인할 수 있다.