はてなにおける日々の仕事の中にあらわれるMackerelの活用

はてなのWebオペレーションエンジニアの @y_uuki1 です。

この記事は Mackerel Advent Calendar 2015 の19日目の記事です。

前回は @mackee_w さんによる 1000円以下で買えるWiFiモジュールESP-WROOM-02でMackerelにメトリクスを送る でした。

今回は、はてなのインフラチーム（システムプラットフォーム部）におけるMackerelを絡めた運用フローの一部を紹介します。

はてなでは、はてなのサービスの基盤となるサーバ・ネットワーク運用全般を専門のインフラチームが担当しています。 はてなブックマークやはてなブログ、Mackerelなどのはてなの各種サービスに対して、インフラチームの各メンバーが担当につきます。 一部例外はありますが、インフラ基盤は基本的に各サービスで共通のものを使っています。 はてなは運用サービスの数が多いかつ各サービスが互いに連携することもあるので、基盤を共通化して、運用効率をあげています。 例えば、ロードバランサ（主にLVS）は単一サービスではパフォーマンスを使い切れないこともあるので、複数サービスで同じロードバランサを使っています。 他にはAWSのアカウントやMackerelのオーガニゼーションなど、クラウド基盤、監視基盤も共通です。

パフォーマンス状況共有会

以上のようにシステムの運用をインフラチームに集約させています。アラートの一次対応もインフラチームが行います。 一方で、このように運用をインフラチームに集約させていると、情報の共有もインフラチーム内に閉じがちで、開発チームのエンジニアが状況を把握できていない、もしくはその逆が問題になることがあります。 そこで、定期的にPWG（Performance Working Group）と呼ばれる会を開き、開発チームのエンジニアとインフラ担当が最近のパフォーマンス状況やサーバ構成の変更を共有します。

このPWGでは、MackerelやKibanaのダッシュボードを用いてみんなでグラフを眺めて、最近のパフォーマンス変化を共有します。 このとき、PWG用にカスタムダッシュボードを作成しておき、それだけみればよいという形にしています。 サービスを構成するホストのすべてのメトリックグラフをみることはあまり現実的ではないため、システムのパフォーマンスにとって特徴的なメトリックを選ぶことが重要です。 最適なダッシュボードは状況によって異なるため、問題が起きたり、気になったメトリックが増えたら、回帰的にグラフを追加して育てていきます。

朝会と部会

インフラチームでは毎日の朝会で、前日からのアラートを振り返ります。 Slackのチャンネルに流しているMackerelからのアラート通知をみて、チーム全員で全サービスの状況を確認します。既に対応済みであれば、どのような対応をしたか共有し、未対応であるまたは追加の対応の必要があればタスクとして登録されます。

さらに、インフラチームでは定期的に部会があり、各メンバーのタスク状況や部内プロジェクトの進捗、最近のアラート状況などを共有します。 その中で、Mackerel上のホストのステータスがmaintenanceのまま、放置されてしまっているものをチェックします。 maintenanceのままだとアラートが発生しないため、メンテナンスが終わっていればステータスを戻す必要があります。 Mackerelにはmaintenance状態のホスト一覧を表示するビューはまだありません。代わりに、下記のように mkr を使って、コマンドラインでmaintenance状態のホスト一覧を出力できます。

mkr hosts --st maintenance | jq -rM ".[].name"

この記事を書きながら考えましたが、hubotで、maintenanceのホストを毎朝もしくは毎週報告してもいいかもしれません。

リリース手順書

はてなブログチームの開発フローとGitHub - Speaker Deck の資料で紹介されているように、はてなの開発チームでは github-pr-release を用いて、リリース手順書の作成を自動化し、作成された手順書にしたがってリリースが実施されます。 筆者がインフラ担当をしているMackerelチームでは、その手順書の中で、MackerelのサービスメトリックグラフやKibanaのグラフのリンクを書いておき、リリース担当者がグラフに変化がチェックする項目をいれてもらっています。 これは、アラート通知よりはやく問題に気づけるという点と開発チームのパフォーマンス意識の向上という効果があると考えています。

アラートのSlack通知

ここまでで既に何度か登場しているアラートのSlack通知についてです。アラートとチャットツールの連携は基本ですが、やはり非常に便利だと感じます。 はてなでは全社的にSlackを利用しており、各サービスごとの業務チャンネルがあります。 特に、一部の開発チームでは、ディレクター、デザイナー、プランナー、サポート、編集などを含むエンジニア以外のメンバーも常駐するチャンネルにもアラートを流し、システムの状況を関係者全員がみれるようになっています。 MackerelのSlackへのアラート通知はグラフ画像が表示されるため、単なる機械的なアラートメッセージよりも馴染みやすく視覚的にわかりやすいという側面があると思います。

Slackにアラートを通知する - Mackerel ヘルプ

あとがき

日々の仕事の中にあらわれるMackerelの活用事例について簡単に紹介しました。 従来の監視システムは、完全にエンジニアだけが触るものという認識でしたが、Mackerelを利用していくなかですこしずつユーザの広がりを感じています。 インフラ専門のエンジニアが使うだけにとどまらず、インフラ運用とサービス開発の距離を縮めていければよいなと考えています。

はてなでは、Mackerelの開発や運用に興味があるエンジニアを募集しています。

SRE (Site Reliability Engineer) 職 - 株式会社はてな Webアプリケーションエンジニア職 - 株式会社はてな

明日の担当はMackerel開発チームの @stanaka です。お楽しみに。