AppSignal로 Ruby on Rails 앱 성능 완벽 모니터링하기

이 글은 시리즈의 두 번째 파트입니다. 첫 번째 편에서는 간단한 Ruby on Rails 애플리케이션을 DigitalOcean 앱 플랫폼에 배포하고, AppSignal을 연동하여 에러 대시보드에서 오류를 손쉽게 추적하고 확인하는 방법을 살펴봤습니다.

이번 편에서는 AppSignal을 활용해 Rails 애플리케이션에 다음 기능들을 설정하는 방법을 자세히 알아보겠습니다.

• 성능 모니터링
• Rails 백그라운드 작업(Background Jobs) 모니터링, API 호출 추적 방법 포함
• 로깅(Logging)
• 알림(Notification) 설정

그럼 바로 시작해 보겠습니다!

AppSignal로 Rails 앱 성능 모니터링하기

가동 상태(Uptime) 모니터가 앱이 정상 작동 중이라고 표시하면 모든 것이 잘 돌아간다고 생각하기 쉽습니다. 하지만 실제로는 느린 프로세스, 최적화되지 않은 데이터베이스 쿼리, 실행 시간이 긴 서비스 호출 등 문제가 내부에서 조용히 진행되고 있을 수 있습니다.

웹 페이지 로딩 속도가 느려질수록 방문자 전환율이 떨어진다는 점을 고려하면 이는 매우 중요한 문제입니다. 요약하자면, 방치된 느린 프로세스는 결국 비용으로 돌아옵니다. 그런데 Ruby on Rails 앱은 구성 요소가 워낙 많다 보니 '무엇을', '어디서' 확인해야 할지가 핵심 질문이 됩니다.

바로 이 지점에서 AppSignal이 빛을 발합니다. Rails 앱의 성능을 추적하는 방법을 하나씩 살펴보겠습니다.

응답 시간(Response Time) 추적

기본 대시보드에서 AppSignal은 Rails 앱이 얼마나 빠르게(혹은 느리게) 동작하는지 한눈에 파악할 수 있는 두 가지 그래프를 제공합니다. 바로 처리량(Throughput)과 응답 시간(Response time) 그래프입니다.

• 처리량(Throughput) — 현재 앱이 초당 처리 중인 요청 수를 의미합니다(앱이 전체적으로 감당할 수 있는 초당 요청 수와 혼동하지 마세요). 일반적으로 초당 처리량이 많을수록 좋지만, 서버가 너무 많은 요청을 처리하고 있다면 서버 리소스 확장을 고려할 때입니다.
• 응답 시간(Response time) — 브라우저 응답에 걸리는 평균 시간(밀리초)입니다. 응답 시간이 길어질수록 앱 성능이 나쁘다는 뜻입니다. 경험상 응답 시간이 100ms 미만이면 빠른 편으로, 300ms 이상이면 느린 편으로 볼 수 있습니다.

예를 들어 지난 7일 동안의 응답 시간과 처리량을 추적하고 싶다면 아주 간단합니다. 왼쪽 메뉴에서 Performance 하위의 Graphs 메뉴로 이동한 뒤, 그래프 상단의 기간 필터 버튼을 사용하면 됩니다.

이렇게 하면 특정 요일에 앱이 다른 날보다 느리게 동작했는지도 쉽게 확인할 수 있습니다.

이 화면에서 Response time 및 Throughput 그래프 아래에 있는 Event groups 그래프도 꼭 확인해 보세요.

이 그래프는 컨트롤러 계층과 뷰 계층에서 앱이 얼마나 빠르게 또는 느리게 동작하는지 세부 정보를 보여줍니다. 여기서 느린 응답 시간의 원인을 찾아내고 그에 맞게 문제를 해결할 수 있습니다.

이제 데이터베이스 쿼리 추적으로 주제를 바꿔 보겠습니다.

데이터베이스 쿼리 추적

응답 시간과 처리량을 최적화하면 앱에서 더 많은 속도를 끌어낼 수 있다는 것은 일반적인 사실입니다. 하지만 대부분의 경우 앱이 느려지는 최대 원인은 최적화되지 않은 데이터베이스 쿼리입니다.

악명 높은 N+1 쿼리를 예로 들어 보겠습니다. 첫 번째 편에서 소개한 지출 관리 앱에서 expenses 컨트롤러의 index 메서드는 다음과 같습니다.

언뜻 문제없어 보이지만, AppSignal 대시보드의 Issues 목록을 살펴보면 흥미로운 점을 발견할 수 있습니다.

expenses 컨트롤러의 index 메서드에서 N+1 쿼리가 감지되어 표시됩니다.

이슈 링크를 클릭해 더 자세히 들여다보면 다음과 같은 Issue details 화면으로 이동합니다.

AppSignal은 해당 문제에 대한 설명과 함께, 해결 방법을 자세히 다룬 블로그 포스트 링크까지 제공한다는 점에 주목하세요.

이제 AppSignal이 백그라운드 작업 모니터링에 어떻게 도움을 주는지 알아보겠습니다.

AppSignal로 Rails 백그라운드 작업 추적하기

백그라운드 작업은 운영 환경의 Rails 애플리케이션에서 흔히 사용되는 기능으로, Sidekiq, Que, Delayed Job, Resque 등 다양한 잡 큐 처리 젬(gem)과 라이브러리 중에서 선택할 수 있습니다.

AppSignal은 이러한 백그라운드 잡 처리 라이브러리들의 추적과 모니터링을 폭넓게 지원합니다.

사용자 대시보드에 매일 환율 정보를 표시해 주는 기능을 만들고 싶다고 가정해 보겠습니다.

이를 구현하려면 환율을 제공하는 외부 API를 호출해야 합니다(사전 설정이나 결제 부담이 적은 서비스를 선택하면 좋습니다). 그리고 정해진 주기마다 해당 서비스 호출을 큐에 넣는 백그라운드 작업도 필요합니다.

이번 예제에서는 GoodJob이라는 백그라운드 처리 젬을 사용하지만, 상황에 맞는 어떤 도구를 사용해도 무방합니다.

환율을 가져오는 백그라운드 작업을 생성해 보겠습니다.

그런 다음 GoodJob이 몇 분마다(또는 원하는 주기대로) 이 작업을 cron으로 실행하도록 설정합니다. AppSignal은 백그라운드 서비스의 존재를 자동으로 감지하고, 이를 기본 웹 대시보드와 구분할 수 있는 유용한 필터까지 제공합니다.

추가 도구 설정 없이도 AppSignal은 API 호출을 감지하고 관련 이슈를 추적합니다.

Rails 백그라운드 작업 모니터링에 대해 더 깊이 알고 싶다면 공식 문서를 참고하시길 권장합니다. 이제 가동 시간(Uptime) 모니터링으로 넘어가겠습니다.

가동 시간(Uptime) 모니터링

많은 Rails 개발자들이 신경 쓰는 또 다른 사항은 최종 사용자에게 애플리케이션이 지속적으로 제공되는지 여부입니다. 다운타임이 발생하면 매출 손실과 여러 부정적 결과로 이어질 수 있습니다.

그렇다고 앱의 가동 상태를 일일이 수동으로 확인하고 싶지는 않을 것입니다. AppSignal을 사용하면 가동 시간 모니터링을 간편하게 설정할 수 있습니다.

설정은 매우 쉽습니다. 먼저 왼쪽 메뉴에서 Uptime monitoring 링크를 클릭하세요.

그런 다음 create uptime monitor 버튼을 클릭하면 아래와 같은 대화 상자가 나타납니다.

필수 설정 항목을 입력하여 모니터를 완성합니다.

• Name — 가동 시간 모니터에 알맞은 이름을 지정합니다.
• URL — 가동 상태 확인용 라우트의 전체 URL을 입력합니다. Rails 7.1부터 기본 가동 확인 라우트는 https://your-app-domain/up입니다.
• Region — 가동 상태를 확인할 지역을 선택합니다.
• Notification — 알림을 받을 채널을 선택합니다.

설정을 마쳤다면 모니터를 생성하세요!

AppSignal 가동 시간 모니터에서 한 가지 유의할 점은 폴링이 거의 매분 수행되기 때문에 요금제 한도에 금방 도달하기 쉽다는 것입니다. 다행히 공식 문서에서 이를 우회할 수 있는 좋은 방법을 소개하고 있으니 참고하세요.

로깅으로 넘어가기 전에, 가동 시간 모니터링 레이어를 완성하는 또 하나의 중요한 기능인 무료 공개 상태 페이지(Public Status Page)를 소개합니다.

아래 그림과 같이 creating a public status 페이지 링크를 클릭합니다.

그런 다음 New status page 버튼을 클릭하면 다음 화면으로 이동합니다.

필수 정보를 모두 입력하세요. 참고로 커스텀 도메인을 사용하는 경우, 해당 도메인의 DNS 설정에 cname.appsignal-status.com을 가리키는 CNAME 레코드를 추가해야 합니다.

AppSignal로 로깅하기

로깅은 AppSignal에 추가된 비교적 새로운 기능이지만, 시의적절하고 반가운 기능입니다. AppSignal을 사용하면 애플리케이션 모니터링과 로깅을 별도의 서비스로 운영할 필요가 없습니다.

로깅을 시작하려면 최신 버전의 AppSignal 젬을 사용 중인지 먼저 확인하세요. 구버전을 사용 중이라면 다음 명령으로 업데이트합니다.

그런 다음 새 이니셜라이저(initializer) 파일을 생성하고 아래와 같이 수정합니다.

이제 다음과 같이 앱의 로그에 접근할 수 있습니다.

로그 심각도(severity)별로 기록을 필터링할 수 있는 편리한 필터와 실시간 로그(Live Logs) 기능도 함께 제공됩니다.

Ruby 로깅에 대한 자세한 내용은 AppSignal 공식 문서에서 확인할 수 있습니다.

그 외 주요 기능들

AppSignal에는 이 외에도 이상 징후 탐지(Anomaly Detection)와 커스텀 메트릭(Custom Metrics)이라는 눈길을 끄는 기능이 있습니다.

이상 징후 탐지(Anomaly Detection)

앱의 메모리 부족이 걱정된다고 가정해 보겠습니다. 사용 가능한 메모리가 눈에 띄게 줄어들면 이메일 알림을 보내는 트리거를 손쉽게 설정할 수 있습니다.

Anomaly detection 메뉴로 이동해 새 트리거를 생성한 후 다음과 같이 구성합니다.

• Metric — 여기서는 메모리 사용량에 주목했지만, 사용 사례에 맞는 다른 메트릭도 자유롭게 선택할 수 있습니다.
• Trigger details — 트리거와 관련된 세부 조건을 구성합니다. 이 예제에서는 호스트 메모리가 200MB 미만으로 떨어지면 트리거가 발동됩니다.

커스텀 메트릭(Custom Metrics)

AppSignal은 커스텀 메트릭을 수집하고 시각화할 수 있는 도구도 제공합니다. 이 기능 하나만으로도 별도의 글을 쓸 가치가 충분합니다. 자세한 내용은 AppSignal의 커스텀 메트릭 모니터링 가이드와 공식 문서를 참고하세요.

마치며

시리즈 첫 번째 편에서는 DigitalOcean에 호스팅된 Rails 앱을 구성하고 AppSignal로 에러를 모니터링했습니다.

이 두 번째이자 마지막 편에서는 성능 모니터링, 가동 시간 모니터링, 로깅 등 Rails 앱에 유용한 AppSignal의 다양한 기능을 살펴봤습니다.

이 시리즈에서 다룬 것보다 AppSignal이 제공하는 기능은 훨씬 더 많습니다. 여러분의 Rails 앱에 직접 적용해 보시길 강력히 추천합니다.

즐거운 코딩 되세요!

P.S. Ruby Magic 포스트가 게재되는 즉시 읽고 싶으시다면 Ruby Magic 뉴스레터를 구독하세요. 단 하나의 글도 놓치지 않을 수 있습니다!