はじめに
こんにちは、NewsPicks の Web Frontend Unit でエンジニアをしています、イイダユカコ（ @becyn ）です。
本記事は、Uzabase Advent Calendar 2021 21日目の記事です。
前日は nikkie さんによる『 イベントレポート | Tech BASE Okinawaに行ってきました！ #TechBASEOkinawa - nikkie-ftnextの日記 』でして、温かくアツい沖縄での tech イベントのお話でした。オフライン勉強会が恋しい！まだ読まれていない方は是非ご覧になってください！
本日は、NewsPicks のプロダクトを開発していく上で、チームで APM として New Relic を取り入れたので、紹介させていただきます。 本記事では、以下のような内容でお送りします。
- New Relic とは
- New Relic 導入に至った理由
- チームの想いと期待していること
-bilityに対する想い- おまけ: 導入がめちゃくちゃ楽だった件（
Install quickstartの紹介）
楽しんでいただけるとうれしいです！
- はじめに
- New Relic とは
- 私達のチームの現在地と New Relic 導入に至った理由
- チームの想いと期待していること
- -bility に対する想い
- おまけ: 導入がめちゃくちゃ楽だった件
- おわりに
New Relic とは
New Relic は「オブザーバビリティプラットフォーム」としてプロジェクトなどに導入される SaaS のツールです。
特に、プロダクト開発者自身がアプリケーションの状態を把握し対応するための APM（Application Performance Monitoring）を得意分野としているようです！
実は、数年前にも New Relic を経験する機会があったのですが、その時はどちらかというと Bugsnag 等を始めとする exception monitoring の立ち位置で認識していました。
今回久しぶりに触ってみたところ、その印象は全くなく、「システム全体の健全性を監視するためのツール」として確立されたように感じました。
気になった方は、この後のセクションで導入についても簡単に触れるので、是非お手元で触ってみてください。
私達のチームの現在地と New Relic 導入に至った理由
私達のチームの現在地
現在、私達 Web Frontend Unit では Web の新基盤開発を担当し、基盤実装と実際にユーザーが触れる画面の実装と移行作業を行っています。
下図でいうところの NEW ラベルがついている部分が私達の主な担当領域です。
詳細が気になる方は、Uzabase Advent Calendar 2021 8日目の記事 Next.js Update! 2021/11/24 に事例講演登壇者として参加しました！ - Uzabase for Engineers をご参照ください。
図の通り、私達の新基盤にのったページにユーザーがアクセスした場合、
- ALB で振り分け
- Web Server に request を送信
- GraphQL Server に request を送信
- NewsPicks Server（図中での表記は NP Server） に request を送信
- GraphQL Server に response を送信
- Web Server に response を送信
- ユーザーの client に取得結果を表示
といったフローで各 server とのやりとりが発生します。
そのため、新基盤導入前はすべて NewsPicks Server 内で完結していたのでそこだけを監視しておけばよかったのですが、今回構造に関連する Server が増えたことで、システム全体の健全性を保つため、複数個の監視が必要となりました。
New Relic 導入に至った理由
システム全体の健全性を監視するため、今回 APM として New Relic を 導入しました。
既存の NewsPicks Server に加え、 Web Server と GraphQL Server にも導入した形です。
New Relic ではそれらを追いやすく、導入しやすい形で tool が提供されているため、導入に至りました。
チームの想いと期待していること
Next.js Update! 2021/11/24 に事例講演登壇者として参加しました！ - Uzabase for Engineers や当日の登壇でも紹介したのですが、私達 Web Frontend Unit は NewsPicks Product Division 内の「Web 基盤屋」として発足しました。 自分たちだけではないメンバーも Web 基盤を触る機会がある中で、誰もが安心して開発ができる環境を用意する責務があります。 そのような中で、今回の APM としての New Relic 導入は欠かせない要素の一つでした。
チームに対して情報が open であること、環境ごとに値をチェックできること、Permalink でページを共有できること、1 request ごとの Transaction Trace を細かく見られること等全てが必要な機能で、その全てが New Relic にありました。
これらは、自身が所属している Unit だけではなく、組織やチーム全体でコミュニケーションをとる際にとても重要視されます。
実際に、新基盤をリリースした直後で一部重めの request が発生してしまっていたのですが、その調査にも早速 New Relic を使用させていただきました。 「どこが起因で、どこにアプローチするのが最短か」を自分のチームだけでなく、同 division 内の他 Unit のメンバーにも共有し、働きかけることを容易にしてくれました。
「ただのデータが載ったページの共有でしょ？」と思われるかもしれないのですが、 「調査担当者が事象を理解していても、それを他のメンバーに伝えることにコストを感じる」といった事象に覚えはないでしょうか？１からスクショを撮って説明文を追加するのがやや大変だったり、伝えるべき情報が漏れてしまったりする場合も往々にして発生します。
わかりやすくデータが描画されていて、そのページを URL 一つで共有できるのは実務面でとても頼もしかったです。
-bility に対する想い
「Web 基盤屋」として、product の品質を高く維持するため、Maintainability、 Testability、Accessibility 等 -bility を上げていくことが重要だと常々思っています。
この教えは、以前社内で @t_wada さんの講演で習ったことでもあります。
今回もその考えに則り、APM として New Relic を入れた際は、 「Maintainability（保守性）」 に着目して導入を決定しました。 しかし、実際に入れてみて、New Relic を推すポイントとしては「Understandability（理解性、理解のしやすさ）」にもあると実感しました。
チーム内でのコミュニケーションを円滑化し、実際起こった事象に向き合い、それをベースに課題を解決していくフローは、複数 project に New Relic を導入したからできたことだと感じました。
これからもユーザーと product に向き合い、より品質の高い開発体験をチームに提供し続けたいと思います。
おまけ: 導入がめちゃくちゃ楽だった件
以下のページは、New Relic を Node.js project に入れるための Instant Observability (I/O) のページです。
ページ内にある Install quickstart ボタンを押した結果、文字通りとてつもなく quick に導入できたのでおすすめです！
他の言語や環境については、以下よりお試しください。
おわりに
今回チームで New Relic の導入を行ったので、その内容とチームとしての思いを紹介させていただきました。
まだまだ「Web基盤屋」としてやらないといけないことは山ほどあります。
もし興味がある方は Twitter の DM など送っていただけるとありがたいです！是非ざっくばらんにお話しましょう！
最後まで読んでいただき、ありがとうございました！
明日22日目は、Podcast でもチームでもお世話になっている @go0517go さんです！ 明日もお楽しみにー！
