모니터링과 로깅

쿠버네티스 모범 사례을 요약한 내용입니다.

다양한 모니터링 패턴, 중요한 메트릭 수집, 대시보드 구축을 살펴보기

3.1 메트릭 vs 로그

• 매트릭과 로그는 상호보완적인 관계이지만 목적은 다름
• ex) 애플리케이션의 성능이 저하될 때 메트릭과 로그를 사용
  • 호스팅하는 파드에 높은 레이턴시에 대한 경고 확인시 메트릭 사용
  • 애플리케이션이 내보내는 오류를 확인하기 위해 로그를 사용

매트릭

• 특정 기간에 측정한 일련의 숫자

로그

• 시스템을 탐색적으로 분석하기 위해 사용

3.2 모니터링 기술

• 블랙박스 모니터링은 애플리케이션 외부에 초점을 둠
  • CPU, 메모리, 스토리지 등의 시스템 컴포넌트를 모니터링
  • 인프라 수준의 모니터링에 유용
  • 클러스터가 정상인지 테스트해보기 위한 파드 스케줄링이 블랙박스 모니터링의 예
• 화이트박스 모니터링은 애플리케이션 상태에 초점을 둠
  • HTTP 요청, 500 오류 수, 요청 레이턴시 등

3.3 모니터링 패턴

• 기존의 방식으로도 쿠버네티스를 모니터링 할 수 있지만 기존과는 다른 시선으로 봐야할 수 있음
  • 가상머신(VM)이 언제나 동작하며 상태가 보존되는지 확인
• 쿠버네티스에서는 파드가 매우 동적이며 라이프사이클(Lifecycle)이 짧으므로 쿠버네티스만의 특성을 고려하여 모니터링을 해야함
• 분산 시스템을 모니터링할 때 중요한 패턴 중 USE패턴이 있음(인프라 모니터링 위주)
  • U(utilization): 사용율
  • S(Saturation): 포화도
  • E(Error): 오류율
  USE 패턴
  • 인프라 모니터리에 활용
  • 시스템의 리소스 제약과 오류율을 빠르게 파악 할 수 있음
  • 사용률, 포화도, 오류율을 모니터링하면 네트워크의 병목이나 네트워크 스텍 오류를 쉽게 알수 있음
• 다른 모니터링 기법으로 RED패턴이 있음
  • R(Request): 요청
  • E(Error): 오류율
  • D(Duration): 소요시간
  RED 패턴
  • 사상은 구글의 네 가지 황금 신호에서 가지고 옴
    • 레이턴시: 요청을 처리하는데 걸리는 시간
    • 트래픽: 시스템에 존재하는 요청의 양
    • 오류율: 요청 실패율
    • 포화도: 서비스의 사용률
  • 쿠버네티스에서 실행 중인 프론트엔드 서비스 모니터링 예시
    • 프론트엔드 서비스는 얼마나 많은 요청을 처리하고 있나요?
    • 사용자는 500오류를 얼마나 받고 있나요?
    • 요청에 대한 서비스의 사용률이 과도하게 높지는 않나요?
• USE와 RED는 상호보완적임
  • USE는 인프라 컴포넌트 중심
  • RED는 애플리케이션 중심

3.4 쿠버네티스 메트릭 개요

• 쿠버네티스 클러스터에서 애플리케이션이 정상인지 확인하려면 모든 컴포넌트를 모니터링 해야함
• 쿠버네티스 클러스터는 컨트롤 플레인 컴포넌트와 워커 노드 컴포넌트로 구성 됨
• 컨트롤 플레인 컴포넌트
  • API 서버
  • etcd,
  • 스케줄러
  • 컨트롤 관리자
• 워커 노드
  • kubelet
  • 컨테이너 런타임
  • kube-proxy
  • kube-dns
  • 파드

3.4.1 cAdvisor

• 컨테이너 어드바이져(cAdvisor)는 오픈소스 프로젝트로 노드에서 실행 중인 컨테이너의 리소스와 메트릭을 수집
• kubelet에 내장되어 클러스터의 모든 노드에서 실행 됨
• 리눅스 cgroups 트리를 통해 메모리와 CPU 메트릭을 수집
• cgroups는 CPU, 디스크 IO, 네트워크 IO 리소스를 고립시킬 수 있는 리눅스 커널 기능
• cAdvisor는 모든 컨테이너 메트릭의 진실의 원천임

3.4.2 메트릭 서버

• 지원이 종료된 힙스터(heapster)대신 쿠버네티스 메트릭 서버와 API를 사용함
• 리소스 메트릭 API의 표준 구현체가 메트릭 서버
  • CPU와 메모리 같은 리소스 메트릭을 수집
  • kubelet API로 부터 수집하여 메모리에 저장
  • 스케줄러, 수평 파드 오토스케일러, 수직 파드 오토스케일러에서 사용됨
• 사용자 정의 메트릭 API를 사용해서 임의의 메트릭을 수집 할 수 있음
  • 사용자 정의 메트릭 어댑터를 구축해 리소스 메트릭을 확장할 수 있음
  • ex) 큐(Queue)크기 등의 메트릭을 가지고 올수 있음
• 메트릭 API의 표준화를 통해 CPU와 메모리 메트릭 외의 다양한 메트릭을 가져와 확장 가능

3.4.3 kube-state-metrics

• 쿠버네티스에 저장된 오브젝트를 모니터링 할 수 있는 쿠버네티스 추가 기능
• kube-state-metrics는 클러스터에 배포된 쿠버네티스 오브젝트의 상태를 파악하는데 중점
• kube-state-metrics를 통해 다음과 같은 문제를 해결할 수 있음
  • 파드
    • 클러스터에 몇 개의 파드가 배포되었나요?
    • 대기 중인 파드는 몇 개인가요?
    • 파드 요청을 처리할 수 있을 만큼의 충분한 리소스가 있나요?
  • 디플로이먼트
    • 의도한 상태에서 수행 중인 파드는 몇 개인가요?
    • 몇 개의 레플리카가 가용한가요?
    • 어떤 디플로이먼트가 업데이트되었나요?
  • 노드
    • 워커노드의 상태는 어떤가요?
    • 클러스터에서 할당할 수 있는 CPU 코어는 몇 개인가요?
    • 스케줄되지 않는 노드가 있나요?
  • 잡
    • 잡이 언제 시작되었나요?
    • 잡이 언제 완료되었나요?
    • 몇 개의 잡이 실패했나요?
• 책 발행 시점에는 kube-state-metrics가 29개의 메트릭을 지원하지만 계속 늘어나고 있음

3.5 모니터링할 메트릭

• 모든 메트릭을 모니터링 해야하지만 너무 많은 정보는 중요한 신호를 발견하기 어려움
• 쿠버네티스에서 모니터링할 때는계층적 방식을 취해야 함
  • 계층적 모니터링 방식으로 간단하고 정확하게 판단 할 수 있음
  • ex) 파드가 대기 상태에 진입하면 노드의 리소스 사용량을 먼저 파악하고 문제가 없으면 클러스터 수준의 컴포넌트를 살펴보는 방향으로
    • 물리적 혹은 가상의 노드
    • 클러스터 컴포넌트
    • 클러스터 추가 기능
    • 최종 사용자 애플리케이션
• 시스템에서 살펴볼 메트릭
  • 노드
    • CPU 사용률
    • 메모리 사용률
    • 네트워크 사용률
    • 디스크 사용률
  • 클러스터 컴포넌트
    • etcd 레이턴시
  • 클러스터 추가 기능
    • 클러스터 오토스케일러
    • 인그레스 컨트롤러
  • 애플리케이션
    • 컨테이너 메모리 사용률과 포화도
    • 컨테이너 CPU의 사용률
    • 컨테이너 네트워크 사용률과 오류율
    • 애플리케이션 프레임워크 특정 메트릭

3.6 모니터링 도구

• 쿠버네티스와 통합되는 다양한 모니터링 도구가 계속 늘어나고 있음
• 대표적으로 프로메테우스, InfluxDB, 데이터독, 시스딕, 클라우드 공급자 도구 등이 있음
  • 시스템 모니터링과 알림 툴킷 오픈소스
  • 많은 개발자가 활동했으며 사용자 커뮤니티가 존재했음
  InfluxDB
  • 높은 쓰기와 질의 부하를 처리하도록 설계된 시계열 데이터베이스
  • TICK(Telegraf, InfluxDB, Chronongraf, Kapacitro) 스택의 필수 컴포넌트
  • 대량 타임스템프 데이터와 관련하여 활용됨
    • 데브옵스 모니터링, 애플리케이션 메트릭, IoT 센서 데이터, 실시간 분석 등에서 활용
  데이터독
  • 클라우드 규모의 애플리케이션을 위한 모니터링 서비스
  • SaaS 기반 데이터 분석 플랫폼을 통해 서버, 데이터베이스, 도구, 서비스를 모니터링 할 수 있음
  시스딕
  • 컨테이너 네이티브 앱을 위한 도커와 쿠버네티스 모니터링을 제공하는 상용 도구
  • 쿠버네티스와 직접 통합되어 프로메테우스 메트릭을 수집, 연동, 질의 가능
  클라우드 공급자 도구
  • GCP 스택 드라이버
    • GKE를 모니터링하도록 설계됨
    • 모니터링과 로깅 서비스를 관리하고, GKE 클러스터에 맞춘 대시보드 인터페이스가 있음
    • 클라우드 애플리케이션의 성능과 업타임, 전반적인 상태를 볼수 있음
    • GCP, AWS, 가동 시간 프로브, 애플리케이션 장치로부터 메트릭, 이벤트, 메타데이터를 수집
  • 컨테이너를 위한 마이크로소프트 애저 모니터
    • ACI나 AKS가 호스팅하는 쿠버네티스 클러스터에 배포된 것
    • 컨테이너 워크로드의 성능을 모니터링하도록 설계됨
    • 메트릭 API를 통해 컨트롤러, 노드, 컨테이너의 메모리와 프로세서 메트릭 수집
    • 컨테이너 로그도 수집
    • 모니터링을 활성화하면 메트릭과 로그가 자동으로 리눅스용 로그 애널리틱스의 컨테이너화 버전을 통해 수집
  • AWS 컨테이너 인사이트
    • ECS, EKS, EC2에 쿠버네티스를 사용한다면 클라우드와치 컨테이너 인사이트를 사용할 수 있음
    • 컨테이너 애플리케이션과 마이크로서비스의 메트릭과 로그를 수집, 집계, 요약할 수 있음
    • 컨테이너의 재시작 샐패와 같은 진단 정보를 제공
• 프로메테우스

3.7 프로메테우스를 사용한 모니터링

• 프로메테우스는 쿠버네티스 레이블, 서비스 디스커버리, 메타데이터와 통합되어 있음
• 구글의 내부 모니터링 시스템인 보그몬(Borgmon)에서 많은 개념을 가져옴
• 쿠버네티스 레이블 시스템이 동작하는 방식과 유사하게 키 쌍의 다차원 데이터 모델을 구현
• node_cpu_seconds_total{cpu="0", mode="idle"} node_cpu_seconds_total{cpu="0", mode="iowait"}
• 메트릭을 수집하기 위해 풀(Pull) 모델을 사용
• 메트릭 엔드포인트로부터 메트릭을 수집하여 프로메테우스 서버로 저장
• 쿠버네티스는 이미 프로메테우스 포멧으로 메트릭을 내보내는 기능을 가지고 있음
  • NGINX, Traefik, 이스티오, 링커디, 등도 같은 포멧 사용
• 프로메테우스 아키텍처는 [그림 3-1] 참고
  • 시스템으로부터 수집된 메트릭을 가져와 저장
  프로메테우스 오퍼레이터
  • 프로메테우스 설정을 쿠버네티스 네이티브로 만듬
  • 프로메테우스와 알림메니저 클러스터를 관리하고 운영
  • 사용자가 리소스 정의를 통해 프로메테우스 리소스를 생성, 제거, 설정을 할수 있음
  노드 내보내기
  • 클러스터 안의 노드로부터 수집한 호스트 메트릭을 내보냄
  kube-state-metrics
  • 쿠버네티스 메트릭 수집
  알림매니저
  • 알림을 설정하고 외부 시스템으로 보냄
  그라파나
  • 프로메테우스의 대시보드 시각화 제공
• 프로메테우스 서버

3.8 로깅 개요

• 어떤 로그를 기록하는지에 대한 명확한 정답은 없음
• 모든 것을 기록하기에는 두가지 문제가 발생
  • 너무 많은 노이즈 때문에 문제를 빠르게 발견하기 어려움
  • 많은 리소스 사용으로 인한 높은 비용 발생
• 쿠버네티스 클러스터에서 메트릭을 수집해야할 컴포넌트 목록
  • 노드 로그
    • 핵심 서비스에서 발생한 이벤트를 수집
      • ex) 워커 노드에서 실행 중인 도커 데몬 로그를 수집하면 도커 데몬 문제를 진단하는데 도움이 됨 → 로그 수집이 된다면 도커 데몬은 정상
    • 그외 노드에서 로깅할 수 있는 다양한 필수 서비스가 있음</aside>
    • <aside> ❓ 필수 서비스면... 알려주면 되는데...?
  • 쿠버네티스 컨트롤 플레인 로그
    • 쿠버네티스 컨트롤 플레인은 여러 컴포넌트로 이루어져 있음
      • API 서버
      • 컨트롤러 관리자
      • 스케줄러
    • 컨트롤 플레인은 정상 클러스터의 핵심
    • 컨트롤러 관리자는 최종 사용자가 정의한 오브젝트를 생성할 의무가 있으
    • 중앙집중식 시스템에 로그를 집계 한다면 더 자세한 내용을 얻을 수 있으면 빠르게 분석이 가능
  • 쿠버네티스 감사(Audt) 로그
    • 시스템 내부에서 누가 무엇을 했는지에 대한 통찰력을 주기 떄문에 보안 모니터링이라고 볼수 있음
    • 이런 로그는 노이즈가 많을 수 있음
    • 많은 인스턴스가 존재할 때 활성화하면 로깅 시스템의 리소스 사용량이 높을 수 있음
    • 쿠버네티스 문서에서 감사 로그 모니터링 가이드를 준수해야 함
  • 애플리케이션 컨테이너 로그
    • 애플리케이션이 내보내는 로그를 통해 통찰력을 제공
    • 통일된 방법으로 애플리케이션을 로깅하기 위해서는 표준 출력으로 내보내는 것을 권장
    • 표준 출럭으로 내보내야 모니터링 데몬이 도커 데몬으로부터 직접 로그를 수집할 수 있음
    • 사이드카(Sidecar) 패턴을 사용하여 파드 안의 애플리케이션 컨테이너 옆에 로그를 전달하는 방식이 있음
      • 파일 시스템에 로그를 남긴다면 이 패턴을 사용하는 것이 좋음

3.9 로깅 도구

• 로그를 수집할 수 있는 많은 도구가 있음
• 로깅 도구는 쿠버네티스 데몬셋(DaemonSet)으로 실행되어야 함
• 표준 출럭으로 로그를 보낼 수 없는 애플리케이션을 위해 사이드카로도 실행 될 수 있어야 함
• 쿠버네티스와 연동되는 대표적인 도구
  • 일렉스틱 스택
  • 데이터독
  • 수모 로직
  • 시스딕
  • 클라우드 공급자 서비스(GCP 스택드라이버, 애저 모니터, 아마존 클라우드 워치)
• 로그 중앙화를 위한 도구로 많은 운영 비용을 절감할 수 있는 호스팅 솔루션이 좋음
• 직접 로깅 솔루션을 호스팅하는 것은 환경이 거대해지면 유지보수를 위함 시간이 늘어남

3.10 EFK 스택을 사용한 로깅

• 로깅 플랫폼을 관리하는 것이 정말 가치 있는 일인가?
  • 처음에는 좋지만 규모가 커짐에 따라 운영이 어려워 질수 있음
  • 정답이 없지만 비즈니스 요건에 따라 직접 호스팅이 필요한지 판단 해야 함
• 일래스틱서치, 플루언티디, 키바나 스택을 사용해 클러스터 모니터링을 실습 해보기
  • 일래스틱서치: 검색엔진
  • 풀루언트디: 쿠버네티스 환경에서 일래스틱서치로 로그 전송
  • 키바나: 저장된 로그 검색, 보기, 상호작용하는 시각화 도구

3.11 알림

• 알림은 양날의 칼
  • 너무 많은 알림은 피로를 줄수 있음
  • 너무 많은 알림은 중요한 이벤트를 놓칠 수 있음
  • 모니터링 할 것과 알림할 것 사이의 균형이 필요함
• 서비스 수준 목표(SLO) 영향에 미치는 이벤트에 집중 하는 것이 좋음
  • 쿠버네티스는 파드가 실패를 하더라도 재시작을 해줌
  • ex) 프론트엔드 서비스의 평균 응답속도가 20ms 보다 지연되면 알림을 준다
• 어떤 알림이 좋을까?
  • 높은 CPU, 메모리, 응답 없는 프로세스 등에 알림 설정
    • 누가 즉각 대응해야하는지에 대해서 명확하지 않음
  • “저절로 문제가 해결되었습니다.”라는 시나리오는 필요 없는 알림
• 즉각 대응할 필요가 없는 알림을 자동으로 처리 하는 것도 알림을 줄일 수 있음
  • 디스크가 가득 찼다면 로그를 자동으로 지우는 방법
  • 앱 디플로이먼트에서 생명성 프로브(Liveness probe)를 이용하면 응답이 없는 프로세스를 자동으로 복원 해줌
• 알림을 구축할 때 알림 임계치(Alert threshold)를 고려해야 함
  • 임계치가 너무 짧으면 거짓 알림을 받을 수 있음
  • 일반적으로 5분 이하의 임계치를 설정하는 것을 권장
    • 5분, 10분, 30분, 1시간 등의 특정 패턴을 사용
• 알림을 보낼때 관련 정보를 보내야함
  • ex) 플레이북(Playbook) 링크를 통해 문제 해결에 관한 정보를 줄 수 있음
  • 데이터 센터, 지역, 앱 소유자, 영향을 받는 시스템 등의 정보를 담아야 함
• 알림 채널을 구축 해야함
  • 알림이 발생하면 누구에게 알려야 하지?
    • 팀 단위로 보내는 것은 추천하지 않음
    • 큰 그룹일 수록 수신자는 노이즈로 판단하고 필터링 할 수 있음
  • 문제에 대한 책임이 있는 사람에게 보내야함
• 처음부터 완벽할 수 없음, 절대로 완벽해질 수 없다고 생각하는 것이 좋음
  • 점진적으로 알림 피로를 주지 않는 쪽으로 개선 해야함

3.12 모니터링, 로깅, 알림 모범 사례

3.12.1 모니터링 모범 사례

• 모든 컴포넌트에 대한 사용률, 포화도, 오류율을 모니터링
• 애플리케이션의 속도, 오류, 시간도 모니터링
• 시스템의 예측이 힘든 상태와 징후를 모니터링할 때는 블랙박스 모니터링을 사용
• 시스템 내부를 조사할때는 화이트박스 모니터링 사용
• 정확도가 높은 메트릭을 얻으려면 시계열 기반 메트릭을 구현
• 프로메테우스와 같은 모니터링 시스템을 활용
• 평균, 합계 메트릭을 이용하여 메트리의 분포를 시각화

3.12.2 로깅 모범 사례

• 전반적인 분석을 하기 위해서는 메트릭 모니터링과 함께 로깅을 해야함
• 30일 ~ 45일까지만 로그를 저장
  • 그이상 저장시 저비용 리소스를 사용
• 사이드카 패턴에서 로그 전달자를 제한적으로 사용
  • 너무 많은 리소스를 사용할 수 있음

3.12.3 알림 모범 사례

• 알림 피로를 조심 해야함
• 완벽해질 수 없다는 생각을 해야함
• 즉각적인 대응이 필요한 알림을 보내야 함

3.13 마치며

• 모니터링 방법에 대해 처음부터 고민 해야 함
• 나중에 모니터링을 구현하게되면 매우 안좋은 상황으로 시스템을 이끌수 있음
• 모니터링 시스템을 통해 빠른 장애 극복을 하는 것을 목표로
• 쿠버네티스와 같은 분산 시스템을 모니터링하려면 많은 작업이 필요하므로 처음부터 준비해야 함