3. 모니터링 시스템 구축기
동기
에러 모니터링은 중요한 요소 중 하나라고 생각합니다. 각각 플랫폼 별로 어떤 방식으로 모니터링 시스템을 구축했는지 과정을 회고하기 위해 작성해 보려고 합니다.
API 서버
WhaTap
먼저 WhaTap을 이용하여 리눅스 서버 자체 모니터링 시스템이 구축되어 있습니다.
만약 CPU나 메모리 사용량이 일정 수치를 돌파하면 바로 메일이 와서 시스템이 과부화 되고 있다는 사실을 바로 알 수 있습니다.
도입 배경
서버의 전체적인 자원 사용량을 감시하고 싶어서 여러 가지 APM 프로그램들을 조사했습니다. 모니터링 프로그램의 도입전제 조건은 다음과 같았습니다.
비용적인 문제가 크게 없어야 한다
프로그램 자체가 가벼워야 한다
비용 문제가 없는 네이버의 PinPoint나 LG의 Scouter 같은 프로그램들도 존재했지만, 테스트 서버에서 메모리 문제로 실행조차 제대로 되지 않아 포기할 수 밖에 없었습니다. WhaTap은 서버 단위의 모니터링은 무료로 제공하였고, 관련 에이전트 프로그램이 메모리 사용량이 비교적 적어 도입할 수 있게 되었습니다.
서버 애플리케이션
Slack
애플리케이션 단에서 일어나는 에러는 슬랙을 통해 구성했습니다.
런타임 중 에러가 발생하면 슬랙으로 관련 메세지가 와서 바로 에러 발생 사실을 인지할 수 있습니다.
도입 배경
현업에서 많이 사용한다고 들었고, 구현 관련 레퍼런스도 많이 존재하여 선택하게 되었습니다. 그러나 원하는 바를 전부 구현하지는 못했는데, 이유는 다음과 같습니다.
무료 회원은 2,000자의 글자 제한이 있습니다. 다른 분들은 유료 버전을 사용해서 언급을 잘 안 하신건지 아니면 관련 메세지를 훨씬 효율적으로 보내서 그런 건지는 모르겠지만, 몇 번의 전송 관련 에러를 겪고 나서야 깨닫게 되었습니다. 저는 전체 스택 트레이스를 보내고 싶었는데 글자 수 제한에 걸리다 보니 내용을 중간에 강제로 잘라서 보내야만 했습니다.
그래서 관련 에러 코드들을 세분화 했고, 최대한 메세지의 제목만 봐도 어떤 에러인지 알기 쉽도록 계속해서 구현 중입니다.
프론트 서버
Sentry
sentry를 이용하여 프론트 단에서 발생하는 에러 관련 정보를 수집하고 있습니다.
에러가 발생한다면 이메일로 에러 발생 사실과 관련 정보들이 전송됩니다.
도입 배경
사실 프론트 단에는 에러 리포팅 시스템이 없어도 큰 문제가 되지 않을 것이라고 생각해서 도입하지 않고 있었는데, 두 가지 정도 사건이 발생한 후 구축하게 되었습니다.
첫 번째는 외부 라이브러리(Google Analytics) 코드가 변경되면서 기존의 제 자바스크립트 코드와 충돌을 일으켰고, 이미지 파일이 제대로 생성되지 않는 문제가 발생한 적이 있습니다. 이 문제를 전혀 인지하지 못하고 있다가 유저 분이 문의 메일을 보내 주셔서 그제서야 장애 발생 사실을 알게 되었고, 급히 관련 코드를 수정함으로서 서비스가 정상화 되었습니다.
두 번째 사건은 신규 유저 분이 서비스 이용에 문제가 있어서 문의를 주셨는데, 슬랙으로 어떤 알림도 오지 않았고 로그를 뒤져봐도 에러의 흔적을 찾을 수 없었습니다. 모니터링이 되지 않는 곳은 프론트단 뿐이라 그 곳에서 에러가 났다고 확신하게 되었지만, 어찌할 도리가 없어서 결국 유저 분에게 관련 에러 로그를 부탁 드릴 수 밖에 없었습니다.
이런 사건들을 겪고 나니 프론트단 에서도 에러 모니터링 시스템이 필요하다고 느끼게 되었고, 관련 서비스인 Sentry를 도입하게 되었습니다.
결론
에러가 발생하지 않는다면 제일 좋지만, 어떠한 장애도 발생하지 않는 서비스는 없다고 생각합니다. 문제가 생기면 해당 사실을 인지하고 그에 맞는 대응을 할 수 있는 에러 로깅과 모니터링 시스템은 반드시 필요하다고 생각합니다.
Last updated