この運用方法ですと、具体的な問題が主に3点ありました。1点目がサーバーを増やす度に余計な手間がかかっていたことです。当時でも既にサーバーをAWSでクラウド化していたので、増設自体は手軽にできるようになっていました。

ところが、それらを監視するには増設したサーバー毎に個別で監視ツールの設定をしなければならず、とても面倒でした。

次に、監視をし始めるまでにたくさんの前工程が必要で、監視サーバーの初期構築に時間がかかっており、そこがボトルネックになっていたことです。

そして最後に、サーバー監視設定の属人化が起こっていたことです。監視ツールの設定や結果の解読に専門知識が必要となることから、サーバーのことをインフラエンジニアしか把握できていない状態になってしまっていたのです。

Mackerelの導入で直感的な理解が手軽に！

そこで新サービスを立ち上げるタイミングで導入したのがMackerelです。Mackerelにはもともと興味があって、私が個人としてフリープランで使っていたので、技術チームの勉強会で紹介したんです。

そこでとても評判が良かったため導入を決めました。簡単に使えることとUIが非常に綺麗であったことが大きかったと思います。

▼直感的なUIのサーバー監視ツール「Mackerel」

導入の具体的な効果は3点あります。1点目は、サーバー構築時の時間を短縮できたことです。

Mackerelではエージェントをインストールするだけである程度の監視を行ってくれるため、エンジニアが監視項目を設計する手間が格段に減り、導入も簡単なため気軽に監視を始めることができました。

2点目が、Slackと連携できるようになったことです。このことにより、インフラエンジニア以外の社員もサーバーの負荷などに関して簡単にチェックできるようになりました。

例えば、サーバーの負荷が上がってアラートが来た時にも通知を全員が確認できるようになっています。詳細が知りたい場合はログインすれば、グラフなどを閲覧することができます。

3点目が、インフラエンジニアでなくとも、APIを活用することでサーバー運用に関する指標を取得する仕組みを作れるようになったことです。APIによりアプリケーションエンジニアでも触ってみようと思ってもらえて、監視ツールへのハードルを下げることができました。

インフラ周りの専門知識を必要としないので、それまでインフラエンジニアしか携われなかった領域に他のメンバーも関わることができるようになりました。

アップデートは毎週！顧客の声を大切にする姿勢も

また、Mackerelはアップデートが頻繁にあり、週に1回程のペースで小さなものから大きなものまで新しい機能が追加されています。「ついにキタコレ！！」みたいな歓喜の声が社内で上がったりしています（笑）。

最近のアップデートの中で一番嬉しかったのは、Slackの複数のチャンネルに各サーバーの通知を送ることができるようになったことですね。

複数のWEBサービスを運営しているので、Aサービスの通知はチャンネル1に、Bサービスのチャンネルはチャンネル2に送るといった出し分けができるようになったことで、これまで以上に便利になりました。

定期的な勉強会もあり、今後のリリースの予定などにもキャッチアップしやすいです。フィードバックの速さや、勉強会などに力を入れている様子が伺えるところが良いと思っています。

エンジニアの視点引き上げ＆メンバーの一体感向上にも貢献

それまで、監視サーバーの設定はインフラエンジニアがやるものという認識でした。というのも、それができたのが我々だけで、ある意味、職人芸のようになって他の人が入れない領域になっていたからです。

しかし、Mackerelを導入してサーバー監視が効率化され、全員がチェックできるようになってからは、自分達が実現したい数値目標やサービスの中身などに我々の視点も上げられるようになりました。

そのおかげで、ビジネス側の社員とも同じ目線で話せるようになり、全体の一体感向上にもつながりましたね。今後もMackerelをサービスの安定運用に役立てていきたいです。(了)