New Relicの導入効果をレビューでご紹介(株式会社MIXI-Isao Shimizu)

参考になった

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

株式会社MIXI / Isao Shimizu

EM / EM / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名

最終更新日2024/05/01投稿日2023/11/10

利用プラン	ツールの利用規模	ツールの利用開始時期
New Relic One Pro	11名〜50名	2014年

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

導入背景

家族アルバムみてねの黎明期（2014年）
- Amazon CloudWatchでは、インフラのモニタリングにしかならない状況で、アプリケーションのモニタリングが全然できていなかった。
- New Relic APMはRuby との相性がよく、導入がスムーズであった
- APMという言葉が聞かれるようになったタイミングで、サーバー台数ごとに課金される状態
- パフォーマンス劣化やエラーの原因を探るのに活用できるのではないかという思いで導入
New Relic Infrastructure/Mobileの導入（2018年）
- 海外ユーザーの体験を知ることを目的に導入

比較検討したサービス

特になし。当時はRubyとの相性がよくあまり競合のサービスもなかったため

比較した軸

オブザーバビリティのツールを比較する際のポイント

自社の課題を解決できるかという点は検証されていることが前提で以下をポイントとしてみています。

APMの言語の対応状況・安定性
- 導入したことによってパフォーマンスが落ちるツールもあるため
料金形態
- データ量に応じた課金は合理的だが、台数ベースの課金などは要検討
世の中でどのくらいそのサービスが使われているかどうか
- 世の中における知見の多さやコミュニティがあるかどうかは大事な観点

選定理由

New Relic Mobile、New Relic Infrastracture を導入したのは、New Relic APMを元々活用していたため
料金形態も台数課金からNew Relic Oneという価格設計によってシンプルにデータの取り込み量×ユーザー数になったのも継続している理由

導入時の苦労・悩み

モバイルはiOSとAndroidのコーディングをしないといけないのでモバイルの開発知識が必要となり少し苦労した部分ではあるが、それ以外ではそこまで大変だった部分はなかった。

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

経営陣・上長への説明

決して安いものではなかったが、従来は負荷が上がるようなイベントがあるタイミングで少なからず障害が起きていた。それをみていたビジネスサイドも必要性を理解していたので、そちらが改善できることで比較的スムーズではあったように思う。

実際に当時と比較して導入後の状況は大きく改善していること、APMによって負荷対策を実践できているため導入の効果は大きい。

費用対効果の算出

特に毎年の更新において費用対効果を細かくは算出していないです。サービス自体は従量課金なので、みてねのサービスが大きくなり、トラフィック量も多くなればコストも上がります。全データをNew Relicに流しているというよりはサンプリングを適切に行うことで、コストを調整しています。

活用方法

よく使う機能

APMのトランザクション
- APIのレスポンス・スループットのランキングを確認、また、非同期のジョブのスループットを確認している。また、データベースのクエリを見ることで、どこのクエリが遅いのかを確認している。
New Relic アラート
- アラートが起きたときにアラート画面を確認
- 運用しているPrometheusで収集しているメトリクスをNew Relic側に任せることができるのでアラートの冗長化を持たせることができ、可用性を担保できる。
- アラート機能を自前で運用するというのは厳しいため外部に出しているが、アラートのサービスが不安定となってしまっては元も子もないので、アラートの機能に信頼がおけているのは良い。
New Relic Browser
- みてねというサービスではネイティブアプリでの機能の提供が大半を占めており、Web版の機能が多くはないため、あまり使う機会は多くないが、ユーザーがどう活用しているのか、バグがあったときの監視、対応にて活用している。

アーキテクチャ

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

New Relic APMを活用しつつ、インフラやKubernetesのメトリクスについてはPrometheusを活用することで、New Relicのデータ転送量を抑えつつ、Grafanaによってインフラの各種メトリクスを統合的に可視化することができている。アプリケーションのログはGrafana Loki、その他ログはAthenaやBigQueryを活用しコストパフォーマンスの面で最適化をしている。

ツールの良い点

APMを重宝している
- アプリケーションの負荷対策において何度もボトルネックを発見して改善につながっているためとても価値が高い。
- NRQL（New Relicクエリ言語）を書くことで、細かく分析ができたり、ダッシュボードの作成をすることができる。
- 今後もサービス規模が大きくなるにつれてデータベースの改善が頻度高く必要になってくるので継続的にAPMを活用していく予定。
導入が手軽なところ
- 言語によって差があるかもしれない（Rubyは手軽、Goは少しだけ手間がいるかもしれない）が、ドキュメントが充実していることとサポートしてくれるため基本的に難なく導入を推進することができる。
統合的に見れるコンソールがあること
- 細かい点で改善点はあるものの、状況を可視化できる点
- アプリケーションの挙動を知る方法としては、ログがキーになるが、個別のエラーログをS3などに送ることもメンテナンスコストが高くなりがちであったり、転送がうまくいかずログが欠損し、挙動が掴みきれないということが起きてしまう可能性があるため、New Relicを通して分析できる基盤があることはとても良い。

ツールの課題点

コンソール（WebのUI）には洗練の余地がある
- すでに色々と改善されているけれども、まだよく分かりづらい部分がある。例えば、APMの画面から階層深く分析することができるが、深く行けば行くほど、迷子になってしまうときがある。また、ここを押したら何が起きるかなど想像がつかないときがある。長く使っている人は良いが、新しく使い始めた人はどこに何があるか一目ではわからないということもある。
操作感が重い
- UI 操作感が重い感じがする、もっと高速に遷移・表示することができたらもっといいなと思う
ここでこの設定できないという画面がある
- APMのトランザクション画面、APIごとのトラフィック時間を見れる画面において、APMのトランザクションの期間設定をしたあとに、個別のAPIを見にいくためブレイクダウンすると、APIの詳細画面においては期間設定ができない。例えば、期間設定にて直近30分を設定すると個別APIの画面では30分固定になってしまい、1時間でみたいときには一度戻って設定しないと変えられない仕様が気になっている。

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

いきなり全て入れるのはコストがかかってしまうので、小さく始めてコストインパクトを抑えて導入するのがベストプラクティスだと思います。そこから価値を感じてユーザー数が増えることによるメリットを出して段階的に進めていくのが良いと思います。注意点としては、データ量は定期的にきちんと確認した方が良いでしょう。むやみやたらにデータを流し込んでもお金はかかってしまうので、気をつけるべきです。データが多い方がオブザーバビリティの観点では良いが、逆にデータ量が多すぎて活用できてないと勿体無いので、データ量は抑えつつ成果を出せるように計算して利用するのがコツです。

株式会社MIXI / Isao Shimizu

EM / EM / 従業員規模: 51名〜100名 / エンジニア組織: 11名〜50名

新卒でSIerにて受託開発、プロダクト開発を担当。2011年8月に株式会社ミクシィ（現MIXI）入社。SNS「mixi」の運用チームにて、デプロイの改善、インフラの改善に従事。その後、モンスターストライクのSREを経て現在は家族アルバムみてねの基盤開発グループマネージャーを務める。