New Relicの導入効果をレビューでご紹介(筋肉CTO)
参考になった
2
筋肉CTO
CTO・VPoE / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 |
|---|---|---|
New Relic One Pro | 11名〜50名 | 2014年 |
| 利用プラン | New Relic One Pro |
|---|---|
| ツールの利用規模 | 11名〜50名 |
| ツールの利用開始時期 | 2014年 |
アーキテクチャ
アーキテクチャの意図・工夫
New Relic APMを活用しつつ、インフラやKubernetesのメトリクスについてはPrometheusを活用することで、New Relicのデータ転送量を抑えつつ、Grafanaによってインフラの各種メトリクスを統合的に可視化することができている。アプリケーションのログはGrafana Loki、その他ログはAthenaやBigQueryを活用しコストパフォーマンスの面で最適化をしている。
導入の背景・解決したかった問題
導入背景
- みてねの黎明期（2014年）
- Amazon CloudWatchでは、インフラのモニタリングにしかならない状況で、アプリケーションのモニタリングが全然できていなかった。
- New Relic APMはRuby との相性がよく、導入がスムーズであった
- APMという言葉が聞かれるようになったタイミングで、サーバー台数ごとに課金される状態
- パフォーマンス劣化やエラーの原因を探るのに活用できるのではないかという思いで導入
- New Relic Infrastructure/Mobileの導入（2018年）
- 海外ユーザーの体験を知ることを目的に導入
比較検討したサービス
This is XSS
選定理由
- New Relic Mobile、New Relic Infrastracture を導入したのは、New Relic APMを元々活用していたため
- 料金形態も台数課金からNew Relic Oneという価格設計によってシンプルにデータの取り込み量×ユーザー数になったのも継続している理由
導入に向けた社内への説明
上長・チームへの説明
決して安いものではなかったが、従来は負荷が上がるようなイベントがあるタイミングで少なからず障害が起きていた。それをみていたビジネスサイドも必要性を理解していたので、そちらが改善できることで比較的スムーズではあったように思う。
実際に当時と比較して導入後の状況は大きく改善していること、APMによって負荷対策を実践できているため導入の効果は大きい。
費用対効果の算出
特に毎年の更新において費用対効果を細かくは算出していないです。サービス自体は従量課金なので、みてねのサービスが大きくなり、トラフィック量も多くなればコストも上がります。全データをNew Relicに流しているというよりはサンプリングを適切に行うことで、コストを調整しています。
活用方法
よく使う機能
APMのトランザクション
- APIのレスポンス・スループットのランキングを確認、また、非同期のジョブのスループットを確認している。また、データベースのクエリを見ることで、どこのクエリが遅いのかを確認している。
ツールの良い点
APMを重宝している
- アプリケーションの負荷対策において何度もボトルネックを発見して改善につながっているためとても価値が高い。
- NRQL（New Relicクエリ言語）を書くことで、細かく分析ができたり、ダッシュボードの作成をすることができる。
- 今後もサービス規模が大きくなるにつれてデータベースの改善が頻度高く必要になってくるので継続的にAPMを活用していく予定。
ツールの課題点
コンソール（WebのUI）には洗練の余地がある
すでに色々と改善されているけれども、まだよく分かりづらい部分がある。例えば、APMの画面から階層深く分析することができるが、深く行けば行くほど、迷子になってしまうときがある。
また、ここを押したら何が起きるかなど想像がつかないときがある。長く使っている人は良いが、新しく使い始めた人はどこに何があるか一目ではわからないということもある。
その他
オブザーバビリティのツールを比較する際のポイント
自社の課題を解決できるかという点は検証されていることが前提で以下をポイントとしてみています。
- APMの言語の対応状況・安定性
- 導入したことによってパフォーマンスが落ちるツールもあるため
- 料金形態
- データ量に応じた課金は合理的だが、台数ベースの課金などは要検討
- 世の中でどのくらいそのサービスが使われているかどうか
- 世の中における知見の多さやコミュニティがあるかどうかは大事な観点
ツールを検討されている方へ
いきなり全て入れるのはコストがかかってしまうので、小さく始めてコストインパクトを抑えて導入するのがベストプラクティスだと思います。そこから価値を感じてユーザー数が増えることによるメリットを出して段階的に進めていくのが良いと思います。注意点としては、データ量は定期的にきちんと確認した方が良いでしょう。むやみやたらにデータを流し込んでもお金はかかってしまうので、気をつけるべきです。データが多い方がオブザーバビリティの観点では良いが、逆にデータ量が多すぎて活用できてないと勿体無いので、データ量は抑えつつ成果を出せるように計算して利用するのがコツです。
筋肉CTO
CTO・VPoE / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
よく見られているレビュー
筋肉CTO
CTO・VPoE / CTO / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法