この記事はディップNew Relic Advent Calendar 2024のシリーズ3 23日目の記事です。是非とも他の記事も読んでみてください！
自己紹介
息子大好きDBエンジニアのだいちです。
現行の監視環境にてPrometheusを利用しているのですが
NewRelic PostgreSQLオンホスト統合へ移行した(している最中)件について
まとめてますので是非とも最後まで読んでください。
誰に向けた記事なのか
今回は次のような環境・状況下の人に向けて纏めていきます。
- NewRelicを使っている
- PostgreSQLを使っている
- とにかくコストを下げたいと思っている
移行前の状況について
移行を検討する前は図にすると以下のようなアーキテクチャで監視をしていました。
※ Python コードでアーキテクチャ図を生成できる「diagrams」を利用したのですがうまく表現できなかったのでちょいと誤解を生む図になっているかもです。
オンホスト統合への移行をして以下のようなアーキテクチャになるように進めていきました。
なぜNewRelic PostgreSQLオンホスト統合を利用するのか
大きく2つの課題がありました。
管理の属人化
Fargateを利用してそこでPrometheusを使っています。
Fargateの構築にはTerraformを利用しているのですが理解してる人は一人だけ。
別の人が何かをしようとしてもキャッチアップに時間がかかってしまうという状況です。
リソースの維持費
DB一つに対してFargateを一つ立ち上げていたため
マスター・スレーブのストリーミング構成を利用しているためにDBの数は多いので
リソースのコストも膨大になっている状況でした。
これらの課題がたまたま利用していたNewRelicにオンホスト統合があったので調べたところ課題が解決されるので導入を進めた次第です。
移行までにやったこと
移行の中で一番大事にしたことは「現状と同じことができるか」でした。
現状と同じことができるかどうか
今現在はPrometheusを利用してPostgreSQLのメトリクスをNewRelicに送りダッシュボードにてチャートで表示させています。
オンホスト統合をしても同じようにみていたメトリクスを取得できてダッシュボードで表示できるのかを調べていきました。
Prometheus（正確にはPostgreExporter）で取得しているメトリクスが
オンホストではデフォルトで取得していないのもいくつかありました。そんなメトリクスに対してはカスタムクエリを使って取得することで解決してます。
NewRelic PostgreSQLオンホスト統合の導入については
公式ドキュメントに書いてある手順を行うことで簡単に導入できます。
移行してみての気づき
カスタムクエリがクエリごとにプロセスが立つことに気づいたのですが想定と違ったので知っておくといいかもです。
当初の想定ではカスタムクエリは一つのプロセスでyamlに書いた順に実行していくのかと思ったのですが、カスタムクエリごとにプロセスが立って実行されていました。
何が影響するかというと、コネクション数のカウントがカスタムクエリのプロセスもカウントするのでメトリクスの取得タイミングでは常にカスタムクエリ分のプロセスがコネクション数としてチャートで表示されます。
まぁそういう状況だと把握しておけば何も問題はないですね。
まとめ
今回移行をしたことで以下のようなメリットが得られるはずです。
料金コストダウン
年間で約7000ドルほどかかっているリソース(ECS)をオンホストで
1つのサーバから複数のDBに対してメトリクスを取得できるようにしたので
不要なリソースを削除できて年間で1000ドルほどになります。
属人化の解消
今現在としては移行に関わったメンバーしか把握していないですが、Prometheusを利用しているときのようなIaCを使ってECSを立ててみたいなことがないのでしっかりと共有すれば誰でも管理ができるようになる見込みです。
今回は上記の2点を現状の課題として解決まで対応を進められたのでとても勉強になりました。