インフラエンジニアのいない SaaS 企業が New relic を導入した話

（最近インフラエンジニアが新規加入しました、とても嬉しい。）

多分皆さんはじめまして、happy_ryoです。本社は日本ですが、ベトナムの子会社でも働いています。このエントリは New Relic Advent Calendar 2019 - Qiita の12/11分のものです。

タイトルの通り、インフラエンジニアが一人も居ないWebサービスを提供している会社でのNew relic導入までのお話（ポエム）です。昨今、AWSやGCPの台頭により専任のインフラエンジニアのいない会社もボチボチ増えているし、そういった会社でアプリケーションやインフラの監視を考える際に「うちではこういう感じで進めたら割と上手く行ったので参考になれば幸いです」的な内容です。

ことの発端

最後のインフラエンジニアの退職に伴い社内にひとりもインフラ専任のエンジニアがいなくなってしまった事により、サーバーステータス（アプリケーション）の監視体制の構築・運用・更新という重要事項に非インフラエンジニアが取り組まなければいけなくなったのが事の発端になります。弊社のバックエンドエンジニアはインフラの基礎的な知識を持つ人が多かったのですが、プロダクトの開発に集中する必要があり、監視の重要性を理解しつつもなかなかその点に関して着手できない状況でした。（各プロダクトでやれるだけやる、という状況）

元々 New relic は一部のプロダクトに無料で利用できる範囲でアプリケーションの監視目的で導入されていましたが、2017年中頃に無料枠の機能変更（サーバーのリソース監視やアラート機能の有料化）がアナウンスされたことを期に、継続利用するのか別プロダクトへ移行するかの検証を行う必要が出てきました。

お金がかかる話になって本腰が入るのも現金な話ですが、この事が長らく着手することのできていなかった、監視環境に対して向き合うきっかけになりました。後からやろうとすると、色々と苦労をするのでできる事なら規模が小さくて「今は出来る範囲で良いでしょ」って段階から取り組むことをオススメしたいです……。

検証

検証の初期段階から、長い間既存の基盤のまま更新されていなかったサーバーステータスの監視も同時に移行できないか検証することになり、両軸から検証を行ないました。検証にあたっては事前にNew relic社に申請を行い、APM と Alert、Infrastructure の機能を解放してもらいました。

インフラの監視を Infrastructure に移行するにあたって、最低限必要だったのは以下の4項目です。

CPU使用率
メモリ使用率
ストレージ使用率
ネットワーク死活

これらは当然問題無く、それに加えて以下の項目がぼくに刺さりました。

各サーバー内で実行中のミドルウェアの状態も監視できる
高機能なアラート
設定がシンプル

普通のミドルウェアをインストールする感覚で導入できて、得られる結果はガッツリというのはインフラエンジニアを抱えていない組織としてはかなり助かる要素でした。

続いて、APM 部分の検証を行いました。 こちらは言わずもがな高機能で、今もって使いこなし切れては居ないのですが、以下のポイントが導入を改めて決心する要素になります。

各時間帯のスループット計測
各トランザクション内のどの部分でどれだけ時間がかかっているかの計測
データベースの各テーブルに対するアクションの計測
- SlowQueryの表示もしてくれる
- Redisの計測も出来る
外部のAPI利用のレスポンスタイム等の計測
Error の詳細な分析

これらの情報をエージェントの導入一つで自動的に収集してくれ、それをWeb上で自由に閲覧できるようにしてくれるというのは一度味わってしまうと抜けられないです……。無料版との違いは情報の保持・閲覧期間ですが、無料の3日間でも短期的な比較やエラー発生のキャッチアップには問題ないし、ある程度日をまたいで居ても自分でデータを記録しておいて比較するなどの手がないわけではありませんが、ツールの導入で新たに定常的な業務を増やしてしまっては意味がないし、ふと日々の開発が落ちついたときに情報を見返して改善に繋げる為にも有料化した方が良いと判断しました。

導入への道

検証の結果、当時の組織とプロダクトの状況にフィットしたソリューションだと判断し、実際の導入に向けて活動を開始しました。

そうです、New relic はぶっちゃけそれなりにお値段の張るサービスなので、皆の大好きな稟議を通す必要があったのです……。

まず、もう一人の担当者だったエンジニアが、導入予定のサーバー情報の収集を各プロダクトのエンジニアの協力を得ながら進めたり、その表を元にNew relicの担当営業の方に利用料金を見積もって貰いました。文章にして書くとあっさりしていますが、インフラエンジニアが不在だった為、AWSのインスタンスの管理は割とエグい状態になっていて、結構大変そうだったのを覚えています。

大体の見積もりが出た段階で、上席へのセールストークを考えて居たのですが結局「インフラの監視はサービスの提供をするなら必須であり、これだけの監視システムを構築、または開発して運用していく為に必要なエンジニアのコストよりも遥かに安価である」という所に落ち着きました。要はエンジニアを採用するコストをツールに転化しましょう、という流れで話をしました。（そもそも、良いエンジニアに出会えるか？は運の要素が大きいし……）

幸い、弊社の上席はエンジニアリングに理解があり、割とサックリ稟議が降りて無事導入と相成りました。

ポイントは以下の三点だったと思っています。

インフラエンジニアが居てもいなくても、New relic 相当の環境を構築・運用する事は容易ではない
ツールの利用料として見ると高額だが、同様の物を用意するために必要な人権費と比べれば決して高額ではない
より品質の高いサービスを自分たちが届けるために、より良い監視・分析は必須である

導入……それから

稟議が通った後はトントン拍子に話が進み、検証用に導入済みだったものはそのまま継続利用できた事も相まって、基本的な機能をざっくりと利用するところまでは割とスムーズに出来たと思っています。とはいえ、New relic は非常に高機能で全ての機能を理解して使いこなす事は難しく、定期的な担当者の方とのMTGでは上手に扱い切れていない状態を歯がゆく思う事もありました。

必要に応じて、必要な設定を随時行っていくような運用になってしまっていたのは良くなかったなと今でも思っていて。リソースの確保が厳しかったとしても、ある程度の期間を区切る形で専任の担当者を充て、全体で共通的に扱えるアラートのルールを用意したり、ダッシュボードの構築をしてサービスの状態をエンジニア以外が見ても、なんとなく状態がわかるような取り組みをした方がエンジニアに閉じたツールにならず広い範囲の人が利用するものになって追加の投資がより安かったなと考えています。

現在は、専任のインフラエンジニアも入社して以前よりも New relic の改善に対して工数を避けるようになって来たため、少しずつよりよい利用環境を構築していっています。