프로덕션 환경에서 애플리케이션을 운영하고 유지보수할 때 가장 중요한 것은 애플리케이션이 의도한 대로 동작하고 있다는 확신을 갖는 것이며, 문제가 발생했을 때 즉시 인지하는 것입니다. 최소한으로도 에러를 추적하고, 성능을 모니터링하며, 애플리케이션 전반에 걸쳐 필요한 지표(metrics)를 수집할 수 있어야 합니다.
하지만 개발자라면 누구나 유지보수하기 쉬운 솔루션을 선호하기 마련입니다. 여러 도구와 통합 설정, 의존성이 뒤엉켜 오히려 관리가 더 어려워지는 상황은 피하고 싶겠죠.
이 글에서는 Ruby on Rails 애플리케이션에 AppSignal을 추가하여 애플리케이션의 동작을 명확하게 파악하는 방법을 소개합니다.
직접 코드를 따라 해보려면 다음 준비물이 필요합니다:
- www.appsignal.com 계정
- Docker 설치 및 실행 (
docker-compose사용)
* 이 글의 샘플 애플리케이션을 사용할 경우에만 필요합니다.
AppSignal 설정 준비하기
참고: 이미 운영 중인 자신만의 Rails 애플리케이션에 AppSignal을 추가한다면 이 섹션은 건너뛰어도 됩니다. 그 경우 Docker 관련 안내나 Rails 서버 재시작 방법도 무시하고, 평소처럼 애플리케이션을 재시작하거나 재배포하면 됩니다.
여기서는 샘플 애플리케이션을 사용해 시작해 보겠습니다. Docker를 이용해 로컬 머신에서 실행합니다.
다음 명령어를 실행하여 저장소를 클론하고, 의존성을 설치한 뒤 애플리케이션을 구동합니다:
$ git clone --branch appsignal-setup/start-docker --single-branch https://github.com/choncou/sample_rails_app appsignal-setup
$ cd appsignal-setup
$ yarn start:compose처음 실행할 때는 Docker 이미지 빌드와 의존성 다운로드에 시간이 다소 걸릴 수 있습니다. 완료되면 Rails 서버, PostgreSQL 데이터베이스, Redis가 함께 시작됩니다. 로그에서 요청 기록을 확인할 수 있으며, https://localhost:3000/ 에서 실행 중인 애플리케이션을 볼 수 있습니다.
샘플 애플리케이션 살펴보기
사용하는 애플리케이션은 아주 단순한 구조이므로 몇 가지만 짚고 넘어가겠습니다.
Post 모델과 PostsController가 있으며, /posts 라우트를 통해 CRUD 액션이 모두 노출되어 있습니다.
또한 PagesController가 렌더링하는 홈 페이지가 있는데, 이 컨트롤러는 랜덤 게시글을 비동기적으로 생성하는 백그라운드 잡 CreateRandomPostsJob을 큐에 등록합니다.
마지막으로 백그라운드 잡 처리에는 Sidekiq를 사용합니다.
이 작은 블로그 플랫폼에는 이미 활성 사용자도 있다고 가정합니다. 서버와 함께 백그라운드에서 실행되는 스크립트(./bin/traffic)가 주기적으로 요청을 보내 실제 트래픽을 흉내 냅니다.
자, 제품을 출시했고 모든 것이 완벽하게 동작하는 것 같습니다...
적어도 사용자들로부터 성능 저하와 에러 신고가 들어오기 전까지는요.
그렇다면 무슨 일이 일어나고 있는지 어떻게 알아낼 수 있을까요? 개발 환경에서는 에러를 확인하기가 비교적 쉽지만, 프로덕션에서 실행 중인 애플리케이션은 이야기가 다릅니다. 방대한 서버 로그를 뒤지는 것보다 더 나은 에러 추적 방법이 분명히 필요합니다.
AppSignal이 구원자로 등장할 차례입니다!
AppSignal 시작하기
애플리케이션에 AppSignal을 추가하며 모니터링 여정을 시작해 보겠습니다. 먼저 www.appsignal.com 에 로그인하세요.
AppSignal 신규 사용자라면 아래와 같이 애플리케이션을 추가하는 화면이 나타납니다(기존 사용자는 'Add app' 버튼을 클릭하면 됩니다).
"Install for Ruby"를 선택하면 몇 가지 간단한 단계가 안내됩니다:
Gemfile에 gem 추가
# Gemfile gem 'appsignal'Docker 컨테이너 내부에서
bundle install실행. 컨테이너는yarn compose:sh로 접속할 수 있습니다.$ yarn compose:sh # 이제 Docker 컨테이너 내부의 bash 콘솔에 접속된 상태입니다 $ bundle install # 다음 명령어를 위해 이 콘솔에 머물러 주세요AppSignal 설치
설치 과정에서 두 가지 질문에 답해야 합니다:
Do you want to change how this is displayed in AppSignal? (y/n): nHow do you want to configure AppSignal?: 환경 변수 대신 설정 파일을 사용할 예정이므로1입력
AppSignal 설정 페이지에 표시된 API 키를 사용합니다:
$ bundle exec appsignal install <your-api-key> ... ... ##################################### ## AppSignal installation complete ## ##################################### Sending example data to AppSignal... Example data sent! It may take about a minute for the data to appear on https://appsignal.com/accounts Please return to your browser and follow the instructions.
설치 스크립트를 실행한 후, 브라우저에서 AppSignal 설정이 완료되었음을 확인할 수 있습니다. 이후 'Go to app'을 클릭하면 개발 환경의 AppSignal 대시보드를 볼 수 있습니다.
설치 명령어는 config/appsignal.yml 파일을 생성하며, 이 파일을 통해 환경별로 AppSignal 설정을 구성할 수 있습니다. 자세한 내용은 AppSignal Ruby 설정 공식 문서를 참고하세요.
config/appsignal.yml에는 Push API 키가 포함되어 있습니다. 실무에서는 보통 이 값을 파일에서 제거하고 환경 변수로 관리하지만, 이 글에서는 생략하겠습니다.
새로운 gem을 설치했으므로 변경 사항이 적용되도록 애플리케이션을 재시작해야 합니다. 가장 간단한 방법은 서버가 실행 중인 터미널 창에서 ctrl-c로 Docker 컨테이너를 중지한 뒤, 다음 명령으로 docker-compose를 다시 시작하는 것입니다:
$ yarn start:compose의존성이 변경되면 Docker 이미지를 다시 빌드하기 때문에 시간이 다소 걸릴 수 있습니다.
AppSignal 메인 대시보드
이제 AppSignal이 설치된 애플리케이션이 실행 중이므로 대시보드를 확인할 차례입니다. AppSignal에서 운영 중인 모든 애플리케이션과 환경을 보려면 appsignal.com/accounts 로 이동하세요.
애플리케이션 이름을 클릭하면 AppSignal이 기본적으로 제공하는 모니터링 기능들을 탐색할 수 있습니다.
트래픽 생성 스크립트 덕분에 몇 분 안에 데이터가 수집되기 시작합니다.
메인 대시보드에서는 핵심 애플리케이션 지표들의 고수준 개요를 한눈에 파악할 수 있습니다. 이제 AppSignal의 좀 더 세부적인 영역들을 살펴보겠습니다.
AppSignal 에러 대시보드
에러 페이지에서는 애플리케이션이 보고한 모든 에러 목록을 확인할 수 있습니다. 설치 스크립트를 실행할 때 테스트 에러가 AppSignal로 전송되었으며, 꽤 규칙적으로 발생하는 에러도 함께 보입니다. 에러를 클릭하면 디버깅에 유용한 상세 정보 페이지가 열립니다.
이 예제에서는 백트레이스(backtrace) 섹션을 통해 애플리케이션 홈페이지(/)에서 app/controllers/pages_controller.rb:7 home 위치에서 유효성 검증(validation) 에러가 발생하고 있음을 알 수 있습니다.
그 외 AppSignal 대시보드
사이드바의 'Dashboard' 메뉴를 보면 AppSignal이 기본으로 제공하는 여러 대시보드가 있다는 것을 알 수 있습니다.
'Overview' 대시보드는 모든 애플리케이션에 제공되며 다음 정보를 포함합니다:
- 애플리케이션 에러율
- 처리량(Throughput)
- 응답 시간
- 상세히 파고들 수 있는 최근 활동 기록
또한 Active Job용과 Sidekiq용 매직 대시보드(magic dashboard) 두 가지도 제공됩니다. AppSignal은 널리 쓰이는 프레임워크와 gem들을 위한 내장 통합 기능을 갖추고 있어, Rails 애플리케이션과 자동으로 연동됩니다.
이 대시보드들을 열면 해당 통합 기능의 활동과 관련된 정보를 확인할 수 있습니다. Active Job 대시보드에서는 큐별 잡 수, 각 잡의 기록된 실행 시간 등을 그래프로 볼 수 있습니다. 직접 확인해 보세요!
애플리케이션 성능 분석
Performance → Issue list 메뉴에서는 AppSignal이 측정하는 액션 목록을 볼 수 있습니다. 이 측정 데이터는 애플리케이션의 어느 부분이 성능을 많이 소모하는지 파악하는 데 귀중한 인사이트를 제공합니다.
예를 들어 PostsController#index 액션의 이슈를 클릭하면 해당 컨트롤러의 성능을 더 깊이 들여다볼 수 있습니다. 시간이 가장 많이 소요되는 지점이나 객체 할당(object allocation)이 가장 많이 발생하는 지점을 빠르게 확인할 수 있습니다.
AppSignal의 숨겨진 보석: Puma 활용하기
AppSignal에서는 별다른 노력 없이 얻을 수 있는 숨겨진 보석들(Ruby 보석이 아니라요!)이 몇 가지 있습니다. 예제를 통해 얼마나 쉽게 활성화할 수 있는지 살펴보겠습니다.
config/puma.rb에 다음 한 줄을 추가합니다:
# config/puma.rb
plugin :appsignal애플리케이션을 재시작하기 전에 docker-compose.yml의 12번째 줄 뒤에 다음 환경 변수를 추가합니다:
# docker-compose.yml
APP_REVISION: "latest_version_tag"Puma 서버 설정과 docker-compose 설정을 모두 변경했으므로, ctrl-c로 Docker 컨테이너를 중지한 뒤 yarn start:compose로 docker-compose를 다시 시작해야 합니다.
새로운 인사이트 추적하기
서버가 재시작된 후 약 1분 정도 실행 상태로 두었다가, AppSignal 대시보드로 돌아가 페이지를 새로고침하세요. 이제 두 곳에서 새로운 정보를 확인할 수 있습니다.
첫 번째는 자동 생성된 Puma 메트릭 매직 대시보드입니다. AppSignal의 Puma 내장 통합 덕분에 애플리케이션 서버의 활동 정보를 얻을 수 있게 되었습니다. 설정 파일에 plugin을 지정하면 Puma 서버의 메트릭을 보고하는 미닛리 프로브(minutely probe)가 활성화됩니다.
두 번째는 AppSignal 대시보드 전반에 표시되는 배포 마커(deployment marker)입니다. APP_REVISION 환경 변수에 git 커밋 SHA처럼 현재 애플리케이션 버전을 식별하는 데 도움이 되는 값을 설정할 수 있습니다.
대시보드의 'Deploys' 섹션에서 배포 이력을 확인할 수 있고, 에러나 성능 이슈 목록 같은 인사이트를 배포 단위로 필터링할 수도 있습니다. 배포 간 성능이나 안정성이 어떻게 변화했는지 비교하면, 어떤 변경 사항이 새로운 버그를 유발했는지 추적하기가 한결 수월해집니다.
다음 편 예고: Ruby 앱을 위한 커스텀 계측 및 모니터링
이 글에서는 AppSignal을 애플리케이션에 설정하고 활용하여 실제 운영 환경에서 코드 가시성을 높이는 방법을 살펴보았습니다.
Rails는 물론 Sidekiq, Puma 같은 의존성과의 자동 연동 방법도 확인했습니다. AppSignal은 이 외에도 수많은 Ruby 프레임워크와 gem을 기본적으로 지원합니다. AppSignal의 Ruby 통합 목록은 공식 문서에서 전체를 확인할 수 있습니다.
이 시리즈의 2부에서는 Ruby on Rails 애플리케이션에 커스텀 계층(custom instrumentation)과 모니터링을 추가하여 더 깊은 인사이트를 얻는 방법을 다룰 예정입니다.
다음 편에서 만나요!
P.S. Ruby Magic의 글을 발행 즉시 읽고 싶다면 Ruby Magic 뉴스레터를 구독하고 어떤 글도 놓치지 마세요!