10월 5일 메트릭 기반 모니터링 환경 구축

https://if.kakao.com/session/79

메트릭 기반 모니터링 환경 구축(feat. Prometheus)

카카오 페이 모니터링

• 로그
  • elk 스택 사용
  • 수집은 file beats, log stash
• 메트릭 & Tracing
  • 자체 제작 Neo 사용
• 얼럿
  • 로그기반 얼럿 사용
  • 센트리를 사용해서 발생하는 에러 익셉션을 검사하고 메신저로 연락

문제점

• 로그기반이라 데이터가 늘어날수록 느려짐
• 원인 기반 얼럿이라 상황 파악하는데 오래걸림
• 메트릭 대시보드 없는 운영
• 서블릿 기반만 지원하는 APM
  • 모니터링이 안됨 (Webflux, Netty, Akka)

메트릭 기반 모니터링 목표

• MTTD (평균 탐지시간) 5분 이내
  • 장애 탐지 타입 정의
  • 장애 탐지 시간 관리
• 운영 피로도 줄이기 위한 프로세스 도입
  • 메신저의 푸쉬가 오면 긴장됨 ( 공감... )

메트릭 기반 모니터링

• 메트릭
  • 특정 시점에 서비스를 측정하고 기록하는 값
  • 숫자로 되어있어 후처리 과정이 거의 없다.
    • 빠른 계산을 통한 트렌드 분석에 용이함
• 로그
  • 특정 상황이 발생하면 서술하여 기록함
  • 정보로 만들기위한 후처리 필요
    • 서비스의 스케일이 커지면 후처리 비용이 늘어남
    • 대신 정확한 분석에 용이하다.

메트릭에 대한 이야기

• 메트릭은 Label이 강력하다.
  • 하나의 메트릭에 여러가지 라벨로 표현할수 있음
  • 라벨이 많아지면 수집서버에 심각한 문제가 발생
    • 200만개의 레이블 추가후 프로메테우스의 scrape timeout이 발생
    • 전체 모니터링에 장애가 남
    • 이런 문제를 Cardinality 문제라고 함

어떤 메트릭을 수집해야 하는가 ?

• 고객 입장의 메트릭 수집
  • system 입장
  • 고객 입장
    • netflix의 예
      • 스트리밍의 정상작동 확인을 위해 playback 요청을 메트릭으로 활용
      • 사람들이 영상이 안나오면 playback 버튼을 누르기 때문에
      • 이를 통해 서비스가 정상인지 비정상인지를 파악
• RED 방법론
  • Rate: 서비스에서 제공하고 있는 시간당 요청 수
  • Errors: 시간당 에러 숫자
  • Duration: 각 요청에 걸리는 시간 분포
  • 컨트롤러 단이 아닌 도메인단에 메트릭을 추가
  • RED 방법론은 효과적이다.

어떻게 보여줄 것인가 ?

• 대시보드
  • 공통의 대시보드를 제공했으나 대부분이 자신 전용 대시보드를 원했고 보고자하는것도 달랐다.
  • 그라파나 권한을 열어 각자 커스텀하게 사용하도록 함
• 분석을 위한 대시보드와 운영을 위한 대시보드는 따로 만드는것이 효과적이다.

Alert은 어떻게 하는게 좋을까 ?

• 증상 기반
  • exception으로 인해 발생한 증상을 alert으로 전달
• 행동을 필요로 하는것
  • 자원의 부족 상황에서는 스케일 아웃, 디펜던시가 있는 서비스의 문제면 다른 담당자를 찾거나 정보를 알려야함
  • 이런 즉각적인 행동을 필요로 하는것
• 에러 레벨과 인포 레벨 분리
  • 에러 레벨의 경우
    • 무조건 연락
• 적중률 검토를 통한 관리
  • 얼럿이 많으면 잘 보지 않는다
  • 그러므로 사용되는지와 거짓 정보인지를 검토해야 한다.

장애 알림 프로세스는 어떻게 할까

• 영상 참조

확장 가능한 메트릭 저장소

메트릭 저장소 확장하기

• 프로메테우스 사용
  • push 방식의 메트릭 저장소는 사용자의 증가를 감당하기 위해 중앙 수집 서비스가 스케일 아웃 하는 과정에서 운영비용의 증가가 너무 심함
  • 확장에 용이한 pull 방식인 프로메테우스 채택
  • target의 증가에 따라 수집에 걸리는 시간이 늘어남
    • 이는 메트릭 누락으로 이어짐
    • 페더레이션을 사용함
      • 프로메테우스는 두가지 방식의 페더레이션을 제공
        • 계층을 두고 tree 형태로 구성하는 방식
          • 각 ZONE마다 수집하는 프로메테우스를 두고 중앙 프로메테우스가 pull해가는 방식
        • 동일한 레벨의 프로메테우스 서버 사이에 페더레이션을 구성하는 크로스 서비스 방식
      • 계층 방식을 채택하여 사용
  • ha 구성에 문제가 생기면 오탐으로 인해 어려움이 생길수 있다.
    • 로드밸런서와 추가 프로메테우스를 통해 가용성을 확보할수도 있다.
      • 추가 프로메테우스는 똑같이 수집한다.
        • 하지만 프로메테우스는 시간에 따라 다른 메트릭을 가져올수있는 확률이 있다.
        • 만약 다른 메트릭을 가져오게 된다면 두대의 프로메테우스의 정보가 일치하지 않는다.
        • 이런 문제 떄문에 로드밸런서에서 스티키 세션을 사용하거나 액티브 스탠바이를 사용하는 방식이 있을수 있지만 근본적인 해결 방법은 아니다
    • 근본적인 해결을 위해 타노스를 추가
      • 프로메테우스는 확장성과 가용성이 부족하다는 문제점이 있다.
      • 타노스는 구조는 계층형 페더레이션과 비슷하다.
      • 타노스는 데이터의 저장을 s3와 같은 오브젝트 스토리지를 사용
        • 기간에 있어서 다양하게 확장할수도 있다.
    • 타노스를 선택한 이유
      1. 가용성
      2. 여러 프로메테우스의 지표를 하나의 인스턴스로 처리하는 기능
      3. 각각의 인스턴스에서 수집된 메트릭의 중복을 제거
      4. HA를 위한 특별한 고민을 하지 않아도 됨
      5. 프로메테우스는 로컬 디스크를 사용하기 떄문에 언젠가 삭제됨
         1. 하지만 타노스는 핫데이터는 메모리와 디스크에 저장하고 콜드 데이터는 외부스토리지를 활용해서 기간 문제를 해결함
         2. 성능 이슈 떄문에 내부에 디스크를 사용할 뿐만 아니라 데이터 롤업을 사용해서 더 넓은 시간 레인지를 보여줄수 있다.
      6. 사용자 측면 , 그라파나 또는 애플리케이션 개발자 측면에서는 달라지는 것이 없다.
         1. 단지 그라파나 주소만 바뀌기만 하면 된다.
      7. 타노스는 외부 스토리지로 aws s3 혹은 클라우드 서비스를 사용하게 함.
         1. 카카오는 IDC를 사용하기 떄문에 외부 서비스를 사용하는게 적합하지 않다고 생각
         2. 현재 minio와 openstack swift를 실험중

  정리

  • 고객 입장의 메트릭 정의
  • 얼럿과 대시보드 교육, 공유, 그리고 관리
  • 확장 가능한 메트릭 저장소 구축
  • 각 서비스에 크기에 맞는 저장소를 구축하고 운영하는것이 중요하다.

  후기

  • 타노스를 경험해 봤지만 자세히 다뤄보진 않아서 새롭게 알아가는 부분이 많아 좋았다.