Graphite の Carbon 三兄弟について整理したメモ + 冗長化（シャーディング）戦略について調べた

Carbon , Carbon , Carbon , Carbon…Carbon 三兄弟、Carbon!（だんご3兄弟より…）のかっぱ（@inokara）です。

はじめに

Graphite をバックエンドでは Twisted という Python 製ネットワークアプリケーションフレームワークを利用して作られた Carbon というツールが動いています。（ややこしい…）

ちなみに Graphite のテクノロジースタックとしては以下のようになっています。

コンポーネント	ツール
Web UI	Django
Graphics library	Cario
Processing backend(carbon)	Twisted
Storage Engine	Whisper

これは以前にどこかで書いたかもしれませんが、自分の復習を兼ねて再掲します。

話は Carbon の話に戻します。

この Carbon ですが Graphite では以下の三つのデーモンが利用可能です。

ということで、こちらを日本語に勝手に訳しながら三つのデーモン小暮について理解を深めたいと思います。

The Carbon Daemons

以下、英語本文に対して勝手に意訳を付けてます。

When we talk about “Carbon” we mean one or more of various daemons that make up the storage backend of a Graphite installation. In simple installations, there is typically only one daemon, carbon-cache.py. This document gives a brief overview of what each daemon does and how you can use them to build a more sophisticated storage backend.

Carbon は Graphite のストレージバックエンドを構成する為に複数のデーモンを提供している
通常のインストールでは carbon-cache.py があります

All of the carbon daemons listen for time-series data and can accept it over a common set of protocols. However, they differ in what they do with the data once they receive it.

全ての Carbon デーモンは共通のプロトコルセットによって時系列データを受け入れることが出来る
但し、データを受け取った後の挙動がそれぞれのデーモンで異なる

carbon-cache.py

carbon-cache.py accepts metrics over various protocols and writes them to disk as efficiently as possible. This requires caching metric values in RAM as they are received, and flushing them to disk on an interval using the underlying whisper library.

carbon-cache.py は様々なプロトコルで計測結果を受け入れる
可能な限り効率良くディスクに書き込む（一旦、メモリにキャッシュした後で Whisper ライブラリを利用して一定の間隔でディスクにフラッシュする）

carbon-cache.py requires some basic configuration files to run:

carbon-cache.py を実行するには以下のような基本的な設定が要求される

carbon.conf
The [cache] section tells carbon-cache.py what ports (2003/2004/7002), protocols (newline delimited, >pickle) and transports (TCP/UDP) to listen on.

carbon.conf
carbon-cache.py が利用するポート（2003/2004/7002）とプロトコル（newline delmited / pickle）とトランスポート（TCP/UDP）を指定

storage-schemas.conf
Defines a retention policy for incoming metrics based on regex patterns. This policy is passed to whisper when the .wsp file is pre-allocated, and dictates how long data is stored for.

storage-schemas.conf
正規表現によって保存するメトリクスのポリシーを定義する
ポリシーは .wsp ファイルが作成される際に保存されるデータ量が事前に割り当てられる

As the number of incoming metrics increases, one carbon-cache.py instance may not be enough to handle the I/O load. To scale out, simply run multiple carbon-cache.py instances (on one or more machines) behind a carbon-aggregator.py or carbon-relay.py.

着信するメトリクスが増えてきても一つの carbon-cache.py インスタンスの I/O 処理は十分で無くて良い
carbon-aggregator.py 又は carbon-relay.py のバックエンドに複数の carbon-cache.py インスタンスを実行してスケールアウトすれば良い

carbon-relay.py

carbon-relay.py serves two distinct purposes: replication and sharding.

carbon-relay.py は二つの異なる目的を果たす
レプリケーションとシャーディング

When running with RELAY_METHOD = rules, a carbon-relay.py instance can run in place of a carbon-cache.py server and relay all incoming metrics to multiple backend carbon-cache.py‘s running on different ports or hosts.

RELAY_METHOD = rules の設定で実行されている carbon-relay.py インスタンスは carbon-cache.py の代わりに実行される
別ポート又異なるホストのバックエンド carbon-cache.py に全てのメトリクスを中継することが出来る

In RELAY_METHOD = consistent-hashing mode, a DESTINATIONS setting defines a sharding strategy across multiple carbon-cache.py backends. The same consistent hashing list can be provided to the graphite webapp via CARBONLINK_HOSTS to spread reads across the multiple backends.

RELAY_METHOD = consistent-hashing では複数の carbon-cache.py バックエンド間でのシャーディングを定義する
同一の consistent hashing リストによって分割された複数のバックエンド全体を CARBONLINK_HOSTS を介して Graphite の Web アプリケーションに提供する

carbon-relay.py is configured via:

carbon-cache.py の設定

carbon.conf
The [relay] section defines listener host/ports and a RELAY_METHOD

carbon.conf にて設定
[relay] セクションで host と ports と RELAY_METHOD を定義する

relay-rules.conf
With RELAY_METHOD = rules set, pattern/servers tuples in this file define which metrics matching certain regex rules are forwarded to which hosts.

relay-rules.conf
relay-rules.conf に RELAY_METHOD = rules を設定すると pattern/servers による特定の正規表現ルールにもとづいて一致したメトリクスがホストに転送される（超意訳）

carbon-aggregator.py

carbon-aggregator.py can be run in front of carbon-cache.py to buffer metrics over time before reporting them into whisper. This is useful when granular reporting is not required, and can help reduce I/O load and whisper file sizes due to lower retention policies.

carbon-aggregator.pyは whisper にデータ登録する前にメトリクスをバッファリングする
carbon-cache.pyの前に実行することができる
I/O 負荷と whisper ファイルサイズを減らすことができる

carbon-aggregator.py is configured via:

carbon-aggregator.py の設定

carbon.conf
The [aggregator] section defines listener and destination host/ports.

carbon.conf にて設定
[aggregator] セクションで host と ports を定義する

aggregation-rules.conf
Defines a time interval (in seconds) and aggregation function (sum or average) for incoming metrics matching a certain pattern. At the end of each interval, the values received are aggregated and published to carbon-cache.py as a single metric.

aggregation-rules.conf にて設定
特定のパターンに一致する着信メトリクスの時間間隔（秒単位）と集計関数（合計または平均）を定義する
各間隔の終わりに、受信した値が集約され、単一のメトリックとして carbon-cache.py にパブリッシュされる

とりあえず…

Carbon は Graphite でメトリクスをバックエンドのデータベース（whisper）に登録する役目を持っている
単純に whisper にデータを登録する carbon-cache.py
他の carbon-cache や他のホストの carbon-cache にリレーする carbon-relay.py
メトリクスを一旦、バッファリング（収集）する carbon-aggregator.py
多くのメトリクスを扱う際には carbon-relay.py と carbon-aggregator.py を利用して冗長化戦略を検討したいところ

Graphite の冗長化戦略

さて…

Graphite の冗長化についてざっくりと調べていたところ興味深い資料に出会ったのでメモっておきます。

Scaling Graphite Installations

上記の資料について纏めてみたいと思います。ついでに以下の資料も参考になります。

バックエンドデータベース

whisper 以外もあるよ
Ceres って時系列データベースも利用出来る
違いについてはこちら
whisper よりも Ceres の方が新しい
whisper が事前にファイルサイズを確保するが Ceres は蓄積されたメトリクス分だけファイルサイズを利用する（っぽい）

シャーディング戦略（1）

複数のバックエンドを追加（carbon-cache + whisper を追加）
手動で分割ルールを作成
メンテナンスやバランシングが難しくなる

ハードウェア増強

IO の性能を向上させる
SSD の採用

statd の採用

statd
アプリケーションの収集に利用している

シャーディング戦略（2）

carbon-relay は CPU 負荷が高い
carbon-relay を HAProxy でロードバランシング
carbon-relay を Pacemaker でクラスタリング
carbon-relay を C で書きなおす（carbon-c-relay）

シャーディング戦略（3）

メトリクスデータをハッシュで分散
データを 2 箇所に設置してリング構成を取る
ミラーリングをデータセンター間で構成
シェルスクリプトでデータセンター間のデータを共有している

問題点

CPU 負荷が高く、簡単に飽和してしまう
ディスクを飽和させ、読み込みが遅い
SSD が更新の負荷で死ぬことがある…

とまあ

若干、ネガティブなご意見な資料でしたが、掲げられている内容にインスパイヤされた周辺ツールが出回っているのでちょっとまとめてみました。

carbon-relay の置き換え系

https://github.com/grobian/carbon-c-relay
=> Enhanced C implementation of Carbon relay, aggregator and rewriter

https://github.com/graphite-ng/carbon-relay-ng
=> Fast carbon relay with admin interface, online routing table changing and zero-downtime restarts

https://github.com/markchadwick/graphite-relay
=> A fast(er) Graphite relay written with Netty. This will read updates in the line-oriented format (metric value timestamp) and write Pickle format to the backends.

whisper 置き換え系

https://github.com/graphite-project/ceres
=> Distributable time-series database

そもそも Graphite 置き換え系

https://github.com/graphite-ng/carbon-relay-ng
=> Fast carbon relay with admin interface, online routing table changing and zero-downtime restarts

その他

https://github.com/grobian/carbonserver
=> A server to handle metric globbing and data retrieval written in go

https://github.com/etsy/logster
=> Parse log files, generate metrics for Graphite and Ganglia

https://github.com/kenhub/giraffe
http://giraffe.kenhub.com/#dashboard=Demo&timeFrame=1d
=> Giraffe : A Graphite Dashboard with a long neck

https://github.com/jssjr/carbonate
=> Utilities for managing graphite clusters

まとめ

Graphite の運用、頑張りましょう
弱点が目に付くが弱点を補う為のツールがある
CPU と Disk I/O がボトルネックになりそう
carbon-relay をどのようにロードバランシングするか重要

まとめのまとめ

carbon は Graphite の主要なコンポーネント
carbon は三種類
冗長化を試みるなら carbon-relay.py と carbon-aggregator.py は抑えておく！
バックエンドのデータベースは whisper 以外にも Ceres ってのがある
Graphite は CPU と Disk I/O に注意しよう（もちろんメモリも適宜確保しておく）
Graphite 日本語情報少ないツライ

ということで長文失礼しました。

元記事はこちらです。
「Graphite の Carbon 三兄弟について整理したメモ + 冗長化（シャーディング）戦略について調べた」

Graphite の Carbon 三兄弟について整理したメモ + 冗長化（シャーディング）戦略について調べた