レガシーシステムにNew Relicを入れて改善を頑張った話

はじめに

レガシーシステム¹にNew Relicを導入して2年弱、直接的・間接的にとてもいい効果がありました🎉

• 調査の人的コストを削減した
• エンジニア共通のプラットフォームになった
• 技術的負債に気づいて返済した
• エンジニアのパフォーマンスを可視化した
• ビジネスサイドのダッシュボードも作成した

その苦労と喜びに関する話です。

調査の人的コストを削減した

システムにまつわるデータがまとめて見えるようになった

APM（Application Performance Monitoring）・Infrastructureの導入により、システム上の多くのデータがNew Relicで閲覧できるようになりました。

• エラーレートの変化から、リリース前後の障害を検知する
• パフォーマンスデータから、ユーザーの満足度向上に効果的なページを見つける

など、システムのさまざまなデータを自動的に計測してくれるようになりました。
これまで手作業で計測していたり、「なんとなく遅いよね」と感覚で話していたことが、根拠を持ったデータとして繋がった瞬間でした。

また、既にZabbixで行っている監視も手動で移行しました。

• インフラリソースを監視してアラートを出す
• アプリケーションでエラーログが出力されたら、アラートを出す

ログの構造化・検索性の向上

以前は以下のような要因で、ログの検索に時間がかかっていました。

• ログはサーバー上にローカルファイルとして出力される
• サーバーにSSH接続してcat・grepを駆使
• 複数のサーバーを跨いだ閲覧に難がある

これが、以下のように改善されました。

• 複数のサーバーを跨いだ検索ができるようになった
  • ログファイルをFluentBitを使ってNew Relicに転送した
  • 検索条件が指定できるので、サーバー別の検索にも対応している
• 細かな条件による検索ができるようになった
  • 豊富な検索機能を使えるように、ログの構造化（JSON化）を実施した
  • 今回はPHPが動いていたので、ログライブラリにMonologを導入
    • 標準でJSON用のフォーマッターがあるので、それを使用
  • ライブラリ管理にComposerを導入

Composerの導入は開発チームの説得に骨が折れました…
近年のPHP開発ではデファクトスタンダードですが、必要性が薄かったようです。

それまでライブラリはPEARやPECLで管理されていて、あまり馴染みがないメンバーもいました。
デプロイで使っているJenkinsのジョブに改修が必要だったり、バージョン更新によるアップデートの運用を考えないといけなかったり…課題も多かったです。

PM・バックエンド・インフラなど、さまざまな役割のエンジニアに掛け合いながら実現に向けて動きました。
頑張った甲斐もあり、現在ではビギナーの方でもログの調査をお任せできるぐらい利便性が向上しました。

エンジニア共通のプラットフォームになった

これまで弊チームの監視ツールは、インフラやSREを担当するエンジニアのみが閲覧するものでした。
一方、New Relicはアプリケーションやアクセス解析に関する情報も収集されているため、エンジニアが共通のプラットフォームとして利用することができます。

障害が発生した際、インフラリソースの状況やアプリケーションのエラーレートなど、お互いが情報を共有しながら総合的に対応できるようになりました。

お互いの関心がわかるようになって、対話をする機会も増えました。
現在では、オブザーバビリティをより実現するために、障害を検知する・未然に防ぐための仕組みづくりにも取り組んでいます。

技術的負債に気づいて返済した

APMやInfrastructureを導入する際、動作環境に満たない現在のシステムでは苦労することが多々ありました…

• 言語のバージョンが古く、APMがガイド付きインストールで導入できない
• OSのバージョンが古く、Infrastructureがガイド付きインストールで導入できない

これらはソースからインストールしてなんとか解決できましたが…
（そもそも既にサポート対象外なのに更新していないのが悪い）

• エラーが捕捉できない
  • 握りつぶしてるじゃん！！
• ログが見づらい
  • そもそも構造化されていない…しかも独自のフォーマットでパースできない…
• アラートが次々と上がる
  • これまで補足できていなかったものが次々と出てくる

などなど、一筋縄ではいかない点も多くありました。

しかし、これらはすべてこれまで気づいていなかったり、いつか改善したいと考えている課題でした。
いずれ直面する問題が表出しているだけだと考え方を改め、抜根的な改善を提案するきっかけとなりました。

技術的負債の地道な返済を続けて、現在は問題なく使える程度に落ち着きました。
次はアプリケーションのパフォーマンスなど、よりユーザー体験に近い部分の改善を進めています。

エンジニアのパフォーマンスを可視化した

これまで開発チームの生産性が可視化できていなかったため、チームのどこに伸びしろがあるのか不明なままでした。
エンジニアの定量的な指標もなく、「なんとなく仕事している」「頑張っているけど証明できない」などもどかしい状態が続いてました…

そこで、New Relicにデータを送信して、Googleの提唱するFour Keysを計測するようになりました。
データをダッシュボードにまとめることで、自分達がどのような状態にあるのか一目でわかるようになりました。

一部抜粋すると、こんな感じです↓

これからの目標として、デプロイ頻度やリードタイムの改善を目指しています。

ビジネスサイドのダッシュボードも作成した

これまでKibanaで構築されていたビジネス用ダッシュボードを、New Relicに移行しました。
基本的なダッシュボードの作成・表示には同等の機能が提供されているため、問題なく移行できました。

エンジニア向け・ビジネスサイド向けのダッシュボードが同じプラットフォーム上にあることで、「ちょっと覗いてみようかな」とお互いの仕事に関心を寄せるキッカケになりました。

今後はKPIやマーケティングデータのダッシュボードも作成して、ビジネス全体のデータ分析基盤として活用していく方針です。

さいごに

New Relicは導入するだけでもいろいろなデータを計測してくれます。
これまで気づかなかった問題に気づき、感覚的に把握していた事柄が根拠のあるデータになり、論理的にシステムを改善していく良い相棒になってくれました。

しかし同時に、自分達でどう活用していくかを考えないといけないツールでもあると感じています。エンジニアの腕の見せ所です。
筆者の場合は、公式イベントやNRUG（New Relic User Group）など、日本語の利用情報が豊富にあるのに助けられました。

New Relicの導入によって、レガシーシステムのマイナスをゼロにするいい機会になりました。
これからは、ゼロをプラスにする攻めの姿勢でオブザーバビリティの実現を目指していきます。

それでは、みなさま素敵なNew Relicライフを！

1. レガシーさの基準はさまざまであり、今回のケースでは「レガシー」と表現すべきではない点もあるかもしれません。あらかじめご容赦いただければ幸いです。 ↩