APMを見たことも触ったこともないエンジニアがNRUG沖縄支部 Vol.0に参加してみた

この記事は New Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2023 シリーズ ３ の ９ 日目の記事です。

TL;DR

筆者が NRUG (New Relic User Group) のイベントに参加して得た経験を共有します。
イベントを通じて「New Relic を実際に使って見たい！」という衝動に駆られ、とにかく勢いでアドベントカレンダーに応募しました。 ※ Tsuyoshi Shimizu(@photographed) さんにも背中を押していただきました。感謝。

はじめに

本記事を読む上で必要な前提知識を私の理解で記載していきます。
APM 初心者なので理解に誤りがありましたらご了承ください。

APM (Application performance management)

アプリケーションパフォーマンス管理の略称で、システムの可用性を監視して最適化するツールや手段を指します。
New Relic は APM ツールの一種で、クラウドサービスを展開しています。

New Relicは、よりよいソフトウェアの構築に役立つオブザーバビリティプラットフォームです。あらゆるデジタルソースからデータを取り込むことができるため、システムを完全に把握し、そのデータを効率的に分析し、インシデントが問題になる前に対応できます。

引用：New Relicの使用開始

NRUG (New Relic User Group)

New Relic ユーザーグループです。（読んで字の如く）
最近、NRUG史上初のローカル支部が沖縄に設立されたようです。
今回参加したイベントは沖縄支部として記念すべき最初のイベントで、飛び入り参加できて光栄でした。見るだけ参加ではありましたが。
NRUG沖縄支部 (New Relic User Group) Vol.0 NR社員来沖予定！＠那覇

本イベントを知ったのは、前職で直属の先輩だった沖縄支部長の 座喜味圭佑(@zackman_x) さんに誘われたのがきっかけです。

イベントのハイライト

個人的なハイライトを記載していきます。
togetterにイベントの様子がまとめられていますので こちら もご確認ください。

問題解決に向けて人力でやっていたあれこれ

個人的にもっとも印象的だったのが Tsuyoshi Shimizu(@photographed) さんの発表。
インフラエンジニアの視点から問題解決に貢献したいという熱い思いが53枚のスライドに盛り込まれていました。

響いたものは沢山あリましたが、まとまらなさそうなので三点に絞って紹介することにします。

ぜひ原本もご確認ください。（引用の許可をいただきありがとうございます！）
引用：インフラエンジニアのためのNew Relic APM活用のキホン by New Relic 清水 毅 さん

1. ログ分析ファーストの時代は終わった

この一言は衝撃でした。

問題解決に向かうフローがとにかくわかりやすい一枚です。
まず、「問題の発生確認」で、どの領域で問題が発生しているか、検討がつきます。
（処理時間の内訳： 水色 → PHP 、 橙色 → MySQL 、 緑色 → 外部サービス）
さらに「問題のAPI特定」で API を特定し、「原因特定」で対象の SQL を特定、実際に出力されたログも見ることができます。

新人の時から「まずはログを見ろ」と叩き込まれてきた当たり前が崩壊しました。
エンジニアはログという大量の情報の中を大航海しなければならず、障害対応はまさに腕の見せ所、というイメージだったのですが、これがあれば視覚的に原因を絞っていくことができそうです。

2. テスト環境で遅いと本番ではもっと遅い

これだけだと当たり前ですね。
何が言いたいかというと、だからこそテスト環境でも活用するべきという話です。目から鱗でした。

これまでの経験から、環境が異なるのでテスト環境ではレスポンスは測れない、なのでテスト環境で性能試験をする意味はあまりない、というのが常識だと思っていました。
Jmeter を駆使して大量のリクエストを投げたことはありますが、準備に手間がかかる割に保証できたとは言えない、結果をどのように扱えば良いかもいまいちわからない、というイメージがありました。

しかし、この言葉を聞いて、最低でもテスト環境ではパフォーマンスを発揮できている必要があるという観点であれば、やる意味はあると気づきました。
結果をどのように扱うかわからない問題も解決できそうです。

さらに、New Relic はユーザー課金（利用する環境の増加自体では課金されない料金体系）なので、テスト環境でも活用しないと勿体無いとのこと。確かに。

3. システムのサービスレベルを聞かれて答えられますか？

ハッとしました。答えられません。
「XXの機能は悪いかもしれません、他はそこまで問題ないと思います。」ぐらいの回答が精一杯です。

New Relic では機能単位で品質指標を観測できるようです。
これがあれば胸を張って具体的な回答ができそうです。
また、問題検知・改善はもちろんのこと、ビジネス指標にも大いに役立ちそうです。
マーケ部と話す時に便利そう。

実際の活用事例

文量が多くなってきたので、登壇資料のリンクとちょっとした感想を載せておきます。
本当はもっと書きたいのですが、我ながらくどいなと思ったので遠慮しておきます。

• バージョンアップ作業でのNewRelic活用事例
  • テストフェーズでの利用事例でした。コミュニケーション面でも効果的だったそうです。
• Enterprise Cloud Service運用での 利用概要と自己紹介 ドリーム・アーツ渡邊
  • New Relic のメリデメ紹介でした。沢山の要望が真摯に向き合ってる結果だと思います。
• 監視基盤をNew Relicファーストにした理由 by サーバーワークス 大城慶明
  • DataDog から New Relic に移行した話でした。 移行中のリアルな話で良かったです。
  • うちなーぐちは全然わかりませんでした。笑

結論と今後の目標

とにかく使ってみたいです。
最も気になるのは導入コストなのですが、やってみなければわからない、ということで無料枠で色々と試したいと考えています。
次は何かしら発表したいとも思っているので、LT登壇を目標に少しづつ始めていきます。

最後まで読んでいただきありがとうございました！
興味があれば他のブログも読んでみてください。