FMSで行っていたURL監視などを導入していきます。サービスの概要はMackerelを知った2年前に確認していました。先ほどお話しした大規模障害の後に、トライアル版を導入して本格的に検証しました。無償トライアル期間を設けているので、その間に細かく検証いただけるようにしています。冒頭でもお話した通り、導入の動機は「大規模障害があった時にMackerelで通知してもらおう」なんです。今でも小規模な障害は従来のやり方で対処していますが、大規模障害となると人手で連絡していたのでは間に合わない。そこでまずお客様に通知しよう、ということで導入しました。通知が来た場合は障害対応のページをご確認いただいています。通知がないと、都度こちらに連絡が入って対応しきれないので。森本から「我々の思い描く仕組みを実装するにはMackereが適している」という意見をもらいました。細かな設定をすることで監視できるので、いろいろ活用できそうだと考えています。Services)上に実装されていることは知っていました。今はクラウド活用がどんどん進んでいるので、基盤として見た場合にAWSならば大丈夫だろうと判断しました。官公庁や製造業などでもクラウド対応は進んできました。世の中のセキュリティ基準を満たそうとすると、自社基盤よりAWSの方がいろいろな認定を受けていて早く作れる側面もあります。MackerelにはAPIがあって、障害中のサーバーを拾い出すことができます。それを使って簡単に実装できました。障害を起こしているサーバーを表示する画面をお客様に公開して、通知メールが来ていない場合でも、このページを見れば障害の有無が分かるようにしています。これは定期的に自動処理で画面を作っているので、人手はかかっていません。「オーガニゼーション一覧」の表示機能を開発していると聞いていますが、そこはまた別ですか。オーガニゼーション一覧は、私たちが構築した独自ダッシュボードで使っています。独自ダッシュボードを見せて頂いたのですが、非常によく作られていて、私たちのチームメンバーも「この機能は標準であった方がいいよね」という話になりました。はい、似た機能を作ってリリースしています。それをすぐプロダクトに反映する早さは良かったですよね。8月にインターン生が来ていて、「お題」としてやってもらうといいんじゃないかと思って、作ってもらったんです。それをチームでしっかりレビューした後に公式機能としてリリースしました。他にも、もしご要望があれば取り込むことを検討していきます。独自ダッシュボードのお話は、監視対象の会社数が多いので、そのための画面を独自に作ったというお話なのですね。数十社のお客様のサーバーを監視しているのですが、1社ごとに監視内容を見ていきたいというニーズがあり、独自に機能を作りました。別の会社の障害で通知メールが飛んでしまうことをオーガニゼーションを分けることで防ぎたかったので。Mackerelは、はてな社内のツールをサービス化したものなので、当初はひとつの会社でひとつのオーガニゼーションを使うことを想定していました。はてなの場合、ひとつのオーガニゼーションで何千台というサーバーを運用しています。お客様によって違うパターンもあり、御社のように顧客別にオーガニゼーションを作るパターンもあれば、ゲーム制作会社様がゲームタイトルごとに分けるパターンもありました。当初僕たちが思っていたのと違う運用があり得ることが分かってきました。そこで、Mackerelでもオーガニゼーション一覧のページを公式に作ることにしたのです。最近は、自分たちの会社の中でもオーガニゼーションを分けた方がいいんじゃないか、という議論があります。DevOps的なチーム分割の側面からするとそれが自然ですし、実際問題、障害で別のサービス担当者に通知が飛んだりすると怖いので。現状では、コネクティビティの通知だけをしているんですよね。お客様に直接触ってもらうことはしていませんが、社内の開発部隊にはRO(リードオンリー)のユーザーを渡して、メモリーやCPUの監視機能を共有しています。Mackerel側の考え方としては、アプリケーションのユーザーにも使ってもらうといいんです。自分たちのプロダクトに対するプラグインなどは、アプリケーションを作っている人でないと作れない側面があります。Mackerelはアプリケーション開発者に使ってもらいたい、という話を座談会のたびにしていますね。MackerelはDevOpsの中核でありたいと思っています。開発と運用に断絶があるとうまくいかない。インフラの人だけが見る画面にはしたくなくて、開発の人も見てアクションを取りましょうと。いうインクリメンタルな改善ができるサービスでありたいと思っています。ひとつは、さきほど挙げたメールのテンプレートがあると嬉しいというのがあります。あと、「一週間単位」とか「9月1日から1カ月」を見るみたいな機能がない。いう機能があると、サーバー稼働状態の報告書を作る業務が楽になります。グラフの表示期間をもっと細かく制御したいというお話ですね。そこのUIは僕たちは「グラフコントローラー」と呼んでいます。たしかにここは、カレンダーから指定するなどもっと多彩な操作ができるように改善したいと考えているところです。来週には、カスタムダッシュボードのリニューアルをリリースする予定なのですが、そこにもこのグラフコントローラーのUIがあります。なると同様の要望は多く出てくるのではないかと予想しているので、次はそこの改善に手を付けたいとは考えています。監視ツールとして、Zabbixも残すつもりです。どこまでMackerelに移すか、と考えたとき、外形監視が今はhttpとhttpsだけなんですが、特定のポート監視ができると、より注力できるかなと。あとはICMPやpingとかですね。特定のポートを叩いて監視できれば。外からICMP監視ができるといいですね。滅多に落ちませんが、上位ルータがダウンすると広範囲にわたる障害となりますので。外側からルータの監視ができたら嬉しいと思います。今は別の業者に監視をやってもらっているんですが。インターネットに露出したポートの監視の機能を追加することは、可能性としてはあります。本当に使いたいモノは、作り込む必要がある。Mackerelは他のツールに比べて作りやすいと感じています。作りやすいし、画面が分かりやすい。新しく入ってきたスタッフにもすぐ把握してもらえる。分かりやすさは重要です。(複数のVMを)ロールでまとめて、同じ役割の中で数値が飛び抜けているものがすぐ分かる。個人的には、エンタープライズかWebかというのは関係なく、すっと入ってきました。他のMackerelのユーザー企業はWebサービスやゲームのように、B2C系の会社が多かったんです。御社のように主に会社相手のビジネスの場合、Mackerelがどうフィットするのか気になっています。今までの監視ツールは、ツールごとにできることが違うし、何かやると費用が発生する。私たちのお客様にサービスを提供するとき「URL監視一点につきいくらかかります」と費用が発生すると、サービスメニューを作るのが非常に面倒です。業務フェーズの監視となると従量課金という訳にもいかない。した細かいことを言うのが嫌なんです。Mackerelは、エージェントを入れると、何でも値を取れる。お客様に提供するサービスメニューを作りやすい。我々のサービスにかなり合っています。いえば、御社は、というより森本さんが、かもしれませんが、結構新しいツールを使っていますよね。僕が、新しいツールを試しがちなんですね(笑)。ホスティングサーバを提供していますので、使っているソフトウェアもLinuxやApacheなどが多く、「オープンソースだからダメ」みたいな思いはありません。取り入れるべきものは取り入れる、新しいもの好きなところはあります。SIerでありつつも、先進的な取り組みをしているなという印象があります。いう風土が、Mackerelの採用に至ったポイントでしょうか。Mackerelの設計思想がいい部分はありました。オープンソースは無償だけど運用コストはかかる。監視サーバーの機能やVMの料金や運用コストが個別に発生します。総合的には考えるとMackerelにお金を払う価値は十分にあると思っています。VM数は増え続けるので、監視にあまり手をかけたくないし、かといってサボる訳にはいかない。エージェントを入れると自動的にやってくれるのはいいですね。ありがとうございました。読者になるバナーとお問い合わせセールスに関するお問い合わせ料金や支払い方法など気なることがあれば、ぜひお気軽にお問い合わせ下さい!お問い合わせ無料トライアルMackerelに興味をもっていただけましたか?まずは無料トライアルで実際にMackerelを使ってみてください。Ltd.スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。