개발자들이 안심할 수 있는 삐삐 서비스 만들기 2탄 (그라파나 경보, Sentry)

서론

서비스 운영을 해나가면서 기존에 수작업으로 서버 health check하는 방식으로는 서비스를 모니터링하기 어려워 프로메테우스를 도입해 서버 매트릭을 수집하고 그라파나를 커스터마이징해 삐삐 서비스를 위한 대시보드를 구축했습니다. 이를 통해 모니터링을 손쉽게할 수 있었지만, 또 다른 문제점이 있었습니다.

삐삐는 24시간 라이브 서비스 중이지만 백엔드 개발자가 24시간 대시보드를 볼 수 없는 노릇이었습니다. 또, 프론트(iOS와 AOS)의 통합 테스트는 함께 진행하였지만, 모바일 플랫폼의 특성 상 심사를 거쳐 배포를 해야므로 배포할 때마다 대기할 수도 없었습니다. 그 외에도 API와 클라이언트 간의 버저닝이라던가 슬랙에 쌓이는 에러 로그 관리, 모바일 플랫폼 마다 따로 대응해줘야 하는 트러블슈팅 등 고려할 것이 산더미 같았습니다.

해결해야 할 문제는 많아졌지만, 처음 경험해보는 서비스 운영의 영역에 도달했고 유의미한 트래픽이 발생하고 있다는 점에 너무 즐거웠습니다. 매일 출근할때마다 그라파나 대시보드만 바라봤던 것 같네요. 유저들이 이슈를 직접 발견하기 전에 개발자들이 파악하고 고칠 수 있는 시스템만들어 문제를 하나하나 해결해 보겠습니다.

---

장애 경보, Issue Alert

모니터링 시스템을 도입하고나서 종종 비정상적인 트래픽이 관측되었습니다. 주로 토큰과 관련된 API에서 4XX 에러가 치솟았는데, iOS 팀에 리포팅하고 함께 원인을 파악해보니 토큰 갱신과 관련된 코드에서 무한 루프가 도는 버그가 있었습니다.

 

굉장히 초기부터 존재했던 버그였지만, 무한루프 돌던 토큰 갱신 코드와 별개로 신규 발급은 정상적으로 되었기 때문에 통합 테스트에서도 파악하지 못했던 것이였습니다. (이대로 모르고 지나갔다면, 늘어난 유저만큼 서버가 DDOS를 당했…)

그리고 삐삐 2차 MVP를 배포할 때, 장애가 발생한 적이 있었습니다. 위의 토큰 버그를 고친 버전이 배포되었는데, 신규 회원 온보딩이 끝나는 조건과 변경된 토큰 코드가 절묘하게 엇나가면서 기존 회원들이 온보딩화면에 갖혀버리는 심각한 장애였습니다…

 

 

당시 회사 외부 교육 중이였는데, 팀 단톡방에서 친구들이 앱이 갑자기 동작안하다는 리포팅을 듣고 급하게 화장실로 가서 휴대폰으로 그라파나 확인하고 iOS 팀장님과 상의하고 깃허브 모바일로 핫픽스 이슈날린 기억이 있네요… 😂

위의 두 케이스 모두 결과적으로는 도입한 모니터링 시스템을 통해 해결하였지만, 비정상 트래픽에 대한 경보가 없어 장애 감지에 활용하지 못하고 사후 조치한 케이스였습니다.

Grafana Alert

그라파나에서는 다양한 경보 기능을 제공합니다. 비정상 트래픽에 대한 기준을 설정한다면, 정해진 인원들에게 알림을 전송하는 기능입니다. 이를 통해 빠르게 장애를 파악하는데 도움을 줄 수 있습니다. 가장 많이 활용하는 Slack에 적용해 보겠습니다.

 

Slack App 생성

우선 그라파나에 의해 트리거되어 슬랙 채널에 알림을 전송할 Slack App을 생성해야 합니다. Slack API 홈페이지에 접속합니다.

 

1. From scratch를 선택 후 이름과 알림을 전송할 workspace를 선택합니다. (🚨 App Name에 이모지 넣으면 에러가 발생하며 생성되지 않습니다!)

 

2. App이 생성되면, 좌측 메뉴를 통해 [Features > App Home > Your App’s Presence in Slack]에서 Display Name과 Default Name을 설정해 봇 사용자를 생성합니다. (🚨 Display Name에 이모지 넣으면 에러가 발생하며 생성되지 않습니다!) (🚨 이 단계를 뛰어넘으면 이후 단계에서 에러가 발생합니다!)

 

3. 슬랙은 Webhooks을 지원하기 때문에 Webhooks URL만 발급하면 간단히 알림을 전송할 수 있습니다.[Features > Incoming Webhooks > Add New Webhook to Workspace]를 통해 알림을 전송할 채널 전용 웹훅이 생성합니다.

 

4. Slack으로 돌아와 선택한 워크스페이스의 채널에서 @APP-NAME (저의 경우 @그라파나 경보 ) 메시지를 입력하면, 생성한 봇을 해당 채널로 초대할 수 있습니다.

 

 

🚨 그라파나 경보 앱에 설치할 봇 사용자가 없습니다. 에러가 발생한다면, [App Home > Display Name] 단계를 건너뛰었기 때문입니다. Display Name과 Default Name을 설정함으로써, Slack App의 Bot profile 생성이 완료됩니다.

 

그라파나 Alert Rule 생성

준비는 완료되었으니 그라파나에서 경보를 설정해봅시다. Alert Rule은 그라파나가 언제 경보를 발생시킬지에 대한 규칙을 설정하는 것입니다. 경보 조건은 3가지로 구성되는데

1. Query : 대시보드를 생성할 때와 마찬가지로 PromQL을 통해 조건의 대상이 될 매트릭을 조회하기 위한 쿼리를 작성합니다.
2. Reduce : 조회한 매트릭을 Last, Min, Max 등의 연산을 통해 한 번 필터링합니다.
3. Threshold : 얻어진 값을 기준으로 경보를 발생항 정확한 조건을 설정합니다.

 

저는 10분간 서버 응답코드가 4XX인 수가 100을 넘어가면 트리거되도록 설정했습니다. 저희 서버는 토큰 유효성 검증과 만료를 4XX 코드로 핸들링함으로 임계값을 조금 높게 잡았는데, 각자 서버나 클라이언트 환경에 맞춰 설정하면 됩니다.

 

 

그라파나 Contact point 설정

Contact point는 경보를 보낼 대상을 설정하는 것입니다. 아까 생성한 Webhook URL을 입력하고 테스트해보면

 

정상적으로 작동하는 것을 볼 수 있습니다.

 

 

그라파나 Notification policies 설정

룰과 대상을 정했으면, 두 개를 서로 연결해야 의도한대로 경보가 발송될 수 있습니다. Default policy를 Edit하고 생성한 contact point와 grafana_folder를 설정해주면 됩니다.

 

 

 

---

에러 추적, Error Tracking

장애가 발생하면 빠르게 파악할 수 있게 되었지만, 보고받은 장애의 원인을 분석하는데 어려움이 있었습니다. 현재는 서버에서 에러가 발생하면 error message와 payload, stack trace를 슬랙에 전송하여 메시지를 기반으로 문제를 재현하고 디버깅하기 시작하였습니다.

 

개발 초반에는 무척 편리하였지만, 서비스 운영과 동시에 개발을 진행하면서 원하는 에러 로그를 찾는 것이 무척 어려웠습니다. 아래와 같이 POST /v1/posts API에 대한 로그를 검색하였지만 전혀 다른 로그만 검색되는 일이 빈번했는데, 단순히 메시지의 문자열 검색에만 최적화된 슬랙을 로그 관리 용으로 사용하기 적합하지 않다고 느꼈습니다.

 

 

Sentry

Data dogs, AWS CloudWatch 등 다양한 로그 관리 솔루션이 있었지만, 저희는 Sentry에 주목하였는데 그 이유는 다음과 같습니다.

 

1. 로그 관리 솔루션이 아니지만, 로그 이상으로 디버깅하는데 필요한 굉장히 많은 정보를 제공합니다.

아래 사진은 Breadscrumbs 기능인데 웹 사이트에서 동작한 모든 행동을 캡쳐하여 기록합니다. Breadscrumbs를 포함하여 에러가 발생한 API를 호출한 클라이언트는 어느 플랫폼이고 어떤 데이터를 전송했는지 등을 별도의 설정없이 자동으로 기록됩니다. 만약, 로깅 코드를 대신해 Sentry error capture 코드를 추가 작성한다면 굉장히 자세한 정보를 확인할 수 있게 되었습니다.

 

2. 프론트엔드 에러 트래킹 솔루션으로 더 유명한 Sentry이지만, Spring boot에 대한 지원과 기능이 매우 다양했습니다.

가장 대표적으로는 Performance Monitoring 기능인데, WAS 서버에서 Mapping 중인 API 별로 응답속도, 실패율, 호출한 유니크 유저 수, 사용 빈도 등 서버 성능 최적화에 필요한 다양한 지표를 제공합니다.

 

3. 프론트엔드, 백엔드 모두에게 필요한 에러 추적 솔루션입니다.

백엔드 보다 프론트엔트 솔루션으로 더 유명한 만큼 iOS, AOS 플랫폼에 적용하여 서비스 전체의 에러 추적이 가능했습니다. Sentry 시스템 하나로 여러 프로젝트 추적이 가능하므로 플랫폼마다 제공된 API Docs를 통해 손쉽게 적용이 가능합니다.

 

 

물론 단점도 존재했지만 단 한가지입니다!

1. 비쌉니다.

Sentry는 Saas 형태로 제공되어 프로젝트와 연결만하면 되는 Cloud Sentry와 직접 서버에 설치하고 연결하는 On-premise Sentry로 나뉩니다. Cloud Sentry의 경우 Team 요금즈는 매달 35000원 정도

 

on-premise sentry는 최소 AWS xlarge ec2가 필요하므로 매달 16만원정도 합니다.

Sentry Docker Service 설치시의 화면

 

두 서비스 모두 부담되는 가격이지만, 프로젝트 팀원이 개인적으로 소유한 AWS Credit을 활용할 수 있었기 때문에 AWS EC2에 온프레미스 형태로 설치하기로 하였습니다.

 

 

Docker container for Sentry

온프레미스 설치의 경우, Self-Hosted Sentry용 도커 설치 파일과 가이드(https://develop.sentry.dev/self-hosted/#getting-started)를 제공하고 있습니다. Sentry를 호스팅할 서버의 터미널를 통해 실행하면 됩니다.

# Assuming current latest version is 24.1.0
# Current actual version can be acquired from the Releases page on GitHub
VERSION="24.1.0"
git clone <https://github.com/getsentry/self-hosted.git>
cd self-hosted
git checkout ${VERSION}
sudo ./install.sh

sudo docker ps 를 통해 실행 중인 sentry container들이 확인되고, server_url:9000 에 접속시 Sentry 콘솔 로그인 창이 뜬다면 정상 설치된 것입니다.

 

🚨 반드시 4 vCPU + 16GB RAM 이상 인스턴스에 설치하세요. (Sentry container 설치 중 계속 터미널이 멈추는 경우)
CPU와 RAM 하나라도 모자랄 경우, 컨테이너 설치 중 성능 부족으로 인해 인스턴스가 멈춰버립니다.

 

 

 

Sentry Project 설정

이제 Sentry와 스프링 부트를 연결해보겠습니다.

Sentry 콘솔에 접속해 Spring boot 프로젝트를 생성합니다.

 

프로젝트를 생성하면, 연결을 위한 가이드를 제공하는데 가이드를 그대로 따라하기를 권장합니다. 별도로 스프링 부트 도큐먼트(https://docs.sentry.io/platforms/java/guides/spring-boot/)를 공식적으로 제공하지만, Spring boot 3 기준 콘솔 내부에서 제공하는 가이드가 오류 없이 정상 작동하였습니다.

 

 

 

Sentry Issue

정상적으로 연결되면 WAS에서 예외가 발생할때마다 Issues 탭에 다음과 같이 기록됩니다. 클릭 시 상세한 에러 트레이싱 정보를 확인할 수 있습니다.

 

저의 경우에는 각 팀원들에게 개인 계정을 발급해주고, 이슈가 발생하면 1차적으로 파악한 후 담당 팀원에게 간략한 설명과 Sentry issue url을 첨부해 슬랙으로 전송했습니다. 모니터링 담당으로서 서비스 전반적으로 발생하는 에러를 빠르게 파악할 수 있어 좋았고, 각 담당자들은 더 촘촘한 디버깅이 가능해서 만족도가 높았습니다.

 

 

 

---

 

마치며

전반적으로 만족도가 높은 개선사항들이었습니다. 다만 시스템 구동을 위한 최소 사양이 ec2 xlarge인 만큼 유지비용이 굉장히 올라갔고, 현재 활용중인 Sentry 기능이 전부 중 극히 일부이기 때문에 활용법에 대해 조금 더 연구가 필요할 것 같습니다. 또, 서비스 운영의 안정기에 들어간만큼 추가로 SRE 시스템들을 도입하기 보단 현재 시스템을 활용하는 방안을 연구하거나, 시스템의 규모와 비용을 최적화하는 방향으로 나아갈 예정입니다.