ベータリリース前に話を聞いて、インストールして試してみた

まずは自己紹介をお願いします。

久森 エム・ティ・バーン サーバーサイドエンジニアの久森（id:myfinder / @myfinder）です。エム・ティ・バーンは、株式会社フリークアウトと株式会社イグニスの共同出資会社で、スマートフォン向け広告ネットワーク事業を行っています。私自身はもともとフリークアウトでインフラ構築、運用から広告配信アプリケーションまで手がけていました。今回のMackerel導入は、まず僕が始めて、各メンバーに展開する形で進めました。

守山 エム・ティ・バーンのエンジニアとして、サーバーサイドを担当している守山（id:cou929 / @cou929）です。

吉牟田 アプリケーションエンジニアの吉牟田（id:yoheimuta / @yoheimuta）です。iOSやAndroidアプリに入れるSDK開発を中心に担当しています。アドサーバー開発もやっています。

ネイティブアドネットワークの Hike（ハイク）by M.T.Burn 株式会社| スマートフォンメディアに最先端の広告技術を提供

田中 はてなでMackerelのプロデューサーを担当している田中（id:stanaka / @stanaka）です。

まず、Mackerel導入の経緯をお聞かせください。

久森 最初の出会いは、Mackerelがベータリリースされる前でしたね。はてな京都オフィスにお邪魔した際、田中さんから「こういうものを作ろうとしている」とMackerelの構想を聞きました。そのタイミングで、自社で10台ぐらいのサーバーに勝手にインストールしてみて、他のソフトウェアに影響が出ないかどうかを見ました。 その後、エム・ティ・バーンのアドネットワーク事業が立ち上がり、サービスが伸びるとインフラに不安があるのでクラウドに移そうということになったんですね。弾力的にサーバーを増やしたり減らしたりするオペレーションの手間を減らしたい。そこで監視ツールを考えると、やっぱりMackerelがいいんじゃないか、と考えました。

Mackerel導入の決め手は何でしたか？

久森 開発が活発であったことがひとつです。それから、早い段階でユーザーとして入ってフィードバックしていくことで、我々の都合含めてよく見ていただいて開発していっていただけるのではないか、という点でした。

はてな側からは、エム・ティ・バーンさんの導入について、どう見ていますか？

田中 アドテク分野はホットです。その分野で使ってもらえることはありがたいと思っています。一般的なWebサービスであれば私たちでも勘所が分かりますが、分野が違うと、私たちの感覚が正しいとは限らないので、そういった分野で使ってもらえることで、Mackerelがより多方面で使いやすいものにしていけるのではないかと思います。

皆さんのMackerelへの第一印象はどうでしたか？

守山 最初にMackerelを触ってみて、見た目がモダンだと思いました。グラフ上で期間を変えてメトリックスを見たりすることがインタラクティブにできる。「現代のツールが来たな」みたいな（笑）。メニューを見ていても、使い方が分からないということがあまりなく、これなら見てすぐ使えそう、という印象がありました。

吉牟田 AndroidとiOSのSDK開発にあたって、監視ツールとしてNew Relicを使い始めたのですが、その直後にMackerelと出会いました。Mackerelは分かりやすく、問題が起きたとき「これを見れば分かる」という感触があり、そこがありがたいと思いました。

田中 はてなでも、以前はOSSの監視ツールを使っていたのですが、「分かる人には分かる」という作りで、分からない時には手探りでやらないといけない感触がありました。Mackerelを作るに当たっては、そこをなんとかしたいとデザイナーとも相談しました。分かりやすくて、シンプルかつクールな感じにしよう、と。

初期ユーザーとしての興奮

Mackerelはどれぐらいの期間、使っているのですか。

久森 導入は2014年8月ごろからだから、半年少々ですね。

田中 正式リリースするかしないかのタイミングで導入していただいた初期ユーザーです。私たちはてな側でもワクワク感がありました。動きがあるアドテク分野でオートスケールを活用していただくなど、私たちの想像以上に使っていただいていて、非常に面白い事例だと思います。

久森 導入したころから比べると、Mackerelの機能もだいぶ増えました。毎週なにか機能が追加されてますね。

記事一覧 - Mackerel ブログ #mackerelio

はてなへのフィードバックは？

久森 フィードバック機能を使って気軽に要望や質問を送ったり、中の人から返事を聞いたり……いちユーザーとして、海外のサービスとは違った、距離の近さを感じますね。サービスメトリックの監視・アラートが欲しいという要望を出していたのですが、ついに実装されて良かったなと思います。売上やアプリケーションのエラーレートなど、サービスの指標を見るためにも使っています。

サービスメトリックの監視が行えるようになりました・ほか - Mackerel ブログ #mackerelio

守山 毎週のように見た目の改善が入っているんです。グラフを3つ並べてぱっと見られるビューを追加していたり。

吉牟田 毎週金曜日に新しい機能が追加されて「今週のMackerelアップデート」っていうメールが送られてくるんですけど、それが楽しみなんです。Slack上で「ついにこれが来た！」って盛り上がったりするんですよ！ 次にどんな機能が追加されるんだろう、というワクワク感があります。ページ全体をリロードするのではなく、グラフだけをリロード表示する機能が追加されたときは、これは良いなと思いました。全体をリロードするとストレスを感じますが、グラフだけの再描画ならあまりストレスを感じないですからね。

グラフがその場でリロードできるようになりました - Mackerel ブログ #mackerelio

田中 毎週のアップデートという点については、MackerelはB2Bのサービスですが、私たちがB2Cのサービスで培ってきたカルチャーが出ている部分だと思います。エンタープライズなサービスは何ヶ月か1回、大型アップデートがある場合をよく見ますが、私たちはもう少しカジュアルに、少しずつ機能を追加しています。

クラウド、オートスケールに対応したMackerelが必要だった

改めて、エム・ティ・バーンでMackerelが必要と判断した背景をお聞かせください。

久森 （親会社の）フリークアウトでは、自前のデータセンターをハウジングで借りてサービスを提供してきました。これはDSP（Demand-Side Platform）という事業にはマッチしていました。トラフィックのピークを見切りやすいし、価格の交渉もしやすい。 一方、エム・ティ・バーンはアドネットワークを事業として手がけているわけですが、そこでの課題は、大きなメディアが参加すると、トラフィックが2倍、10倍と急に変化することが予想されることです。オンプレミスで設備を持つと、サーバー増強のリードタイムに1ヶ月といった期間が必要になってしまい、事業展開が遅くなってしまいます。そこを乗り越えるにはクラウドだと。そういう方向に考えをまとめ、合意形成を進めました。

Mackerelで嬉しかったことは何ですか？

久森 オンプレミスをIaaSに移すだけなら、ツールセットを変える必要はないのですが、運用費用は高くなります。ではどうするべきか。よりクラウドらしい設計のシステムにしていく必要があります。必要なときに必要なリソースを確保し、使わないときには解放する、というやり方です。ピークタイムに合わせて弾力的に変えて、オートスケールで運用したかったのです。 問題が発生したときには、サービスのどこに問題があるのかを知るためにメトリックスを見たいですよね。ところが、従来の監視ツールのMuninなどは、オートスケールに対応していませんでした。Mackerelのクラウドらしい使い方に対応した監視機能は、私たちのようなサービスにフィットします。

田中 オープンソース系のツールの設計思想は、AWS（Amazon Web Services）のようなクラウドサービスが普及する以前のもので、主にオンプレミスを想定しています。それぞれの要素が動的に動くことを想定していないし、やろうとすると手数が多くなる。AWSと組み合わせると設計の古さが見えてきてしまいます。 例えば、サーバーのリストに記録した数が増えた／減ったを、管理ツール上でどのように認識するか。従来のツールでは手数がかかります。「ツールに熟練した人ならできます」という話と、「ツールの標準機能で熟練を必要とせずにできます」という話には、大きな開きがあります。

久森 運用上、人間が気を付けないといけない点が増えちゃう、というのが問題です。例えばサーバーのリストを追加したり更新したり削除したりが必要だと、更新漏れが起きたりします。サーバーがサービスに参加したけど監視されていない、という状況は良くありません。これは極めて重要なポイントです。Mackerelであればそうした心配がありません。

田中 Mackerelがうまく時流に沿ったプロダクトになったなと思うのは2つのポイントがあって、1つがクラウドが登場して、運用パラダイムが変わったこと。もう1つは、GitHub EnterpriseやSlackのように、開発に使うツールが「自前主義」から「サードパーティのサービスを使う」という風潮に変わってきたこと。この2点が追い風になっていると思っています。

アプリケーションエンジニアが異常検出の仕組みを作り込めた

守山 アプリを作る立場から見ると、Mackerelは職人芸を必要としないところがありがたいですね。普段からインフラを追求している人でなくても、誰でも触れる。学習コストが低く、その分、本業に専念できます。

吉牟田 警告などのアプリケーションのログについて、少数ならば無視していいけど、あまりに多いようなら検知したい、という仕組みを作ろうとしたことがあります。 普通の組織だと、こういう機能はインフラエンジニアにお願いして、詳しい人に作ってもらうところです。でも今回、僕らもMackerelには親しんでいたし、APIの使い方も分かるので、自分たちアプリケーションエンジニア側で作ってみたんです。ログをOSSのストリーム処理ミドルウェアのNorikraを使って集約して、件数をMackerelにポストする、という仕組みが、インフラに詳しくなくても実装できました。 この機能を使って検出できた事象として、メディアさんの「支払いの設定」の漏れがありました。件数が少ない場合はテスト環境だろうから無視しても構わないが、件数が多い場合は、メディアさん側で本番環境の設定が漏れている可能性が高い。この事象に数分のタイムラグで気がつくことができました。メディアさんへの支払い漏れを高い精度で防ぐことが可能になりました。

田中 とても良い活用法だと思います。Mackerelはサーバー監視を基本とするプロダクトですが、サービスのKPI（Key Performance Indicators）の可視化にも使えます。当初は、サービスの応答時間やエラーレートを想定していましたが、他の用途にも応用できるだろうと思っていたところでした。アドテク分野ならではの問題の解決に応用していただいていて、とても嬉しいです。

久森 KPIといえば、サービス売上のグラフを分刻みで出しています。グラフ上で、青い線を赤い線が上回ったら赤字ですよ、と。それを毎分で出します。

守山 Slackに通知する機能も使っています。例えばCPU消費量などを通知するようにしています。最近は通知だけでなく、直近のグラフもSlackで流れてきます。

久森 この機能は何が良いかというと、「Slackだけ見ていればいい」ことなんですね。画面を切り替えなくても、Slackで直近のグラフが見られる。詳しく知りたいと思ってから、初めて切り替えればいい。

田中 グラフが見えると緊急性が把握できますね。パラメータがじわじわ上がってきたのか、それとも急激に上がってきたのか、で対応が変わります。

Mackerelでうまく監視できない構成は、考え直す

Mackerelを導入して大きく変わったことは何かを教えてください。

久森 運用の仕組みや考え方そのものを変える必要があって、それが実現できました。従来はサーバーのリストのマスターがあって、それをメンテすることが仕事でした。クラウドに移行するにあたって、この管理の仕組みを180度変えたんです。リストのマスターを後生大事に管理するのではなく、ツールに任せようと。 今まではオンプレミスで、データベースに入れたサーバー情報を管理ツールを通して管理する必要があったのですが、それをやめて、むしろ「Mackerelをサーバー管理の中心に据える」発想に切り替えました。この結果、よりモダンな、運用に関する取り組みができるようになり、結果として仕事が減って、本来の価値創造に集中できるようになったんです。

守山 状態をサーバーに持たせちゃうと、急に追加したり抜いたりは難しい。そこで、データは外に持たせて、アプリケーションは伸縮する、という考え方に変わりましたね。

田中 Webシステムの需要は変化していきます。適切なボリュームのリソースを調達する上で、どこまで最適化できるか。手元のリソースもどんどん動的になります。サーバーも増えたり減ったりします。そうした現状に対応できるように……という点は、Mackerelの設計思想として大事なところです。

吉牟田 最初、Mackerelは「ロール単位で複数のサーバーを重ねて見ることができるのが売り」と説明されたのですが、そのときには何が嬉しいのか、ピンと来なかったんですね。でも、Mackerelを導入してから、毎日ロール単位で見るようになって、そのメリットが理解できました。ひとつのロールに10サーバーが含まれていても、Appサーバーとして重ねて見ることができる。以前はこういう見方では見ていませんでした。

久森 従来のツールは、ロール単位ではなくサーバー単位でした。これはオンプレミスの発想です。サーバーという箱があって、箱単位で見る。サービスを作っている人から見れば、機能をわざわざサーバー単位で見ないといけないわけで、確認する心理的障壁が高いですよね。Mackerelの良いところは、ロール単位でグラフを見て、例えば1個だけ太っているグラフがあれば、そのページに飛べばいい。これは大きな違いです。

吉牟田 同じように配置して同じようにリクエストがくるとはいっても、10個のサーバーを見ることはあまりやりたくありません。全体でどうなっているかが分かればいいんです。Mackerelを使った環境はそれを可能にします。リリースして、ツールを見て、短時間でちゃんと分かる。開発してリリースしてすぐチェックできます。

久森 ロールの考え方に沿ってモノを作ることで、構成がシンプルになります。そこから外れそうだったら、むしろ全体の構成を考え直した方がいい。Mackerelで管理できないような構成は、良くない場合が多い。問題の分解ができていないんじゃないか、よりシンプルにできないか……と考えるようにしています。 世の中が進化して、ツールがこれだけいっぱいある。それなのに、エンジニアの仕事が増えるのは、どういうことだと思っています。もっとシンプルにできるはずですし、もっと楽ができるはずなんです。やらなくていいことを、できるだけやらないで、やるべきことに集中したい。生産性をあげて価値を提供するのがエンジニアの仕事のはずです。

クラウドベンダーに「べったり」は避けたい

久森 AWSと一緒に、6カ月Mackerelを使ってきたわけですが、クラウドサービス側にもメトリクス集計機能は用意されています。これを使えばいいじゃないか、という考え方もあるかもしれませんが、クラウドベンダーのツールにべったり依存するのはどうか、という思いがあります。それに、使い勝手が優しくない。 サービスのメトリクスを集計・監視する機能は、できればインディペンデントな方がいいと思います。クラウドベンダー特有の監視機能だけだと嬉しくない。サービスの足回りが悪くなります。

田中 今はAWSのシェアが高くて「一強」の状態ですが、GCP（Google Cloud Platform）やMicrosoft Azureも立ち上がってきました。将来はバランスが変わり、マルチクラウドのユーザーももっと出てくるでしょう。プラットフォームを移行可能にしておきたい人も出てくると思います。そういう観点で、特定のクラウドベンダーから独立したサービスには価値があると思います。

久森 SaaS的なサービスを組み合わせて使うと、1種類のクラウドだけではなくなっていきます。ログ集計にGoogle BigQueryを使って、監視ははてなのMackerel、情報共有はQiita:Team……といった形で複数のサービスを使っています。

最後に一言ずつお願いします。

田中 Mackerelでは、サーバーインフラの指標だけでなく、サービスのKPIも監視できるようになっています。ただ、通知がサーバー系と混ざってしまうという課題があります。そこで、サーバーインフラとは関係がなくサービスのKPIだけ見たい人のために、通知を分離できるようにしようとしています。監視と通知を対応付けて、見たい人に見たい通知を届けられるようにできたらいいな、と。

守山 サーバー管理ツールに自分たちで触れると、考え方が変わります。従来はインフラチームに依頼しないといけないことが、調べれば自分たちでできるようになりました。トラフィックの変化があったとき、その原因を自分たちで切り出せます。カスタマイズも気軽に試して、良かったら採用することができます。

吉牟田 Mackerelは導入が簡単でびっくりしました。他の人に頼らず自分ひとりでできることが増える。あと「はてなのサービス」という安心感もありますね。これまでもユーザーとしてはてなのサービスを使ってきましたから。

久森 導入を通じて、サービスの開発サイクルを高速化できたと感じます。今から自前で監視しろと言われたら困るでしょうね。開発と運用を取り巻く状況は今後も変わっていくでしょうし、今の構成が決定版かというと、もちろんそんなことはないと思いますが、今後も変化させていきやすい環境にできたかな、と思います。

mackerel-meetup-3/slide.md at master · myfinder/mackerel-meetup-3 · GitHub 久森さんが「Mackerel Meetup #3」で登壇した際の資料