New Relicで実現するユーザーとエンジニアの「幸福」──PR TIMESのオブザーバビリティ改善への旅路とは？

【16-C-3】技術的負債との戦い！　PR TIMESエンジニアチームのオブザーバビリティ改善ジャーニー

エラー発生時も効率的に対応、「New Relic」のエンジニアフレンドリーな機能

　櫻井氏は、これらの課題解決に向けてNew Relicを活用した改善ジャーニーに乗り出す。

　エラーの検知に関しては、New Relicの著名な機能であるAPM（アプリケーション・パフォーマンス・モニタリング）を活用した。APM内の「Errors」というタブを使うと、エラーの一覧を発生件数や割合のグラフと共に確認できる。エラークラスやエラーメッセージによるグルーピング機能もあり、「問題発生時やリリース後には、このページを最初に確認するようにしています」と櫻井氏は利便性の高さを評価した。

エラーの発生具合を一覧で確認できる

　エラー一覧ページでは、特定のエラーを選択すると詳細ページに遷移し、発生日時やURLなどのデータを確認できる。さらに「Logs in Context」という機能を利用すれば、エラー発生前後のログを閲覧できるので、エラーの原因を効率的に特定できる。エラーの原因特定に必要なデータはこの詳細ページに集約されるので、ここを見るだけで多くのエラー原因を理解できるというわけだ。

　またエラーが発生した場合、New RelicならSlackなどのコミュニケーションツールに通知を送ることができる。重要なアラートには担当者へのメンションをつけ詳細ページへのリンクを付与することで、迅速な対応が可能となった。

　パフォーマンスの改善では、改善すべき箇所の特定が重要だ。例えばページ表示のパフォーマンス改善なら、アクセスが1日数回のページよりも何万回も表示されるページを優先して改善すべきだ。New RelicのAPMのTransactionsという機能を使うと、総実行時間が長い処理を順に表示したり、平均実行時間や実行回数、エラーレートなどでソートしたりできる。これらの機能により、改善が必要な処理を特定しやすくなった。

　ログの監視に関しては、オープンソースのデータ収集ソフトウェア「Fluentd」を活用し、New Relicにログを転送して、New Relic上で確認できる体制を構築した。特に監視が必要なエラーログについては、Slackに通知する仕組みも導入した。また定期的なタスクを実行するcronについても、実行結果のログをNew Relicに転送し監視している。

　その他、New Relicには「NRQL（ヌルクル）」という独自のクエリ言語があり、これを使うとNew Relicに保存されているほぼ全てのデータを検索し、表示できる。データはグラフ描画やCSV、JSON形式で出力し、URLを通じた共有やダッシュボードでのアラート作成も可能だ。最近では生成AIが搭載され、テキストの指示だけでもクエリを生成できる。櫻井氏は「NRQLは、個人的にNew Relicで最も気に入っている機能の1つです。まだ試していない方にはぜひ使用をお勧めします」と述べ、この機能の有用性を強調した。

「NRQL」の機能

「エンジニア人生に余裕が生まれる」デブロイスクリプトとマルチステージングとは

　今回の改善に合わせて、デプロイスクリプトも根本から全面的に見直された。従来は、「デプロイ時間が長い」「ダウンタイムが発生する」「処理がさまざまなファイルに分散していて読みづらい」といった課題が存在していたためだ。

　デプロイ時間については、サーバーごとにビルドを行っていたのを、最初に一括でビルドしてから全てのサーバーにデプロイする形に変更し、6分30秒から約2分と大幅に短縮した。そのほか、シンボリックリンクを活用して無停止でデプロイを実施するなど工夫を凝らし、デプロイの高速化を達成している。これら改善により、PR TIMESのエンジニアからは「人生に余裕が生まれた」というポジティブなフィードバックが寄せられていると櫻井氏は報告した。

　またステージング環境については、改善前は環境が1つしかなく、使用前に他のエンジニアに連絡するか他の人が使い終わるのを待つ必要があった。そこで、「Apache」のVirtualDocumentRoot機能を活用し、開発者ごとにディレクトリを作成するようにデプロイスクリプトを変更した。これにより1台のサーバーで複数のステージング環境を並行して動かすことができ、複数人で作業を進行できるようになった。

Apacheの機能を使って、1台のサーバーで複数のステージング環境を並行して動かす