New Relicで開発者体験を上げていくための意思決定

ツール導入前の課題

負荷の高い既存サービスの運用作業と、リアーキテクトプロジェクトの並行進行による課題とリスクがありました。

既存サービスの運用課題

• サービス同士の通信をコードから追う辛さ
• レガシーコードに夜認知負荷の高さ
• システム知識の属人化

リアーキテクトプロジェクトのリスク

• デプロイ失敗率が高いままでのプロジェクト完遂までのリリース回数増加
• システムの本質的複雑性は上がる一方
• 遅延したときに、既存サービスの苦しい運用がその分継続される

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

運用負荷の軽減とデプロイの品質担保をすることで、開発生産性を高めていくことを目指しています

開発生産性＝テクノロジー投資戦略×開発者体験
という観点で開発者体験を上げられるような取り組みを、オブザーバビリティを通して行おうとしています。

• システムの内部構造の可視化される状態
• リリースに夜システムの変化が観測しやすい状態
• 対応が必要なアラートだけが通知される状態
• SLOの運用によって、機能開発と運用のコントロールがしやすい状態

• Datadog
• OpenTelemetry

• APMやRUMの機能によってシステムの状態がどのくらい可視化されるか
• メンバーヘのオンボーディングのしやすさ
• 導入コスト

サポート体制

月１で勉強会やハンズオンの開催、Slackで随時担当エンジニアと相談できる体制など

課金体系

ユーザーライセンス数中心の課金体系なので、サービスの拡大による課金増加ペースが抑えられます。
弊社の開発部が、一気に人数を増やす段階でもなかったことも考慮事項に含んでいました。

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

システムの内部構造の可視化

導入を希望するチームも多く、半年で30システムにAPM、RUM含めて導入することができました。

アラート品質

導入当初からSeverityがCriticalのアラート通知数が４割削減されました。

社内事例

• パフォーマンスのボトルネックを特定して解消し、コンピュートリソースを1/4に削減
• ユーザーがフォームのバリデーションに引っかかっている回数を計装
• フォームのポスト実行時にトレースIDと実行ログをNew　Relicに転送することでユーザーアクティビティの可視化

各システムそれぞれの言語やフレームワークへの計装

ある程度統一されていたものの各システムに導入するのは、ボタンポチッで済まない場合もあって調査しながら導入を進めないといけない場面もありました。
特にフロントエンドは、起動コマンドや使用しているライブラリ、ロガーが各システムで違ったりしていたので気をつける必要がありました。

既存の運用の引き継ぎ

オブザーバビリティを導入するからといって、既存のモニタリング運用をまるっと変えるわけにはいかないので既存のアラート設定やログ通知などカスタマイズしながら設定していきました。
それまではメトリクスとログ中心のアラート設定で、アラートの評価期間やログの通知の仕方はNewRelicと既存ツールとの違いを理解しながら進める必要がありました。

まず、オブザーバビリティを導入するかを事業とシステム戦略に沿って検討していくと後々のスピード感が違ってくるかなと思います。

オブザーバビリティを大きなシステム群に入れていく場合はどうしてもコストがかかってしまうためその意思決定をなるべく上のレイヤーの方と進められると、色々スムーズになると思います。

ツールの選び方に関して
導入時の開発チームの状態や本格導入までのスケジュールなどで観点が変わってくるのでまずはそこの整理から入って、機能群の比較をやっていくといいのかなと思いました。


弊社のツール選定事情記事も出ているのでご参考になれば！

SLOの実装を各サービスで行っていくことと、本番環境・検証環境をトラブルシューティングがしやすい環境にしていくために 環境差分をなくしたり追加の計装を行っていく予定です。