배경
담당하는 서비스들에서 장애가 발생해도 이를 늦게 탐지하는 상황이 자주 있었다. 심지어 고객 문의를 통해서야 장애를 파악하는 경우도 있었다. 이러한 상황들이 작은 불편함과 불안함을 주었지만, 시간이 지날수록 문제를 해결하기보다는 이에 적응하며 지내고 있었다. 마침 이번에 기회가 생겨 미뤄두었던 이 문제를 해결하기로 했다.
이 글에서는 기술적인 해결책보다는 고민했던 과정과 후기를 공유하고자 한다. 알림 채널을 운영하는 방식에는 정답이 없을 수 있다. 팀 규모나, 담당 서비스의 실시간성, 트래픽 등을 고려해야할 것이다.
기존 문제점 정의
처음에는 구체적으로 어떤 문제가 있는지도 현황 파악이 어려웠다.
나름대로 이렇게 문제점들을 정의해보았다. 장애 심각성이 비교적 낮은 서비스들의 경우, 대부분의 팀들이 겪었을 법한 문제이다.
메신저 채널에는 400 에러들이 쌓이고 또 쌓이고 있었다
거짓 양성(false positive) 또는 1종 오류(type I error)는 통계상 실제로는 음성인데 검사 결과는 양성이라고 나오는 것이다. 예를 들어, 어떤 메일이 스팸 메일인지 검사하는 프로그램이 있다고 하자. 이때 어떤 메일이 실제로는 스팸 메일이 아니지만 프로그램 검사 결과 스팸 메일이라고 판정한다면, 이것이 거짓 양성이다. 위양성(僞陽性), 혹은 거짓 경보(false alarm)라고도 한다. - wikipedia
거짓 양성(false-positive) 문제가 당장 가장 큰 불편함이었다. 실제 장애 상황에만 알림이 발생해야 하는데, 장애가 아닌 상황에도 알림이 과도하게 발생하다 보니 결국 모두가 알림을 음소거하게 되었다.
그렇다면 HTTP 400 에러를 왜 alert으로 보내면 안 되는 걸까? 또 이런 기준은 누가 정해야 할까?
이런 고민을 하다 보니 로그 레벨에 대한 정책이 부재하다는 점이 드러났다.
일부 서비스는 예외였지만, 대부분의 서비스에서 일관된 정책 없이 실패로 보이는 상황마다 무분별하게 log.error와 serverException을 사용하고 있었다.
로그 레벨을 제대로 설정하자.
이런 방식으로 최소한의 규칙을 담아 로그 레벨을 설계하고 적용했다.
이 기준에 따르면 400 에러는 클라이언트의 잘못이며, warn에 해당한다. 매번 받아볼 필요는 없지만, 갑작스럽게 warn이 빈도가 높아질 경우 모니터링하면 좋을 것이다.
이러한 시스템을 구축한 이후에는 이 일관된 규칙을 모든 담당 서비스에 적용해야 했다.
각 애플리케이션마다 최소 한 번의 배포가 필요했다.
기존의 잘못된 로그 설정들을 모두 수정하는 반복 작업을 이어나갔다.
결과
필요한 작업량과 장애 심각성을 고려해 우선순위를 정하고, 이에 따라 작업을 진행했다.
그 결과 20여 개에 달하던 채널을 3~4개로 줄일 수 있었다!
새로운 코드에서 가끔 거짓 양성이 발생하기도 했지만, 팀 내 공감대와 가이드라인이 있었기에 지속적으로 개선할 수 있었다.
현재까지도 채널은 안정적으로 운영되고 있다.