여기어때 서비스 모니터링 : New Relic 이야기

안녕하세요. 여기어때컴퍼니 파트너혜택개발팀에서 B2B, 포인트 업무를 담당하고 있는 JR입니다. 최근 여기어때 서비스 모니터링 도구로 사용하던 Pinpoint를 일부 서비스를 제외하고는 New Relic으로 전환하는 작업을 진행하였습니다. 이 과정에서 제가 경험하고 느낀점에 대해 공유해보려 합니다.

여기어때 서비스에서 모니터링이란?

여기어때는 여행과 여가와 관련한 숙박, 항공, 액티비티, 렌터카, 맛집 등 다양한 서비스를 제공하고 있습니다. 또한 월평균 이용자수가 300만(2022년 기준)이 넘는 등 대규모 트래픽을 처리하고 있는데요. 이러한 서비스에서 장애가 난다면? 생각만해도 아찔한 상황이 벌어질 것입니다. 개발자로서 마주하고 싶지 않은 상황인데요. 장애를 완전히 막을 수는 없겠지만 최소화 혹은 빠르게 대응하기 위해 저희는 항상 모든 서비스를 모니터링 하고 있습니다. 그리고 그 모니터링 도구로써 Pinpoint를 이용해오고 있었습니다. (적어도 제가 입사한 이래로는 말이죠..)

Pinpoint란?

Pinpoint는 오픈소스 APM(Application Performance Management) 툴로써 대규모 분산 시스템의 성능 분석 및 문제를 진단할 수 있는 플랫폼입니다. 특징으로는 서버 상태를 시각화 하여 볼 수 있고, API 호출 이력 확인, 서버간의 관계를 한눈에 볼 수 있게 뷰로 표현해주는 Server Map 기능 등을 제공합니다.

Pinpoint UI 화면

오픈소스지만 상용APM 못지 않게 제공되는 내용이 괜찮고 사용하기에도 편한 APM입니다.

그렇게 잘(?) 사용하고 있던 Pinpoint를 놔두고 New Relic이라는 APM을 도입한다는 이야기가 나왔습니다.

그리고 저는 New Relic이 대체 어떤 부분이 좋아서 전환하는 걸까 하는 의구심을 갖게 되었습니다. 마침 팀장님도 New Relic이 왜 좋은지, 꼭 도입이 필요한지 다시 한 번 검토해보면 좋겠다는 의견을 주셨고 이를 기회로 한 번 알아보기로 했습니다.

그래서 New Relic이 뭐야?

사실 New Relic은 2008년에 설립된 미국 기업으로 이 회사에서 만든 APM 툴을 통상 New Relic 이라고 합니다. 같은 APM 툴이라면 굳이 New Relic을 써야할까 라는 질문이 다시 떠오르는데요.

일단 New Relic의 특징들을 몇 가지 찾아보았습니다.

New Relic은 우선 기존에 저희가 사용하던 오픈소스 APM인 Pinpoint와 다르게 ‘상용’ APM 입니다. APM 서비스를 제공하는 회사에 돈을 내고 이용하는 셈이죠.

상용 서비스라는 특징은 큰 장점이기도 하지만 단점이 될 수 도 있습니다. ‘돈을 낸다’ 라는 것 때문에 비용이 발생하고 이는 부정적인 이미지로 보일 수 있습니다. 하지만 버그나 보안사항이 발생하였을 경우 비용을 지불 하였으니 그에 대한 수정과 책임에 대해서는 서비스 제공사에 일임할 수 있다는 점에서 장점이 되기도 합니다.

이에 비해 오픈소스의 경우 버그나 보안 위험 발생 시 수정이 안되는 것은 아니지만 상용 서비스 만큼 빠르게 처리되지 않을 가능성이 높습니다.

더불어 New Relic은 모니터링 중 문제(Error) 발생 시 이메일 등의 기존 알림 외에도 webhook 등 다양한 채널로 알림을 받을 수 있게 되어 있습니다. webhook 설정을 통해 기존에 사용중인 슬랙으로 알림을 받을 수 있는 것도 특징이자 장점입니다. (물론 기존 Pinpoint도 가능하지만 New Relic에서는 이 알림 설정이 매우 간편합니다.)

다양한 채널로 알람을 받을 수 있게 설정이 가능하다.

그리고 NRQL(New Relic Query Language) 이라고 하는 SQL 쿼리와 비슷한 언어를 통해 New Relic 내에서의 차트나 대시보드 생성, 알림 등을 손쉽게 설정할 수 있게 해줍니다.

위와 같은 특징이자 장점이라고 할 수 있는 내용들을 찾아보고 나서는 ‘쓸만하겠는데?’ 라는 생각을 하게 되었습니다. 그리고 본격적으로 New Relic을 도입하기에 앞서 사전에 적용하고 테스트해 볼 수 있는 기간을 갖게 되었는데요. 막상 어플리케이션에 도입하려고 하니 Pinpoint의 경우 사내에서 기존에 빌드팩이라고 하는 유용한 도구를 이용해 간단하게 설정이 가능 했었는데 New Relic은 또 어떻게 별개로 적용해야 하나 걱정부터 앞섰습니다.

그런데 그러한 제 걱정이 무색하게도 간단하게 build.gradle에 설정 추가와 config 파일 하나를 추가하는 것으로 개발 영역에서의 설정은 끝이었습니다.

프로젝트(혹은 모듈) 내에 newrelic.yml 하나만 추가하면 된다.

생각보다 설정 방법이 간단한 데 비해 APM 내에서 측정되는 값들이 다양해서 놀라기도 하였습니다.

실제 New Relic 도입 후…?

그래서 실제 New Relic을 도입하여 사용한 개인적인 소견을 말씀드리자면 ‘좋다’ 입니다. 물론 개인적으로는 Pinpoint에서 정말 유용하게 사용했던 서버 간 관계를 직관적으로 확인하기 좋은 Server Map 기능이 없어서 아쉬운 점이 있습니다. (Automap 이라는 비슷한 기능이 있으나 개인적으로는 가시성이 Pinpoint에 비해 살짝 아쉬웠습니다.)

Pinpoint의 Server Map 기능 : 관계도 내에 그려진 아이콘만 봐도 어디에서 호출이 오고 가는지를 한눈에 파악이 가능하다.

그렇지만 이러한 몇 가지 아쉬움을 뒤로 하고서라도 New Relic은 위에서 말한 특징들과 더불어 실제 사용했을 때 편리한 부분이 많았습니다.

현재 여기어때는 MSA 형태로 여러 개의 서비스로 나누어서 운영되고 있습니다. 이러한 여러 개의 서비스를 Pinpoint에서는 모니터링을 위해 서비스별로 켜둬야 하는 한계가 있었습니다.

여러개의 서비스를 개별로 ‘선택’해서 확인해야 하였음.

New Relic은 여러 서비스들을 목록화하여 간단하게 그 상태를 아이콘의 색으로 간단히 구분이 가능하고, 여러개의 인스턴스도 하나의 차트 내에서 확인이 가능합니다.

빨간색은 상태이상, 초록색은 정상, 회색은 모니터링 중이 아닌 것으로 구분된다.

주황색과 초록색으로 표시된 각 인스턴스들의 Response time, Cpu 이용률 등을 동일 차트 내에서 비교 가능하다.

또한, 알림 설정시에도 기존 Pinpoint에서는 커스텀한 설정에 한계가 어느정도 존재했습니다. New Relic을 도입한 이후에는 NRQL이라고 하는 New Relic 전용 언어를 통해 개발자가 원하는 방식으로 알림 설정이 가능해졌습니다. 쿼리 형식의 언어를 통해 ‘5분 동안 cpu 이용률이 90% 이상 사용시 알림 오게 하기’ 라든지 ‘1분 동안 에러 카운트 5회 이상시 알림 오게 하기’ 등으로 조건을 다양하게 설정이 가능합니다.

그 외에도 알림형식이나 알림 대상자 등을 설정하거나 webhook을 통해 여기어때 개발자들이 애용하고 있는 슬랙과 연동하는 부분도 개발자가 손쉽게 설정할 수 있어서 편리한 부분 중 하나였습니다.

알림 형태도 본인이 쉽게 설정 가능하다.

트러블슈팅

이런식으로 슬랙과도 연동하고 나서 실제로 뉴렐릭의 유용함을 깨닫게 된 경험을 하게 되었는데요. 신규로 진행한 프로젝트를 개발 서버 배포 후에 모니터링 중이었습니다. 그림처럼 에러 카운트가 1분에 적어도 5개 이상일 때 알림이 오게 설정을 해둔 상태였습니다.

NRQL의 의미는 ‘메트릭 데이터에서 error 카운트를 하겠다’ 라는 의미이고, 아래 조건으로 들어간 쿼리는 1분에 적어도 5개 이상일 때 알람을 보내겠다는 조건을 나타내고 있다.

갑자기 슬랙으로 알림이 왔습니다.

Activated는 건 ‘알림 조건에 부합하여 이슈가 열렸다.’라는 의미

로그를 확인하여 분석해보니

/xxxx?Id=1234

이런 식의 요청을 할 때 Id 값에 해당하는 값이 없으면 서버 에러로(500번대 에러) 취급되는 현상이었습니다.

사실 이 부분에서 ‘Id 값이 없을리가 없다’ 라고 가정하고 코드를 짰는데, 제가 잘못 생각한 부분이었습니다. 그래서 해당 부분에 예외처리를 해주고 Id 값이 없어도 서버 에러가 아닌 클라이언트 에러(400번대 에러)로 변경해 주었습니다.

그리고 추가적으로 뉴렐릭은 별도 설정이 없으면 400번대 에러도 위 알람 조건에서 에러 카운트 할 때 카운팅이 되기 때문에 이를 제외하는 설정이 필요했습니다.

설정 파일인 newrelic.yml 파일에서 ignore_status_codes 값을 기존 404 에서 400-405로 변경해 주었습니다. 404번 에러만 에러 카운트에서 제외하겠다는 설정을 400번부터 405번까지 범위로 변경해준 것입니다. (필요에 따라 400-499 와 같이 범위를 더 확장해서 변경해도 됩니다.)

결과적으로 이렇게 처리하니 더 이상 해당 부분이 에러 카운트로 잡히지 않았습니다.

그리고 나서 Alerts & AI 메뉴 내의 Issues & activity 메뉴에서 Active 상태로 잡혀 있는 것을 클릭하여

Active 상태의 이슈를 선택한다.

우측의 Close issue 버튼을 눌러주면

우상단에 빨간 네모로 표시된 Close issue 버튼을 누르면 된다.

슬랙에 다음과 같이 해당 이슈가 CLOSED 되었다는 메시지가 오게 됩니다.

알림 조건에 해당하는 상황이 발생하면 하나의 이슈로 등록되고 그 이슈를 해결하는 등 일종의 이슈관리를 할 수 있다는 점에서 유용했습니다.

그리고 서비스에 문제가 있거나 error 등이 발생하여 알림 조건을 충족한 경우 APM & Services 메뉴에서도 다음과 같이 빨간색 아이콘으로 표시되고 있었는데요. 위에서 제가 처리한 대로 문제 해결 후 issue를 종료하고 나니 초록색 아이콘으로 바뀌며 정상 서비스라는 것을 나타내 주는 형태로 바뀌었습니다.

APM 목록만 봐도 문제 상황을 쉽게 파악할 수 있는 이점이 있습니다.

마무리

이렇게 New Relic을 도입하여 사용한 경험에 대해서 이야기해 보았습니다. 그간 개발자 생활을 하면서 모니터링을 할 때 다양한 APM을 사용해 보았으나, 개발자가 다룰 때 New Relic만큼 간단하면서도(인프라 측면 제외) 가시성이 좋은 도구는 없었던 것 같습니다. 아직 New Relic을 접하지 않은 다른 개발자 분들이나 여기어때 내의 다른 팀 분들도 한 번 사용해보시면 편리함에 금방 빠지실 것 같습니다.

물론, 제가 아직 겪어보지 않은 APM들도 있고 기존에 사용하던 도구도 온전한 사용법을 모른 채 사용했을지도 모릅니다. 다만 ‘이거 써보니까 괜찮은데?’ 라고 의견을 제시하는 정도로 봐주시면 좋겠습니다. 끝까지 읽어주셔서 감사합니다.