Mackerel（マカレル）導入事例 GMOペパボ様：情報を集約してインフラの競争力を高める！　プライベートクラウドへの移行に合わせてGMOペパボが、Mackerelを大規模導入

株式会社はてなサービス開発本部ディレクター兼チーフエンジニア松木雅幸
株式会社はてなサービス開発本部プロデューサー杉山広通
GMOペパボ執行役員CTO栗林健太郎さん
GMOペパボ技術部技術基盤チーム柴田博志さん
GMOペパボ技術部インフラグループ高谷雄貴さん
インタビュー星暁雄（ITジャーナリスト）

記事公開日： 2016年2月2日 · 所属はインタビュー当時のものです

インフラ基盤などの監視に500台弱を導入

自己紹介をお願いします。まず、はてな側から。

杉山 2015年9月からMackerelのプロデューサーをしています。前職は製造系SIで、サーバーやネットワークなど数千台規模の環境を、インフラエンジニアとして企画から運用まで見てきました。ここ数年はITILベースのサービスマネジメント領域のプロジェクトを牽引し、マネジメント経験を積みました。これまで便利な仕組みやサービスは海外発のものが多かった中、日本発で国際的に勝負できるものに携わりたい、それをMackerelで実現したいという思いで今の仕事をやっています。

松木 Mackerelの開発ディレクターをしています。アプリケーションエンジニアでもあるので、エンジニア向けのサービスであるMackerelに関われることに面白さを感じています。

栗林 GMOペパボの執行役員CTOをしています。呼び名は「あんちぽくん」の方が通りがいいかもしれません。CTOなので、あまり手を動かすことはないんですが、GMOペパボではインフラ基盤を大きく刷新している最中で、その技術的な舵取りをしています。新しい基盤に向く運用管理ツールは何だろう、ということでMackerelを選びました。

柴田チーフエンジニアです。CTOの栗林が決めた方針や戦略を、粛々と実行する仕事をしています。Mackerelは使っていて楽しいし、プログラミングのしがいがあると感じています。自分たちでプログラムを書いて、サービスを動かせるのが楽しいです。

栗林いじりたくなる（笑）。

柴田そんな感じです。自分たち用にグリグリ触って、たまには穴を見つけたりする（笑）。こういうのもできちゃうんだと。そういう形でサービスへの導入や普及活動を進めています。

高谷ブログサービス「JUGEM 」のインフラを主に見ています。以前は（サーバー監視ツールの）Munin やNagios を使っていたのですが、社内でインフラをプライベートクラウドに寄せていく中で、今までのツールではクラウドのアーキテクチャに載せるのに難しい部分があり、Mackerelを使い始めました。使いやすいし、監視やメトリクスを取る以外にもいろいろ使えそうだと感じていて、模索中です。

Mackerelを導入した時期はいつ頃ですか？

柴田 Mackerelのリリース当初（2014年9月）から2〜3台で試していて、2015年の1月から2月頃にかけて、ハンドメイドマーケットのサービス「minne（ミンネ）」にガツンと導入しました。100台規模で「これからはこっち側にいくぞ」と。

栗林インフラ基盤として正式には、2015年の4月からです。

高谷私が（JUGEMで）触り始めたのが、2015年8月頃です。

栗林今は、ホスト数でいうと500台弱には導入していますね。

プライベートクラウドへの移行に伴い、新たなツールが必要に

500台ともなるとかなりの規模ですが、Mackerelを導入するに至った背景はどのようなものでしょうか？

栗林大きくは、クラウドに移行したことが理由です。GMOペパボはいろいろなサービスを手掛けていますが、全体像からお話しすると、ホスティング、EC支援、コミュニティの3事業に分かれています。ホスティングはレンタルサーバー「ロリポップ！」や、ドメイン管理の「ムームードメイン」など。EC支援は、ネットショップを持ちたい人を支援する「カラーミーショップ」などで、2015年は特にminne（ミンネ）に注力してきました。コミュニティ事業としては、JUGEMや、CGM系のサービスです。このように事業領域は3つですが、サービスの性質は大きく2つに分かれています。ホスティングでは、いかにお客さんにサーバーを使ってもらうかが勝負なので、ハードウェア特性が大切です。これはガチガチにオンプレミスでやった方がいい。それとは逆に、コンシューマ向けWebサービスでは機動性がコストに効いてくるので、プライベートクラウドに移していこうとしています。そうなると、今までのようなサーバーの入れ替えが起こらない世界から、サーバーがポコポコと立ち上がったり消えたりする世界になっていく。監視対象の個別のサーバーが常に入れ替わる世界なので、スタティックなファイルベースの設定とは相性がよくない。アーキテクチャが（クラウドに）変わるのでツールも変えましょう。ということで、Mackerelを全面的に投入しているところです。具体的には、3つの事業領域でそれぞれWebサービス側、ホスティングでは（サーバー側ではなく）ユーザーに見せるポータル画面や管理画面など。ECでは、ショップのカートの決済機能を構成するマイクロサービスのうちいくつか。それに、JUGEM。こうした部分をすでにプライベートクラウドに移しており、そこにMackerelを入れています。

プライベートクラウドの移行が大きいトリガーだったのですね。

栗林 Mackerel導入にはもう1つ、インフラをガラッと入れ替えるタイミングで、情報を集約する仕組みを導入したいという狙いもありました。サーバーがたくさんある中で「このサービスのこのサーバーを見たい」わけではなく「全体として」今どうなっているのかを見たい場合もあります。それが今までのツールでは難しかった。例えば、ある場所はCSVで管理していて別の場所ではYAMLという状況だったのを、技術的な統制をかけて統一的に見られるようにしたかった。Mackerelを使うことで否応なく情報が集約される側面があります。

作るのが得意なエンジニアがMackerelで自動化に取り組む

Mackerel採用について、現場の観点からもお話しいただけますか。

柴田もともとアプリケーションエンジニアですが、サービスに必要なものはインフラも含めて、すべて自分で手を動かして開発してきました。そのため、既存ツールに対する特別な思い入れは、あまりありません。死活監視とリソースのモニタリングができればなんでもいいと思っています。使いやすさには、そもそもツールとして使いやすいものと、慣れているから使いやすいことがあると思います。例えば、慣れている人にNagiosはものすごく便利だけど、慣れていないとつらいツールだと感じます。Nagiosを勉強するより、今すぐ目の前の問題を解決したいというモチベーションが高かったので、minne（ミンネ）ではMackerelを全面的に導入しました。プライベートクラウドを作る過程で、今までインフラエンジニアしか触っていなかったサーバーを、アプリケーションエンジニアも触るようになってきました。（プライベートクラウド基盤の）OpenStack に限らず、AWS （Amazon Web Services）でも、Googleのクラウドサービスでも同じですけど、インフラ専任じゃない人でもサーバーをどんどん作って、サービスを開発できる時代の流れもあり、「Nagiosは分からないけれど、監視はやらないといけない」「Muninは分からないけれど、CPUのレートを見ないとサービスが維持できない」といったエンジニアも増えてきた。それなら、最初からある程度用意されているものを使って、目の前の問題を解決しよう。そういう考えでMackerelを採用しました。

栗林プライベートクラウドを使うことによって、「サーバーの側を自動化していきましょう」という話になります。開発の人はコードを書くのが得意なので、「監視も同じ水準で自動化しましょう」となるのが自然です。

アプリケーションエンジニアがインフラを意識し可視化

杉山 Mackerelの導入によって、インフラエンジニアだけでなくアプリケーションエンジニアもインフラを見るようになったということですが、それによってどんなことが起きるのでしょう？

柴田アプリケーションエンジニアも、自発的にインフラの運用を気に掛けるようになります。サーバーが過負荷になりそうなときや、メモリを使い切ってスワップしそうなときに気が付くようになりますね。

杉山インフラエンジニアとは違う視点や、知見もありますか？

柴田サーバーが重たいとか、サービスのレスポンスが遅いということには気付きやすいですね。開発と運用のチームが分断されていると「そこから先はインフラエンジニアに任しておこう」となりがちですが、サービスを作るスタッフが気になる部分に目を向けやすくなっていると思います。

杉山インフラエンジニアとアプリケーションエンジニアが助け合えることはありますか？

柴田監視プラグインを、アプリケーションエンジニアが書いたりしてますね、書くのは得意なので（笑）。「DBのこのカラムのこの数をカウントすれば、ジョブがどれだけ滞留しているか分かって、値を取ってグラフにプロットすれば便利だと思いませんか？」「はい！」みたいなやりとり（笑）から、Ruby on Rails で動いているバックグラウンドのジョブ監視をアプリケーションエンジニアが書きました。インフラエンジニアじゃなくても、プロットした数値から自分たちのサービスを見るという動きもあります。

松木インフラチームと開発が切り離されていると、なかなか気付けないですからね。グラフがSlack に投稿されていたりすると、傾向が変わってきたところで、アプリケーションエンジニアも「あ、さっきのデプロイがまずかった！」と気付きやすくなる。いいサイクルが回しやすくなりますね。

杉山ビジネス側のメンバーとはどう共有していますか？

柴田 Mackerel導入以前からそうなのですが、Slackに赤い文字が流れると「大丈夫？」と聞かれます（笑）。

高谷 Slackを全社的に使い始めたときに、アラートが上がったらCPU利用率などのトレンドをグラフで出そうとしたのですが、Mackerelにはすでに機能があって衝撃的でした。「使うしかない！」と。 Mackerelはエージェントタイプの監視ツールで、サーバーが増えたのにconfigに追加し忘れて監視できない、ということも防げる。すごく便利だと思いました。Muninで管理していたころには、サーバーを増やすたびに管理ファイルに追記していたのですが、サーバーが増えてくるとたまに忘れることがあって、「ないじゃん！」となる（笑）。Mackerelには、そうした漏れをなくす効果がありました。エージェントタイプには他にもZabbix とかSensu がありますが、新しいツールを勉強して導入するのもつらい。

プラグインには「作る楽しさ」がある

松木もともとの独自環境からMackerelに移行して、困ったことはありましたか？

高谷ありません。Mackerelで「NagiosやMuninのプラグインをそのまま使える機能」がリリースされていたので、特に問題なく移行できました。

杉山補足しますと、Mackerelのプラグインは、人気のOSS監視ツールであるNagiosやSensuのプラグインとほぼ同じ仕様にしているので、Nagios（Check系）やSensu（Check、Metric系）でも利用できますし、逆にNagiosやSensuのプラグインをMackerelで利用することも可能です。さらに、データフォーマット変換用のプラグインを使うことで、Muninのプラグインも利用できます。

柴田僕はプラグインが大好きで。プラグインは「プログラミングの最初の一歩」にめちゃくちゃいいんですよ（一同、うなずく）。プラグインなら、シェルのワンライナーでも機能を満たせばいいわけですし、ちょっと頑張れば、CでもRubyでもGolang でも書ける。やりたいことだけを実現するプラグインを書いてポンと入れると、あたかも元からMackerelの一機能だったかのように動いてくれるので、エンジニアとして「やってやったぜ！」という楽しさがあります。

ミドルウェアのメトリック可視化に公式プラグイン集を使う

松木そういうところがありますね。プラグインのシステムがあると、ちょっとしたものを動かすだけでも貢献できた気がしてすごく嬉しい。Mackerelでも、プラグインを作る人のコミュニティを育てていきたいと思っています。

杉山 Mackerelはエンジニアがワクワクする仕組みでありたいと考えていますので、プラグインで喜んでいただけたのは嬉しいです。自発的に使ってみたくなる仕組みでないと、本来の価値が引き出せないと思っています。

一番大事なことは「現場で使われる」こと

松木採用にあたっては、どんな基準で検討したのでしょうか？　他のツールと比較したりは？

栗林他のツールも検討しました。例えば、Datadogですね。既存の他のツール、例えばNew Relicでも、よりお金をかければ（笑）使えないわけではありませんが、Mackerelは、はてなから提示いただいた価格が機能に見合っていた（笑）。

松木 New RelicとMackerelの使い分けはどうしていますか？

柴田 New Relicは、アプリケーショントレーサーですね。どのSQLにどれぐらい時間がかかったか、それぞれのリクエストがディスパッチされて内部で処理してレスポンスが返るまでどれだけ時間がかかったか、などなど。サービスの上の方でリソース管理に使っている感じです。それより下の方、そもそものサーバーがどういう状態にあるか、いつスパイクしたか、などはMackerelで見ています。

栗林採用にあたって一番大きかったのは、現場で使ってくれるかどうか。価格が安いことも機能が良いことも大事だけど、誰も使わなかったら導入した意味がない。プラグインの仕組みにおけるコミュニティ形成にしても、技術力にしても「はてなだったらやってくれるだろう」みたいな信頼もあります。

機能や価格以上に、エコシステムや、幅広いユーザーが使いやすいかどうかが大切だったのですね。

栗林そこが一番重要なので。

柴田エコシステムということでは、日本のWeb界隈のインフラの人たちが、会社を越えて知見を共有している度合いは業界でも特別だと思います。はてな製のツールということで、そうした背景を共有している安心感はあります。フィードバックするときも説明が通じやすい。海外製のツールでは、説明の時間が余計にかかります。

松木はてな社内では、もともとMackerelをサーバー監視と、もう1つサーバー管理にも使っていました。そのため、サービス管理・サーバー管理を統合した部分があり、サーバーの中からデプロイ対象を洗い出す際にも、Mackerelから情報を取得しています。そういった管理の面で利用している事例はありませんか？

高谷デプロイ対象をどう管理するかが一番問題です。ファイルで管理していると、記入を忘れてデプロイされないといったことが起きます。Mackerelで管理していれば、本番環境に入っているサーバーがデプロイ対象から漏れるといったミスは起こりにくくなりますね。Mackerelのmkrコマンドで、ホストの一覧がサービス、ロールの単位で取れますから。ホスト名とインタフェースのIPアドレスのペアを引っ張ってきてhostsファイルを作るといったことも、Mackerelでやってます。DNSを立てるほどではない場合に便利です。

柴田面白い使い方なら、Mackerelのサーバーライセンス数を、Mackerelで管理しています。アクティブなホストを取ってきて、契約の上限に近づいたらワーニングが出る（笑）。グラフ化も簡単です。

松木どんなものでもグラフ化することに慣れてしまうと、用途が広がるので面白いですね。

杉山広告の分単位の売上をグラフにして、減るとアラートが飛ぶ、といった使い方をしているお客様もいます。マニアックな使い方では、シングルボードコンピュータの「Raspberry Pi」にエージェントを入れて、不快指数が一定値を越えると「空調の設定温度を変えてください」と総務部に連絡するとか（笑）。

松木 MackerelはAPIデザインにもこだわっていて、ハックしやすい作りになっています。そのため、何かを作るときの敷居が、アプリケーションエンジニアにとっては低いという特徴があります。

そういった拡張性の部分で、要望などはありますか？

栗林サーバー管理、インベントリ（資産管理）の仕組みとして見ると、ホスト名に紐付く属性がもっとあるといいですね。

松木そういったフィードバックは日常的にSlackのチャンネルに流れてくるので私たちも見ていますが、ありがたいし、励みになります。

インフラの競争力を高めるため、Mackerelには厳しい要求を

栗林「自分のドッグフードを食え」という言葉があるけれど、はてなの中ではMackerelを使っていますか？

松木使っています。特に新規サービスなどでは、積極的に利用しています。ただ、運用上の都合があり、はてなのインフラに特化した機能の残っている、古いバージョンのMackerelを使っているところもあります。Mackerel自体の監視などですね。もっと、Mackerelだけに寄せていきたいと思っていますが、Mackerel自体で障害を起こしてしまってはユーザーへの影響が大きいこともありますから。

監視ツールは、ミッションクリティカルな部分でもあるのですね。

栗林 GMOグループはホスティング中心の会社なので、サーバーを自分たちで運用するところで競争力を出そうとしています。そこでOpenStack系の技術には大きな投資をしています。お話ししてきたように、実運用しているサービスでも使い始めているところです。そのため、監視ツールにも、OpenStack環境をいかに効率よく動かして競争力を高めるか、という役割があります。そういうツールを、僕自身が頑張って作ろうと思っていた時期もありました。以前、はてなという会社にいたことがあって（爆笑）、そこにはMackerel的な内部ツールがすでにあり、ああいうものがあれば便利だろうと考えたんですね。結局は、（そのツールの後継にあたる）Mackerelを導入したわけですけど。

柴田プライベートクラウドでは、ホストサーバーの監視がすごく重要です。特にリソースコントロールに敏感にならないといけません。Mackerelが入っているサーバーの数として先ほど500台弱という数字が出ましたが、そのうち200台弱がプライベートクラウドを動かすホストサーバーの監視です。

松木プライベートクラウドの基盤を作る上では、同じノード内に同じサービスを同居させないといった工夫があると思いますが？

柴田そういう工夫は取り入れています。OpenStackは、AWSでいうavailability zoneを自分で作れるんですね。特定のラックやPCゾーンに集中しないように、サービスごとある程度バラバラに載せるようにします。例えば「JUGEMはこのホストサーバーに全部入ってます」だと、ホストがダウンしたときにサービス全体が簡単に死んでしまうので。問題としては、OpenStackのリソース管理機能は「空き容量」しかないんですね。CPUに16のコアがあって、どのコアがどれぐらいの利用率か、などは見てくれない。そこはMackerelに期待したいところです。

Rubyの開発サーバーを支えるMackerelの無償OSSプラン

柴田さんはRubyコミッタですね。Rubyの開発サーバーにもMackerelが入っているそうですが、それについて教えていただけますか？

柴田 ruby-lang.org というWebサイト群がありまして、一部分はクラウドサービスに載せていますが、ビルドサーバーは物理的なサーバーで、リリースごとにビルドをしています。Rubyの開発面ではフルタイムで働いているコミッタもいるのですが、インフラは実は完全にボランティアで、僕とあと2名が趣味のような形で運用しています。でも、サーバーが落ちると、コミッタやユーザーからむちゃくちゃ文句を言われる。そこで、はてなCTOの田中慎司さん（Mackerelの初代プロデューサーでもある）に相談して、Mackerelを無償で導入しています。ディスクフルが近づいたらアラートがくる、といった機能を使っていますね。

松木 MackerelではOSS向けのプランを提供していて、Rubyプロジェクトにもそれを利用してもらっています。OSSプランでは、標準機能を無償でフルに利用できます。最近のオープンソースプロジェクトは、以前よりクオリティへの要求が高くなり、サーバー費用などの開発コストもかかるようになっています。はてなは、多くのOSSを活用しながらサービスを展開している会社なので、コミュニティへの還元の意味でも、Mackerelで支援できるといいなと思っています（※OSSプランにご興味のある方はぜひお問い合わせください）。

まとめ

今回、プライベートクラウド基盤のOpenStackとMackerelを本格的に導入したわけですが、今後の展望は？

栗林前述したように、GMOグループはホスティング中心の会社です。サーバーを自分たちで運用して、そこで競争力を出す。インフラを自分たちで構築してサービスを提供することにこだわりたい。その過程でOpenStackには大きな投資をして、実運用を始めています。はてなのMackerelの力を借りて、この基盤を強化していきたいと思います。

柴田 Mackerelをうまく使って、自分たちがやりたいことをやっていきたいですね。MackerelのエージェントはOSSなので、それを自分たちでいじってOpenStackの情報を登録できるようにしたり、そういった外部から貢献できる範囲でMackerelを開発するのもいいかもしれない、と思っているところです。

どうもありがとうございました。