# Mackerel [[Hatena]] が運営する SaaS 型のサーバ監視(monitoring-as-a-service)サービス(mackerel.io)。[[HeteroTSDB]] のストレージアーキテクチャが 2017 年 8 月に実投入された本番環境であり、博士論文の社会実装の 1 つ。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - データ取り込み間隔 1 分・保持 460 日という要件をもつ実運用テレメトリシステムの例として論文中で参照される。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - 本番実装は論文プロトタイプと差異がある。メッセージブローカーを前置し、Amazon DynamoDB(ディスクベース KVS)+ Amazon S3(third-tier)の 3 層化、Ingester/Flusher の AWS Lambda 化を施す。([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) - [[池田将士]] の SRE NEXT 2023 発表では、Warning/Critical の Severity 差、Slack 通知、Webhook、アラートメモの表示先として使われる。[[prepalert]] は Mackerel の Webhook を起点に補助情報を収集し、Mackerel のアラートメモへ結果を貼る。([[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]]) ## Graphite 時代の時系列 DB 基盤（〜2018 年） [[Yuuki Tsubouchi]] の 2015 年ブログ記事（[[@2015__yuuk.io__High-Performance-Graphite]]）によると、Mackerel は 2018 年以前に [[Graphite]]（whisper + carbon-cache + graphite-web）を 時系列 DB 基盤として使用していた。 - **規模**: 1 分あたり 100,000 件以上のメトリクス書き込みに対応するクラスタを運用 - **課題**: carbon-cache の Twisted 2 スレッド上限によるマルチコアスケール限界、多数ファイルへの全方位書き込みによるページキャッシュ圧迫、carbon-relay のレプリケーションが一貫性保証なし - **クラスタ進化**: 単一ホスト → 2 台冗長化（LVS + carbon-relay レプリケーション） → consistent-hashing によるスケールアウト → 2 段 carbon-relay（tsdb-relay-lb）による replication + consistent-hashing 組み合わせ - **移行**: 2018 年 1 月に [[HeteroTSDB]] へ移行。Graphite 時代の構造的課題（マルチコア限界・一貫性なし）が HeteroTSDB の設計動機となった。 ## SLO 導入事例 [[渡辺 起]]（プロデューサー、2022 年まで PO）が SRE NEXT 2023 で発表した事例（[[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]]）: - **チーム規模**: 10 人前後（うち SRE 1〜3 名）。2014 年リリースのエンジニア向け監視 SaaS。 - **DORA 2022 位置**: フロー段階・後期段階。以前は停止メンテ時間が長く、デプロイが週 2 回、リリース頻度が低い状態だった。 - **SLO 導入の動機**: 信頼性より開発速度の課題——「判断と改善をチームで回したい」という PO の意思決定負荷軽減が主目的。 - **SLI/SLO の実値**: 可用性 SLO 99.8% → 実測 99.98%、レイテンシ SLO 99.8% → 実測 99.88%（SLI/SLO ダッシュボード画面より）。 - **Error Budget Policy**: 「調査をするか判断する」という最低限のアクションから開始（段階的強化設計）。 - **外形監視の難しさ**: Mackerel の外形監視では「サービスに到達できない状態」が正しい挙動になる場合もあり、SLI 設計に独自の難しさがある。 ## 関連 - 本ソース: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] - 関連ソース: [[@2023__SRE NEXT__Warningアラートを放置しない！アラート駆動でログやメトリックを自動収集する仕組みによる恩恵]] / [[@2023__SRENext2023__プロダクトオーナーとしてSLOに向き合う 〜Mackerelチームの事例〜]] - 運営: [[Hatena]] - 担当者: [[渡辺 起]] / [[池田将士]] / [[Yuuki Tsubouchi]]（元 SRE、Graphite 時代） - 採用技術（現行）: [[HeteroTSDB]] - 採用技術（2018 年以前）: [[Graphite]] - 関連概念: [[時系列データベース]] / [[テレメトリ]] / [[Warningアラート]] / [[サービスレベル目標]] / [[エラーバジェット]] / [[ラウンドロビンデータベース]]