株式会社ProgateのNewRelic導入事例
株式会社Progate / 708u
利用プラン | 利用機能 | ツールの利用規模 | 事業形態 |
---|---|---|---|
Pro + Standard | APM, Browser, Synthetic Monitoring, Logs, Alerts | 10名以下 | B to B B to C |
利用プラン | Pro + Standard |
---|---|
利用機能 | APM, Browser, Synthetic Monitoring, Logs, Alerts |
ツールの利用規模 | 10名以下 |
事業形態 | B to B B to C |
導入の背景・解決したかった問題
導入背景
新規プロダクトであるProgate Path / Progate Prospectsの開発にあたり、メインのプロダクトで元から利用していたため、特に迷うことなく導入しました。
導入の成果
改善したかった課題はどれくらい解決されたか
新規プロダクトのため、もともと改善したい課題自体は特にない状態でした。
どのような成果が得られたか
チーム内の開発者全員がアプリケーションの状態を確認できる様になりました。エラー発生時の初動確認のような受動的なアクションはもちろん、収集したデータを元にボトルネックになっている処理の可視化し改善していくような、能動的なアクションも促進されました。
導入時の苦労・悩み
バックエンド、フロントエンド等への個別計装
各コンポーネントごとに個別に導入する必要があり、多少の調査や試行錯誤が必要でした。
バックエンド: go + gRPCを使っているため、go-grpc middlewareとNew Relicが提供しているプラグインを用いた計装を行いました。
- rpcごとのtransaction可視化。gRPC起動時にInterceptorとしてNew Relicが提供しているInterceptorを渡す
- loggerの実装について
- Logs in Contextによるlog同士の紐づけやuser情報埋め込みを利用するため、context内にlogger(logrus)を埋め込むようにした
- アプリケーション初期化時にNew Relicが提供しているlog formetter(log出力先をNewRelicにしてくれる)を設定して、grpc logrus interceptorに引き渡してrpc実行ごとに取り出せるようにする
- rpcを実行するたびにcontextから上記のloggerを取り出し、userの情報を含めたloggerをcontextに埋め込み直すgRPC interceptorを自作して適用
- loggingしたい箇所でcontextからloggerを取り出してloggingする
- Logs in Contextによるlog同士の紐づけやuser情報埋め込みを利用するため、context内にlogger(logrus)を埋め込むようにした
フロントエンド: Next.js App Routerを用いているため、Node.jsサーバーとBrowser両方に対する計装が必要でした。
- Browser
- New Relicが提供しているプラグインを用いることで、サーバー上で初回SSRでhtmlを生成するタイミングでsnippetを含んだhtmlを生成できるとのことでした。ただし、実際に検証した結果うまく動作しなかったためSPA pro agentのsnippetをNew Relic上で作り、初回SSR時にNewxt.jsのScriptを用いて埋め込むようにしています。(App Routerリリースの早期時点で乗り換えたため、現在は解消している可能性があります)
- Node.jsサーバー
- アプリケーション起動時にNew Relic agentを含めて起動するように変更するだけで計装できました
導入に向けた社内への説明
上長・チームへの説明
前述の通り
活用方法
アプリケーション全域の観測
新規プロダクトにおいて、インフラ改善に多くのリソースを割くことは難しい状況で、クリティカルなエラーや性能劣化を正確に観測し、必要に応じて迅速に対応するためのツールとして重宝しています。 チーム内で週に1回、各サービスごとのAPMを確認して異常や性能改善の必要性がある箇所などを確認しています。 Transactionだけでは把握できないパフォーマンスの問題があるときは、Transaction内部にsegmentを埋め込んで、より小さい単位の処理ごとに計測を行います。その結果を元に性能改善を行うか、特に何もしないか、などの意思決定をしています。
エラー監視
エラーや性能の問題発生時に、アラートとErrors inBoxを活用して迅速に対応できるようにしています。
よく使う機能
APM
一番重点的に見ている箇所です。以下の項目を定常的に確認しています。
- Web Transaction time
- Apdex score
- アプリケーションやサービスのパフォーマンスをユーザー満足度の観点から評価する指標です。計算式は省きますが、ユーザー体験を満足、許容、不満の3つに分けて、それらを元にスコアが算出されます。
- この数値が一定の閾値を超えていないかどうかによってアプリケーションがユーザーさんにとって快適な状態を保っているか可視化できます。
- Throughput
また、APMの中でもTransactionも頻度高く確認しています。gRPCの1RPC callなどを一つのトランザクションとして、その中で発生したステップごとの処理(Redis、DBアクセスなど)を可視化し、リクエスト全体の処理を追跡できます。また、Logs In Contextを利用することで、トランザクションに紐づくログも容易に検索することができます。
Browser
クライアント側の各種モニタリングを行っています。 特にSession Replayが便利でよく使っています。これはフロントエンドで発生したエラーがする前から発生するまでのユーザーさんのインタラクションを動画で確認することができる機能です。一部始終を確認できることで、エラーの発生原因をより詳細に特定しやすくなります。
Alerts & Errors Inbox
異常発生時の初動から、実際のトラブルシューティングまで活用しています。slack連携による通知とErrors inboxによるエラー管理が必要十分であるため、現在すべてのエラー管理をNew Relicに集約しようとしています。(一部他エラートラッキングサービスが稼働していますが、段階的に廃止予定)
Frontのコードに関しては、事前にsource mapをuploadしておくことによってエラー補足時にminify前のコードを確認できるので、コードレベルでの具体的な原因を把握しやすくなっています。
Synthetic Monitoring
シンプルなPingによる死活監視に加えて、Scripted Browserを利用した死活監視を行っています。JavaScriptとSelenium WebDriverを利用できるので、アプリケーションにユーザーがログインできるかどうかなどの簡易的なE2Eを定常的に実行しています。
ツールの良い点
包括的なオブザーバビリティ アプリケーション全域の観測が可能で、gRPC、Redis、DBアクセスまで細かく追跡可能になる。 特にAPMは各言語ごとに最低限agentを設定するだけで概ね知りたい情報を可視化できるので、オブザーバビリティツールに慣れていなくてもすぐに必要な情報を確認できる状態にできる。
エラー対応の迅速化 アラート機能がSlackと連携しており、エラーをリアルタイムで把握し優先順位付けをできる。発生したエラーも前述の通り関連情報を紐づけて確認できるので、起きている問題を迅速に把握しやすい。
ツールの課題点
Full platform user権限を付与できるユーザー数が限られる。権限がない場合、特にAPMが確認できないと有益な情報をほとんど得ることができない。 そのため、実運用においてはFull platform user権限を持つメンバーがダッシュボードを作り、それ以下の権限を持つメンバーはそちらを参照する、という運用になる。 SREチームなど包括的かつ専門性を持ってオブザーバビリティに責任を持ってくれるチームが社内にいる場合は運用可能に思える。ただし、弊社のようにチーム単位でプロダクトを作っている場合、実際にダッシュボードをつくる人と情報を見たい人が異なるので、整備ハードルから積極的にNew Relicが使われなくなってしまう危険性がある。
課金体系がユーザー数に依存している 前述の通りすべての機能を使いたい場合Full platform user権限が欲しくなるが、一人追加したときのコストが高い。また、残シート数の切り替えが契約切り替えのタイミングのみのため、柔軟に権限を切り替えることが難しい。 個別に従量課金に切り替えることも可能とのことなので、契約時に相談してそちらを利用することはとできそうです。
NRQLの学習コストの高さ 欲しい情報をクエリすることは十分に可能だが、記法が独自のため若干学習コストがかかる。
ツールを検討されている方へ
オブザーバビリティツールとしては必要十分なので、課金形態が組織とフィットするかどうかで検討されるのが良いのかなと思います。前述の通りFull platform userが高額かつ柔軟に切り替えづらいので、組織内でどのようにオブザーバビリティを普及させるか計画したうえでシートをアサインすることをおすすめします。
また、弊社Progate PathにてNew Relicを実際に用いてアプリケーションを改善するタスクを用意しています。無料枠の範囲内です。 こちらを試していただくことでどのような使い勝手なのか一通りお試しいただけるかと思います。
https://app.path.progate.com/tasks/muzHlTIVNZkSxom_eL_be/preview
今後の展望
- IASTの導入
- オブザーバビリティの成熟モデルにおけるLevel3(予測的対応)以上を定常的に目指す
株式会社Progate / 708u
よく見られているレビュー
株式会社Progate / 708u
レビューしているツール
目次
- 導入の背景・解決したかった問題
- 活用方法