はじめに
本記事では、Datadogへの移行を試みたものの、課金体系の誤解からNewRelicに戻ることになった経緯を共有します。この経験が監視ツール選定に役立つことを期待しています。
Datadogへの移行を決めた理由
コストカットの目的
Datadogへの移行は主にコスト削減を目的としていました。Datadogの料金体系は使用量に応じたものであり、ユーザー数に基づく課金ではなかったため、私たちのプロダクトに適していると判断しました。NewRelicではAPMとエラー検知のみを利用していたため、Datadogへの移行はユーザー数の追加とコスト削減を可能にしました。また、多くのユーザーがDatadogを利用していることも、移行を決断する大きな要因でした。
課金体系の誤解
Index Spanの誤解
Datadogのテスト期間中は問題がなかったものの、本格的な使用開始時にIndex Spanに関連する通信料が予想外に高いことが判明しました。これはログデータ量に基づく課金で、当初の理解が不十分だったため、予期せぬ高額な請求が発生しました。Datadogの営業との連携のもと、テスト期間中は月額のコミットメントフィーのみという理解で進めていましたが、実際は異なっていたことが残念でした。
結果として、Datadogを継続してもNewRelicと同等のコストがかかることが明らかになりました。Index Spanの検知率を変更することも考えましたが、それにより検知できるエラーが減るため断念しました。コスト削減を目指しましたが、モニタリング環境を悪化させるつもりはありませんでした。
NewRelicへの回帰
課金体系のシンプルさ
NewRelicに戻ってきて、課金体系のシンプルさが改めて魅力的に感じられます。ユーザー数に基づく課金は割高に感じることもありますが、新機能の追加に伴う追加料金の心配がない点は大きなメリットです。特にSREチームを設ける場合、NewRelicは万能ツールとして非常に有用です。
UIの好み
UIの見やすさもNewRelicの魅力の一つです。特にグラフ表示やダークモードの色合いはNewRelicの方が好きです。今年はWebコンソール画面の表示速度改善も大きく改善されて、軽快に動作するようになったと思っています。
APMアクセスとNewRelic Logsの活用
NewRelicではAPMの閲覧にはユーザーの追加が必要ですが、NewRelic Logsとダッシュボードの活用により、無料ユーザーでも重要なエラー箇所を効果的に確認できます。これにより、効率的かつコスト効果の高いシステム監視が可能になりました。BigQueryの利用を減らすことでコスト削減も実現しましたし、ログの検索速度もNewRelic Logsの方が格段に早いです。
結論
DatadogとNewRelicの移行経験から、コストカットを目的とした移行は軽率な判断であり、余計なコストがかかってしまったと反省しています。移行するに際しても課金体系への理解は必要であり、公式ドキュメントやユーザーグループなど多方面から情報を仕入れる必要性を改めて感じています。
今は、NewRelicを使っている場合、わざわざ他のツールに移行するメリットは少ないと感じています。監視ツールそのものをコストカットすることは考えず、代わりにNewRelicを使って既存のインフラコスト（AWS、GCP）を下げることに取り組む方が建設的だと思っています。
*NewRelicだけではないですが、私のところでは円安効果により12~14%、インフラコスト増になりそうでしたが、逆に15~18%くらいのコストカットができました。このあたりもどこかで共有できればと思います。