この記事は、New Relic Advent Calendar 2024 の 19日目の記事になります。

はじめに

こんにちは！エイチームライフデザインの後藤です。

私は基盤技術グループという組織横断型チームに所属しており、最近は主に「オブザーバビリティ向上」に取り組んでいます。📈

本記事は NRUG 名古屋 Vol.0 での登壇スライドの内容をベースに、New Relicを活用したオブザーバビリティ向上の取り組みを紹介させて頂ければと思います。☺️

登壇スライド: New Relicを活用したシステム監視の強化とオブザーバビリティ向上 - Speaker Deck（P24〜37）

背景

なぜ、オブザーバビリティを向上させたいのか

主に、以下の問題を解決したいからです。

トラブルシュートしづらい問題
トラブルシュートがベテランエンジニア頼りになりがち問題

「トラブルシュートしづらい問題」

事業成長と共にシステムが肥大化・複雑化してしまい、一部システムで全体の見通しが悪くなっている場合があります。
見通しの悪さは、トラブル発生時に "トラブルシュートがしづらい" ことにも繋がってしまい、MTTI（平均調査時間）、MTTR（平均修復時間）等への影響も避けられません。
またそれらの数値の悪化は、開発生産性の低下はもちろん、"ユーザー体験の損失" や "ビジネス上の機会損失" にも繋がりかねません。

「トラブルシュートがベテランエンジニア頼りになりがち問題」

また、トラブルシュートが経験豊富なベテランエンジニアに偏りがちな問題もあります。
これは原因の特定がしづらい状態も加担していると考えますが、システムに対して豊富な知識を持ち、豊富なトラブルシュート経験を持つベテランエンジニアにどうしても対応が偏りがちです。

問題が深い場合、ベテランエンジニアでも解決に時間を要してしまう場合もあります。

オブザーバビリティというより、システムの問題なのでは？

...もちろん、上記の問題はシステム自体やその他にも原因はあると思っています。
じゃあシステムの改修を...と行きたいところではありますが、そう簡単には進められない現実もあります。

また運用面では、従来のモニタリングをベースとした運用を行っていました。

オブザーバビリティの向上によって解決できる問題なのか？

一定は「できる！」と思っています。

書籍「オブザーバビリティ・エンジニアリング」の記載を引用させていだたきます。

「オブザーバビリティ」とは？「オブザーバビリティが高い状態」とは？

“システムがどのような状態になったとしても、それがどんなに斬新で奇妙なものであっても、どれだけ理解し説明できるかの尺度です。（中略）
もし、新しいコードをデプロイする必要がなく、どんなに斬新で奇妙な状態でも理解できるなら、オブザーバビリティがあると言えます。”

引用元：「オブザーバビリティ・エンジニアリング - 1章オブザーバビリティとは？」

「オブザーバビリティを実践している場合のデバッグ」とは？

“モニタリングベースのアプローチでは、年功序列が知識への鍵であるという考えに基づいて、チームが方向づけられることがよくあります。チームに最も長く在籍しているエンジニアが、チーム最高のデバッガーであり、最後の砦のデバッガーとなることが多いのです。
（中略）
逆に、オブザーバビリティを実践しているチームは、根本的に違う方向に傾きます。オブザーバビリティツールでは、チーム内の最高のデバッガーは、通常、最も好奇心の強いエンジニアです。”

引用元：「オブザーバビリティ・エンジニアリング - 2章オブザーバビリティとモニタリングにおけるデバッグ方法の違い」

このオブザーバビリティの考え方からも、現状の問題を解決する打ち手として「オブザーバビリティの向上」は理に適っていると考えられますし、オブザーバビリティが向上した際には問題が一定解決できている姿もイメージできます。

なぜNew Relicなのか

今回改めてオブザーバビリティ製品を選定したわけではなく、以前からNew Relicを活用していたため、選定理由等は特にございません。🙇‍♂️

...で終わってしまうと面白くないため、「取り組みを通して再発見したNew Relicのいいところ」を後述します。😉

進め方（導入）

オブザーバビリティ向上の取り組みを、どのように進めてきたかをご紹介します。

以下を基本的な方針として定め、取り組みを進めました。

小さくはじめて、大きくしていく
まずはNew Relicの基本機能を導入し、正常に動作させる

方針1：「小さくはじめて、大きくしていく」

システムを構成する全てのコンポーネントに対して、計装のためのエージェントを一気に導入するのではなく...

計装を追加 → New Relic上での見え方を確認 → 計装を追加

のように、

導入対象を選定して計装を追加
軽装を追加した後の状態を確認する
確認した結果をもとに、次に計装を追加する対象を選定する

を繰り返しつつ、段階的に軽装を追加していきます。

「2. 軽装を追加した後の状態を確認する」について補足すると、

Service mapでの可視化状態
Distributed tracingでのトレースの繋がり（トレースコンテキストの伝搬）の状態

等を確認しています。確認した上で、

Service map上で External service と認識されているエンティティ
Distributed tracingではトレースの繋がりが確認できないが、システムレベルでは繋がっているはずのもの

を見つけつつ、次に計装を追加する対象を選定します。

イメージ：Service map上でExternal serviceとして認識されているエンティティ

上記の流れで、ひとまずは "Observability成熟度モデル" の "成熟度1: Reactive" な状態を目指すことにしました。

引用元：監視からオブザーバビリティへ〜オブザーバビリティの成熟度/From Monitoring to Observability - Maturity of Observability - Speaker Deck

小さく始める理由は、以下によるものです。

計装の知識が薄い
「求めるオブザーバビリティの高さ」「オブザーバビリティを向上させるための道のり」が不明確
システムへの影響、コストを確認しつつ慎重に進めたい

理由1：「計装の知識が薄い」

今までもNew Relicは活用していましたが、計装を追加するといった観点では、用意されているエージェントをそれとなく導入しているだけに留まっていました。
（もちろん、それだけでも豊富なデータは収集可能です。）

いざしっかり計装していこうとなると、

New Relicから提供されているエージェントのみで対応できるのか？
はたまたOpenTelemetryモジュールが必要なのか...？

と、さっぱりな状態でした。
「小さくはじめて」の方針であるため、最初から「こうしていこう」とは決めきらず、計装の追加を繰り返していく過程で意思決定をしていくことにしました。

また最初の段階では、「まずはNew Relicの基本機能（エージェント等）を導入し、正常に動作させる」といったゴールを置きました。

理由2：「求めるオブザーバビリティの高さ」「オブザーバビリティを向上させるための道のり」が不明確

オブザーバビリティには上限がありません。（※参考）
理想の状態を考えれば考えるほどドツボにハマっていることに気がつき、いつまで経っても先の見通しを立てられません。
いわば「正しく悩めていない」状態でした。

なので、理想の状態を描きつつ少しずつ計装を追加し、さらに必要なテレメトリデータを取得するための計装を考え、次へ次へと進んでいくことにしました。

参考：オブザーバビリティには限りがない話 – JUMPERZ.NET Blog

理由3：システムへの影響、コストを確認しつつ慎重に進めたい

計装を追加することで、以下の問題が生じます。

計装自体がシステムのパフォーマンスに少なからず影響を与える
New Relicへのデータ転送コストが増加する

システムパフォーマンスへの影響を計測

システムパフォーマンスへの影響（オーバーヘッドの発生）は、ドキュメント上では微々たるものであると記載されています。

参考：
ブラウザのモニタリングとパフォーマンスへの影響 | New Relic Documentation
インフラエージェントのオーバーヘッド | New Relic Documentation

しかし、パフォーマンスの悪化はユーザー体験の悪化に繋がり、ユーザー体験の悪化は事業に影響してしまいます。
また、実際に自社のシステムに導入してみないことには、影響は計り知れません。
たとえ杞憂に終わったとしても、実測値ベースで確認しつつ進めていくことにしました。

計測は、以下のような方法で行いました。（一例）

呼び出し元のアプリケーションに導入しているAPMにて、呼び出し先へのDurationを確認する
（外部から到達可能な場所は）Synthetic Monitorを用いて定点観測し、パフォーマンスデータを確認する

データ転送コストの計測

データ転送コストについても、無視できません。
New Relicのデータ転送コストは $0.35/GB （2024/12/19時点）と非常に安価ですが、継続的に発生するコストであるため、意識しておきたいところです。

データ転送コストは Data Management UI で確認できます。
より確認しやすくするためダッシュボードを作成し、計装を追加した都度確認しています。

確認は手間ではありますが、「なにをどうすると、どのデータ転送量が増えるのか」の理解が深まったのは収穫でした。

イメージ：作成したダッシュボードの一例

おまけ：「小さく始める」はアンチパターン？

オブザーバビリティ向上の取り組みと並行して、チーム内でオブザーバビリティ・エンジニアリングの輪読会を開催していました。

第10章に以下のような記述があります。

新しい技術の導入にはリスクがつきものです。そのため、新しい技術への取り組みは、小規模で目立たないサービスをスタート地点にすることが多いようです。直感に反して、オブザーバビリティにおいて、小さく始めることは、人々がしばしば犯す大きな過ちのひとつです。
オブザーバビリティツールは、捉えどころのない問題を素早く発見するために設計されています。目立たない、比較的重要でないサービスから始めると、オブザーバビリティの価値を証明するのと正反対の効果になってしまいます。もし、すでに比較的うまく機能しているサービスから始めると、チームはオブザーバビリティを始めるために必要なすべての作業を経験し、なんのメリットもえられないことになります。

ここでは、
小さく始めること＝小規模で目立たないサービスをスタート地点にすること
とされています。

確かに、小さく始めていくことで少しずつ効果を感じてはいますが、価値を証明するには効果が薄いなと感じる時もあります。こに感覚はまさに、この記述の通りです。

おっしゃる通りです！！！...と言いたいところですが、個人的にはケースバイケースかなと思っており、弊社の場合においては「小さく始める」方針で良かったかな、と思っています。
オブザーバビリティツールによって得られる効果はありつつも、多少なりとも影響があることは事実だからです。
その影響は、結局のところ事業に影響してしまい、事業への影響が大きくなってしまっては、オブザーバビリティ向上の取り組みへの理解を得ることは難しくなってしまうため、小さく、かつ慎重に始めています。

方針2：まずはNew Relicの基本機能を導入し、正常に動作させる

基本機能とは、以下を指します。（一例）

APMエージェント
Browserエージェント
Distributed tracing
Infrastructureエージェント（Cloud, Middleware, OS...）

これらをまずはきちんと導入し、正常に動作している状態を目指します。
正常に動作している状態とは、以下のような状態です。（一例）

テレメトリデータが取得され、New Relicに転送されている
取得したテレメトリデータによって、意図した通りシステムの動作状態が可視化できている
Distributed tracingによって、トレースのつながりが可視化できている
Service map上で、エンティティ間の繋がりが表現できている

これらを対応issueの受け入れ基準に明記し、受け入れ基準を満たせない場合（正常に動作していない状態）は別途調査を行うなどし、理想の状態に向けて導入を進めていきました。

進め方（展開）

オブザーバビリティを向上させたら、はい終わり！ではありません。
我々は組織横断型のチームであるため、実際にNew Relicを活用する開発チーム（ストリームアラインドチーム）に展開するところまでがお仕事です。

開発チームへの展開

「はい、どうぞ！」と渡すだけでは、活用されにくいと思っています。
なぜなら...「オブザーバビリティ」の概念・考え方はもちろん、オブザーバビリティツールである「New Relic」においても、多機能ゆえに難しく、学習コストがそれなりに高いからです。

せっかくオブザーバビリティを向上させても、活用してもらえなければ効果は現れません。
なので「基礎知識の習得」と「実践的な知識の習得」の二段階に分け、オンボーディングを実施することにしました。

オンボーディング

基礎知識の習得

用意した自習コンテンツをもとに各自自習をしてもらい、自習完了後にフォローアップのための勉強会を開催する流れにしています。
勉強会では、理解度の確認や質疑応答の受け付けを行っています。

また、着実に知識を身につけてもらうためにも一気に知識習得を行うのではなく、自習と勉強会を数回に分け、各回にゴールを設定するようにしました。

イメージ：オンボーディング用の自習コンテンツ

学ぶ内容は、New Relicの活用状況と直近で目指しているゴールを鑑みて、以下に絞りました。

オブザーバビリティとは？
New Relicとは？APM, Browserについて知る
Logs, Infrastructure, Synthetic Monitorについて知る
NRQLについて知る

実践的な知識の習得

New Relic株式会社様ご協力のもと、座学かつハンズオンを行う勉強会を開催して頂きます！
この勉強会は、自習によって習得した知識をより実践的なものにすることが目的です。

またこの勉強会以外にも、定期的にNew Relicを見る会を設定するなど、アフターフォローをしつつ更なる活用を後押ししていく予定です。

取り組みを通して再発見！New Relicのいいところ

個人的に、New Relicはオブザーバビリティツールの中で最も好きなプロダクトです。
オブザーバビリティ向上の取り組みを通して、改めて「いいな！」と思ったポイント、すなわち推しポイントを紹介させていただきます。

コストの見積もりがしやすい！

オブザーバビリティにはお金がかかります。オブザーバビリティとコストは切ってもきれない関係です。
そういった性質を持つオブザーバビリティだからこそ、コストの見積もりがしやすいことは重要だと考えます。

New Relicの課金項目は、

ユーザー数
データ転送量（New Relicへの取り込み量）

の2つと非常にシンプルで、このシンプルさが見積もりのしやすさにも繋がります。
お金がかかるオブザーバビリティにおいて、コストコントロールや、コスト面での計画の立てやすさに繋がると思っています。

また、True-upモデル という料金モデルもオブザーバビリティの性質に非常に合っていると思います。
どれだけ計装を追加したら、データ転送量はどれほどになるのか？の予測は立てづらいです。
しかしTrue-upモデルであれば、契約量を超過してしまった場合でも即座に追加のコストが発生するわけではなく、一定の期間連続して超過した場合に、

追加分として費用を支払うのか
超過している分のデータ転送を止めるのか

の選択が可能になります。

New Relic の価格の考え方は、いわゆる自動従量課金による Bait & Switch モデルではありません。年間契約消費型による True-Up モデルです。
（中略）
一方、New Relic が採用する年間契約消費型モデルでは、事前に年間で消費予定の量だけを購入し、その消費量を超えた場合は、改めて調整費用として追加するのか止めるのかを判断することができるモデルです。New Relic では契約以上の自動請求が突如行われるようなことは発生しません。

引用元：New Relic の新しい製品体系と価格体系

サポートが手厚い！

サポートチケットを日本語で起票できるだけでも十分にありがたいのですが、なんと追加料金なしで TAM (Technical Account Manager) をアサインしていただけることが非常に魅力的です。
TAMによるサービスメニューによって、社内で勉強会を開催して頂けたり、導入のサポートをしていただけるなど、幅広いサポートを受けることができます。

そういったサポートを受けられるか否かは導入時のスピード感にも繋がりますし、我々が本来集中したいことに集中できるようにもなります。

学習コンテンツが豊富！

New Relic University (NRU) はご存知でしょうか。
New Relicを利用する上で習得しておきたい知識は、こちらのコンテンツでキャッチアップすることが可能です。

弊社でも、このコンテンツを自習コンテンツとして開発チームに推薦しています。
開発チームのエンジニアはNRUを観つつ、各自自習を進め、知識習得しております。

さいごに

New Relicを活用したオブザーバビリティ向上の取り組みを紹介させていただきました。
技術的な話、New Relicの機能等の話は殆どできませんでしたが...それはまたいつか、別の機会で！

弊社のオブザーバビリティの旅は始まったばかりです。
また今後、どこかの場でアウトプットできればと思います。