この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
クラスメソッド主催のオンラインイベント「Developers.IO Showcase」。
DAY 5 となる 11/6 に、弊社の監視オプションサービスが基盤につかっている Mackerel の話をしてきました。
本記事では当日うけた質問に対する回答（Q&A）とともに、話した内容を簡単に記載します。
内容
今回、大きく以下の 3 点について話しました。
- そもそも監視とは（おさらい）
- クラメソ監視サービスの歴史と課題
- Mackerel と、それを基盤に採用した監視オプションの話
そもそも監視とは
まず簡単に、ここで話す「監視」について定義的な話をしました。
- 内部からの監視と外部からの監視があり、それぞれ得られる情報の質が違うこと
- システムの内側からの監視（メモリやディスクの消費率など
- システムの外側からの監視（インフラ指標や疎通確認など
- 監視を行う目的は、「そのシステムの稼働状況に責任を持つ」ためであること
その上で、弊社クラスメソッドは何をどう考えて監視サービスを提供してきたのかを、次節で紹介しました。
クラメソ監視サービスの歴史と課題
当時の顧客からの要望や社会事情の背景から、弊社の監視サービスはこれまで何かあったことを検知し、その運用代行まで視野に入れたものを提供してきました。
そのため前世代の「フートモニタリング」は、Zabbix をベースに独自の（= クラスメソッドが顧客に提供すべきと判断した）機能を実装・拡張したものを運用していました。しかしながらそこから数年が経ち、経年効果も含めて運用負荷が高めになっていた状態です。
また前述した図にもあるように、「いまクラスメソッドが世に出すべき監視サービスとは」という視点と照らしても、2018 年はリニューアルすべき時期にきていたのではないかと考えています。
Mackerel と、それを基盤に採用した監視オプションの話
Mackerel は、株式会社はてな が開発・提供する SaaS 型サーバー監視サービスです。
クラスメソッドの監視オプションでは、この Mackerel をエンジン部分に使用し、最低限必要な機能を AWS 上でサーバーレスに構築したものを組み合わせています。
採用してまる 2 年が経過しましたが、その間大きなトラブルも無く、順調に利用者も増え続けています（ありがとうございます）。
今後も情勢の変化をにらみつつ、Mackerel の進化を取り入れて、サービスをより良くしていきたいと思います。
Q&A
セッション中に頂いた質問にお答えします。
Q: 監視サービスの今後の展望などあれば教えて下さい。
こちらのスライドでも言及しましたが、お客様の要望も変化しますし AWS 自体も進化していきます。それらと歩調を合わせるかたちで、「クラメソが提供したい監視とは」を常に問い続けていければと思っています。
Q: Mackerel のほかに検討されたサービスはありましたか？
New Relic をはじめいくつか検討しましたが、最も比較検討したのは Datadog になります。
実際のところ Datadog は弊社内の別の案件でも使用していましたので、直前まで決めかねていたのですが、下記のような点が決め手となって Mackerel に軍配が上がりました。
- Datadog は機能が豊富で、逆に今回の用途ではオーバースペックだった
- Mackerel のほうが学習上のイニシャルコストが低かった（分かりやすさ）
- 検討当時、外形監視的なサービスがなかった（現在は Synthetics があります）
Q: AWS 以外に Azure や GCP も含めた統合監視としてマカレルは使えそうでしょうか？
もちろんです！
現在 Mackerel は Azure と Google Cloud Platform（GCP）にもインテグレーション対応しています。使用しているサービスによっては難しいところもあると思いますので、ご自身のプロジェクトで使用できるかどうかは是非トライアルで確認して頂ければと思います。
まとめ
監視オプションで使用しているからこそ言えるのですが、Mackerelは本当にいいサービスなので、ぜひ皆さんいちど使ってみてください！ 監視オプションじゃ無くていいので！
参考
今回は「監視とは？」の部分はかなり端折ってお話ししました。こちらについて興味が沸かれた方は、こちらの動画をご覧頂ければと！（ステマ）
また、話の中で弊社関連企業のネクストモード社が提供する監視サービスのことにふれましたが、こちらについてもセッションレポートと資料が公開されています。あわせてご参照ください。
5
