EKS 처음 설치한다면 - 모니터링, 관측가능성

가시다님 EKS 스터디 참여하고 내용을 정리합니다.

EKS 처음 설치한다고 가정하면 어떻게 설치하는것이 Best Practice일까 고민을 많이 한다. 항상 그렇듯이 현재 설정은 무언가 아쉽고 불만이다. 하지만 막상 변경하려고 하면 이런저런 고민을 핑계로 미룬다.

처음할 때 제대로 하는게 당연히 좋다. 내 경험이 비록 제한이 많지만 그래도 실제 경험은 항상 소중하니, 혹시 새롭게 구성하는 사람들에게 작은 도움이 될까봐 정리해본다.

===============================

모니터링, 옵저버빌리티 속성

개인적으로 시니어 운영자와 주니어를 구분하는 주요한 기준이라 생각한다. DevOps, 인프라 담당자의 중요한 일이 회사의 시간, 돈, 장애를 아끼는 것이다. 그 출발은 바로 현재 우리 회사의 서비스, 시스템의 상태를 정확하게 아는 것인데, 그 기본이 바로 모니터링, 옵저버빌리티 - 관측가능성이다.

그리고 모니터링 일의 속성 상 한번에 알거나 짠하고 구축하기 불가능하여 꾸준히 노력하여 하나하나 완성하는게 필요하다. 사람을 판단할 때 꾸준함이 중요하다고 생각하는데, 인프라 담당자의 꾸준함을 모니터링 체계를 잘 구축하였는지로 판단할 수 있는 것 같다. 다양한 장애 상황에 대비한 탐지 시스템이 구축되었는지, 슬랙 등을 통하여 얼마나 빠르고 적확하게 담당자에게 도달하는지 등을 고려하여 끊임없이 개선해야 한다.

개인적으로 부족한 부분이 많다. 당장 구축하지 않는다고 바로 장애로 이어지지 않기에 많이 미루고 있다. 꾸준한 노력과 개선이 필요하다.

모니터링, 옵저빌리티 차이

• 장애 예방에 집중한다면 모니터링, 현재 시스템의 상태를 파악할 수 있는 것에 집중하면 옵저빌리티 정도로 이해한다.
• 최근에 비용 절감 등의 활동을 많이 하니 옵저빌리티도 중요한 요소다. 물론 모니터링 체계가 잘 구축된 상태에서 옵저버빌리티이지만.

운영 현황

• 다시 구축한다면 기존 경험이 중요할 듯. 데이터독 경험이 있다면 동일하게 중요 Prod 환경은 데이터독으로 가고 이 외 개발, 중요하지 않는 운영 환경(만약 분리되어 있다면)은 Prom, Loki 등의 오픈소스 조합으로 갈 것 같다.
• 데이터독이 매우 편리하지만 자체 라이센스 비용, CloudWatch, Data Transfer 등 추가 AWS 비용 등을 고려하면 오픈소스로 대체하는 게 좋은 선택이다. 실제로 나도 데이터독에서 오픈소스 조합으로 이전해서 많은 비용을 절감할 수 있었다.
• Tracing은 개발자들이 자주 보지 않는다고 하여 아직은 운영 환경에서만 데이터독 사용 중이다. 오픈소스 Tempo 등으로 구축 가능한데, 개발자들이 활발하게 사용한 경험은 없다.

Robusta

• 기본으로 제공하는 alert manager에 비하여 메시지가 직관적이고 어드민 콘솔에서 시간대 별 이벤트 히스토리를 확인할 수 있는 기능이 마음에 들어 잘 사용하고 있다.
  
• 위 슬랙 알람 메시지 예시에 볼 수 있듯이 직관적이라 장애 원인을 빠르게 파악하는데 큰 도움이 된다.
• 관련 제니퍼 시스템에 기고한 글, https://jennifersoft.com/ko/blog/kubernetes/2024-01-10-kubernetes-16/

로깅

• ELK to Loki 변경
• Elastic 환경을 사용하고 있었는데 이를 Loki로 변경하고 비용 절감 하였다. 우려했던 성능 이슈도 별로 없다. 지난 회사부터 지금까지 잘 사용하고 있다.

EKS Control Plane 로깅

• GuardDuty로 문제가 될 수 있는 클러스터 이벤트는 확인 중
• 비용 이슈로 관련 로그를 저장하지는 않는다.

로그 확인 도구

• stern 사용해서 여러 파드의 로그를 편리하게 한번에 검색한다.

부족한 점

• MSK, ElastiCache 등이 대시보드, 알람 설정이 안되어 있다. 데이터독 설정 필요.
• Kafka, Redis에 대한 지식이 부족하여 어떤 것을 모니터링 해야하는지 잘 모른다 정도
  그저 Managed Service 사용하니 별 문제 없기를 바란다?

아직 Grafana Mimir 사용하지 않음

• 분산 처리 가능하여 프로메테우스 보다 성능이 뛰어날 것으로 예상
• 데이터독에 비하여 프로메테우스 성능 차이가 많이 남. 1달 로그 조회하면 1초 이내 vs 10 초 이상 정도
• 새롭게 시스템을 구성한다면 테스트 예정
• VictoriaMetrics는 대규모가 아니라 아직은 고려하지 않았음
• 관련 참고 글
  https://www.anyflow.net/sw-engineer/prometheus-large-scale-comparison

프로메테우스-스택 설치 많이 편함

• Prometheus to v3 업그레이드 필요

그라파나 대시보드

아래 views 4가지 대시보드를 자주본다.

그라파나 커스텀 대시보드

• 인프라 운영에 필요한 대시보드는 만들지 않고 기존에 있는 것 그대로 사용. 처음 구축 시 있는 것 그대로 사용해도 크게 부족한 기능은 없었음.
• 개발 어플리케이션 대시보드는 개발자가 직접 작성.
• 개인적으로 대시보드, 패널 만드는 연습이 필요함

그라파나 얼럿

• 개발자와 협의하여 주요 지표, 예를 들어 응답 속도 지연 등은 그라파나 얼럿에 등록 하였음. 카프카 Lag 등 인프라 관련 지표도 등록 필요

오픈코스트(kubecost) 설치하였으나 잘 활용하지 못하여 사용하지 않음

• 스타트업이라 테넌트, 네임스페이스 별 비용을 분리해야 하는 요구 사항이 없음
• 각 파드 별 최적 Request 설정은 KRR(Kubernetes Resource Recommendations) + 그라파나 히스토리 데이터 통하여 최적화

기타

• Container Insights 사용하지 않음. 유용성은 글쎄.

• SLI/SLO/SLA 사용하지 않음

• 연초 KPI 작성 시 장애율을 주요 지표로 등록하지만 아직 구호 이상의 의미는 가지지 못한다.

• k8sgpt, 몇번 사용했는데, 아직은 그닥 정도

• AWS AMP & AMG 고려하지 않음

• 오픈텔레메트리 잘 모르겠음