개요
내 개인 서버에는 유틸리티 기능을 제공하는 API 서버가 존재한다. 해당 서버는 Spring Boot로 구현되어있으며 최근에 배포 자동화 작업을 마무리하고 계속 필요한 기능들을 추가하고 있다.
해당 서버에 점점 기능이 많이 추가되면서 그에 따라 버그들도 생기기 시작했는데 프로그램에서 출력되는 로그로만 분석하는 것에는 슬슬 한계를 느껴 APM을 도입을 결정하게 되었다.
APM 선정 진행
NAS의 성능 한계로 Pinpoint와 같은 Self-Hosted 방식은 부득이하게 사용하지 못하고 SaaS 형태의 APM을 선택하기로 하였다.
APM 솔루션 선정 기준은 다음과 같다.
- 많이 사용하는 솔루션
- 기능 제한이 적어야 함 (유저 수 제한은 제외)
- 무료 플랜 (기간제 플랜 제외)
국내 솔루션들은 대부분 기간제라 제외되었고 해외에서 찾은 APM 제품의 리스트는 다음과 같다.
- New Relic
- Sentry
- Datadog
Node.js로 서버를 구성하였을 때 Sentry를 사용한 경험은 있었지만. 이 때는 사내에서 유료 플랜을 걸고 사용했었고 내가 지금 사용하려고 하는 무료 플랜에서는 기능 제한이 어느 정도 걸려있다. 그리고 제공되는 대시보드의 형태가 나에게는 조금 불편했다.
New Relic은 위 선정 기준을 모두 충적하지만 사용해본 경험이 없다. 문서를 살펴보니 내가 필요한 metric, trace 정보들을 수집하고 있고. 여러 가지 도움이 되는 프로파일 기능 또한 무료 플랜에서 기본적으로 제공해주는 것으로 보인다. 그리고 대시보드를 사용자에 입맛에 맞도록 수정할 수 있는 기능 또한 제공한다.
Datadog도 New Relic 이랑 비슷한 성격의 기능을 제공해주는 것으로 확인하였다.
결국 New Relic과 Datadog 중 하나를 결정해야 된다. 둘 다 훌륭한 APM 서비스를 제공하지만 인프라, 메트릭 모니터링이 더 강력한 Datadog와 달리 애플리케이션 모니터링은 New Relic 이 더 괜찮다는 내용을 들어 일단 목적에 맞게 우선 New Relic를 도입하기로 했다.
New Relic의 무료 플랜은 기본적으로 100GB의 할당량을 제공해주지만. 이 데이터가 내 애플리케이션에서 시간에 따라 얼마나 누적되는지에 대한 정도를 가늠하기는 현재로서는 힘들다. 일단 New Relic을 적용해보고 운영을 돌려보면서 정도를 파악해보려고 한다.
APM 적용
New Relic의 APM 은 javaagent를 이용하여 서버 애플리케이션에 바이트 코드를 주입하는 방식을 사용한다.
Agent는 주입할 jar 파일과 설정 파일로 구성되어있는데 jar 은 프로젝트 파일에 추가하는 형태이고 yml 파일은 라이선스 키와 같은 민감한 정보들이 포함되어있어 Jenkins에서 파일을 추가해 배포하는 형태로 구성하였다. 대략적인 구성도는 다음과 같다.
결론
New Relic적용 후 Dashboard를 통해 수집되는 metric, trace, log 정보를 확인할 수 있었고. 이제 나는 디버깅을 위해 직접 docker log를 확인하는 노가다를 멈출 수 있었다.
비고
- 최근 버전의 Agent에서는 yml 설정 파일 없이 환경변수로도 설정이 가능하다고 한다. 이를 이용하여 파이프라인을 조금 더 단순화시킬 수 있을 것 같다.
'개발 > 일지' 카테고리의 다른 글
| EP3. 개인화 TTS 적용 (0) | 2022.07.02 |
|---|---|
| EP1. 개인 서버 이전 및 배포 자동화 환경 구축 (0) | 2022.06.25 |
