はじめに

Mackerelは、はてな社が開発・運営されているSaaS型のサーバー監視サービスです。
2023年12月19日にMackerel Meetup #15が開催されました。

それではMackerelチームが発表されていた内容についてレポートしたいと思います。

Mackerelの2023年ふりかえりと今後のロードマップ

  • 2023年のMackerel
    • オフラインイベント復活で再び開発者に会えるサービスへ
      • Meet up Drink up を毎月やってます
        • ここで要望を聞いて実現した機能も
    • 2023年 95件のアップデート
      • ダッシュボードの進化
        • 値ウィジェットの期間追従、トレンド表示
        • グラフウィジェットの縦軸固定
      • グラフアノテーションの進化
        • グラフアノテーションの一覧表示ができるようになった
      • その他
        • AWSインテグレーションのメトリック自動取得有無選択
        • アラートステータスの配色変更
    • 大型開発ロードマップ
      • OpenTelemetry メトリック対応
        • OpenTelemetry Protocol, ラベル付きメトリックの取り込み
        • PromQLクエリでダッシュボードへ表示
        • (対応予定)アラートシステムの対応
      • 今後の予定
        • リリース予定
          • 2024年前半 公開ベータ提供
          • 2024年後半 正式リリース
        • 今後の構想
          • メトリックの探索
          • ホスト、リソース検出
          • ダッシュボードテンプレート
        • SAML認証対応
          • 外部Idpを利用してMackerelが利用可能に

Mackerelの2023年ふりかえりと今後のロードマップ 資料

アプリケーションの「信頼性」の育てかた

  • SREについて
    • SLOがコアになるプラクティス
    • RiskとToilの撲滅
  • SLIとは
    • サービスの信頼を計測するための指標
  • SLOとは
    • サービスの信頼性の目的値 / SLIが目指すべき値
  • Error Budgetとは
    • SLOから計算される信頼性の余裕
  • SLI/SLOはどのように使えるか
    • SREチームの意思決定
      • どのようなアクションがSLIを低下させているかを調査する
      • SLIを特に低下させるようなアクションがあれば改善を行う
    • 監視
      • 短期間にSLIが急激に低下しアラートを出したら即時対応する
    • プロダクトチームオーナーの意思決定
      • リリースサイクルや機能開発を加速する
      • 機能開発をやめて信頼性の改善に取り組む
  • SLI/SLOの定め方
    • SLI
      • 「良いイベント/有効なイベント」を使い割合になるように設定する
        • 重要なユーザージャーニーをターゲットにするといい
        • 障害モードも網羅できると良い
          • 例: 外形監視なども組み合わせる
    • SLO
      • 現状のSLIの値とユーザーの期待値から設定する
        • 高すぎる信頼性は相応に高いコストを払う必要がある
      • 現状のSLIの値でユーザーの期待値を満たせているかを確認する
      • 信頼性目標が高すぎると挑戦・失敗・学習する機会を奪ってしまう可能性もある
        • 結果として、機能開発が遅れる・長期的に見ると信頼性が低下する可能性
    • SLI/SLOの定め方 運用
      • SLO違反した時にどのようなアクションを取るか合意を取る
        • 例: チームがアプリケーションコードを確認して問題を改善する
      • 合意をとったあとはアクションについてはドキュメントに残して公開するようにする
    • 「信頼性は会話である」
      • SLI/SLOは信頼性のニーズを論理的に判断するためのツール
        • 単に設定を眺めているだけでは何も得られない
      • SLI/SLOのようなツールを持っていないと雰囲気で交渉をすることになる
    • 「完璧である必要はない」
      • 重要なのははじめて改善していけるような素早いフィードバックループを行うこと
      • むしろ最初は少ないSLI/SLOから小さく始めていく方がいい
    • SLO ドキュメントのようなものを用意するといい
      • サービスの名前・SLOの定義
      • サービスの概要
      • SLI/SLO
      • 見直しのスケジュール
      • エラーバジェットポリシー
    • 監視との関係を考える
      • 「入門 監視」デザインパターン「ユーザー視点」の監視である
      • SLI/SLOに対して burn rate alertを設定することでユーザ視点での監視を実現できる
    • Burn rate aleart
      • Error Budgetが消費されるレートに対してアラートを掛けるもの
      • 期間あたりに観測されたエラーの数 / 期間あたりに許容されるエラーの数
      • 稼働が停止して全てのリクエストにエラー返す Fast Burn
      • 断続的にリクエストに対してエラーを返す Slow Burn
    • これらの消費のされ方に対して適切にアラートと設定する
      • 閾値ベースのアラートとの違い
        • 閾値ベースのアラートは固定値を使うことが多くビジネスや環境の変化に追従しづらいことが多い
      • Burn rate alertはSLI/SLOの上に成り立っている
        • よりユーザ目線に立ったものになっている

アプリケーションの「信頼性」の育てかた　資料

パネルディスカッション

テーマ「アラートが来たときにどのようなアプローチをしたらいいの？」

  • しっかりアクションできるようなアラートを設定していく
    • どうしたらいいかわからないアラートがあっても困るのでアラートそのものを見直す
  • チームとしてどう対応するか、アラートの意図を汲んで動く
    • 原因を調査する人とかユーザーサポートとコミュニケーションする人など現状をまとめる人だとかロールを決められる体制づくりをしておく
  • 人が対応しなくていいように自動化する。
  • 俗人化への対応について
    • 振り返り・定例MTGで共有する
    • 組織として誰でも対応できるようにする
    • 職人芸がいらないオープンな情報がたくさんあるツールを選択していく
  • SREとしての組織がないが、どのように立ち上げるか？
    • 運用チームでもどこからでもまずSREをやってみて成功例を見せていく
    • 一緒にSLI/SLOを考える機会を作ってSREが役立つことを開発者に実感させる

テーマ「障害対応」

  • 障害起きたらまず集まる場所を決める
  • 障害が出た時のためにアクションについてドキュメントに記載する
  • ランブックがないとCIがコケるなどランブックを強制的に書かせる環境や仕組みを作る

(質問) 定期的にSLI/SLOの確認するが違反がなくてエラーバジェットが余ってる場合どのようなことをするか？

  • デプロイなど変更が入っているか？
  • SLOが低すぎないか？どのくらいが妥当なのか確認する
  • リリース前にチェックが厳しすぎないか？開発速度が落ちてないか？
  • SLI/SLOが正しく設定されているか確認する
    • 例: カスタマサポートに聞くなど。
  • それでも余ってるならよりSLOをあげてより信頼性の高いサービスを目指す

(質問) Webサイトではなくバッチシステムの場合はどのような運用をしていくとよいか

  • SLIやSLOを工夫して監視するようにする
    • バッチの目標時間、何時間以内に終わるバッチなのか
    • 何%が何時間までに終わっていればいいのかなど
      • 例:データのマスキングが何分で何割できているかなど
    • ジョブが何をして何を達成するのかなど要件を整備することでどのようにSLI/SLOを工夫するのか判断できる

(質問) SLOドキュメントを準備するのが大変なんですがどのようにすべきですか？

  • 最初は簡単にでもドキュメントを設定して、話し合いなど試行錯誤して進化させていく
  • 小さく始めて改善していくのが重要、SLO本を買ってテンプレートを埋めるところから
  • 一人でやらずにいろんな人と話を聞きに行って一緒に考えていく
  • 小さく始める時に大事なのは経緯などがわかるようにしておくこと(Github上に残す、仮決めなのかなど記載する)

クリティカルユーザージャーニーを活用したSLI/SLOの改善

  • クリティカルユーザージャーニーとは
    • ユーザーがサービスを利用して、目的を達成するために行う
    • 特に重要な顧客体験に注目して、ユーザーの体験とタスクを整理する
    • SLI/SLOに設定できるものを設定する
    • タスクを達成する上でユーザーにとって何が重要なのか？
    • ユーザーにとって重要なことを測る指標は何か？
    • CUJで見えないものについて
      • ユーザージャーニーに現れにくいものも存在する
        • データのお掃除バッチなど
  • SRE Workbookの実装例がとても参考になる
  • 前提としてSLI/SLOは見直していくもの
    • とりあえず始めて最初から完璧を求めない

クリティカルユーザージャーニーを活用したSLI/SLOの改善　資料

さいごに

OpenTelemetry対応も着々と進んでおりユーザ目線からも正式リリースに期待が高まっていることを感じました。
今後のMackerelの進化を楽しみにしたいです！

今回、発表やパネルディスカッションからSREについて非常に多くの学びがあり、
現在チームで取り組んでいる社内サービスへのオブザーバビリティ導入の取り組みに活かしていければと思います。