service)事業や、年間約405万人(※2019年12月時点)が利用する移動ポータルサイトを運営しています。サイトでは、日本全国の高速バス、フェリー、タクシー、鉄道、ホテルやそれらを含むツアーが予約・決済でき、人の移動のソリューションをトータルに提供しています。数年前には業務システムを外注から内製に切り替えました。クラウドを活用し、自社で開発と運用を手がけています。同社ではMackerelの機能をフルに活用し、システムの状態を可視化したダッシュボードを大型モニターに映し出し、チーム内の情報共有に役立てているそうです。Mackerelのアラートステータスウィジェット機能は同社の要望を取り入れて作られた経緯もあるようです。現在、マイクロサービス化、コンテナ対応に取り組んでいる最中の同社に、はてなMackerelチームがお話を伺いました。スピード感を求め外注からクラウド上の内製へまず皆さんのご担当を教えてください。)がWILLERのインフラ担当です。分業制で、僕はデータベースをメインに見ています。田崎はどちらかというとサーバー環境。ECSを選択する場合もあります。廣田はネットワークを見ています。業務システムはクラウド上で内製しているのですね。WILLERはもともと外注でシステムを作っていて、運用も外注していました。その状態だとスピード感がなく施策が後手に回ってしまうという課題がありました。そこで、スピードを出すために開発チームを社内に持とうと意思決定をしてチームを作り始め、前職同じ職場で働いていた僕や廣田が集められました。私が入社したのが約5年前の2015年の2月です。そこから「変えていこう」という動きが始まりました。お話を聞いた時点ですでにクラウドシフトが完了していらっしゃいましたよね。他の企業様がクラウドシフトの過渡期にある中で、WILLERさんのスピード感に驚きました。「データセンターでは運用が回らない」というのが僕らの実感です。遠方に出かけて作業するのは苦痛が大きいので、選択肢は自然とクラウドになります。そこまでの意思決定は早かったですね。Mackerel導入の意思決定もスピーディでした。いった、新しいものをスピード感をもって選択していく、といったWILLERさんに根付いた風土を感じました。現場の要望に対して「やってみたら?」という前向きな雰囲気は、他社に比べて凄くあると思います。逆に責任者が「使ってみたいから」といった理由でツールを選定したりするケースもありますね。チャレンジを受容する風土のある会社だと思います。高速バスのオンライン予約を24時間365日動かすWILLERさんの業務システムの概要について教えてください。WILLERは、高速バスや旅行商品などの幅広い商品のオンライン予約のシステムを運営しています。要求されているのは、24時間365日いつでも予約でき、予約確認や変更の機能が使えることです。御社の業務システムにとって、監視ツールはどれくらい重要だったのでしょうか。システムに問題があると基本的なサービスが落ちたり、決済ができなかったりする事象が発生します。その原因把握までに時間を要してしまう事例が過去にあって、監視ツールは重要なファクターであるという認識がありました。2019年12月)Mackerel導入前の監視はどういった状況だったのでしょうか。ダッシュボードおよびメール通知の仕組みをPerlスクリプトを組んで自作していました。Services)を使い始めていました。Mackerel導入の動機は「誰でも触れるダッシュボードが欲しかった」ことです。自作のダッシュボードでは属人化してしまい、チームとしてどう対応するのかが難しかった。インフラエンジニアだけが触れるダッシュボードになってしまっていました。10名前後の社員です。そのうちインフラエンジニアはここにいる3人。残りはアプリケーション開発に関わるメンバーです。自作のダッシュボードの属人化が課題だったのですね。それまで使っていた自作ダッシュボードのままでは担当者が休むと触ることができません。みんなでダッシュボードを見て、触って、どこがボトルネックなのかを把握し、問題解決ツールとして使えるようにしたいと考えていました。それまでの手作りには限界を感じていました。あの自作ダッシュボードは廣田の努力の集大成なんです。監視すべき部分を最低限押さえることはできていましたが、台数の増減にどう対応するかという課題がありました。既存のOSS、もしくは商用の監視ツールだと、サーバーダウンが発生した場合に監視しているすべての項目についてアラートが発生していて、しかもそれが1台ずつ全てに対して起こるので、それが辛かった、というのもあります。クラウドの世界になると、(個別のサーバーの)死活はあまり参考になりません。サービスが生きているかどうかが重要ですので。Mackerelもそのような思想で設計されています。一点、監視で大変なのは監視ツールが生きているかどうかを見る「監視の監視」の必要が出てくることです。前職では2系統で相互監視していました。Mackerelだとその必要がなくなります。具体的にMackerelの導入検討を始めたのはいつ頃だったのでしょうか。2018年の夏頃です。開発側のエンジニアもインフラエンジニアも触れるようにしたいということで、8月から9月にかけて検討、トライしてみました。同じ時期に海外でも人気があり、グラフィカルにダッシュボードを作れる海外製品と比較検討しました。私たちがお会いしたのはちょうどその頃、2018年夏のセミナーでしたね。セミナー後にハンズオンをさせて頂く機会を頂いたので1〜2時間体験していただきましたが、そこで大丈夫そうだという感触は持って頂けたと感じました。導入の素直さに惹かれました。できることの幅も、井上さんに質問して回答していただいて、これならアプリケーションの監視ができるな、と。当時からSlackは導入していましたので、監視ツールが出すアラートがどういう形で飛ぶのかをテストしました。実験用の環境があり、そこで実際にインスタンスに負荷をかけるテストを実施して、どこまでステータスが取れるのか。どれだけ使えるのかを試しました。これまでの監視ツールでは、どのメトリックを取得するかは都度調べて、コマンドの組みあわせで決めていました。Mackerelはエージェントがあり、どのメトリックを取得すればいいのかが分かりやすいセットとして揃っています。それをダッシュボードにグラフィカルに配置するだけで傾向を見ることができますし、見やすくもなります。WILLERさんはMackerelを使って精緻なダッシュボードを作っているのですが、直感に訴えかけていますよね。数値ではなくグラフで、どういう傾向にあるかを分かるようにしてらっしゃいます。私自身もともとアプリケーションエンジニアなのですが、そのような作り方をしているのを見てとても驚きました。傾向は重視しています。その瞬間の数値だけを見ても分かりづらいところがありますので。導入事例資料をご希望の方はこちらをどうぞ。こんなに楽に監視できるものがあるんだという驚きがありました。自分で運用することなく、土台を用意せず、さっと今の環境に適用できます。Mackerelの場合はエージェントをインストールすると自動的にメトリックが取られていきます。従来の自作監視ツールでは、テンプレートとなるスクリプトが用意されているのでそれを調整しひとつひとつをcronで回し、それらのメトリックを集約するサーバーを用意していました。それに比べるとMackerelは楽です。「監視は楽しい」「使ってみたい」という欲求が生まれてきます。システムを改善していく上で土台になるなという感触もあります。「楽しい」「使ってみたい」と思っていただけることを大事にしているので嬉しいです。CloudWatchだとデータの保持期間がMackerelほど長くないんです。5分おきのメトリックだと2カ月ぐらいですね。見たいのは、季節要因も考慮できるような、もっと長い期間のデータだったんです。その点では、Mackerelでは1分粒度のデータを460日間、保持しています。長期間データを俯瞰して確認できることはもちろん、いつでも遡って1分単位のデータを見ていただくこともできるので、WILLERさんのご要件にもぴったりでしたね。オートスケーリングにより、サーバーの増減が動的に発生するということもクラウド環境ならではの特性です。した特性は便利ではあるのですが、そのぶん、コストと必要リソースの最適化が難しいですね。長期間データの保持を機能として提供している理由の一つです。新機能アラートステータスウィジェットは、要望からリリースまで2カ月Mackerelの新機能「アラートステータスウィジェット」はWILLERさんの要望がベースになっているのですね。ひとつの大きなダッシュボードの中で、俯瞰的に多数のサービスを見る方法はないか、という相談をしたんです。結果として、信号機のように赤、黄、青で表示するウィジェットができました。田崎さんにアンケートにくわしくお答えていただいたので、もう少し詳細を伺うために訪問させていただきました。そこでいただいた要望のうちのひとつが、いま仰った「管理しているサーバー群のどれくらいが正常で、どれくらいが問題のある状態なのかどうかを、俯瞰的に把握したい」というものでした。実は、これに似たご要望を他のお客様からも伺っていたということもあり、ちょうど私も同じ課題意識を持っていたところでもあったので、社に持ち帰り検討しました。そのときの開発リソースとのかみ合わせも良かったこともあり、要望をお伺いしてから機能としてお届けできるまでの期間が2カ月、という、比較的短い期間で機能リリースを実現することができました。いうのは、一生リリースされないこともあるから。理想的には、シグナルのマルの大きさをもっと大きく、サイズを変えられるようにしてほしいです。オートスケール前提だとマルの数が凄いことになるんです。10台、20台になるともう追えないので。追加のご要望、ありがとうございます。こちらについても、社内外の意見とも合わせて、検討していきたいと思います。社内からの意見も重視するのは、はてな自身がMackerelを大規模に使っているユーザーでもあるからです。Mackerelは「最高のドッグフーディング環境」(ドッグフーディング:製品・サービス提供をおこなう企業の社員が、自社製品や自社サービスを日常的に利用すること)で開発しています、というのは、普段からお客様へお伝えしていますね。「この機能があったら、我々もそれを使うだろうか?」という点を吟味して作っています。いう機能選定基準やスピード感も、私たちの会社やプロダクトの良さだと考えていますので、いい意味でそのことを利用していただければ、と思っています。お客様のご要望から生まれた「アラートステータスウィジェット」ですが、我々自身にとっても欲しいもの・あるべきものが出せたと思っています。この機能は正式リリースの後、即日使っていました。ブログダウンタイム機能が出たらすぐ利用、アラート抑制のため従来型の監視ツールは、夜中でもアラートが飛んでくる形だったのでしょうか。外注先に運用をお願いしていた時代には、数字だけのアラートが飛んできていました。そんな感じだと、そのうち受け取る本人が反応しなくなっていくんですよね。夜中に送られてきても、対応は出社してからでいいや、となってしまっていました。いった経験があるので、不要なアラートは出さないようにしたいと考えています。深夜帯には監視が不要になるインスタンスのアラートが鳴ったこともありました。そんな、ちょうどいいタイミングでMackerelのダウンタイム(時間帯を設定して監視を停止する機能)がリリースされて。それも使ってアラートを抑制するようにしました。WILLERさんだけでなく、他にも多くのお客様からご要望いただいていた機能でした。喜んでいただけてとても嬉しいです。マイクロサービス化とコンテナ対応に取り組むコンテナ環境については、どのような取り組みをしていますか。今年の夏頃から、新しい取り組みが始まっています。ひとつのモノリシックなサービスとして作っていました。ECSを活用してコンテナ化に取り組んでいます。CloudFormationでサーバー構築をコード化しようとしています。この新しいサービスの監視もどうするかな、と考えているタイミングで、ちょうどMackerelのコンテナエージェントがプレビュー版の段階だったので、実際に試してみました。CloudFormationに適用する例もドキュメントに載っていたので構築は簡単にできました。すべてのタスク定義にMackerelのコンテナエージェントを載せています。基本的にはコンテナエージェントで取れているもので十分と判断しています。コンテナが持っている上限のメモリ、タスクごとの上限も把握できます。どれだけリソースを担保すればいいかを視覚化できればいいと思っています。大型モニターにダッシュボードを表示、コミュニケーションに役立てるチーム内への監視ツールの普及のため、どのような働きかけをしていますか。これまでの監視ツールのダッシュボードの画面を、Mackerelの画面に取り替えてみたり。エンジニアの話を聞きながら、徐々に慣れてもらうようにしました。チームが監視に対してどのように理解しているか、どういったメトリックを見ていけば良いかといった意見を聞きつつ導入してきました。大きいのは、みんなが見える位置に大型モニターを置いたことでしょう。Analyticsの情報も合わせて出して「どのページにアクセスがきているぞ」と分かるようにしています。すると、アプリケーションエンジニアが「いつもとパターンが違うぞ」と言ってくることがあります。大型モニターがアプリケーションエンジニアからも見える場所に置いてある。それで、アプリケーションエンジニアの方から「グラフの傾向がいつもと違うぞ」と言ってきて、お互い調べ始めたりします。いろいろな人が通る場所に置いてあるので、そこからコミュニケーションが生まれたりしています。それはとてもいいですね。Piを使ったので4KモニターなのにフルHDで表示しています。情報を出したいなぁと思っています。実は、前職でも50インチモニターを2台並べていたんです。その時代には液晶の50インチが手に入らなかったので、高価で重いプラズマディスプレイを使って。きれいに焼き付きました。前職ではプラズマ2枚のうち1枚はシステムの稼働状況で、もう1枚は営業の状況を表示していました。WILLERではまだ1枚です。システム部は社内で「何をやっているか分からない」と言われやすいので、こうしてモニターを社内の見える場所に置いておくとシステム部以外の社員からも興味を持ってもらえます。「これ、どういうグラフなの?」と聞いてくれたり。管理部門のマネージャーも話しかけてきます。ここでクリティカルな数字になったら色が変わるとさらにいいんですよね。Mackerelをそのように使っていただく事例が、世の中にもっと広まってほしいです。今回WILLERさんからご要望いただいたようなさまざまな情報を見やすくする機能、サービスの容易性、これらの特性も今後は追求していきたいと思っています。皆さん、ありがとうございました。CAFE導入事例資料をご希望の方はこちらをどうぞ。Ltd.日本語English。