はてなでMackerelが生まれたワケ
まずはMackerelが誕生した背景について見ておこう。はてなは2001年7月の設立以来、「はてなブックマーク」「はてなブログ」「人力検索はてな」といった数々の個人向けWebサービスを提供してきた。当初はオンプレミスで運用していたが、2011年から本格的にクラウドに移行。サーバー2000台規模にまで順調にシステムが拡大していく中、スプレッドシートでの管理が限界を迎えようとしていた。
はてなでは、監視システムの「Nagios」、構成管理ツールの「Chef」、デプロイ自動化ツールの「Capistrano」など、さまざまなサーバー管理ツールを組み合わせてサーバー管理の効率化を図っていたものの、目的別にツールが存在することで、ホスト情報が分散してしまうなどの課題を抱えていた。そこで、ホスト情報を一元管理しながら、周辺の各ツールと疎結合に統合できるものをフルスクラッチで作ることに。この社内向けのシステムがMackerelの原型となる。
そうして社内運用で培ったノウハウをサービス化すべく、概念やUIのブラッシュアップを図るとともに、システムは一から作り直した。Mackerelのベータ版が公開されたのは、2014年4月。当時はAWSが本格的に普及し始め、DockerやKubernetesなどのツールが登場したことで、「サーバーを使い捨てる」思考へと転換が起きていた。そんなImmutable Infrastructureの実現を支援するサービスの構築に向けて、はてなのエンジニア陣は自らの知見をMackerelに詰め込んでいったのだ。
「今の時代のシステムは作って終わりではなく、正解がない中で試行錯誤しながら、運用段階で育てていくことが大切。『MackerelをPDCAのスタート地点にしてもらいたい』という想いから、導入の敷居を下げてすぐに始められるようにしたり、分かりやすいUIで直感的に操作できるようにしたりしながら、クラウド時代のプラクティスの提供を目指している」（渡辺氏）
SaaS型サーバー監視サービス Mackerel 無料ダウンロード資料はこちら
クラウド運用の道標となるSaaS型サーバー監視サービス Mackerel。概要資料や事例、セミナー動画などの各種ダウンロードコンテンツを提供中です。ぜひご覧ください！
エンジニアによるエンジニアのためのプロダクト開発だからできること
先述のとおり、Mackerelはサーバー監視を支援するエンジニア向けのプロダクトであるため、Mackerelを開発しているエンジニアがユーザー像をイメージすることは難くない。ユーザーが欲しいものは何なのか、自分に当てはめて考えることができるわけだ。
だからこそMackerelでは、自社のプロダクトを日常的に使用してサービスの改善に役立てる「ドッグフーディング」をとても大切にしているという。
例えば、渡辺氏が日頃Mackerelを利用している中で「MackerelもInfrastructure as Codeでインフラ管理したい」と思うようになった。そこで調べてみたところ、有志のユーザーが独自で作っていたモジュールがあることが分かる。しかし、最新のAPIに追従できていないなど多少の問題があったことから、直接ユーザーに接触し、仕様を調整することで、公式のモジュールとしてTerraform Mackerel Providerを提供するに至った事例がある。この動きを主導したのはMackerelのSREのメンバーだ。
このようにドメインエキスパートであるインフラエンジニアやSREが企画の主役になるMackerelでは、チーム内での意見交換を活発に行ったり、開発合宿でアイデアを爆発させる機会を作ったりしている。
一方、「これが欲しい」という一言だけがGitHub Issueとして立ち上がり、その場で盛り上がったまま、放置されてしまうこともあった。あるいはエンジニアだけで議論していると、解決策はたくさん出てくるものの、Howに縛られてWhyが欠如してしまう失敗もあったという。
「そんなときは、会話を増やす、バックログのリファインメントをきっちりやる、Product Backlog Itemの完了条件を確認する、といった基本に立ち返ることが大事。加えて、仮説検証のフローを整備することで、愚直にプロダクトを育てている」（渡辺氏）
インフラ技術を取り巻く環境は、日々急速に進化していく。クラウドファーストからクラウドネイティブの時代へと移り行く中で、Mackerelをローンチした初期の頃は、200週連続リリースしたこともあった。
「常に新しい技術を取り入れ、世の中の先端に立ち続けなければならないプレッシャーが非常に強いサービスだからこそ、ドッグフーディングだけでは限界がある」と渡辺氏は語る。Mackerelの社内環境ではAWSやLinuxを使い、プログラミング言語としてはPerl、Scala、Goを使っているが、ユーザーの環境はそれよりもっと広がっていくことは避けられない。
その中で、何を優先して対応すべきなのか。市場で必要とされる技術を見極めるには、ユーザーの声に耳を傾けることが重要である。
ユーザーの声を取り入れやすくするために、Mackerelでは「開発者に会いに行けるサービス」を掲げ、ミートアップを開催するほか、Slack上のユーザーグループでコミュニケーションを行うなど、さまざまな工夫を行っている。
加えて、少しでもユーザーから身近に感じてもらえるよう、技術に対して誠実な姿勢を見せることも忘れない。内部の構成を公開するなど、情報はできるだけオープンに。これはMackerelに限らず、はてな全体の文化だという。ほかにも、障害報告やメンテナンス告知の際には、「なぜ障害が発生したのか」「なぜそのメンテナンスが必要なのか」といった背景まで詳細に公開するよう心がけている。
そんなMackerelとユーザーの距離を近づけるために一翼を担っているのが、CRE（Customer Reliability Engineer）である。CREはユーザーの課題解決をミッションとする、いわばカスタマーサクセスを担うエンジニアのことである。
MackerelのCREは、説明会や勉強会を開いたりブログを書いたりしてユーザー向けの情報提供を行うほか、ユーザーからの技術的な問い合わせにも対応している。また、社内向けには、ユーザーからの要望やフィードバックをBacklogにためていき、開発の優先順位をエンジニアとともに考えている。
「Mackerelは運用・監視のノウハウを提供することが主眼にあるため、アラート設計や管理方法、システム監視のあり方についてなど、自分の環境に閉じず、広く世の中の運用・監視について、本気で考える機会をもらえる。これは、いちエンジニアとして貴重な経験だと感じている」（渡辺氏）
自分も使うサービスを自ら作っていると、「あれも欲しい、これも欲しい」と欲が出てくるのは当然のこと。しかし、それを繰り返すうちに、思想がぶれてしまっては、元も子もない。「繰り返しになるが、Mackerelで提供したいのは、監視・運用のプラクティス。ベストプラクティスではないにせよ、“こうあるべき”という模範解答を示していきたい。できることを無限に増やしたいわけではないため、エンジニア中心に取捨選択することを大切にしている」という。
最後に、そんなMackerelの最近の事例として、SRE（Site Reliability Engineering）の取り組みが紹介された。SREはGoogleが提唱したコンセプトであり、SLI（Service Level Indicators）やSLO（Service Level Objective）の指標を用いて、サービスの信頼性の最適化を図るものだ。
システム障害を限りなくゼロに近づけるには無限の努力が必要だが、果たしてそこまでのコストをかける必要性は本当にあるのか。「目標値を設定して計測すること自体よりも、『これくらいでいいよね』とビジネスオーナーの合意を得ることのほうが難しい」と語る渡辺氏。Mackerelを活用したSREの実践例を紹介したユーザーの技術ブログが公開されたのを機に、MackerelのSREチームも「MackerelでSLI／SLO運用をする際に役立つ機能やツールの紹介」というブログでノウハウを共有している。
SaaS型サーバー監視サービス Mackerel 無料ダウンロード資料はこちら
クラウド運用の道標となるSaaS型サーバー監視サービス Mackerel。概要資料や事例、セミナー動画などの各種ダウンロードコンテンツを提供中です。ぜひご覧ください！
