모니터링 자동화를 위한 New Relic 도입기

그동안 개발 환경에서 EC2 서버에 문제가 생기거나, 혹은 code deploy를 통한 배포 자동화 과정에서 문제가 발생할 때 바로 상황을 파악하지 못했던 적이 종종 있다. 어떤 방식으로든 개발자에게 알림이 가게끔 환경을 구축했다면 좋았겠지만, 사실 개발 단계에서는 실시간으로 알림을 받아 볼 필요성을 크게 느끼지 못했다. 그렇지만 프로덕션 환경에서는 이 문제를 분명 개선할 필요가 있었다.

도입기

우리에게 필요한 건 자동화된 모니터링 도구였다. 더 이상 배포가 잘 되었는지, 서버가 잘 돌아가고 있는지, 장애가 난 포인트는 없는지 등을 직접 확인하지 않아도 되게끔 만드는 것이 제일 중요했다. '무소식이 희소식이겠거니 ~' 하면서 있다가 모니터링 도구가 실시간으로 문제를 알려주면 우리는 빠르게 문제를 해결해서 사용자들이 안정적으로 서비스를 이용할 수 있도록 환경을 마련해야 했다!
이를 도와주는 자동화된 모니터링 도구로는 sentry, data dog, prometheus, cloud watch 등으로 매우 다양한데, 우린 그 중에서도 new relic을 사용하기로 했다. 사실 뉴렐릭은 sentry, cloud watch, prometheus 등에 비해서 레퍼런스가 굉장히 적기도 했고 올해 5월인가에는 뉴렐릭 한국 지사가 철수하기도 하는 등 '도입하지 않을' 이유가 더욱 많아보였다. 그럼에도 소수의 레퍼런스 자료에서(여기어때 기술블로그) 뉴렐릭의 만족도가 커 보여 한번쯤은 경험해보고 싶다는 생각이 들었고, 또 무엇보다 현재 활동 중인 소프트웨어 마에스트로의 담당 멘토님께서 뉴렐릭을 써볼 것을 강추❗️하셨기 때문에 그냥 믿고 써봐야겠다 싶었다.

✋ 들어가기 전에

모니터링에는 pull과 push 방식이 있다

뉴렐릭 연동 과정에 대한 마땅한 참고자료가 없었고 공식문서도 개인적으로는 이해하기에 부족한 점이 있었기 때문에 의존성만 설치하면 끝나는건지, 아님 배포 서버에서 뭔가를 더 설정해줘야 하는건지 기본적인 설정법조차 와닿지 않았다.
이제와서 돌아보니 이 '모니터링 방식'에 대한 개념이 부족해서 이리저리 헤맨 것 같다. 간단하게 설명하면 pull 방식의 경우 모니터링 도구가 메트릭을 자동으로 수집(pull)해서 에러 상황을 분석해주고, push 방식의 경우 코드 상에서 직접 특정 포인트에서 데이터가 수집되도록 설정해 보내야(push)한다. sentry가 대표적인 push 방식으로 동작하며 new relic의 경우 pull 방식으로 동작한다.

new relic이 pull 방식으로 동작하기 위해서는 애플리케이션을 실행할 때 new relic agent가 애플리케이션에 통합하도록 설정해주는 과정이 필요하다. 또한 애플리케이션이 실행 중일 때 뉴렐릭 에이전트도 같이 돌아가는 것이기 때문에, 새 버전을 배포하는 과정에서 기존에 돌아가던 애플리케이션을 kill 해버리면 뉴렐릭 에이전트도 더 이상 모니터링을 하지 못하게 된다. 따라서 새 버전을 배포할 때마다 new relic agent를 애플리케이션에 통합되도록 해줘야 한다.

뉴렐릭이 제공하는 기능

• ~~뉴렐릭은 APM 모니터링 기능에 매우 특화되어 있다. ~~

학생용 뉴렐릭 사용하기

뉴렐릭은 상용 서비스로 돈을 내고 사용하게 되는데 사용량에 따라 가격이 매겨지고 이게 상당히 비싼 것으로 알려져있다. 공식 사이트에서는 사용한 만큼 비용을 지불하는 걸 큰 장점처럼 어필하고 있긴 한데, 사용자 입장에선 이게 더 폭력적으로(😅) 다가오긴 한다.

프라이싱 모델은 아래와 같이 구성되어있다. 무료버전으로 사용해도 괜찮을 것 같다는 생각이 들었는데, 럭키🍀하게도 학생의 경우 무료로 더 많은 혜택을 받을 수 있게끔 되어있었다. 애플리케이션 모니터링 + 인프라 모니터링 등 30개 기능을 이용할 수 있고, 매월 500GB의 데이터를 사용할 수 있고, 플랫폼 사용자도 3명까지 등록할 수 있다!!
다행히(?) 아직 대학생 신분이라 학생용 뉴렐릭 계정을 만들었다.

프로젝트에 통합하기

1. APM(Application Monitoring) - 언어 선택
   자바로 개발중이라 모니터링 대상 언어는 자바로 선택했다.
   
2. 설치 방식
   의존성을 추가할건지(gradle, maven), 아니면 운영중인 서버에 직접 설치할 건지(On a host) 선택하면 된다. 나의 경우에는 프로젝트에 의존성을 추가하는게 이후에 설정하거나 커스텀하기에 더 편할 것 같아 gradle을 선택했다.
   
3. 개발 환경 선택하기
   linux, window 중에 선택하고 사용하고 있는 프레임워크를 선택하면 된다. 다음 단계에서 설정파일을 제공해주는데 거기에 사용되는 것 같다.
   
4. buil.gradle에 의존성 추가
   아래 예시로 보여준 build.gradle을 복사해서 프로젝트 build.gradle에 추가한다. 내가 사용하는 버전에서는 조금 문법이 달라져 추가 수정이 필요했다.
   

tasks.register('downloadNewrelic', Download) {
    mkdir 'newrelic'
    src 'https://download.newrelic.com/newrelic/java-agent/newrelic-agent/current/newrelic-java.zip'
    dest file('newrelic')
}

tasks.register('unzipNewrelic', Copy) {
    from zipTree(file('newrelic/newrelic-java.zip'))
    into rootDir
}

5. 설정파일(newrelic.yml) 세팅
   4 단계를 거치고 나면 프로젝트의 루트 디렉터리에 newrelic 폴더가 생긴다. newrelic 폴더 안에 newrelic.yml 파일이 있는데 여기에 4의 화면에 보이는 newrelic.yml 코드를 그대로 복사해서 붙여넣으면 된다. 주의할 건 newrelic.yml에 lisence_key가 그대로 노출되어 있다는 건데, 이걸 환경변수로 등록해주는게 좋다.
   
6. 애플리케이션 실행 시 new relic agent를 통합
   여기가 조금 헷갈렸는데, 처음에는 code deploy의 라이프 사이클 중 Application Start단계에서 new relic agent를 실행시키기 위한 스크립트를 하나 새로 생성해야 하는건가 싶었다. 결론적으로 그건 아니었고 배포 자동화가 이뤄지고 있는 경우에는 새 애플리케이션을 실행하는 스크립트를 아래 명령어로 보완만 해주면 됐다. (뉴렐릭이 어떻게 동작하는건지 이해가 부족했음)
   
   우리 서비스는 start.sh에 새 애플리케이션을 실행하는 스크립트를 짜뒀기 때문에 아래와 같이 start.sh을 보완했다.
   (기존)

   nohup java -jar $JAR

   (보완)

   nohup java -javaagent:$NEW_RELIC_JAR_FILE -jar $JAR

7. (optional) 인프라와 연동
   그 다음 과정부터는 선택적으로 진행하면 되는데 왜인지 모르게 계속 실패가 떠서 일단은 APM 모니터링 연동까지만 진행했다.

짜잔

여기까지 진행하면 이제 아래와 같이 모니터링 내용을 확인할 수 있다. 사실 좋은 도구가 있어도 해석하는 능력이 없으면 무용지물인데 지금 좀 그런 기분이 든다.. 😓 이제는 어떻게 데이터를 해석할건지에 대한 공부를 해보고, 어떤 경우에 알림을 받을건지 정책을 정하기 위해서 또 이리저리 알아봐야 할 것 같다 ~!