所属はインタビュー当時のものですアイテック阪急阪神は、企業ユーザー向けにクラウドサービスを提供しています。サービスの障害発生時に正確かつ自動的にユーザー通知を届けられるツールを求めた結果、Mackerelを採用しました。エージェント導入だけで利用でき、カスタマイズが容易なMackerelの性質が役に立ったということです。導入検討から運用まで、はてなMackerelチームが話を聞きました。顧客に対して自動的にメールを送りたかったまずは皆さんの自己紹介をお願いします。マルチメディア事業本部、ネットワーク技術課の課長をしています。インターネット関連、クラウドやサーバーの部門なので、ネットワークやサーバーのエンジニアは課に集結しています。フルマネージドクラウドという名前で、設計から構築までぜんぶ引き受けるサービスを提供しています。そのネットワーク技術課で主にサーバーエンジニアとしてやってきました。ホスティングのサーバー基盤、関連するストレージやネットワークも見ています。機器を買ってきて、セットアップして、OSやミドルウェアが動きます、というところまでを担当しています。Mackerelのプロダクトマネージャーをしています。プロダクトの仕様や方向性を決めています。アイテック阪急阪神さんのような歴史があるSI企業がMackerelを大規模導入してくださって嬉しく思っています。Mackerelのビジネスマネージャーです。肩書の通りビジネス面を担当しています。Mackerel導入のきっかけを教えていただけますか。2年ほど前に、初めてMackerelを知りました。その頃は監視システムに特別な問題は起こっておらず導入は見送っています。FMS、Cacti、GrowthForecastなど各種ツールを試していました。情報があちこちに散らばっているのは分かりにくい。新しいスタッフが入ってきて、複数のツールに情報が散らばっているのを把握するまでが大変でした。とどめを刺したのが障害です。2018年3月頃に、我々が管理しているクラウドで大規模障害が起きたのですが、その際に監視サーバーからアラートが正常に飛ばないという出来事がありました。監視ツールを動かすためのサーバーのリソースが障害で尽きてしまっていて、うまく動作しなかった。手動で障害が起きたサーバーを拾い上げ、お客様に連絡を回すのに相当の時間を要しました。監視ツールで検知できないと、連絡に時間かかかり関係者に大きな迷惑をかけてしまう。ここをなんとかできないか。考えたことが、監視システムの刷新を考えたきっかけでした。アラートが「オオカミ少年」になるのを避けたかった導入時点では、どのようなことを考えてらっしゃいましたか。監視の仕組みをどうすればいいかを課の中で議論しました。社内では営業部門や本部長、それに社外のお客様への連絡が遅くなるのは困る。通知をいかに早く届けるかが重要です。単純に考えると、監視システムにメールを組み込めばいいように思えるのですが、実際はそうなっていませんでした。私たちが提供するフルマネージドサービスでは、最終的にアプリケーションを作るのはお客様です。メンテナンスをするのもお客様。そのため、どのようなエラーをどこまでお客様に通知するのかの見極めができておらず、通知をメールで送る形になっていませんでした。アラートを送る場合も、気をつけないと対処する必要がないブラフのようなアラートを送ってしまいます。そのすべてにお客様から問い合わせが来るのでは仕事にならない。サービスに影響が出るような事態ではアラートを送りたいが、一方で必要がないアラートは送りたくないと考えていました。たいしたことがないアラートばかりだと「オオカミ少年」のようになってしまいますね。運用規定書を提供していたのですが、お客様によっては「細かく連絡が欲しい」と要望をいただくこともあり、温度感がまちまちでした。Mackerelを使うことで課題を解決できそうだった訳ですね。機能的にもMackerelなら通知も含めて解決できそうだと考え、選択しました。障害時にお客様に通知する仕組みを「2カ月で作って欲しい」と言われていましたので、時間的にもMackerelなら実現できそうだと考えました。Mackerelでは、サーバー上のエージェントが、Mackerelのサービスと通信して情報を収集します。サーバーで障害が起きたらMackerelのサービスから通知が飛んでくる。サーバー上で動く監視ツールと違って、サーバー側リソースがほぼ食い尽くされているような状態でも大丈夫です。ホストが完全にダメになった場合もアラートを出せます。人手による判断を経ず、メールはリアルタイムに届きます。私たちの使い方では、Mackerelのメールを直接お客様に送信するのではなく、一度サーバーで受けて、fromフィールドや本文を私たちのお客様向けに書き換えています。この取り組みでは自動的に通知を送ることが重要だったのですね。メールはMackerelからではなく、私たちのサポートから届く形にしています。お客様がMackerel宛てに返信しないようにするためです。内部の独自監視では異常を捕捉しきれないので、外部の監視ツールを使うという形ですね。するとアラートの通知はMackerelがやってくれるのですが、メールを加工したいニーズがあった訳ですね。MackerelのメールだとHTMLメールでグラフを表示したりしますが、もっとシンプルにしたかったということでしょうか。フルマネージドのサービスを提供していて、基本的にお客様は我々に任せきりです。そのため、シンプルなメール文面で通知するようにしています。私たちもSaaSの提供者として、どうしても作り手目線になっているところがありました。したサービスの再提供まで考えると、Mackerelとして公式でメールのテンプレート機能があるといいわけですね。現在、Mackerelによる監視を導入したサーバーは450ぐらいですが、導入すべきサーバーは潜在的に1000VM(仮想マシン)ぐらいのニーズがあります。毎年、VM数は増えていますから、今後規模は上がっていくと思います。Mackerelによる監視をお求めのお客様には、行き渡っている形でしょうか。