概要
自社クラウドサービスのリリース当初（2018年）から監視基盤として使用してきたOSS版ZabbixからNewRelicに移行した経緯、ZabbixとNewRelicのざっくりとした違い、契約方法、移行作業と気を付けることなどを書いていきます。
経緯
自社クラウドサービスはシングルテナントで運営していて、契約社数が増えるごとに監視対象も増えます。過去に何回かZabbix起因のトラブル（サービス障害に至らない程度）に見舞われ、Zabbixの冗長化を検討したがそれなりのコストがかかりそうなので、ひとまずスケールアップと設定のチューニングで凌いできました。
一応弁解しておきますと、トラブルの素はZabbixをほぼ初期パラメータで運用していたことが原因でしたので、Zabbixの問題ではなく使い方の問題でした。
それでも過去に経験したトラブルの影響で安心、安定した監視基盤が欲しい気持ちがずっと心の奥に残っていたところ、NewRelicの紹介をうけ移行を決意しました！
移行を決意した決め手
その１ ホスト数にかからず料金が一定である
前述通りにシングルテナントで運用しているため、契約社数に応じて監視対象も増えていきます。他社の監視サービスはホスト数課金のため、コストパフォーマンスを出すのは難しく導入を見送っていました。
しかし、NewRelicはホスト数にかからずフルプラットフォームユーザ＋データ量に応じた課金体系なので、弊社サービスのようにホスト数に比例してコストが肥大する心配も少なく済みます。
その２ すべての機能が利用できる
これもNewRelicの特長の一つともいえると思いますが、APMや外形監視なども追加料金不要で利用できることから、今後APMによる自社サービスの品質向上を図れる計画をしています。
その３ 一般ユーザは無料
一般的な監視データの収集のみならず、任意のデータを投入することもできるので、組織内全員向けに一般ユーザとしてデータマート的な使い方も検討しています。
ZabbixとNewRelicのざっくりとした違い
OSS版のZabbixは当然ながら自由度は高いですが、過去に使用してきた機能においての大きな機能的な違いを簡単に以下のようにまとめました。
| NewRelic | Zabbix | |
|---|---|---|
| ホストを任意に削除 | ×（時間設定は可能） | 〇 |
| サーバサイドで任意のスクリプトを実行 | × | 〇 |
| アラートの放置（※1） | ×（一定時間を経過すると自動Close） | 〇 |
| 監視方式（エージェント） | Push型 | Pull型 |
| 通知をまとめる | 〇 | × |
| テンプレート（※2） | × | 〇 |
| 外形監視 （※3） | 〇 | △ |
| 導入サポート（※4） | 〇 | x |
※1･･･無駄なアラートはノイズなので自動Closeで良いと思うが、休日の間に発報されたアラートがいつの間にかCloseされることもあるので、自動Closeしないように調整が必要です。
※2･･･Zabbixでは各種設定をテンプレートとして保存し、複数環境に適用できたが、NewRelicにはそういう仕組みはないので、自前でAPI経由で設定をコード化するのがよいかもしれない。
※3･･･NewRelicでは世界中の観測地点から外形監視できるが、ZabbixはZabbix本体からの死活監視になるので可用性が高くなりました。
※4･･･ZabbixはOSSなのでサポートがないのは当然ですが、NewRelicの導入時は専属担当者がサポートしてくれます。
構成
自社クラウドサービスは開発、ステージング、本番と3つの環境があります。それに合わせてNewRelicも環境ごとにアカウントを作成しました。ただし、3環境ではなく、大きく本番と開発で分けました。
それぞれの環境はタグ付け(Env)で判別しています。また、複数のクラウドサービス(Prd)が共存できるようにタグも設けています。今後はイントラネット内の社内インフラも開発アカウントに統合していく予定です。
アカウントを追加で申し込む方法
移行作業
基本的にZabbixでの運用をNewRelicに移行します。
ただ、一部仕様が異なる部分もあるので、NewRelicに合わせて変更しました。
作業内容
- 命名規則の定義
前述通りに複数サービス、複数環境、複数バージョンが混在する前提でサービス名_xxx、環境名_xxx、バージョンなどをタグ、アラート、ポリシー、ダッシュボードに付与するようにしています。 - アラート、Webhookなどの動作検証
契約前にクリティカルな要件は動作検証済み - ユーザ・権限設計
- ダッシュボード設計
- タグ設計
- インフラ関連のプログラムの修正とテスト
Zabbix APIを呼び出している処理をNewRelicに置き換える
契約
日本法人（New Relic株式会社）と契約になります。
請求は日本円なので為替リスクも無く安定した予算取りも可能です。
データ量については1か月分超過しても直ちに追加請求されることはなく、年間で超過見込みになったら追加請求になるとのこと。
気を付けること
データ保存期間
Zabbixを使用していたときはデータの保存期間は自分たちでコントロールできるが、NewRelicにおいてはデータの保存期間があります。監査や分析用に長期の保存期間が求められている場合は、要件が合わない可能性もあるので要注意です！
なお、未発表情報ではありますが、長期のデータ保存プランを準備中との噂を耳にしています。
データ量
契約前に監視対象の（本番）システムからエージェントによるデータ量のサンプリングを必ずしておきましょう！
エージェントの設定をデフォルトのままだとそれなりのデータ量になります。当然と言えば当然ですが、オブザーバビリティを高めるということなのでデータ量も必然的に多くなります。
弊社の失敗談になりますが、本番でサンプリングせずにざっくりなデータ量で契約して、いざ本番でサンプリングしたら契約した量の10倍以上のデータ量になる試算になりました。リリース直前にチューニングし、なんとか契約したデータ量内に収めることができました。弊社クラウドサービスのようにシングルテナントではない限り基本的に問題ないと思いますが念のために確認しておくことをお勧めします。
データの保存先
現時点（2023.11）においてはデータの保存先はUSまたはEUなので、企業のデータポリシーによっては要注意です。
これも未発表情報ですが、日本リージョンも準備中との噂も耳にしています。