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