メディアドゥのNew Relic導入から現在までの話

はじめに

こんにちは。IT統括本部SRE部の川俣です。今年の4月にSRE部へJOINし、会社のビルの1階にどんなご飯屋さんがあるかも把握しないうちに、”New Relicの活用推進”業務にアサインされました。（最近はサラダ屋さんに通い詰めています）前職で監視周りの業務を経験していたのと、同じくNew Relicの導入提案に少し関わっていたのを面接でお話ししていたので、経験に基づいての采配だと思います。

とはいえ、New Relicを利用してどんな状態を目指しているのか、現状はどこまで進んでいるのかを知らなければ、計画を立てられません。ということで、私なりにメディアドゥでのNew Relicの導入経緯と現状を調べたり聞いたりしてまわったので、ご紹介したいと思います。

背景〜製品選定期

「New Relicがいいんじゃないか」と声が上ったのは、意外にも開発部隊からでした。曰く、電子書籍流通システム”DB4”を担当していた当時の開発者が、前職で利用した経験があり、評判が良かったとのことです。

当時のSRE部では、部門編成後バラバラだった監視システムをCloudWatchへようやく集約できたタイミングでした。部門統合の影響でバタバタしながらも、メディアドゥの提供するサービスに対して一貫性を持ったインフラ監視を構築できたという状態です。しかし、機能単位の障害検知が遅れるなど、期待するクオリティに達しない部分もありました。組織上部としてもこの課題を重く捉えており、サービス品質向上のため監視システムの改善が求められていました。

当時はCloudWatchを利用しており、AWSのサービスだけでも作り込みによって上記の課題を解決できます。しかし、メディアドゥではAWSだけでなくGCPでサービス提供しているプロジェクトも存在することや、導入や運用の簡易さから、冒頭の声が上がりました。何気ない1on1の場で上がった開発者の声は上長経由でSRE部に届き、サービスの利用検討が始まりました。

SRE部としても、統合的なモニタリングにSaaSを利用するのは歓迎すべき方針でした。 New Relicを含むオブザーバビリティを提供する代表的なSaaSの中から比較検討し、以下の観点でNew Relicに優位性があると判断しました。

・アプリケーションパフォーマンスモニタリング（以下、APM）が高機能
・導入工数が軽微
・取り込みデータ量課金なので比較的費用が安価

上記については、導入事例としても紹介されています。

newrelic.com

導入〜運用開始期

New Relicでは様々な機能が提供されていますが、メディアドゥでは以下の機能を主に利用しています。

・Synthetics
・Dashboard
・APM
・Infrastructure
・Logs
・Alerts

”導入工数が軽微”とメリットを上げましたが、とはいえ導入に当たっての課題は数点ありました。 PoC〜実際の導入時には、以下を例とする議題が上げられていました。

・APMによるパフォーマンス計測自体が、パフォーマンスに悪影響にならないか
・New Relicによるログ監視運用に慣れるまで、CloudWatchLogsの現行運用と並行稼働期間を設けたいため、FireLensから両方にログを出力する必要がある
・当時から推進していたInfrastracture as Codeに即して、Alerts設定をTerraformで構築したい

一つ一つ潰し込んだ末に、弊社主要サービスの電子書籍流通システム”eBook 取次システム”およびその刷新システムである”DB4”へ導入が叶いました。 New Relicの導入によって、開発現場からは以下の感想をいただきました。

・「パフォーマンス改善アップデートによる効果が可視化でき、定量的に評価することができた。」
・「リリース作業後にAPMを確認することで、サービスが適切に動作していることを簡単かつ詳細に知ることができるようになった。」

”サービス障害への自動的な一次対処”や”持続的なパフォーマンス改善”という目標にはまだ取り掛かり中ですが、現状の可視化という面では既に効果を感じることができました。

PHPやJavaに対するAPMの実装はエージェント導入のみで工数が軽微でしたが、一部で利用しているGo言語ではAPMの導入工数が大きく、完全導入できていない実状も残念ながらあります。可観測性を効果的に運用するため、現在も未実装部分へ対応を続けています。