4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

New RelicAdvent Calendar 2019

Day 24

NewRelicを導入して運用効率を改善させた話

Last updated at Posted at 2019-12-23

はじめに

こんにちは。NewRelicアドベントカレンダー24日目のエントリになります。

最近会社のメインプロダクトにNewRelicを導入し、運用効率が上がり捗るようになったのでその話を書きます。
ライトな内容ですので、NewRelicの導入を検討している方、もしくは導入直後の方などを対象にしています。

なんでNewRelicを導入したか?

長らくオンプレ環境で稼働させていたメインプロダクトを、GCPに移行させてKubernetes環境(GKE)で稼働するように構成を一新しました。
その際に、インフラ監視ツールをKubernetes環境に適したものを導入するのに合わせて、今まで導入していなかったAPMも入れることになりました。
監視ツール自体に保守工数をかけたくなかったのでSaaSサービスで探したところ、インフラ監視とAPMを兼ね備えているのはNewRelicとDatadogの2つがあり、トライアル導入をさせていただき比較検討を行いました。
スクリーンショット 2019-12-23 21.35.01.png
結果として、DatadogのAPMは対応しているフレームワークを使用していないと見れる情報が少なく、フレームワークを使用していないメインプロダクトではあまり有用ではなかったため、NewRelicを導入することとしました。

導入前の運用

NewRelic導入前はzabbixでインフラ監視はしていたものの、APMのようなサービス状況を可視化するものは導入していませんでした。
そのため、インフラ監視のアラートがなった時に、サービスの状況がどうなっているかわからない状態でした。
問題が発生して調査が必要な時は、人力でアクセスログの集計やDBデータから検索など、様々なオペレーションを行い調査を行なっていました。
この運用だと、問題の原因把握にまず時間がかかってしまうことで根本対応を行うスピード感も落ちてしまい、結果としてサービス品質を落としてしまうことがあり、NewRelic導入により改善を進めました。

導入後の運用

導入直後

NewRelicを導入することで、様々な情報がデフォルトで可視化できるようになりました。
スクリーンショット 2019-12-24 0.19.23.png
しかし、弊社のメインプロダクトはBtoBのSaaSサービスで、導入企業により契約プランが複数あり、導入企業ごとの環境や性能上限が異なる作りをしていました。
そのため、運用においてはサービス全体での状況というよりも、導入企業ごとの状況を知りたいケースが多く、それらを見れるように設定を追加していきました。
また、NewRelicでは上記のグラフをホスト単位で切り替えて見ていくことはできるのですが、特定のホスト(Node)に依存しないKubernetes環境では有効ではなかったため、設定の追加を進めました。

導入企業ごとの状況の可視化

NewRelicではコードを数行書くことで任意のデータをNewRelicに連携できる仕組みがあり、
導入企業ごとのIDをカスタムパラメータとして連携することで企業ごとに可視化することにしました。
書き方はAgentの言語ごとに異なるのですが、PHPだと下記のようなサンプルになります。


// NewRelicを導入していない環境でもエラーにならないように
if (extension_loaded('newrelic')) {
    // 導入企業のIDを取得する処理
    $client_code = ClientDetector::detectCodeFromDomain($_SERVER['SERVER_NAME']);
    // NewRelicへデータ(カスタムパラメータ)を連携する処理
    newrelic_add_custom_parameter('client_code', $client_code);
}

これをアプリケーションが実行されるごとに必ず実行される場所に書くと、全てのトランザクションデータに導入企業のIDのパラメータが追加されるようになります。
弊社のメインプロダクトではフレームワークを使用していないため自前の仕組みの中に記述しましたが、laravelだとbootstrap/app.phpなどになるかと思います。

さて、後はこのIDカットで見れるダッシュボードを作るだけです。
ダッシュボードはNRQLというSQLに似たNewRelic独自の言語によって作成できます。
FACETという構文を使うことで、導入企業IDごとのアクセス数・エラー発生件数を可視化しました。

スクリーンショット 2019-12-24 1.03.12.png

これにより、アラートがなった際にも、導入企業ごとにどのぐらいアクセスがあって、エラーが発生しているか、というサービス状況が一目でわかるようになりました。
今ではアクセスログを集計する、等のオペレーションもなくなり、快適に日々のサービス運用を行なっております。

まとめ

NewRelicを導入したことで今まで人力で行なっていた運用作業がなくなり、日々の運用を効率化することができました。
また、NewRelicでは今回紹介したカスタムパラメータの追加のような、様々なニーズに答えてくれる機能を備えています。
個々のアプリケーションに沿った見える化を行なっていくことで運用効率を向上していけることができるかと思います。

4
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
4
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?