# Mackerelを支える時系列データベース技術
[[Yuuki Tsubouchi]] が 2015 年 4 月 30 日に公開したブログ記事（2018 年 1 月 6 日に HeteroTSDB 移行を追記）。サーバ監視 SaaS [[Mackerel]] で採用していた [[Graphite]] 時系列データベースの構築・運用経験を詳述する。1 分あたり 100,000 件以上のメトリクス書き込みに耐えるための設計・チューニング・クラスタ構成を公開している。
> [!key-insight] 本記事の位置づけ
> 2015 年の Mackerel/Graphite 時代を記録した一次資料。2018 年に [[HeteroTSDB]] へ移行したため、Graphite 運用の完全な生涯を持つ。[[時系列データベース]] 概念ページの「RRD アプローチ」と「監視 TSDB の一貫性トレードオフ」の実証事例として参照される。
---
## Graphite アーキテクチャ
3 コンポーネント構成:
| コンポーネント | 役割 | 実装 |
|---|---|---|
| **whisper** | RRD ストレージライブラリ | C + Python |
| **carbon-cache** | 書き込みデーモン | Twisted（非同期 I/O） |
| **graphite-web** | 読み込み Web UI | Django |
書き込みはプレーンテキストプロトコル（`<path> <value> <timestamp>`）または Pickle 形式でソケット通信。graphite-web の CARBON_LINK 機能により、carbon-cache のメモリバッファと whisper ファイルをマージして最新データを含む応答を返せる。
---
## whisper の RRD 設計
whisper は RRDtool の後継として設計された時刻束縛型ストレージ。ファイルサイズが作成時点で固定される。
```
File = Header + Data
Header = Metadata + ArchiveInfo群
Data = Archive群
```
**archive**: 精度（1 分）× 保持期間（7 日）の組。複数 archive を定義すると古いデータは **Rollup Aggregation** により粗い精度（例: 10 分平均）に自動変換される。データが古くなるにつれて精度が劣化する一方、ディスク使用量は一定に保たれる。
これは [[Gorilla]] や [[HeteroTSDB]] の「追記型 + TTL tiering」アプローチとは設計哲学が根本的に異なる:
- whisper/RRD: 固定サイズ・ローリング・精度劣化
- Gorilla/HeteroTSDB: 追記型・圧縮・階層マイグレーション
---
## carbon-cache のパフォーマンス特性と限界
**Twisted による非同期 I/O 設計**:
- listen スレッドが書き込み要求をバッファリング
- writer スレッドが whisper に `update_many` でまとめ書き込み
- ただし Twisted ベースにより実質 2 スレッド上限でマルチコアスケール不可
**ディスク I/O 問題**:
大量の小ファイルへのランダム書き込みが発生する。archive が複数あると 1 つのメトリクス更新に複数シークが必要になり、I/O スケジューラによるシーク統合が効きにくい。
**ページキャッシュ圧迫**:
全方位書き込みがカーネルページキャッシュを圧迫してスラッシングを引き起こす。試みた対策:
- posix_fadvise DONTNEED: 部分的効果のみ
- O_DIRECT: Python バッファのアライメント制約で実装困難
- **採用解**: メモリ増強
---
## チューニング（carbon.conf 主要パラメータ）
| パラメータ | 推奨値 | 理由 |
|-----------|--------|------|
| MAX_CACHE_SIZE | inf | スレッド競合回避 |
| MAX_UPDATES_PER_SECOND | inf | SSD 使用で制限不要 |
| CACHE_WRITE_STRATEGY | naive | CPU 効率化 |
| WHISPER_AUTOFLUSH | False | iowait 低減 |
| WHISPER_FALLOCATE_CREATE | True | ファイル作成高速化 |
---
## クラスタ構成とレプリケーション
carbon-relay によるシャーディング:
- **consistent-hashing**: メトリクス名の一貫ハッシュで複数 carbon-cache に均等分散
- **rules**: 正規表現マッチングで手動ルーティング
レプリケーションの実態:
- 複数 carbon-cache への単純コピー
- **バイナリログなし・一貫性保証なし**
- 復旧は rsync による同期（DRBD は全方位書き込みでネットワーク帯域が限界に達するため不採用）
### Mackerel の構成進化（2015 年時点まで）
1. 単一ホスト（carbon-cache + graphite-web）
2. 2 台 tsdb-master + carbon-relay レプリケーション + LVS 冗長化
3. バックアップノード追加（非対称）
4. consistent-hashing による複数 carbon-cache へのスケールアウト
5. tsdb-relay-lb 導入: 2 段 carbon-relay（レプリケーション + consistent-hashing の組み合わせ）
著者評: "多段になればなるほど全体としての可用性やメンテナンス性は落ちる"
---
## 2018 年への橋渡し
本記事は 2018 年 1 月に「Mackerel が新しい時系列 DB 実装へ移行した」と追記され更新が終わった。その新実装が [[HeteroTSDB]] であり、[[Yuuki Tsubouchi]] の博士論文 ([[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]]) の核心となる研究成果だ。Graphite 時代の「ページキャッシュ圧迫」「マルチコアスケール不可」「一貫性なしレプリケーション」という課題が HeteroTSDB の設計動機として連なる。
---
## 関連
- ソース: `.raw/articles/high-performance-graphite-2026-06-30.md`
- 著者: [[Yuuki Tsubouchi]]
- プロダクト: [[Mackerel]] / [[Graphite]]
- 後継技術: [[HeteroTSDB]]
- 関連概念: [[時系列データベース]] / [[ラウンドロビンデータベース]]
- 関連ソース: [[@2025__Kyoto University__Scaling Telemetry Workloads in Cloud Applications - Techniques for Instrumentation, Storage, and Mining]] / [[@2019__yuuk.io__Rethinking-Serverless-Architecture]]