모니터링툴 도입

 

 

 

모니터링 툴 도입 이유

결론부터 말하면 구현 복잡도를 적정 수준으로 조절하기 위해서 도입했다.

 

현재 제작하고 있는 앱은 MVP 제작을 마치고 QA 단계에 들어섰다.

MVP 제작을 하면서 느낀점은 "굳이 이렇게 복잡하게 만들어야 하나?"에 대한 의문이었다.

가끔식 보면 기획자가 굉장히 디테일하게 기능 설계를 하는 경우가 있었다.

예를 들어, MVP 앱에서는 알람의 종류를 푸시 알람, 공지 알람, 실시간 알람. 3개로 정의한다. 

여기서 기능 중 몇 개가 3개 알람을 동시에 사용자에게 전달한다.

본인은 과하다고 느낄 때가 있지만, 기획자의 기능 설계에 반박하기는 어려웠다.

근본적으로 사용자가 써보질 않았으니 무엇이 옳은 선택인지 판별할 수 없었기 때문이다.

 

그렇기 때문에 모니터링 툴의 도입이 필요하다고 느꼈다.

만일, 사용자의 API 사용량을 추적하는게 가능하다면 앱의 핵심 기능은 무엇인지, 어떤 기능을 최우선으로 좋게 만들어야 할지 판단할 수 있는 기반 자료가 될 것이다.

이를 기반으로 기획자와 소통하는데 사용할 것이다.

만일 기획자가 사용 비중이 적은 기능에 대해서 고도화를 제안할 시, 퀄리티를 적정 수준으로 낮추는 데 좋은 자료로 사용 될 수 있을 것이다.  

 

 

목표

각 API의 사용 횟수를 기록한다.

핵심 API의 쿼리 파라미터 사용 분포를 기록한다.

 

 

문제점

모니터링 툴을 설치할 곳이 마땅치 않았다.

주어진 자금이 크지 않았기 때문에, 최대한 인프라는 비용을 절감해서 설계했다.

따라서 별도의 모니터링 서버를 두기는 어려웠다.

 

 

<prod 인프라>

 

 

<dev 인프라>

 

 

 

 

대처

모니터링 툴을 설치했을때 가장 피해를 덜 볼 수 있는 곳이 어디인가?

-> dev 인프라의 Cache 서버로 판단했다.

was 서버를 써도 괜찮긴 하겠지만, 갑자기 마비가 됐다고 생각했을 때는 Cache가 동작하지 않는 쪽이 피해가 당연히 적을 것이다.

 

 

구현

보안쪽은 PROD의 WAS 서버와 DEV의 Cache 서버 간의 Inbound를 허용하는 식으로 설정했다.

 

모니터링 툴은 Grafana + Prometheus + Loki를 사용했다.

해당 그래프를 통해 각 API 별로 몇 번 호출됐는지 파악할 수 있다.

이를 통해, 사용자에게 가장 중요도가 높은 기능이 어떤 것인지 짐작할 수 있는 근거가 된다.

 

사용자가 각 API마다 사용한 쿼리 파라미터 조합은 Grafana + Prometheus 툴로 조회할 수 있는 방법을 찾지 못했다.

따라서, 핵심적인 API 면서도 쿼리 파라미터가 빈번히 사용되는 API에 log를 심었다.

해당 log 파일을 Loki 툴을 사용해서 읽는 것으로 해결했다.