Munggae Project 세 번째 키워드는 바로 모니터링 입니다.
모니터링은 애플리케이션의 상태를 실시간으로 모니터링 하여 관찰 및 분석을 실시하여 애플리케이션의 안정성을 보장하게 하는 중요한 역할이라고 생각합니다.
특히 모니터링은 구성 및 구축의 단계를 넘어서 애플리케이션을 안정적으로 운영하게 도와주는 가장 중요한 요소라고 생각합니다. 따라서 Munggae Project에서 모니터링을 구축하고 클러스터의 상태, 애플리케이션의 상태를 관찰하여 더 좋은 애플리케이션으로 업그레이드를 하기 위해 모니터링의 도입을 결정하였습니다.
모니터링 도구는 여러가지가 존재합니다. 대표적으로
1. Prometheus, Grafana
2. ELK stack
3. AWS CloudWatch
4. Datadog, New Relic
다양한 도구들이 존재합니다. Munggae Project에서 선택한 모니터링 도구들은 다음과 같습니다.
1. metrics-server - 쿠버네티스 클러스터의 CPU, 메모리 등의 실시간 리소스 사용량을 제공
2. Prometheus, Grafana - 매트릭 기반 모니터링 도구 및 데이터 시각화 대시보드 도구
3. Loki - Prometheus와 동일한 라벨링 시스템 사용으로 메트릭과 로그를 함께 분석
우선 metrics-server의 도입으로 클러스터의 리소스 사용량을 실시간으로 제공 받아서 빠른 리소스 사용량 조회를 실시하려고 하였고, Prometheus + Grafana의 조합으로 컨테이너 및 쿠버네티스 기반인 Munggae Project에서 직관적이고 유연한 대시보드 구성 및 다양한 Alert 설정을 실시하기 위해 결정했습니다.
마지막으로 로그 분석을 위해서 ELK stack을 고민하던 중 Munggae Project에서 대규모 로그 데이터를 다루는 환경이 맞는가에 대한 생각 및 의견 나누기를 팀원과 해본 결과 로그 데이터를 다루는 비율이 높지 않고, 최소한의 리소스로 애플리케이션 완성 및 고도화가 목표였던 상황에서 리소스 소모가 높았던 ELK stack 대신 Loki를 사용하여 Prometheus와 연계되는 부분 및 가벼운 리소스 사용, Grafana와의 통합으로 매트릭 및 로그를 대시보드에서 확인 가능한 점까지 확인하여 Loki를 도입하기로 결정했습니다.
Helm chart를 통해서 서버에 구성을 진행하였고 다음과 같이 초기 구성을 진행하였습니다.
대시보드
원하는 네임스페이스(우리 서버만 모인 곳)안의 파드 cpu 사용량, 메모리 사용량 모니터링 가능.
각 deployment별 비교 또한 가능
알림 설정
하지만 개발에 집중하기 위한 환경 구성에는 아직 부족하다고 느꼈습니다. 풀스택 팀원분들은 대시보드를 매번 들어가서 확인할 시간이 없었고, 배포 환경 로그를 개발을 진행하는 동시에 확인하는 경우가 쉽지 않다고 느껴서 추가적으로 Slack의 알림 설정을 진행하여 특별한 지표가 나오거나 로그가 나올때 알림이 표시되어 확인하게 진행하려고 했습니다.
Slack과 Grafana 연동 방법은 아래 사이트를 참고하였습니다.
Grafana와 Slack 연동하여 Alert 설정하기
오늘은 Grafana와 Slack을 연동하여 알림을 설정하는 방법에 대해 알아보자. 알림 설정을 해두면 시스템의 상태를 더 효율적으로 모니터링 할 수 있다. Slack 설정하기 Grafana가 Slack에 알림을 보내기
velog.io
위 사이트 방법대로 진행하여 Slack의 WebHook 가져오고나서
Alert Rule 설정을 진행하였습니다.
sum(rate(container_cpu_usage_seconds_total{namespace="munggae"}[5m])) / sum(kube_pod_container_resource_limits{namespace="munggae", resource="cpu"}) > 0.85
- 계산 방식:
- sum(rate(container_cpu_usage_seconds_total[5m])): 네임스페이스 munggae 내 모든 파드의 최근 5분간 CPU 사용량 합계.
- sum(kube_pod_container_resource_limits): 네임스페이스 munggae 내 모든 파드의 CPU 제한값 합계.
- 이 비율은 **전체 CPU 사용량 대비 CPU 제한값의 비율(평균 CPU 사용률)**을 나타냅니다.
- 조건:
- 평균 CPU 사용률이 85**% 이상**일 때 조건이 참(true)이 됩니다.
추가적으로 메모리 설정도 진행하였습니다.
container_memory_working_set_bytes{namespace="munggae"} / on(namespace, pod, container) kube_pod_container_resource_limits{namespace="munggae", resource="memory"} > 0.8
네임스페이스 내의 각 컨테이너의 메모리 사용률이 80% 이상인지를 확인하는 조건
위 처럼 각 Rule 설정을 하면 밑과 같이 Slack 채널에 알람이 들어오게 됩니다.
(현재 사진은 알람 확인 테스트를 위해 80% 이전에도 알람이 들어오게 설정하였습니다)
마무리 회고
모니터링 시스템을 구축하며 깨달은 점은, 단순히 데이터를 수집하고 대시보드를 만드는 것으로 끝나는 작업이 아니라는 것이었습니다. 이는 결국 팀원들과 협업하며 문제를 더 빨리 파악하고 해결로 나아가는 팀의 효율성을 높이는 도구라는 것을 알게 되었습니다.
구축한 모니터링 시스템 덕분에 팀원들이 시스템 상태를 명확히 이해하고, 문제의 원인을 빠르게 파악하는 모습을 보면서 큰 보람을 느꼈습니다. 특히, 대시보드와 알림 시스템을 통해 애매했던 상황들이 명확히 정의되고, 불확실성이 줄어드는 과정을 보며 모니터링의 중요성을 다시 한번 실감했습니다.
프로젝트는 혼자 잘한다고 끝나는 것이 아니라, 함께 더 나아지는 과정이라는 것을 이번 경험을 통해 다시 확인했습니다. 내가 조금 더 고민하고, 시스템을 고도화하고, 데이터를 직관적으로 전달하려고 노력할수록 팀원들은 더 가벼운 마음으로 문제를 해결할 수 있었습니다.
모니터링 시스템은 단순히 데이터를 보여주는 것이 아니라, 팀의 신뢰를 강화하고 협업을 원활히 하는 도구라고 생각합니다. 저는 앞으로도 이런 시스템을 통해 팀원들이 힘들어하거나 답답해하기보다는, 빠르게 원인을 찾아 해결하고, 결국에는 웃을 수 있는 환경을 만드는 엔지니어가 되고 싶습니다. 이번 프로젝트는 그 목표에 한 발 더 가까워질 수 있었던 소중한 경험이었습니다.
감사합니다!
'munggae-cloud' 카테고리의 다른 글
| Munggae Project 두 번째 키워드: CI/CD (1) | 2024.12.25 |
|---|---|
| Munggae Project 첫 번째 키워드: 아키텍쳐 구성 (1) | 2024.12.23 |
