サービスが増え、少人数でのインフラ管理が課題に

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

田中 はてなでCTOをしている田中慎司（id:stanaka / @stanaka）です。今回は「Mackerel」正式リリースということで、初期ユーザーとして使っていただいているヌーラボさんのお話を伺いにきました。

Mackerel: A Revolutionary New Kind of Application Performance Management

染田 ヌーラボ テクノロジーエバンジェリストの染田貴志（id:tksmd / @tksmd）です。今日は京都支社からテレビ会議で参加しています。

中村 ヌーラボ エンジニアの中村知成（id:ikikko / @ikikko）です。プロジェクト管理ツール「Backlog」をメインに担当していますが、兼任でインフラも見ています。Mackerelの導入支援や設定を手掛けました。

Fun. Creative. Collaboration. | ヌーラボ [Nulab Inc.]

Backlog [バックログ] - チームではたらく、すべての人のためのプロジェクト管理ツール

ヌーラボがMackerelを導入した背景を教えてください。

染田 ヌーラボでは、オンラインで図を作成するCacoo、プロジェクト管理のBacklogの2つのサービスについて、少人数で開発運用を続けていました。ところがそこに、2013年秋ごろからチャットサービスのTypetalk、シングルサインオンのヌーラボアカウントが加わって、管理するサービスが4種類に増えました。倍増ですね（笑）。そこで、インフラ運用、中でもモニタリングが課題となりました。 サービスを自社で運用している人には分かってもらえると思いますが、モニタリングの環境の準備と運用にはそれなりに手間がかかります。自分たちの運用スタイルに合ったサービスということで、はてなのMackerelを試したいと思いました。

田中 2013年末に「Mackerelっていう新サービスを考えているんだけど、話を聞いてくれませんか」とヌーラボさんをお訪ねしたんですね。そうしたら、ちょうどいま染田さんがおっしゃったような状況だったこともあって、予想以上にノリが良かったんです。それ以降、フィードバックもいただいたりしています。開発段階からユーザーさんがいることは、デベロッパにとっても心強いことです。

染田 ヌーラボの文化かもしれませんが、新しめのサービスや開発フレームワークなどには飛びつく人間が多いもので。 ここにいる中村も、2〜3年前からVagrantなどのツールを使ってパッケージ環境のテストやビルドをやりやすくできないか、インフラ方面でも結構試みています。新しいサービスのTypetalkでも、AngularJSなど、トレンドになっているテクノロジを取り入れています。

京都オフィスでの交流が縁で初期ユーザーに

染田 私と田中さんが同じ京都にいたことは、Mackerelの初期ユーザーになったきっかけの1つですね。はてな本社オフィスのセミナールームをお借りして、AWSやFlexなどの勉強会をさせてもらったり、というのは前からあったんです。開発者コミュニティの関わりで知り合いになった感じですね。

中村 Mackerel導入は、染田と、私と、もう1人インフラを見ている者の3人で進めました。

染田 段階的に、徐々に導入していきました。最初からプロダクション環境に適用することはせず、新サービスの開発環境のモニタリングなどから試しました。 最初、怖かったのは、（モニタリングをする）エージェントが暴走するなどが起きて、プロダクション環境に影響を与えないだろうか、ということでした。なので段階的に導入しなきゃということで、新しくスタートしたばかりのサービスならいきなりピークががんと上がることもないだろうと、新サービスの一部に入れてエージェントの様子をうかがいながら、Mackerelを試していきました。その結果「エージェントが悪さをすることはないね」と確認できたので、導入サービスを増やしていきました。 とはいっても、かなり早い段階でプロダクション環境にもMackerelを入れていくことになりましたね。

田中 プロダクション環境に新しいものを導入するのはリスクが伴うことなので、大胆に導入していただいたことは有り難いと思っています。はてなの自社環境でも、すでにプロダクション環境のモニタリングにMackerelを使っています。

改めて、ヌーラボがMackerelに注目した理由をお聞かせください。

中村 従来使っていたモニタリングツールの、運用の負担が大きかったことがあります。一つ一つの設定は大した負荷ではありませんが、台数が増えると保守・運用が大変な手間になります。そこを手間をかけずに済ませたいと考えました。導入のタイミングとして、ヌーラボのサービスが4種類になって、インフラに目が届きにくくなっていたという事情もあります。それぞれのサービス担当者がインフラのメンテナンスをしていける体制にしてきたいと考え、外部サービスであるMackerelを導入しました。

染田 それまで、モニタリングツールは「Munin」を使っていました。Perlで書かれたツールなのですが、依存ライブラリがたくさんあり、インストール時にいろいろなライブラリを導入する必要がありました。エージェントのバージョンを上げたり、32ビットから64ビットに変わっていったりと徐々に変わる環境の中で、依存関係を含めてちゃんとメンテナンスしていく手間が負担になっていました。 また、Muninはサーバー側でグラフを生成するのですが、台数が増えて生成するグラフが増えると、Muninサーバーの負荷が増えてグラフ生成が追いつかなくなることがありました。「Muninサーバーの管理」という、本質的ではない部分に、相当な手間が発生する状態になってしまったんです。 Mackerelは、エージェントがGo言語で書かれていて依存関係を気にせず使えます。サーバー管理も必要ありません。複数の環境が混在することに伴う苦労がなくなりました。

Mackerelの導入で運用の負荷を減らし、サービス立ち上げを迅速にしたい

田中 MackerelのエージェントにGoを使った意図は依存関係の最小化にあったので、そこは狙い通りですね。 はてなでも、もともと社内のサーバー運用ツールにコストをかけていました。ただ、これは各社共通にできる部分でもあり、会社ごとに個別にサーバー監視のコストをかけるのはもったいないのではないかと。 ネット業界には、サービスのコアに集中して、コアではない部分は外部サービスを使いましょう、という流れがあります。チャットツールのSlack、リポジトリのGitHubなどの利用もその流れの上にあります。昔だとチケット管理にRedmineを使っていた部分も、今は外部サービスを使おうという流れになっています。 また、最近の開発の流れとして、チームを作ってサービスを開発して、うまくいかなかったらすぐ縮退、といったスピーディな取り組みが増えています。ツール周りを全部自社でやっていると、立ち上げと縮退に時間がかかります。外部で調達できるツールは調達して、サービスに集中し、いらなくなったらツールは解約する、そういったニーズが生まれています。インフラのAWS（Amazon Web Services）が流動的な需要に対応しやすいことから使われているように、ツールも外部調達の流れがあります。

染田 AWSやクラウドが背景としてある部分、よく分かります。Mackerelが良いなと思った理由の1つとして、機動性を高めたかったんですよね。ヌーラボでは4年前から、すべてのサーバー環境をAWSに移していこうとしています。今、オンプレミスのサーバーはほとんどない状態です。

中村 メールサーバーが1個だけオンプレミスですね。

染田 最近の傾向として、何か問題が発生した時はサーバーを入れ替える運用に切り替わっています。トレンドの言葉でいうとImmutable Infrastructureみたいな。サーバー構成管理ツールとして僕らはAnsibleを使っているんですけど、何か問題があると新しいサーバーに入れ替える、ということを自然にやっています。 モニタリングについても、サーバー構成を変えたときに、その前後で同じようにサービスレベルをキープしたいという部分があります。例えばAWSのインスタンスタイプを変えて、新しいインスタンスに入れ替えたとき、その前後で負荷傾向が変わっていないか、サービスレベルが変わらないかをモニタリングしたい。ところが、ホストに注目して監視するツールだと、ホストが入れ替わるとモニタしてきた情報も途切れちゃう。 Mackerelの場合は「ロール」ベースで集計する機能があります。そのあたりのコンセプトは最初に田中さんから説明を受けたのですが、使ってみたらしっくりきました。インスタンスタイプを上げたらこうなった、という様子がよく分かる。見やすくなりました。

「ロール」の概念でImmutable Infrastructureを管理

田中 もともと、はてな社内でのサーバー管理で「ロール」の概念を入れたら面白いだろう、とやってきました。そうやって社内で監視ツールを運用していくうちに、良い感じになってきて。Immutable Infrastructureという概念が2013年ごろから言われはじめたこともあって、ロールベースの監視は世の中のニーズとうまく合致してきました。 Mackerelでは、例えばAWSのインスタンスタイプを入れ替えた前後のグラフも連続的に見られるのですが、こうした監視ツールはこれが初めてだと思います。従来の監視ツールの概念では、こうしたImmutable Infrastructureの運用はカバーできていませんでした。

もう少しImmutable Infrastructureとモニタリングの関係について説明をお願いします。

田中 分かりやすいのはオートスケールです。サーバー台数が24時間の間に増えたり減ったりします。じゃあモニタリングはどうすればいいのか。これは他の会社さんで聞いた運用ノウハウですが、これまでは、1台だけ消えないサーバーを用意してそれを観測するとか、そういったバッドノウハウで可視化していたそうです。

中村 昔に比べてImmutableな運用がやりやすくなってきました。やはりAWSの普及が大きいと思います。ヌーラボでは、昔は台数は立てない方針でした。サーバーを立ち上げるのに時間がかかりますから、1台のサーバーになるべく詰め込む方針でした。そうするとImmutableな考え方は採用しづらい。 これがAWSになって、冗長性を持たせた構成が当たり前になってきました。そうなると1台1台のホストの死活監視などにはあまり意味がなく、まとめて「ロール」単位で見る機能が重要になります。例えば、従来の運用ではサーバーが落ちるのは一大事でしたが、今はAWSで10台のホストで運用されているとしたら、そのうち1台だけ落ちても残りの9台で果たすべき役割が果たせればいい。

染田 AWSに移行したタイミングで、ホスト構成のアプローチが変わりました。以前は、サーバー1台になるべく詰め込むアプローチの方がコストが安かった。ただ、この場合は構成管理などが大変になります。AWSだと、物理障害で再起動するなどは日常的に起きていて、1台が落ちるだけでサービスが死んでしまうのは辛い。自然と、ロール単位で見るようになるし、1台1台のホストの役割は小さい形になっていきます。

田中 ロールの中の台数も意識しないのが理想ですね。例えば、CPU使用率を積み重ねるグラフなどで、ロール単位でこれぐらいのキャパシティがありますよ、と分かればいい。

クラウドに合うよう作られたMackerel

AWSへの転換ですが、トリガーになった事はありますか？

中村 一番はサービスに求められる要件です。例えばBacklogでは、ディスク容量を増やしたり減らしたりする要求があります。ホスティングだと、ディスク容量の増設にも時間がかかります。それにディスクに限らず、すべてのリソースを柔軟にスケールしたい。そうすると、ホスティングよりクラウド系のインフラの方がいい。 逆に考えると、柔軟にスケールすることが求められないなら、価格や管理のしやすさでホスティング系のインフラの方が良い場合もあるでしょう。

田中 Mackerelは、ホスティング環境でも使えないことはありません。ただ、真価を発揮するのはクラウド環境です。クラウドの優位性を引き出したい場合にオススメです。

染田 ヌーラボがAWSに移行した際の背景として、大きかったのはCDN（コンテンツ配信ネットワーク）のAmazon CloudFrontの存在です。それまでは、ヌーラボが必要とする規模で使えるCDNがなかなかなくて困っていました。CacooのエディタはFlashで、そのキャッシュをさせたかったのですが、日本からアメリカのサーバーにつなぐとレイテンシが馬鹿になりません。海外のユーザーも多いので、AWSが北米にデータセンターを提供していることも大きかったですね。

北米と日本の複数のリージョンにまたがるシステムも、Mackerelで問題なく監視できるのですか。

田中 大丈夫です。太平洋を越えようが、インターネットがつながってさえいれば。モニタリングの場合はms単位のレイテンシが問題になることはありませんしね。

中村 アラートを出す時間感覚は気になります。以前に使っていたMuninは5分単位でした。Mackerelは1分単位で、使ってみると5分単位だと分からない問題が1分単位だとけっこう絞れることが分かりました。ちなみに、そのときの問題の原因は、Muninのグラフ描画のタイミングでCPU使用率が跳ね上がっていたことだったんですが（笑）。

染田 モニタリングの時間感覚として、1分という単位は地味に聞こえるかもしれませんが、実用上はけっこういいところだと思います。

中村 5分単位でも傾向を把握するだけならいいですけど、（リソース消費が）跳ね上がる様子を監視するには、できるだけ短いインターバルで監視したい。

染田 もちろんトレードオフはあって、見ないといけないデータが増えすぎるのも問題です。エージェントがボトルネックになる場合もありますから。

エンジニアの中には、自前の運用や監視にこだわる人もいるのでは？

中村 自分たちが提供したいものを中心に考える必要があります。人的リソースの問題で、全部を100％の完成度でこなすことは厳しい。自分たちが提供したいサービスを中心に考えて、中心から外れる部分は外部のサービスでいいと思います。

田中 社内向けの改善や運用などは、エンジニアとしては仕事をした気になるのですが、本来の価値を創造しているわけではありません。外部サービスを使うと、エンジニアはだんだん逃げ道がなくなって、本来の価値に集中せざるを得なくなってきます。特に小さい会社を経営している人には、外部ツールの採用はオススメです（笑）。

染田 Mackerelは、APIで自分たちが欲しいメトリックスを定義できます。ここは大事だと思っています。例えば、ヌーラボのサービスはJava上で動いているので、JVM（Java仮想マシン）の挙動を取りたい。あるホストでフルGC（ガーベジコレクション）が発生する挙動があって、それは複数あるアプリケーションサーバー全体がそうなっているのか、突発的にそのホストだけで起きているのかを確認したい、ということがあります。滅多にないんですけど、画像系とかで一撃必殺でJVMを殺せる不具合を踏むこともあるので（笑）。特定の瞬殺系のバグなのか、全体傾向なのか、そこはモニタリングで初めて分かることがあるので。

好評のグラフUIにはこだわりが

田中 ツールを自前で運用していると、日々、細かいことを気にしないといけません。特にモニタリングは運用の負荷が割と大きい。オープンソース系のモニタリングツールは、作られたのが2000年代前半で、監視対象がホストベースだったりしてアーキテクチャが古い。

染田 UIが使いづらいものも多いですね。

中村 MackerelのUIは、グラフの重ね合わせが便利だと思います。1台のサーバーだけでは分からないが、他と比べると明らかにおかしい傾向を示しているとか、1台だけ跳ね上がっているとか、そうした場合に直観的に分かります。

染田 グラフの作り込みがよくできていますよね。トラブルシューティングの際、例えば1週間当たりの傾向を見て、そこから時間間隔を絞って問題点を探したり、そうしたことがストレスなくできます。

田中 グラフは頑張って作り込みました。実はGoogle Financeのグラフ機能を参考にしています。あのグラフでサーバーが見られたらいいな、と（笑）。 有償サービスとして提供する上では、UIが気持ちよく使えるかどうかが重要と考え、かなりこだわりました。モニタリングでは「期間を選ぶ」ことが重要です。積み重ねグラフと重ね合わせグラフを切り替えたり、CPUとメモリを切り替えたり……と、運用する人のニーズを考えて作り込みました。はてな社内での運用上のニーズが元になっているのですが、それがどれだけ普遍的なのか分からなかったので、ヌーラボさんから意見をいただけたのは、ありがたかったですね。

ヌーラボさん、先行ユーザーとしてのメリットは感じましたか？

中村 はい。とにかく、こちらの要望を伝えやすかったのが良かったですね。そのうちいくつかは機能として取り入れていただけましたし。

田中 一例として、「1週間」「1カ月」「1日」を1ボタンで切り替える機能は、ヌーラボさんからの要望がもとになっています。

中村 もちろんベータより前から使っているので、最初の導入などは、多少の手間はかかっています。

田中 初期の段階ではドキュメントもなかったので、ヌーラボさんのリテラシーの高さに助けられました。ログがJSON形式なのを見てくれて、「こんな感じで送ったらいいんですか」と言ってくれたり。

中村 先ほども話しましたが、最も恐れていたのはプロダクション環境への影響です。その点、実サービスへの悪影響は無く、安心して使うことができました。

ヌーラボさんは、今後もMackerelを使っていきますか？

中村 使っていきたいと考えています。

染田 Mackerelがない状態に戻れと言われても、もう辛いです（笑）。

田中 良かったです（笑）。これからも、よろしくお願いします。