はじめまして。
7月にApplication Engineerとして入社した徳田 (id:hazeblog) です。
この記事では、先日社内に導入したDatadogのAPM（Application Performance Monitoring）機能と、APMを使ったアプリケーションの調査の様子を紹介します。
TL;DR
- Datadog APMを導入してRailsアプリケーションレベルでの監視を行うようにした
- APMを利用することでRailsアプリケーションのボトルネックを簡単に調査できるようになった
- 最近リリースされたAPM Trace Search & Analyticsはほぼリアルタイムでリクエストデータをトレース出来て大変便利
はじめに: Kaizen Platformの状況
Kaizenでは、これまでMackerelとNewRelicを使ってホストとアプリケーションの監視を行なっていました。
複数のサービスを横断して監視するよりも一つのサービスで総合的に監視をしたほうが監視がしやすいといった点やサービスの価格などから、上記の2つをDatadogにインテグレーションすることになり、移行作業を進めています。
そもそもDatadog とは？
www.datadoghq.com
一言でいうと、システムモニタリングのSaaSです。ホストの監視、アプリケーションの監視、ログ蓄積などの様々な機能を持っています。
Kaizen Platformでは全てのサーバにDatadogが導入されており、これまでもNginxのエラーを監視したり、Delayed::Jobの処理数を計測したりしています。
APM（Application Performance Monitoring）について
名前の通りではありますが、アプリケーションのパフォーマンス監視機能のことです。
APMを使うことでアプリケーションのAction単位、DBのQuery単位での監視が可能になり、どの処理が原因でレスポンスが遅くなっているかといった調査が可能になります。
Rails アプリケーションへのDatadog APMの導入
それでは、導入をするための手順を説明していきます。
Datadogのドキュメントに主要なアプリケーションフレームワークでの導入手順が記されているので、これを元に設定していきます。
まずはローカルでAgentを立ち上げて、正しくデータを飛ばせるかどうかを確認してみます。
ローカル環境でのTrace Agentのセットアップ
Datadogにログインして、Installation Instructionsの通りにDatadog Agentをインストールします。
正常にインストールができると、macの場合はメニューバーに骨のマークが出てきます。
これで完了...ではなく、WindowsやMacの場合はまだ続きがあります。
MacにインストールされるDatadog Agentには、APMを使うためのTrace Agentが含まれていないため別途導入する必要があるのです。
GitHub - DataDog/datadog-trace-agent: Datadog APM agent.
Trace Agentをインストールし、手動で起動したらAgentのセットアップは完了です。 （Windowsの方は別の設定が必要なので、ドキュメントを参照してください。）
Rails アプリケーションの設定
次に、アプリケーション側でAgentにデータを飛ばすための設定を行います。
gem ddtrace をインストールします
[Gemfile] gem 'ddtrace'
configファイルに転送先や内容を設定します。
[config/initializers/datadog-tracer.rb] Datadog.configure do |c| c.tracer enabled: true, env: development c.use :rails end
Dockerを使ってアプリケーションを立ち上げている場合や、AgentをDockerで立てていたり、他の場所に設置している場合は hostname: の指定が必要です。
正しくDatadogへ監視データが飛ばせていると、ログイン後のAPM>Serviceの画面に対象サービスが表示され、内容が確認できるようになります。
以上で、導入は完了です。
アクションのどこでレイテンシが高くなっているかを調べる
APMの活用例として、稼働しているアプリケーションの速度課題を見つけていきます。
APM -> Service から対象のアプリケーションを選択すると、リクエスト量やレイテンシ等のグラフが並んでいるダッシュボードが表示されます。
ダッシュボードの下に行くと、アクションごとのリクエスト量、平均レイテンシ、アクションの実行総合時間などが一覧で確認することができます。
これをTotal Timeの降順で並べると、「周りと比べるとアクセス数は少ないがレイテンシが高い」ものが一目でわかるようになります
それが、仕様上どうしても時間が掛かってしまう処理なのか、本来はもっと速いはずなのに遅いのかどうかを判別し、後者なのであれば更に詳細を見ていきます。
クリックすると1リクエスト単位での詳細なグラフやリストが表示され、そのアクションでどれだけのDBリクエストが発生したかといった情報を元にボトルネックを探します。
この例では、LIMIT=1のクエリが大量に発生してしまう問題が発生していて、それが原因で処理が遅くなってしまっていたようです。
このように、原因を特定し修正していくことでアプリケーションの高速化を行なっていきます。
Trace Search & Analytics
今回はアプリケーションの速度について紹介しましたが、APMは障害時の原因調査や、挙動検知にも活用することができます。
先日リリースされた Trace Search & Analytics という機能では、ほぼリアルタイムでリクエストデータのトレースを行うことができ、エラーが起きた時間やアクションを特定したり、そのアクションでどんなクエリが発行されているかといった情報を見ることができます。
まだ完全に移行しきっておらず、活用できていない機能もいくつかあるので
これからも触りつつ知見ができればこのブログで紹介していきたいと思います。
