[SRE] Ch06. 분산 시스템 모니터링

이번 장에서는 사람을 반드시 호출해야 하는 이슈들은 어떤 것인지에 대한 가이드라인을 제공하고, 굳이 호출하지 않아도 되는 이슈들을 처리하는 방안에 대해 설명하고자 합니다.

 

1.  정의

모니터링과 관련된 논의들에 공통적으로 사용될 수 있을 만큼 통일된 용어는 아직 존재하지 않습니다. 하지만 가장 널리 사용되는 용어는 알아두면 좋을 것 같습니다.

• 모니터링 : 쿼리의 수와 종류, 에러의 수와 종류, 처리 시간 및 서버의 활동 시간 등 시스템에 대한 정량적 실시간 데이터를 모으고 처리하고 집계해서 보여주는 것을 말합니다.
• 화이트박스 모니터링 : 로그나 자바 가상 머신의 프로파일링 인터페이스 같은 인터페이스 혹은 내부의 통계 지표를 제공하는 HTTP 핸들러 등을 이용해서 얻은 시스템의 내부 지표들을 토대로 하는 모니터링을 의미합니다.
• 블랙박스 모니터링 : 사용자가 보게 되는 확인 가능한 동작들을 외부에서 테스트하는 과정을 말합니다.
• 대시보드 : 서비스의 핵심 지표에 대한 요약된 뷰를 보여주는 애플리케이션을 말합니다. 쌓여있는 티켓의 숫자나 높은 우선순위를 갖는 버그의 목록, 현재 비상 대기 중인 엔지니어와 담당하는 분야 혹은 최근에 배포된 코드 등 팀과 관련된 정보를 보여주기도 합니다.
• 알림 : 사람이 읽을 수 있도록 작성된 통지를 말하며, 주로 버그나 티켓 큐, 메일, 혹은 호출기 등으로 보내집니다. 이런 알림들은 각각 티켓, 메일 알림, 및 호출 등으로 분류됩니다.
• 노드와 머신 : 물리적인 서버, 가상 머신 혹은 컨테이너에서 동작하는 커널의 단일 인스턴스를 의미하며 동의어로 사용됩니다. 한 머신이 모니터링할 여러 개의 서비스를 운영하고 있을 수 있습니다.
• 푸시 : 서비스가 실행하는 소프트웨어나 관련된 설정에 대한 모든 변경사항을 의미합니다.

 

2.  왜 모니터링해야 하는지?

모니터링과 알림을 이용하면 시스템에 언제 문제가 발생했는지 또는 어떤 문제가 발생하려 하는지를 알 수 있습니다. 시스템이 스스로 문제를 해결할 수 없는 경우에는 사람이 알림을 살펴보고, 실제로 문제가 발생했다면 증상을 처리한 후, 문제가 발생한 근본적인 원인을 파악해야 합니다.

 

뭔가 이상하다는 이유로 알림을 보내서는 안됩니다. 호출이 너무 빈번하면 직원들은 그냥 추측으로 넘어가거나 심한 경우 호출을 무시하게 되고, 경우에 따라서는 잦은 호출에 묻혀버린 '진짜' 호출마저 무시하게 됩니다. 이렇게 잦은 호출은 신속한 분석과 수정에 방해가 되므로 장애가 더 연장될 수 있습니다. 효과적인 알림 시스템은 정확한 신호와 낮은 오보 비율을 갖춰야 합니다.

 

3. 증상과 원인

모니터링 시스템은 어떤 장애가 왜 발생했는지에 대한 질문에 답을 제시할 수 있어야 합니다. '어떤 장애가 발생했는가'는 증상을 의미하며, '왜 장애가 발생했는가'는 원인을 의미합니다. 아래 표는 장애의 증상과 원인의 예시입니다.

 

4.  블랙박스와 화이트박스

블랙박스와 화이트박스 모니터링을 한마디로 비교하면, 블랙박스 모니터링은 서버 상에 나타나는 증상을 기본으로 하며 현재 문제가 발생하는 상황을 모니터링하는 것입니다. 즉 '시스템이 지금 현재 올바로 동작하지 않고 있는' 상황을 알기 위한 것입니다. 

 

반면, 화이트박스 모니터링은 로그나 HTTP 종단점과 같은 시스템의 내부 동작들을 규범에 따라 살펴보는 기법들을 토대로 합니다. 그래서 문제가 발생하려는 재시도에 의해 가려진 실패 작업 등을 포착할 수 있습니다.

 

 

5. 네 가지 결정적인 지표

• 지연 응답 : 요청이 서비스에 의해 처리되기까지의 시간을 말합니다.
• 트래픽 : 시스템에 얼마나 많은 요청이 들어오는지를 측정하는 것으로, 높은 수준의 시스템 관련 지표를 통해 측정할 수 있습니다.
• 에러 : 실패한 요청의 비율을 의미합니다.
• 서비스 포화 상태 : 서비스가 얼마나 '포화' 상태로 동작하는지를 의미합니다. 가장 병목이 발생하는 리소스를 집중해서 측정해야 합니다. 많은 시스템들이 100% 사용량에 도달하기 전에 체감 성능의 하락이 발생하므로 기본적으로 목표 사용량을 설정해야 합니다.

 

6. 결론

아래 질문은 위에서 정리했던 내용을 바탕으로 앞으로 모니터링과 알림에 대한 규칙을 정의할 때 큰 도움이 될 것입니다.

• 이 규칙은 해당 규칙이 존재하지 않는다면 알아챌 수 없는 긴급하고, 대처가 가능하며 즉각적으로 사용자가 인지할 수 있는 상태를 탐지할 수 있는가?
• 긴급하지 않은 알림이라면 무시할 수 있는 알림인가? 언제, 왜 이 알림을 무시할 수 있으며, 이런 알림을 받지 않으려면 어떻게 해야 할까?
• 이 알림은 분명히 사용자에게 좋지 않은 영향을 미치는 상황에 대한 알림인가? 가용 트래픽이 모두 소모되었거나 테스트 배포처럼 사용자에게 부정적인 영향을 미치지 않는 경우에는 알림이 발생하지는 않았는가?
• 이 알림에 대해 대응이 가능한가? 이 알림은 긴급한 것인가 아니면 내일 아침까지 기다려도 되는 것인가? 대응책은 안전하게 자동화가 가능한가? 알림에 대한 대응은 장기적인 수정이 될 것인가 아니면 단기적인 우회책이 될 것인가?
• 다른 사람들이 이 이슈에 대한 호출을 받아서 적어도 하나 이상의 불필요한 호출이 발생했는가?