컨테이너 모니터링

How to Monitor the SRE Golden Signals

너무 좋은 글을 발견하여 번역하고 요약해 보았습니다

황금 신호 방법론이란 컨테이너 모니터링 방법론 중 하나로 Google SRE book에서 언급되었고 다른 곳에서도 모니터링 권장 사항으로 언급이 많이 되었다. 여기서 SRE란 Site Reliability Engineering로 현장에 얼마나 적용할수 있는 있는지 기준으로 엔지니어링 하는 것입니다.

모든 사람들이 증상에 관한 신호들이 중요하다는 것에 동의 하지만 정작 모니터링에 대해서 이야기를 나누지는 않습니다.

여기서 언급한 신호들은 전통적으로 모니터링 했던 리소스들인 CPU 나 RAM을 모니터링을 하는 것 보다 어렵습니다.

각 서비스마다 요구하는 지표, 정의 그리고 그에 관한 도구가 다르기 때문이지요.

마이크로 서비스, 컨테이너들 그리고 서버리스 등으로 아키텍처들이 복잡해 진 것이 가장 큰 이유라고 생각 하면 됩니다. 그럼 신호들이 어떤 것들이 있는지 살펴 보겠습니다

• Google SRE 에서는 Latency, Traffic, Errors, and Saturation
• USE 방법론(Brendan Gregg): Utilization, Saturation, and Errors
• RED 방법론(Tom wilkie): Rate, Errors, and Duration

나열된 신호들을 보면 몇몇 겹치는 것이 있습니다. 아래의 블로그를 보면 각 방법에 따라 초점이 다르다고 언급합니다.

Monitoring and Observability With USE and RED - Orange Matter

USE는 내부(인프라)를 보기에 적합하고 RED는 요청, 실질 작업, 외부 보기(서비스 사용자의 관점에서 보기, 어플리케이션 단)에 적합합니다.

이 방법들은 서로 연관되며 상호 보완적입니다.

각각 지표가 나타내는 의미를 표로 나타내면 아래처럼 정리가 가능하다.

• Rate - 요청 비율, 초단위(/s)
• Errors - 에러 비율, 초단위(/s)
• Latency - 응답 시간, 큐/대기 시간 포함, (millisecond 단위)
• Saturation - 과사용, 사용량(utilization)과 연관되는데 큐 깊이 같은 것에 의해 더 직접적으로 측정한다. 큐 측정으로 인해 포화 상태가 되면 non-zero가 된다. 대체적으로 수치로 표시한다.
• Utilization- 리소스나 시스템이 얼마나 바쁜지 보여준다. 대체적으로 0 ~ 100% 단위 예측을 위해서 대부분 사용 (저자는 Saturation이 낫다고 한다.) 여기서는 Utilization 법칙(~ Rate * Service Time/Wokers)을 사용하지 않는다.

이 중 Saturation 와 Utilization이 얻기가 가장 힘듭니다. 왜냐면 해당 지표들은 가정(assumptions), 주의사항(caveats) 그리고 계산 복잡성(근사치로 취급(treat))으로 대부분 되어있기 때문입니다. 하지만 현재와 미래의 장애를 포착하기에는 가장 좋은 지표입니다. 그렇기 때문에 복잡하더라도 이 두 지표를 반드시 포함 시켜야 합니다.

이 모든 측정들은 여러가지를 분리하거나 수집이 가능한대, 예를 들어 HTTP 는 URL로 대기시간과 속도를 나눌 수 있는 것 처럼 4xx & 5xx 에러로 분리가 가능합니다.

게다가 계산을 하기 위해 더 세세한 방법을 사용하기도 하는데 예를 들어, 에러는 요청 성공보다는 낮은 지연시간에서 더 많이 나타나기에 지연시간에서 에러를 제외 할 수 있습니다.(정확히 어떤 의미인지는 아직 잘 모르겠습니다.)

만약 골든 시그널을 지표에 포함시켰다면 무엇을 할 수있는지도 같이 생각해 보아야 합니다.

골든 시그널의 핵심은 엔드 유저와 시스템의 work-producing 영역에 직접적으로 영향을 가는 것들을 측정해야 한다는 것이다. 즉 엔드 유저 관점에서 오류가 없는지를 중요하게 봐야 한다는 의미입니다.

이론적으로 CPU나 RAM 네트워크 등 비교적 덜 직접적인 항목들을 측정하는 것보다는 효율적입니다.

몇가지 이유로 골든시그널을 수집한다.

• Alerting - 문제가 발생했을때 알린다.
• Troubleshooting - 찾는 것에 도움과 문제 해결
• Tuning & Capacity Planning - 좀 더 향상

아무래도 알럿을 잘 설정해야지 장애여부를 잘 대처 할 수 있기에 위 블로그에서는 알럿을 중심으로 설명합니다. 알럿은 전통적으로 고정된 기준을 가지고 알림을 보내는데 그 기준을 설정하는게 어렵고 잘못하면 지나치게 많은 소음을 겪게 된다. 그래서 알럿 도구도 같이 설명해 주는데 위 블로그에 들어가서 보면 좋을 것 같습니다.

평균 이냐 퍼센트지 이냐

평균으로 알럿을 사용하기도 하는데 가능하다면 median 가치를 사용하는게 좋다고 합니다. 양 극단에 있는 아웃라이어 값의 덜 민감하기 때문이지요.

퍼센트지는 좀 더 사용하기 쉽게 생각하는데 예를 들어 95프로의 지연이면 알림을 보낸다 등 사용자에게 얼마나 안 좋은지 측정하는데에 더 낫습니다.

헌데 사실 퍼센트지는 보여지는 것보다 더 복잡합니다. 예를 들어 시스템이 “실제로 측정한 시간 대비 평균의 백분율이다” 라는 식으로 경고를 해주기에 보고 있는 현시점의 퍼센트가 아니라 1분 동안의 평균 퍼센트 이렇게 출력될 수 도 있습니다.

변칙이냐 아님 이상이냐

이상적으로, 새로운 골든 시그널 기반으로 현대의 변칙 감시(Anomaly Detection)를 사용하는 것을 시도할 수 있습니다. 변칙 감시는 off-peak나 너무 낮은 매트릭의 값을 포착하는데에 무척 유용합니다, 거기에 더해서 타이트하게 알럿을 설정 할 수 있고 그로 인해 이슈를 빨리 파악이 가능합니다

그렇지만 이상 감시는 도전적인 면이 있는데, 온 프레미스 같은 경우는 모니터링 솔루션이 거의 없습니다(Zabbix는 못합니다.) 그래도 계속 해서 발전해 나가고 있으며

다행이게도 새로운 SaaS나 DataDog같은 클라우드 모니터링 솔루션이 있고 온 프레미스에서는 프로메테우스같은 솔루션도 생겨나게 되었습니다.

이글이 나온건 2017년인데 현재 프로메테우스는 가장 인기있는 컨테이너 모니터링 도구가 되었고 그라파나라는 시각화 도구도 나온 상태라 더더욱 모니터링이 편해졌다.