모니터링 시스템 구축하기

모니터링과 화법

회사에서 관련 자료로 발표할 일이 좀 있을 것 같아서 준비하는 김에 블로그에도 써본다.

본론에 들어가기 전에 그냥 요즘 하는 생각들을 써놓자면 기술 도입을 주장할 때 어떤 식으로 말해야 할지 많이 고민이 되는 것 같다. 팀의 전체적인 상황이나 여러가지 고려할 것도 많긴 한데, 그 중에 가장 ‘지양’하려는 방식이 기술의 우수성으로 주장하는 건 많이 피하려고 생각중이다. 어떻게 보면 가장 설득력이 떨어지는 방식이 아닐까.

누구는 좋은거 몰라서 안했겠나. 그 기술이 좋은건 알아도 당장 도입을 해야하는 당위성이나 전체적인 상황을 많이 고려해보면 좋지 않을까 싶다. 효과적인 설득 방식이 어떤 방식들일지 많이 고민중이다. 화법에 대한 생각일수도 있겠다. 인풋 대비 아웃풋, 더 나아질 수 있는 상황에 대한 설명, 우려되는 점 등등 다양하게 구상 중이다…

왜 필요한가?

기술적인 이득은 다들 알고 있지 않을까 싶다. 로그 보기 편하고, 메트릭이나 에러가 난 상황에 대해 조사하기 좋고, 어떤 지표가 튀는지 관찰하기도 쉽고 등등…

나는 좀 다른 관점으로 생각해봤는데, 이게 결국 신뢰의 문제가 아닐까 싶다. 에러를 빨리 캐치하고 대응하는 것이 상황에 대해 인지하고 있다는 뜻이고, 고객에게 개발팀이 믿음을 얻을 수 있는 다양한 방법 중 하나가 아닐까? 계속 결제 에러나서 연락해봤는데 에러 난 줄도 모르고 있으면 ‘얘네는 뭐하는 애들인가’ 싶을 것 같다.

모니터링 툴

Sentry

모니터링, 로깅 대표 주자 중 한명이다. 참고로 사진은 내 개인 프로젝트에서 사용중인 화면이다. 회사 리소스 아니다.

프론트, 브라우저 단에서의 로깅은 사실상 센트리 말고 대안이 있나 싶긴 하다. 이런 생각이 들게 할 정도로 사용률이 높고, 참조할 만한 레퍼런스 자료도 풍부한 편이다.

나는 매주 토요일 이메일로 리포트가 이런식으로 오는데, 나름 보는 재미도 쏠쏠하다.

프론트 강자라고 백단에서 못 쓰는 것도 아니다. 나는 프론트단에서만 사용 중이긴 한데, 다양한 지표들과 로그들을 아주 손쉽게 남기고 확인할 수 있다.

언어별로 다양한 sdk를 지원해줘서 개발하기도 편하다. 슬랙같은 메신저로 에러 리포팅을 보내기도 깔쌈하고 사용하기 편한 포맷을 가지고 있다.

하지만 Saas라서 데이터가 저쪽으로 다 넘어가는게 문제다. B2B라면 분명 고려해야 할 요소일 듯 하다.

이런 현상을 막기 위해 자체 호스팅 옵션으로도 센트리가 구매 가능한데, 생각보다 가격이 많이 차이난다. 관리가 귀찮아 지는 건 덤이다. Saas 형태로 대여하면 월마다 $20 (team) / $80 (business) 와 같은 가격 구성을 가지고 있는데, Self-hosted 옵션으로 가면 $ 276 (ec2/8cpu/16mem) 이다. 제법 차이난다. Self-hosted 가격은 찾아도 잘 안나오길래 블로그 글에서 참고했다. 아마 회사마다, 구성하는 인프라마다 가격은 다 다르지 않을까 싶다.

Grafana +a(Loki, Prometheus, Promtail….)

역시나 많이 사용하는 그라파나다. 회사에서 임시로 만든 템플릿이긴 한데 아무리 개발 리소스라도 혹시 몰라서 좀 가렸다.

사실 얘는 모니터링 툴이 맞다고 해야되나 아니라고 해야되나… 어쨌든 대시보드 그리는 애다. 장점으로는 오픈소스이며, 무료다. 다양한 플러그인, 템플릿 레퍼런스를 가지고 있고 무엇보다 우리 회사가 Azure를 사용 중인데 Azure 마켓플레이스에 서버 생성 템플릿이 존재한다. 로그인 같은 건 자동으로 다 연동해서 처리해주니까 편하긴 하다.

직접 제공한 템플릿이라 그런지 Azure Monitor와 다양한 연동도 쉽고, 그 덕분에 +a로 구성되어야 하는 조합들을 azure에서 비교적 손쉽게 처리가 가능하다.

단점으로는 직접 구축해야 되다보니 어느정도 리소스 소모된다. 여러 패널들을 배치하거나 메트릭을 띄우기 위한 쿼리 작성, 지표 선정 등등의 수고를 해야한다.

가장 고민되는 건 프론트 로깅은 상당히 까다로울 것으로 예상 중이다. 사실상 수동 로깅 느낌이지 않을까 싶다. 한 줄로 끝나는 Sentry에 비해 익셉션 핸들링 전용 api 구성이나 다양한 측정 지표들은 어떻게 처리해야 할 지 아직 감도 안온다.

Azure Monitor

약간 놀랐는데, 생각보다 azure 자체 모니터링이 잘 만들어져 있다. 장점으로는 가장 azure 친화적인 모니터링이다보니 메트릭, 노드간 추적 등등 다양한 지표 관찰이 굉장히 용이하다. 만약 프론트 리소스도 여기서 띄운다면 프론트까지 통합 모니터링이 가능할 것으로 생각된다. 세팅도 라이브러리를 제공해줘서, 거의 코드 몇 줄 추가만 해주면 끝난다. 아주 간편하다.

치명적인 단점으로는 할당된 서버 리소스당 하나의 패널을 생성해야 할 것 같다. 사실 지금도 로그나 모니터링이 너무 파편화되어 있는 것 같아서 고민중인데, 얘를 사용하면 그대로 답습하는 셈이다. 관리 포인트가 계속 늘어나는 느낌이라, 그라파나처럼 중앙에서 뭔가를 한 번에 확인하기는 힘든 구조일 듯 싶다.