制作開発部の野原です。
今回は、弊社が導入しているサーバの監視サービス、Mackerel（マカレル）についてご紹介したいと思います。
Mackerelってなに？
Mackerelとは英語で 「鯖（サバ）」 を意味します。
そう、魚の 「サバ🐟」 です。
なぜサーバ監視サービスの名前がなぜ 「サバ」 なのかと思う方もいるかもしれませんが（もしくは既にお気づきの方もいるかもしれませんが）、
昔からエンジニアの界隈からは、サーバやサーバ管理者のことを、「鯖」「鯖缶」などと呼ばれてきました。
「サーバ」 → 「サバ」 → 「鯖」
「サーバ管理者」 → 「サバ管」 → 「鯖缶」
なんともウィットに富んだサービス名で、私はエンジニア心がくすぐられました。
名前の由来はともかく、Mackerelはサーバを監視するためのサービスを提供していますが、
特徴はその手軽さにあります。
Mackerelの公式ページをみると、こんな特徴が記載されています。
"Mackerel（マカレル）は、運用中のクラウドもしくはオンプレミスのサーバにエージェントを1つ入れるだけで、簡単にサーバ管理を始められます。監視サーバ自身の構築・運用は不要です。さらに負荷のリソース状況などの数値をグラフに可視化します。障害発生時にはアラートが記録され、様々なツールに通知できます。システム運用保守に最適な監視サービスです。"
サーバ監視というものが一体どういう作業なのか、皆さんはあまり想像がつかないかと思いますが、これが結構大変です。
これまではサーバ監視や、監視システムの構築や設定といった作業に多くの時間を割かなければなりませんでした。
しかし、Mackerelを使うことで監視に関する業務を軽減し、空いた時間を自社サービスの改善へ費やすことができるようになりました。
Mackerelの特徴
ここからは、Mackerelの特徴や内容をもう少し具体的に紹介します。
私自身が使ってみてよかったポイントをいくつか挙げてみたいと思います。
１．UIが直感的でわかりやすい
サーバ監視用のツールは様々ありますが、ダントツで分かりやすいです。むしろなんだか楽しさすら覚えます。
弊社ではMackerel導入前まで、Nagiosやmunin、Zabbixなどを利用していましたが、とても使いやすいといえるものはありませんでした。
使い方が複雑で設定も難しく、職人的な技術が必要になるというのがサーバ監視ツールの印象でした。
Mackerelの開発チームはUI/UXにかなり力をいれており、継続的な改善に取り組んでいるようで、Mackerelの開発ブログを見ると、同じウェブサービスの開発者としてとても参考になります。
2．AWSのフルマネージドリソースに対応
一般的なサーバ監視ツールは、監視対象のlinuxやwindowsサーバに監視するためのエージェントをインストールし、そのクライアントが定期的にデータを収集します。
ところが、AWSのRDSやELB、ElasticCacheなどのクラウドサービスは、ユーザがそのサーバの実体を操作することができないため、エージェントをインストールすることができません。
もしもこういったリソースを監視しようとした場合は、一項目ずつデータを収集する設定を作りこんでいく必要があり非常に手間がかかります。
Mackerelの場合はAWS製品の一部にデフォルトで対応しており、簡単に監視設定を行うことができます。
AWSメインでサーバ運用している弊社にとって、これはとても魅力的で、監視設定に費やす時間を大幅に節約することができました。
3．設定が簡単
ものすごい簡単です。今まで使っていた監視ツールはいったい何だったのかと思うくらい簡単です。
やり方によっては新しいサーバを追加した瞬間に、自動的に監視設定が完了します。
私が初めてMackerelを導入したときの実体験ですが、新しくサーバを監視対象に置くまでに１分かかりませんでした。
AWSのフルマネージドリソースを監視する場合は、専用のIAMロールを発行してあげることで自動で監視対象になります。（弊社では利用していませんがAzureも対応しています）
通常のLinuxOSなどのサーバであれば、エージェントをインストールするだけです。
4．監視システムがサービス任せ
これも割と大きなメリットですが、Mackerelはサービスなので、こちらで監視システム自体の保守をする必要がありません。
NagiosやZabbixのように自分たちで監視システムを動かす場合は、その監視システム自体を管理しなければいけません。
よくあるケースなのですが、
例えばZabbixは過去のサーバのデータを蓄積するのため、日を追うごとにデータ量が増えてきます。
データ量が増えてくると、データをグラフ化したり集計するための計算量が増えてしまい、監視システムが高負荷状態になってしまいます。
そのため、ある程度の期間運用した（もしくは監視対象が多い）監視システムは、それ自体のチューニングやメンテナンスが必要になり、とても手間がかかります。
結果、監視の監視という訳の分からないことをしなければならないのです。
拡張性もあるぞ
このように、Mackerelはインフラのクラウド化にベストマッチした監視サービスで、インフラの知識の少ないアプリケーションエンジニアでも簡単に導入できる代物となっていますが、簡単なだけでなく拡張性も十分にあります。
標準の収集データで足りない場合は、プラグインという形で追加することができます。
また、公式が提供しているプラグインで物足りない場合は自分で、Go言語を使って開発することができます。
go-mackerel-pluginを利用してカスタムメトリックプラグインを作成する
それ以外にも、mkrというコマンドやHTTPベースのAPIが用意されており、グラフや監視設定をAPI経由で作成することもできます。
あとはエンジニアの想像力と行動力でいかようにでも拡張することが可能です。
よくある例ですが、弊社ではコードをリリースするスクリプトのなかでmkrコマンド使い、
グラフにリリースした記録を自動的に残せるようにしています。
まとめ
今回は弊社で導入しているサーバ監視サービス Mackerel の紹介をしました。
なんだかMackerelの宣伝みたいになってしまいましたが、それくらい導入にはメリットしかないサービスだと思います。
有料サービスなので費用はかかりますが、自社で監視システムを運用した場合と比較すると、決して高くはないと思います。
インフラエンジニアが足りなくて監視まで手が回らない・サーバ監視になんて時間を割きたくないと思っている方はぜひトライしてみてください。
