껌딱지 개발팀은 백엔드 서버 알림을 디스코드로 받는다고?

시작하며

안녕하세요! 껌딱지 개발팀에서 기술 리드이자 백엔드 파트 리드 및 개발을 맡고 있는 BackEnd 개발자 종하입니다!

 

백엔드를 개발하고 배포할 시기가 다가올때 서버의 이상징후 알림을 어떻게 알리고 수집해야하는지 고민을 굉장히 많이 하게 되었었습니다. 리얼 서버에 배포를 하고 사용자들이 생기게 되면 예측 할 수 없는 부분의 변수들도 분명히 존재한다는 부분을 인식하고 있었고 어떻게 변수들을 다 막을것인지 보다는 어떻게 하면 최대한 빠르게 그리고 편하게 문제들을 확인하고 접근 해야하는지에 초점을 맞추게 되었습니다.  

 

그래서 저희 팀은 백엔드 서버의 알람들을 어떤 방법으로 Notice 받고 왜 이런 방법을 채택했는지에 대해서 설명드리도록 하겠습니다!

어떻게 하면 100% 커스텀 된 알림을 보내고 받을 수 있을까?

제일 처음으로 고려했던 부분은 어떻게 해야지 완벽하게 내가 그리고 우리 팀이 읽고 이해하기 쉽고 문제점을 찾아가는데 필요한 정보들을 한눈에 보여주는 알림을 만들 수 있을까였습니다. 일단 저희만의 알림용 클라이언트나 서버를 만드는것은 너무 불합리적이라는 생각을 가장 먼저 했습니다. 그래서 우리가 지금 사용하고 있는 클라이언트들을 이용하기로 결정했습니다. 대표적으로 메일을 전송한다던가 메신저 알림을 보내는 등의 방법이 존재합니다. 메일 같은 경우에는 내가 원하는 형식으로 전송할 수는 있지만 무언가 좀 사용하기 불편하고 단순 알림이라는 목적과는 멀게 느껴졌습니다. 그래서 선택했던 클라이언트가 디스코드입니다. 디스코드는 자체적으로 웹훅 링크를 제공하여 적절한 값과 함께 요청을 하게 되면 그대로 메세지 채널에 메세지를 전송해줍니다.

디스코드 웹훅은 어떻게 이용하는데?

디스코드 웹훅을 어떻게 사용하는지 설명하기 앞서 저희 팀은 회의를 할때 디스코드를 주로 사용해서 회의를 진행합니다. 그래서 디스코드 채널에 팀원 모두가 볼 수 있게 서버 로그라는 메세지 채널을 생성했습니다. 이 메세지 채널의 설정을 누르고 연동으로 가서 웹 후크를 생성하면 됩니다! 웹 후크 URL로 적절한 바디값을 담아서 POST 요청을 보내게 되면 아래와 같이 알람을 보내게 됩니다!

메세지 타입이나 기타 자세한 부분들은 디스코드 공식 개발자 문서에 자세하게 설명되어 있습니다.

https://discord.com/developers/docs/resources/webhook

Discord Developer Portal — API Docs for Bots and Developers

그럼 디스코드 웹훅을 코드에서 어떻게 호출해?

자 위에서 디스코드로 알림을 보내주는 웹훅에 대해서 알아봤고 어떻게 요청하는지도 간단하게 알아봤습니다.

이제 중요한 부분은 어떻게 이 기능을 코드에 적용하는지 입니다, 저희 개발팀은 백엔드를 SpringBoot + Java를 이용해서 진행하기 때문에 혹시 적절한 디스코드 로깅 관련 gradle 라이브러리가 있는지 검색해봤습니다. 하지만 찾지 못했고 하나의 Bean으로 만들어 사용할까 생각을 했지만 생각보다 다른 프로젝트 할때도 유용하게 사용할것 같아서 한번 라이브러리로 만들어보기로 결정하였습니다.

 

라이브러리를 어떻게 만들었느냐에 대해서는 다른 글에서 자세하게 다루도록 하겠습니다, 간단하게 설명하자면 처음에 웹훅 링크를 사용자가 설정을 하고 send 변수를 이용해서 단순 메세지나 메세지 + 언급 조합으로 알림을 보낼 수 있도록 개발했습니다. 하지만 급하게 쓰려고 개발했고 라이브러리 코드를 만드는 부분에 대한 이해도가 전혀 없이 대충 개발해서 다시 자바를 진득히 공부하고 리팩토링 할 생각입니다.

https://github.com/archan0621/discord-logger

GitHub - archan0621/discord-logger: Discord WebHook을 등록해서 자바 로그를 보내주는 라이브러리

discordLogger.send(String.format("🚨경고🚨 권한 없는 접근 시도 발생 - 아이디: %s, 아이피: %s, URL: %s", user != null ? user.getUsername() : "Unknown", request.getRemoteAddr(), request.getRequestURI()), Scope.here);

그래서 실제 백엔드 코드에서는 위처럼 사용하고 있습니다, 알림도 잘 오고 익숙한 클라이언트여서 그런지 편하네요!

가끔 이런식으로 응답 지연이 발생하긴 하는데 흠흠.. 문제가 되는 부분은 아니라 일단 모니터링만 하고 있습니다.

디스코드로 서버 알림을 받고 좋아진 점

일단 제일 큰것은 마음이 편해졌습니다. 개발자 입장에서 버그가 나자마자 바로 내가 설정한 로그들로 즉각 알림을 받고 분석하는거랑 사용자를 통해서 제보 받는거랑은 느낌이 엄청 다르기 때문이죠 ㅋㅎㅋㅎ..  크리티컬한 버그가 발생한적은 없지만 가끔 알림이 올라올때마다 같이 개발하는 친구랑 동시에 확인하고 서로 연락하는 모습을 보면서 '그래도 이거 덕분에 큰일은 나지 않겠구나' 라는 생각에 마음이 많이 편해진것 같습니다. 그리고 에러가 났을때 디버깅하기가 편해졌습니다. 로그에 엔드포인트를 같이 찍어주기 때문에 어떤 컨트롤러의 어떤 변수를 요청했을때 에러가 났는지 즉각 확인이 가능하고 편한 디버깅을 할 수 있게 되었습니다. 결국은 사람을 편하게 해주기 위해 개발된 셈이죠

마치며

사실 고정 사용자수가 80명 남짓 되는 서비스에서 설계만 어느정도 제대로 했다면 Slow Query & Response가 발생하거나 DeadLock이 발생할 확률은 극히 드뭅니다. 하지만 저 그리고 저희 팀에서 처음으로 고정 활성 사용자들이 있는 서비스를 배포하는만큼 빈틈없이 사용자들에게 저희의 서비스를 소개하고 싶었어서 이런 사소한 부분들까지 신경쓰지 않았나 생각을 했습니다. 저는 코드를 치고 배포를 하는것만이 개발이라고 생각하지 않습니다. 코드로 어려운 부분들은 비즈니스로 해결하고 배포 후 모니터링과 사후 대처까지 이 모든 과정을 개발이라고 생각합니다. 앞으로도 저희의 서비스를 사용하게 될 예비 유저분들을 위해 노력하고 발전하는 개발자가 되도록 하겠습니다!