イオンスマートテクノロジー株式会社におけるNew Relicの導入効果をレビューでご紹介

参考になった

レビュー投稿日の情報になります

イオン株式会社 / Hikaru Saito

メンバー / インフラエンジニア / 従業員規模: 101名〜300名 / エンジニア組織: 51名〜100名

最終更新日2024/08/01投稿日2024/08/02

利用プラン

ツールの利用規模

ツールの利用開始時期

事業形態

Pro

51名〜100名

2022年8月

B to B

B to C

アーキテクチャ

アーキテクチャの意図・工夫

New Relic Agentで取得できないミドルウェアが一部存在するため、それらのメトリクスは Prometheusやtelegraf経由で取得している。

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

導入には2stepあった。

ローンチしたモバイルアプリのエラー調査や利用状況・エラー状況の可視化に苦労していたため、mobileでの導入を行った。
その後、mobileのみ利用し、backendは別のトレーシングツールを利用していた。その状況ではトレーサビリティに乏しく、障害調査もスムーズに進まないためNew Relic APMを導入を進めていった。

どのような状態を目指していたか

このモバイルアプリが動くためには複数のバックエンドサービス、複数のチームで構成されていたが、それを一つのプラットフォームで一貫して観測できる状態。

比較検討したサービス

mobileについては特になし
APMについては、既存のトレーシングツール(Azure Application Insight)

比較した軸

得られるアウトカム
コスト

選定理由

APMに強みがあること
mobileを起点にバックエンドまで統一的に観測することを目的とした場合、mobileでNew Relicを入れている時点で他にする理由が特にないこと

導入の成果

改善したかった課題はどれくらい解決されたか

ユーザの利用状況やエラー状況の可視化
クライアントアプリでのエラー調査が

どのような成果が得られたか

障害時の初動調査の改善（経験と勘から、データで語れるように）
New Relicを契機に開発チームが運用状況を気にするようになった（組織文化への貢献）

導入時の苦労・悩み

GOで作られたアプリケーションへの計装
既存のトレーシングツールから移行したのだが、それがW3C TraceContextに準拠しているため、一部にでも既存のトレーシングツールが残っているとTraceIDが上書きされてしまう。その結果うまくtraceができない事態が発生した。

導入に向けた社内への説明

上長・チームへの説明

バックエンドへのAPM導入前は、サービスやチームでバラバラのツールを利用しており、これを1つのプラットフォームに統一して観測することへの理解は抵抗なく得られていた。
障害調査や分析について定量的効果・定性的効果が実績として認められており、導入後に方向性を変えるようなフィードバックはない。

活用方法

開発チームで日々の調査や障害時に調査に利用
開発チームとSREチームで週次の定点観測会を行い、傾向的な変化の確認

よく使う機能

特に、Transaction機能はレスポンス劣化の時に有用だった。この機能により、すぐに原因を特定できることが多くなった。
また、平常時は定期的にSummaryに表示される内容を確認している。

Mobile

Errors in boxを定期的に確認し、傾向の変化や見慣れないエラーが新しく出ていないかを確認している。
ユーザのエラー調査がこの機能により格段に進む。

Kubernetes

iAEONアプリを支える大半のワークロードはKubernetes上で稼働しており、このKubernetsの状態をサクッと確認できるのがgood。

ツールの良い点

導入における設定が容易であること。

弊社で扱うアプリケーションのほとんどの言語ではドキュメントを読めばすぐに導入できるレベルだった。ただし、GO言語だけはかなり手間が要るので、スケジュールを立てる際は予め考慮する必要がある。

APMにより障害時の初動が格段に早くなった。複雑なシステム・チーム構成であればあるほど効果が高くなると考えている。

課金体系

ホスト単位で課金といった形ではなく、データ量とFull Platform Userライセンスの量で課金が決定する。どちらもプロダクトの成長、それに伴うチームの成長と相関があるので正しく運用していれば納得感を得やすい。

ツールの課題点

UIが突然変わる。
- New Relicに限った話ではないが、UIがアップデートされたタイミングで見慣れた情報がどこへ行ってしまったか、今までどのように該当の画面に辿り着いていたか分からなくなる。なお、後者はパーマネントリンク機能がリリースされたため辿り着くこと自体はできるようになった。しかし、同じ操作を二度とできる自信はない。
Full Platform Userライセンスの付与の難しさ
- 良い点で言及した課金体系の副作用となるが、Full Platform Userの費用が決して安くないため、どのメンバに付与するか頭を悩ませる。
- 「使いこなせる人に付与したいが、使ってみないと使いこなせるかわからない」というジレンマに陥る。とはいえ、コスト的に開発者全員にFull Platform Userライセンスを付与することができる企業は多くないため、現実的には各プロダクト開発チーム内で徐々に広げていくスタイルが良いと考えている。

ツールを検討されている方へ

モニタリングやオブザーバビリティの文脈全般に言えるが、チーム間（アプリケーション開発チームとインフラチーム、など）で異なるツールを使う状況は避けた方が良いと考える。異なるチームであっても一つのプラットフォームで同じものを見るという状態に持っていくことが大切。
使用する技術スタックによっては、New Relic Agentではメトリクスを取れないためPrometheusなどを利用するケースがある。Prometheusで取得できるメトリクスは膨大のため、New Relicにingestされるデータ量が大きくなり課金に影響しがち。予めフィルタリングを行う覚悟が必要。それに限らず、データ量をモニタリングし、多い場合は対策を都度打つという運用は必要になるので予め想定しておくことを推奨する。
New Relicの力を発揮するためには、従来の監視ツールのようにSREチームや運用チームのモノといった立て付けにせず、開発者が利用することを中心に考慮した方が良い。そして、新しいツールは操作に慣れるまでが非常に大変。根気強く勉強会や気軽に質問をできる環境を整えて、新規利用者のハードルを下げる努力をすることを推奨する。
ツールの課題点の繰り返しになるが、Full Platform Userライセンスの付与に頭を悩ませることが多いため、どのように組織内にライセンス付与を展開していくか計画しておくこと。予算策定の時期にはこの情報が必要となる。