AWSKRUG 컨테이너 소모임
Amazon EKS 모니터링
- EKS의 주요 지표를 확인하고, 모니터링 방안을 소개합니다.

발표자 소개
- 이현진, Sales Engineer at Datadog
- CDN Engineer 2년 / Solutions Architect 7년
- AWS에서 운영 중인 사이드 프로젝트
- MAU 1,500: Aggregator 웹서비스(서버리스 아키텍처)
- MAU 6,000: WebView Android(Fargate on ECS)
- MBTI: ISTP같은 ESTP

모니터링과 알람 그리고 SLO

EKS Architecture
Control Plane Node
- API Server
- Controller manager
- Scheduler
- etcd
Work Node
- kubelet
- CoreDNS
- Kube Proxy

EKS 모니터링의 핵심
2) 사용자 중심의 서비스 단위 모니터링
• 요청 수
• 지연 시간
• 요청 실패율
• 서비스 인프라 사용률
• 분산 트레이싱(APM)
1) 모든 컴포넌트, 리소스, 플랫폼 메트릭
• 컨트롤플레인 메트릭(etcd, workqueue, scheduler, API)
• 클러스터, 노드, 파드 등 리소스(+coredns)
• NGINX, Kafka, Redis 등 플랫폼 메트릭
3) 모든 로그 저장 후 노이즈 로그 제거
• 쿠버네티스 로그
• 애플리케이션 로그
Label
- env: Prd
- app: DatadogWeb
- service: Frontend
- version: 1.0.1
- team: FrontA

CPU, 메모리가 과포화 상태일 때?
네트워크 특이사항?
디스크 I/O?
K8s 혹은 다양한 플랫폼 메트릭?
응답 시간이 3초 이상 일 때?
에러율이 높을 때?
프로세스가 죽었을 때?
EKS 환경에서 언제 알람을 받아야 할까?

고객님의 심기가 불편해지기 전
-> 느리거나, 안 될 때…
각 서비스의 모니터링 기준 필요
-> 메인 페이지 2초 이내
-> 주요 API 1초 이내 등
EKS 환경에서 언제 알람을 받아야 할까?

서비스 수준 지표(SLI) - 서비스의 측면(일반적으로 메트릭)을
표현하는 정량적 측정입니다. SLI는 정량적이어야 하며 합리적인
수준의 정확도로 측정 가능해야 합니다. SLI는 SLO의 기초입니다.
서비스 수준 목표(SLO) - 지정된 기간 동안 서비스에 대한 SLI의
대상 값입니다. SLO는 유지하거나 노력해야 하는 합당한
값이어야 하며 궁극적으로 시간이 지남에 따라 서비스 실패의
성공을 측정하는 방법입니다.
서비스 수준 계약(SLA) - 기본 SLO는 SLA 규정에서 측정될 수
있지만 실제 SLO 목표는 더 엄격하게 구성합니다.
SLA, SLI 그리고 SLO

SLI 주요 지표 및 측정 방법
● 가용성(availability) : 리소스 업타임
● 에러율 (Error rate%) : 전체 요청에서 실패한 요청의 비율
● 응답 시간 (Request latency) : Application 응답 시간
● 처리량(Throughput) : TPS 또는 QPS
Google SRE: Golden Signals

SLO 예시

K8s 모니터링 도구

Observability 도구(Monitoring, Tracing, Logging)
참고: https://landscape.cncf.io

리소스 모니터링: Metrics-Server, Kube-state-metrics

리소스 모니터링: Prometheus, Grafana, Alertmanager

리소스 모니터링: Prometheus, Grafana, Alertmanager

kube-prometheus의 미리 제공되는 룰과 대시보드

EKS의 주요 메트릭
의도한대로 K8s가 동작하지 않을 때
● Pod status: Not Ready 상태
● Node status: Not Ready 상태
● Deployment: Desired와 Current 불일치
● PersistentVolume: 상태 이상
● Container Image: ImagePullBackOff, CrashloopBackOff
● 그 외…
기타 메트릭
● CoreDNS: 지연시간 등
● Kubelet: 인증서 만료
● API Server: 지연 시간
● StatefulSet: 리소스 메트릭

서비스 단위 모니터링: Kiali and JAGER with istio
ServieMesh istio 구조

서비스 단위 모니터링: Kiali and JAGER with istio

서비스 단위 모니터링: AWS X-Ray

● 응답 시간 (Request latency) : SLI 기준 응답 시간 지연(P95?)
● 에러율 (Error rate%) : SLI 기준 에러율 증가(P95?)
● 처리량(Throughput) : Pod 개수 대비 TPS 증가
알람이 필요한 서비스 단위 메트릭

데이터독의 모니터링 level과 알람 체계
자동화 API 테스트(블랙박스 모니터링)
핵심 API(실패) / 인증서 체크(15일
이내)
리소스/사용자 관점
Statefulsets 리소스 중요 메트릭
Gateway(Ingress controller 등)
리소스/사용자 관점
팀별 중요 API(지연, 실패률 / P50~P95 )
K8s 컨트롤플레인 특이사항
SLO 버닝 레이트 초과
외부 API 모니터링(결제 등)
리소스 관점(런북 필수)
리소스 관련(CPU, 메모리 등)
실제 서비스 이슈 X
개인 및 R&D 팀 용도
서비스 실무팀
오퍼레이터팀

1) 모니터링 값에 대한
설명
2) 이슈
영향도
3) 이슈 관련 런북 / 플레이북
4) 1차 팀 채널
7) 직관적인 이슈 대응
가이드
9) 현재 이슈 관련된
대시보드
5) 언제까지? (업무 시간까지)
완료하지 못하면 2차 팀에
노티
6) 2차 팀 채널
8) 작업 완료 후 결과 보고
채널
현재 문제가 발생되지 않는 리소스 이슈의 경우
작업자에 정확한 런북 메시지와 함께 알람 등록
여러 메트릭을 혼합해 알람을 만든 경우
알람을 만든 이유와 관련된 Doc link를 첨부
데이터독의 포스트모템과 알람 메시지

1. 알람을 최소화 하자.
2. 처음부터 완벽한 모니터링을 구축할 수 없다.
3. 장애 후에는 다양한 메트릭을 활용해서 장애 징후를 파악하자.
4. 알람에는 대시보드, 런북 그리고 플레이북을 추가하자. (포스트모템)
5. 새로운 플랫폼 도입 시 모니터링 방안은 데이터독 블로그 참고.
마지막 😙 모니터링 훈수 몇 마디