レガシーシステムにNew Relic... - Qiita

レガシーシステムにNew Relicを入れて改善を頑張った話 #NewRelic - Qiita 16 いいねしたユーザー一覧へ移動 4 X（Twitter）でシェアする Facebookでシェアする はてなブックマークに追加する more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete info この記事は最終更新日から1年以上が経過しています。 21日目 New Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2023 @ ramiyon_chan ( らみよん ) レガシーシステムにNew Relicを入れて改善を頑張った話 NewRelic 16 最終更新日 2023年12月21日 投稿日 2023年12月20日 はじめに レガシーシステム 1 に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ライフを！ レガシーさの基準はさまざまであり、今回のケースでは「レガシー」と表現すべきではない点もあるかもしれません。あらかじめご容赦いただければ幸いです。 ↩ 16 いいねしたユーザー一覧へ移動 4 comment 0 コメント一覧へ移動 新規登録して、もっと便利にQiitaを使ってみよう あなたにマッチした記事をお届けします 便利な情報をあとで効率的に読み返せます ダークテーマを利用できます ログインすると使える機能について 新規登録 ログイン 16 いいねしたユーザー一覧へ移動 4 more_horiz 記事を削除する close 一度削除した記事は復旧できません。 この記事の編集中の下書きも削除されます。 削除してよろしいですか？ キャンセル 削除する delete