インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

HeteroTSDB: 異種混合キーバリューストアを用いた自動階層化のための時系列データベースアーキテクチャ
坪内 佑樹†1,a)

脇坂 朝人†1

濱田 健†1

松木 雅幸†1

阿部 博†2,†3,†4

松本 亮介†5,†6

概要：システム管理者からの需要の増加に伴い，システムの状態を時系列データとして収集するためのモ
ニタリングシステムがサービスとして提供されるようになってきている．モニタリングサービスの時系列
データベースには，高解像度な時系列データ，時系列データの長期間保存，高い書き込みスケーラビリティと高可用性が求められている．一方で，これまでサービスの機能追加のためにデータ構造の拡張性を考慮した時系列データベースは提案されていない．本研究では，インメモリのキーバリューストア (KVS) とオ
ンディスクの KVS を組み合わせた異種混合 KVS により自動階層化する時系列データベースアーキテク
チャを提案する．提案手法では，メモリとディスクのデータ構造を異なる KVS として分離することにより，書き込み効率とデータ保存効率を保ちつつ，用途ごとに最適化されたデータ構造へ書き込みを複製するといった拡張が容易となる．

HeteroTSDB: A Time Series Database Architecture
for Automatically Tiering on Heterogeneous Key-Value Stores
Yuuki Tsubouchi†1,a) Asato Wakisaka†1 Ken Hamada†1 Masayuki Matsuki†1
Hiroshi Abe†2,†3,†4 Ryosuke Matsumoto†5,†6

Abstract: A monitoring system has been provided as a monitoring service as the demand from systemadministrators increases. Providing a monitoring service requires high resolution time series, long-term retention, high write scalability, and high availability to a time series database (TSDB). On the other hand,
TSDBs in consideration of the extensibility of the data structures for function addtions of a monitoring service has not been proposed so far. In this paper, we introduce a TSDB architecture for automatically tieringon heterogeneous Key-Value Stores (KVS) that combines with an in-memory KVS and an on-disk KVS.
Our proposed architecture enables the TSDBs extensibility to duplicate the writes to new data structures
optimized each use case without reducing writing efficiency and the data storage efficiency by unbundlingthe data structure on memory and disk as different KVSs.

1. はじめにの要求が高まっている．したがって，システムに障害が発生したときに，システム管理者がいち早く問題を特定する

インターネットが普及し，当たり前に利用できるようにためには，システムの状態を常に計測すること（以降，モなるにつれて，インターネットサービスを支える計算機シニタリングとする）が必要である．しかし，モニタリング

ステムに対するサービス利用者からの可用性と応答速度へのためには，モニタリングを実現するためのシステム（以降，モニタリングシステムとする）が別途必要となり，シ

†1
†2
†3
†4
†5
†6
a)

株式会社はてな
株式会社レピダム
ココン株式会社
北陸先端科学技術大学院大学
GMO ペパボ株式会社
さくらインターネット株式会社
y uuki@hatena.ne.jpⓒ 2018 Information Processing Society of Japan

ステムの構築のための作業や継続的なハードウェアまたは
ソフトウェアの更新作業といったシステム管理者への負担が発生する．そこで，これらの負担を軽減するために提供されているサービス [1]（以降，モニタリングサービスとする）をシステム管理者が利用することがある．

7

インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

モニタリングシステムでは，対象のシステムからメモリ

本研究では，将来のデータ構造の拡張性を確保しつつ，使用量などのシステムの状態を計測するための指標（以降，書き込み処理効率とデータ保存効率を高め，書き込みス

メトリックとする）を定期的に収集し，時系列データとし

ケーラビリティと高可用性を達成する時系列データベースてデータベース (以降，時系列データベース [2] とする) に

アーキテクチャの実現を目的とする．まず，データ構造を保存したのちにグラフとして表示する機能を提供すること

拡張するために，DBMS 自体を変更するのではなく，拡張がある．グラフを利用し，発生中の障害を分析するために内容の特性に合わせた異なる DBMS を追加する疎結合なは，短時間での状態の変化を見逃さないように，メトリッ

アーキテクチャをとりつつ，内部に複数の DBMS を利用しクを高解像度で時系列データベースに記録しておくことがていたとしても，時系列データベースの利用者からは，書必要となる．また，障害復旧後の原因分析や，未来の増強

き込みと読み込みのためのインターフェイスをそれぞれ 1計画のための過去の負荷状況の分析のために，過去のデー

つに見えるように統合する．次に，OpenTSDB と同様に，タを長期間遡れるようにしておくことが求められる．しか書き込みスケールアウト性と高可用性のために，DBMS とし，高解像度のメトリックをストレージに書き込むと，ディ

して KVS を利用する．さらに，ディスクへの書き込み回

スクへの書き込み回数が増加し，高解像度のメトリックを数を減らし，書き込み処理効率を高めるためには，ディス

長期間保存すると，ストレージの使用領域が増加するため，

ク上にデータ配置する KVS（以降，オンディスク KVS と書き込み処理とデータ保存を効率化する必要がある．加えする）ではなく，メモリ上にデータをすべて持つ KVS[5]て，モニタリングサービスでは，利用者数の増加または利（以降，インメモリ KVS とする）に着目する．しかし， 時

用者が管理するシステムの規模の拡大にともない，単位時

系列データベースでは，時間が経過するほど新しいデータ間あたりに収集するメトリック数が増加するため，時系列が追加で書き込まれるため，短期保存と比較し，長期保存

データベースに高い書き込みスケーラビリティが求められには大きなデータ保存領域が必要となるという前提がある．さらに，モニタリングサービスが障害のために利用でるため，ディスクと比較し，メモリは容量単価が大きいた

きない状態が続くと，その間利用者は自身が管理するシス

め長期保存するには向いていない．そこで，書き込み処理

テムの状態を知ることができなくなるため，時系列データ

効率を高める役割をインメモリ KVS が担い，データ保存

ベースには高可用性が必要となる．

効率を高める役割をオンディスク KVS が担う，異種混合

書き込みスケーラビリティと高可用性を実現するには，

KVS による疎結合な時系列データベースアーキテクチャ

複数のサーバを用いて冗長化しつつ，スケールアウトさせを提案する．具体的には，インメモリ KVS で書き込みをる必要がある．先行手法である OpenTSDB[3] は，データ

受け付けつつ，メモリ上の古いデータをオンディスク KVSの基本要素がキーと値のペア（キーバリューペア）であり，に移動することにより，メモリ使用量を抑え，インメモリ

要素同士が互いに依存せず要素単位でデータを分散してKVS の高い書き込み処理効率の利点とオンディスク KVS

配置しやすいために，書き込み処理をスケールアウトさせのデータ保存効率の利点を得られる，KVS 間の自動階層

やすいデータベース管理システム (DBMS) であるキーバ化を実現する．本研究で提案するアーキテクチャを実現す

リューストア (KVS)[4] を利用している．先行手法は，単ることにより，メモリとディスクへの書き込み処理が特定

一の DBMS として構成されるために，新たなデータ構造の DBMS から分離されるため，当該書き込み処理の部分を追加するなどの変更を加えるためには，当該 DBMS にを変更するのみで，データ構造の拡張が可能となる．

対して変更を加えることになる．しかし，一般に，密結合

本論文の構成を述べる．2 章では，関連研究の調査と課したソフトウェアへの変更よりも，疎結合なソフトウェア

題を提示する．3 章では，提案手法のアーキテクチャおよへの変更の方が変更時の影響箇所が少なく変更が容易とさ

び実装の詳細を示す．4 章では，実験環境で提案手法の有れているため，各種機能が密結合した DBMS は変更しづ

効性を評価する．5 章では，実験結果を考察する．6 章でらいという課題がある．モニタリングサービスの成長のたは，株式会社はてなのモニタリングサービス Mackerel*1 のめには，長期間のメトリックの分析などの単にグラフを表

本番環境への提案手法の適用を示す．7 章では，本論文を示する以外の機能を追加する必要があり，将来のデータ構まとめ，今後の展望を述べる．

造の追加などの変化に対応するための時系列データベースの拡張性が求められる．ここでの時系列データベースの拡

2. 関連研究

張性とは，例えば，メモリとディスクそれぞれに対する書

モニタリングサービスの時系列データベースには，書きき込み処理の内容を変更し，用途ごとに最適化されたデー

込み処理効率，データ保存効率，書き込みスケーラビリ

タ構造を別々に用意し，それぞれのデータ構造に対して同ティ，高可用性およびデータ構造の拡張性が求められる．

一のデータを書き込むことを指す．我々の知る限りにおい

しかし，先行手法は，データ構造の拡張性の観点においてて，データ構造の拡張性を考慮した時系列データベースは提案されていない．
ⓒ 2018 Information Processing Society of Japan*1

https://mackerel.io/8インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

課題が残る．そこで，先行手法の特徴と問題点を述べる．

ために，密結合な DBMS を拡張するのではなく，拡張内容

OpenTSDB[3] は，ディスク上にデータを配置する KVSの特性に合わせた異なる DBMS を追加し，各 DBMS を一である HBase にデータを格納しており，HBase の分散機

つの DBMS にみえるように統合した疎結合なアーキテク

構による書き込みスケールアウト性と高可用性をもつ．

チャをとる．その上で，書き込みスケールアウト性と高可HBase のストレージエンジンは LSM-Tree(Log Structured

用性を達成するために，分散構成をとりやすい KVS を利Merge Tree)[6] を利用した Bigtable[7] と同様に，ログ先行用する．さらに，書き込み処理効率とデータ保存効率を実書き込み，MemStore と呼ばれるメモリ上のデータ構造，

用上問題ならない程度に高めるために，インメモリ KVS

および HStore と呼ばれるディスク上のデータ構造で構成にデータを書き込み，インメモリ KVS 上に蓄積された古されており，MemStore へ蓄積されたデータを HStore へいデータをメトリック系列単位でまとめてオンディスク

まとめて書き込むことにより，ディスクへ直接書き込み方

KVS へ移動する自動階層化を実現する．インメモリ KVS式と比較し，単位時間あたりのディスク書き込み回数を小は，メモリ上のデータが揮発し消失するという課題がある．

さくしている．さらに，OpenTSDB では，時系列データ

そこで，インメモリ KVS に書き込む前にインメモリ KVSの読み出し効率を高めるために，MemStore 上でメトリッとは異なるサーバ上のディスクにデータ点をログとして書ク系列ごとにタイムスタンプの順にソートされるようにス

き込んでおき，インメモリ KVS が故障しデータが揮発しキーマが設計されており，メトリック系列単位で範囲検索たときに，ログを元にデータ点をインメモリ KVS に再度が可能となっている．

書き込むことにより，揮発したデータを復旧させるログ先

Gorilla[8] は，直近のデータをすべてメモリ上に保持する

行書き込み [10] により解決する．受信したメッセージを保ことにより，読み込み性能に特化させたインメモリの時系列

存し予め購読している購読者へメッセージを送信するメッ

データベースであり，HBase を利用した ODS(Operational

セージブローカー [11] を経由して時系列データを書き込

Data Store) と呼ばれるストレージ層に長期間のデータをむことにより，メッセージをログとして捉えたログ先行書保持する．Gorilla と ODS の両方に同時にデータが書き込

き込みを実現する．メッセージブローカーは，ディスクにまれるため，ODS への書き込み処理を削減するわけでは

シーケンシャルにメッセージを書き込むため，書き込み効なく，あくまで高速にデータを読み出すことに焦点を置い率が高く，時系列データベース全体での書き込み処理効率ている．

を大幅に低下させるわけではない．

InfluxDB[9] は LSM-Tree を時系列データに最適化しHeteroTSDB アーキテクチャの仕組みを図 1 に示す．また Time Structured Merge Tree(TSM) を実装しており，ず，書き込み処理は次のような流れとなる．

HBase 同様にメモリ上のデータ構造に蓄積したデータをま(1) クライアントがメッセージブローカーに書き込み，メッ

とめてディスクに書き込み，さらに Gorilla で提案されてセージブローカーに書き込みを完了した時点でクライいる差分符号化手法などを取り入れているため，書き込み処理効率とデータ保存効率が高い．
デ ー タ 構 造 の 拡 張 性 の 観 点 で は ，OpenTSDB と In-

fluxDBB は各種構成要素が密結合な単一の DBMS としアントにレスポンスが返却される(2) クライアントの書き込みとは非同期に，メッセージブ
ローカーを購読する MetricWriter がインメモリ KVSに書き込むて構成されており，データ構造の拡張性が低いと言える．

(3) バックグラウンドでインメモリ KVS からオンディス

Gorilla は，HBase では満たせない要求のために，インメ

ク KVS へ一定以上古いタイムスタンプをもつデータ

モリのデータ構造を拡張しているといえるが，読み取り処を移動させる理の高速化以外の拡張については言及がない．

3. 提案手法
2 章で述べた先行手法の課題である拡張性を確保するた
めに，特定の DBMS のアーキテクチャに依存せず，KVSの特徴である書き込みスケールアウト性と高可用性を持
ち，書き込み処理効率とデータ保存効率を両立するために，メモリとディスクのデータ構造をそれぞれ異なる KVS に分離し疎結合化した時系列データベースアーキテクチャ

HeteroTSDB を提案する．

次に，読み込み処理は次のような流れとなる．

(i) クライアントは MetricReader へメトリック名とタイ
ムスタンプの範囲を含んだ問い合わせを送信する(ii) MetricReader は問い合わせの条件に基づき各 KVS からメトリック系列を読み出す(iii) MetricReader は各 KVS から読み出したメトリック系
列を結合し，クライアントへ返却する

3.1.1 時系列データ構造
HeteroTSDB アーキテクチャでは，書き込みスケールア
ウト性と高可用性を確保するために KVS 上に時系列デー
タを格納するため，キーバリュー形式で時系列データを格3.1 HeteroTSDB アーキテクチャ概要
HeteroTSDB アーキテクチャは，将来の拡張性を高めるⓒ 2018 Information Processing Society of Japan

納する必要がある．以下に示す時系列データベースとしてデータを保存および取得するだけの機能をもつ KVS 上の

9インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

図 1: HeteroTSDB アーキテクチャ

図 2: 時系列データ構造

時系列データ構造を提案する．

(1) 64 ビット整数の UNIX 時間により表現されるタイム
スタンプと 64 ビット浮動小数点数の組（以降，デー
タ点とする）の系列を保存可能(2) メトリック名とタイムスタンプの開始時刻と終了時刻を入力として，該当するメトリック系列を取得可能

Redis[12] のようないくつかの既存の KVS は，与えられたキーに対してハッシュ計算したのちに順序を維持せずにデータを格納しているため，範囲検索をサポートしていな
いことがあり，タイムスタンプによる範囲検索ができない．
ただし，Bigtable や HBase のように，内部的にキーをソートした状態で保存することにより，効率的に範囲検索できている．

KVS への書き込み処理中に一時的なエラーが発生した
ときのデータ消失を防ぐために，書き込み処理を再試行する必要があり，同じデータを重複して書き込まないように，
書き込みに対してべき等となるようにする．そこで，1 つの一意キーに 1 つの値を紐付け，キーに対応する値を参照するためのデータ構造であるハッシュマップを利用する．
具体的には，ハッシュマップのキーをタイムスタンプ，バリューをタイムスタンプに紐づく値とすると，同じタイム
スタンプをもつデータ点であれば上書きされるため，べき等性を担保できる．

る KVS も存在するが，提案手法では範囲検索をサポート

以上のタイムスタンプアラインメント，タイムウィンド

していない KVS であっても実現できるデータ構造をとる．

ウ，およびハッシュマップを組み合わせたキーバリュー形

そこで，データ点を書き込む前に，タイムスタンプを解像度の倍数に揃える（以降，アラインメントとする）ことにより，タイムスタンプの範囲をもとに範囲内に含まれるタ
イムスタンプの一覧を静的に特定できるため，それらのタ
イムスタンプをキーとして参照すればよい．例えば，解像度を 60 秒とし，元のタイムスタンプが 1482699025 であれば，60 で割った剰余を差し引いた値である 1482699000に変更したのちに，KVS に書き込む．問い合わせに含まれるタイムスタンプの範囲が 1482699000 から 1482699180
であるとすると，1482699000，1482699060，1482699120，

1482699180 をそれぞれキーに含む 4 回の KVS への参照となる．ただし，アラインメントにより，元のデータをそのまま保存できないことと，解像度の秒数の間隔よりも短い
時間間隔で新たなデータ点が書き込まれる場合，一つ前の古いデータ点が上書きされるという制限が発生する．
さらに，一つのキーバリューペアに一つのデータ点を格納するのではなく，一つのキーバリューペアに同一メ
トリック系列内の複数のデータ点を格納することにより，

KVS への参照回数を削減する．しかし，このデータ構造では，メトリック系列内のデータ点が追記されるたびにキー
バリューペアのサイズが増大し，KVS の制限に達する可能性がある．そこで，メトリック系列を固定幅のタイムウィ
ンドウに分割することにより，制限されたサイズ内にデータを収める．KVS のキーバリューペアのサイズ制限については，例えば Amazon DynamoDB[13] は 400KB となっⓒ 2018 Information Processing Society of Japan

式の時系列データ構造を図 2 に示す．図 2 の name はメト
リック名を表す文字列，timestamp はデータ点の UNIX 時間を表す 64 ビット整数型の数値，value はデータ点の値を表す 64 ビット浮動小数点型の数値，および wtimestamp
はタイムウィンドウの開始時刻を表す UNIX 時間である．
例えば，ウィンドウサイズを 3000 とすると，wtimestampの値は 1482699000，1482702000，1482705000... のように

3000 の倍数となる．データ点の書き込みでは，wtimestampの値は書き込むデータ点のタイムスタンプを 3000 で割った剰余を差し引いた値となり，データ点の読み込みでは，入力されたタイムスタンプの範囲の開始から終了までに含まれる 3000 の倍数をすべて wtimestamp の値とし，各wtimestamp に対応するタイムウィンドウからデータ点を読み込み，メトリック系列として結合する．

3.1.2 KVS 間のデータ移動
HeteroTSDB アーキテクチャでは，新規の書き込みを受けつつ，インメモリ KVS からオンディスク KVS へ古い
データのみを移動する必要がある．3.1.1 節で述べた時系
列データ構造により，KVS 上には，書き込まれたメトリッ
ク系列の個数に対して線形にキーバリューペアが増加する
ため，メトリック系列数の増加に対して，データ移動時間
がスケールするデータ移動手法が必要となる．そこで，タイマー手法とカウント手法を提案する．
図 3 にタイマー手法を示す．タイマー手法では，KVSのキーバリューペア単位でタイマーを設定し，タイマーが10インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

部分的にバッチ処理する必要があるが，TTL の実装されていない KVS を利用する場合に有効な手法となる．

3.1.3 データ構造の拡張
HeteroTSDB アーキテクチャにおいて，データ構造を拡張するための手法を示す．まず，3.1.1 節で述べた時系
列データ構造をもつインメモリ KVS およびオンディスク

KVS 以外に，異なるデータ構造を備えた異なる DBMS（以図 3: KVS 間のデータ移動: タイマー手法

降，追加 DBMS とする）を用意する．次に，書き込まれた0 になると予め登録したトリガーに当該キーバリューペア

データを複製し，追加 DBMS に書き込む処理を追加する．

を引き渡し，トリガーが当該キーバリューペアのデータ移

最後に，MetricReader に追加 DBMS を参照するための処

動処理を実行する．タイマー手法により，各キーバリュー

理を追加する．

ペアに紐づくトリガー処理では一つのキーバリューペアの複製書き込みのための処理を追加する手法は，次の 2 点

データ移動を処理すればよいため，互いの処理に依存関係のいずれかとなる．

がなく独立して処理できるため，並行処理が容易となる．

(a) リアルタイム書き込み: MetricWriter と同様にメッ

したがって，キーバリューペア数が増大したとしても，そセージブローカーを購読する処理単位を並置させ，追の分だけスレッドなどのデータ移動のための処理単位を増加 DBMS にデータ点を書き込む．

加させることにより，各キーバリューペアの合計移動時間(b) バッチ書き込み: カウント手法とタイマー手法のいずの増大を低減できる．さらに，各トリガー処理中にエラーれにおいて，オンディスク KVS に書き込む処理の後が発生したとしても，3.1.1 節で述べたようにべき等性をもに，オンディスク KVS に書き込んだデータ点と同一

つデータ構造であるため，再試行によりデータの一貫性はの内容を追加 DBMS に書き込む．

保たれる．タイマーの実装として，キーバリューペア単位

リアルタイム書き込みでは，クライアントから時系列で設定可能な TTL(Time To Live) を用いることを想定しデータベースに書き込まれたデータ点は即時追加 DBMSている．

に書き込まれ，参照可能となる．バッチ書き込みでは，追一方で，TTL が実装されていない KVS を利用できな

加 DBMS に書き込むタイミングがインメモリ KVS 上にい場合のために，メトリック系列のデータ点が一定間隔

データ点を蓄積する間だけ遅延する一方で，オンディスク

で書き込まれることに着目したカウント手法を提案する．

KVS と同様に追加 DBMS に対する書き込み回数を削減でカウント手法では，MetricWriter がデータ点をインメモ

きる．さらに，いずれの手法においても，追加 DBMS に

リ KVS に書き込むときに，タイムウィンドウ内のデータ

対する書き込み処理がべき等となるように工夫しておく点数を計上し，一定個数以上であれば，インメモリ KVS

ことで，いずれの DBMS への書き込み処理中にエラーにからタイムウィンドウを読み出し，オンディスク KVS になったとしても，処理を最初から再試行することにより，書き込んだのちにインメモリ KVS から削除することによ

各 DBMS 間のデータの一貫性が担保される．

り，データ移動を実装する．ただし，データ点が書き込ま本手法により，追加 DBMS に対する書き込み回数と追れなくなったメトリック系列は，オンディスク KVS に移加 DBMS へのデータの反映遅延時間のトレードオフに対動されず，インメモリ KVS 上にデータ点が残り続けるた

して，追加 DBMS の性質に合わせて，リアルタイム書き

め，MetricWriter の処理とは独立して，定期的なバッチ処

込みまたはバッチ手法のいずれかを選択できる．

理により残留データ点をオンディスク KVS へ移動させる．
データ点が書き込まれ続ける系列はオンディスク KVS へ

3.2 実装逐一移動されるために，バッチ処理により移動させなけれ

HeteroTSDB ア ー キ テ ク チ ャ の 一 実 装 と し て ，ばならない系列の数は小さくなるため，実行時間を短くでAWS(Amazon Web Services) を利用した実装を示す．本き，系列の数の増大に対するスケーラビリティの問題は実装では，書き込み処理効率と容量単価の異なる KVS を 3解消される．エラー処理の問題についても，バッチ処理の階層に構成し，2 階層の構成と比較してデータ保存効率を実行時間が短ければ、失敗時に最初からやり直しやすい．

高めている．また，異種混合 KVS とメッセージブローカー

3.1.1 節で述べたようにべき等性をもつデータ構造であるを運用することは単一の DBMS を運用することと比較し，ため，一連の処理の流れの中で一時的なエラーが発生した

サーバ上で動作する OS と各種アプリケーションの環境構

場合は，処理の最初から再試行することにより，KVS 間の築，ソフトウェアのバグや脆弱性の対応のための更新作業，

データ整合性が担保される．カウント手法は，タイマー手負荷の増大に合わせたサーバのスケールアウト作業といっ法と比較し，データ点数の計上と，インメモリ KVS からた負担が発生する．そこで，本実装では，これらの負担をのデータ読み出しのためのオーバーヘッドがあり，さらにクラウド事業者が自動的に処理することにより，利用者はⓒ 2018 Information Processing Society of Japan11

インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

表 1: 実験環境
ロール

項目

BenchmarkEC2 インスタンス

Clientタイプ

c5.4xlarge

OS,Kernel

Amazon Linux 2, 4.14

Message

Kinesis Data Streams

Brokerシャード数

MetricWriter

Lambda

図 4: システム構成

API(Application Programming Interface) を実行するのみ

In-Memory KVS

で作業を容易に自動化できるサーバレスプラットフォー
ム [14] を利用する．
図 4 に シ ス テ ム 構 成 を 示 す ．Amazon Kinesis Data

仕様

On-Disk KVS

32

メモリ量

1600(MB)

ランタイム

Node.js 8.10

ElastiCache for Redis
タイプ

cache.r4.large

バージョン

3.2.10

DynamoDB

Streams[15] は，メッセージブローカーとして動作し，受起動できるため，サーバレスプラットフォーム上で容易に信したメッセージを利用者が追加でプログラムを書くこと

タイマー手法を実装できる．ここでの Lambda 関数 (Met-なく Lambda 関数の引数に渡せる．Kinesis Data Streams

ricMover) の処理は，削除されたキーバリューペアを受けにおけるストリームはシャードと呼ばれる単位の集合体で取り，単に S3 へ書き込むのみとなる．一方で，Redis からあり，シャード数の増加により，メッセージの書き込み処

DynamoDB へのデータ移動では，Redis には DynamoDB

理をスケールアウト可能である．MetricWriter は，Kinesisのように Lambda 関数と連携する機能はないため，実装

Data Streams と連携した Lambda 関数であり，Kinesis要件であるサーバレスプラットフォーム上で実現するため

Data Streams のシャードの個数だけ Lambda 関数の処理に，カウント手法をとった．

単位が起動するため，シャード数の増加によりスケールア
ウトできる．インメモリ KVS の Amazon ElastiCache for

4. 実験

Redis[16] は，書き込みを分散できる Redis Cluster として

HeteroTSDB アーキテクチャの有効性を確認するため利用し，稼働中のクラスタに対してノードの追加が可能に，3.2 節にて示した実装の一部が動作する環境にて，書きであり，ノード間でデータを均等に分散する機能をもつ．

込み処理効率，データ保存効率，および書き込みスケール

オンディスク KVS の Amazon DynamoDB は，SSD(Solid

アウト性を評価した．実験では，表 1 に示す実験環境を構State Drive) 上で構築された KVS であり，秒間の読み取

築し，メッセージブローカーに対してメトリックを書き込

り回数，書き込み回数，およびキーバリューペアのサイむベンチマークを実施する．実環境を模すために，収集しズを基に独自定義されたキャパシティユニットという単たメトリックを定期的にモニタリングシステムへ送信する

位を増加させることにより，クラスタのスケールアウト

ためのエージェントがホスト上で動作している状況を想定が可能となっている．Redis と DynamoDB は，ハッシュし，エージェントの個数，エージェントのメトリック送信

マップをサポートするため，3.1.1 節で述べた時系列デー

間隔および 1 回の送信に含まれるメトリックの個数を指定

タ構造を実装できる．Amazon S3[17] は DynamoDB と比可能なベンチマークプログラムを作成した．ベンチマーチ

較し，約 1/10 の容量単価となるオブジェクトストレージプログラムは，Go 言語で実装されており，指定したエーであり，ファイルパス名をキー，ファイルコンテンツをバ

ジェントの個数分のスレッドを作成し，各スレッドが自動リューとすると KVS とみなせる．MetricCleaner は，イン生成したメトリックを定期的に送信している．以下のベン

メモリ KVS 上に残留するデータをバッチ処理でスキャン

チマークでは，メトリックの送信間隔を 1 分，エージェン

し，オンディスク KVS へ移動させる Lambda 関数であり，トの同時送信メトリック数を 100，MetricWriter がインメ

Amazon CloudWatch Events[18] により定期的に Lambda

モリ KVS 上に同一メトリック系列内のデータ点を蓄積す

関数を起動する．MetricReader は，Go 言語 [19] で実装しる個数を 15 とする．これらの固定のパラメータ値を除いた Amazon EC2[20] のインスタンス上の Web サーバであた，ベンチマークごとに可変なパラメータの組み合わせをり，処理に必要なデータは各 KVS 上に保存されており，

表 2 に示す．WCU(Write Capacity Units) とは，AWS に

MetricReader 自体は状態を持たないため，ロードバランサ

より定義されている DynamoDB のテーブルに対する書きを利用することによりスケールアウトできる．

込みのためのキャパシティ量であり，テーブル上の 1 項目

DynamoDB から S3 へのデータ移動では，DynamoDBは DynamoDB Triggers と呼ばれる機能により，TTL が 0になりキーバリューペアが削除されると Lambda 関数をⓒ 2018 Information Processing Society of Japanに対する 1KB 以下の 1 秒あたり 1 回の書き込みが 1 WCUとなる．
まず，書き込み処理効率を評価するために，オンディス
12インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

2
1
0
0

20

40

60
minutes

80100(a) 分間書き込み回数

12
10
8
6
4

0

120

14

20

40

60
80
minutes

100

500

14
12

400

10

300

8
6

200

4

2

2

0
120

0

(b) インメモリ KVS のリソース使用量600

In-Memory KVS [writes/min (mega)]
On-Disk KVS [writes/min (kilo)]16

16

writes / min (kilo)

3

18

master CPU usage (%)
slave1 CPU usage (%)
slave2 CPU usage (%)
Free memory size (GB)writes / min (mega)

4

100
90
80
70
60
50
40
30
20
10
0

Free memory size (GB)In-Memory KVS
On-Disk KVS

CPU usage (%)

datapoint writes / min (mega)

5

IOTS2018
2018/12/6

100
0
P1

P2
P3
parameters set

P4(c) 書き込みスケールアウト性能

図 5: 実験結果

表 2: スケールアウト性能ベンチマークのパラメータ

みデータ点数と一致する．オンディスク KVS への分間書

エージェント数

インメモリ KVS のノード数

WCU

き込み回数は，インメモリ KVS の分間書き込み回数の約

40,0003

6,000

1/20 程度となっている．

P2

80,0006

12,000

図 5(b) では，インメモリ KVS の空きメモリ使用量は最大P3

120,000

9

18,000

容量の 16GB からベンチマーク時間が増加するにつれて 50

P4180,000

12

24,000分経過するまで徐々に減少し，その後約 10.5GB 前後で一P1定の値をとりつつ遷移している．図 5(b) の master はクラク KVS に直接書き込む場合と比較し，インメモリ KVS でスタ内のマスタノードを示しており，slave1 と slave2 はそ書き込みを受けることにより，オンディスク KVS への書

れぞれ 2 台のスレーブノードを示している．マスタノード

き込み回数が減少しているかを確認する．次に，データ保の CPU 利用率は，15 分経過するまで約 45%で一定となっ存効率を評価するために，書き込みを続けた結果，インメているが，その後約 75%まで増加し，約 60%から約 75%の

モリ KVS の空きメモリ量が 0 になることなく，オンディ間を波形状に値をとりつつ遷移している．MetricWriter が

スク KVS へデータを移動できているかを確認する．表 2

一部の読み取り処理を分散させているスレーブノードのの P1 のパラメータを用いてベンチマークプログラムを 2

CPU 利用率は，グラフの形状はマスタノードと同様だが，時間動作させ，インメモリ KVS とオンディスク KVS への15 分経過以降は，最大値として約 40%，最小値として約分間書き込み回数変化，インメモリ KVS の空きメモリ量35%の値をとる．

と CPU 利用率の変化を観察し，グラフ化した．図 5(a) に

図 5(c) の parameters set は表 2 のパラメータの組み合

分間書き込み回数の遷移，図 5(b) に空きメモリ量と CPU

わせを示しており，Redis Cluster のマスタノード 1 台，ス

利用率の遷移を示す．

レーブノード 2 台を一つのグループとし，3 台ずつ増加させ最後に，書き込みスケーラビリティを評価するために，ている．図 5(c) では，インスタンス KVS とオンディスク

各 KVS のキャパシティを増加させたときに，分間書き込み

KVS への分間書き込みデータ点数がノード数および WCU

回数がスケールアウトするかどうかを確認する．表 2 のパの増加に対して線形に増加しているため，スケールアウト

ラメータの各組み合わせについて，それぞれベンチマークしていると言える．

プログラムを 2 時間動作させ，分間書き込みデータ点数の5. 考察

平均値をとり，グラフ化した．図 5(c) にインメモリ KVSとオンディスク KVS のそれぞれのスケールアウト性能をオンディスク KVS へ直接書き込む方式で同様のベンチ

示す．ただし，ベンチマークの最初の 15 分間はインメモ

マークを実施したとすると，提案手法にてインメモリ KVS

リ KVS にデータ点を蓄積しており，オンディスク KVS のが受け付けていた書き込みをインメモリ KVS の代わりに書き込み回数は 0 となるため，オンディスク KVS の書き

オンディスク KVS が受け付けることになるため，オンディ

込み回数が不当に小さくならないように最初の 15 分間の

スク KVS への分間書き込み回数が提案手法におけるイン

値は平均値の計算対象から除外した．

メモリ KVS への分間書き込み回数が同程度になるはずで

図 5(a) では，インメモリ KVS の分間書き込み回数は約ある．したがって，4 章で示した結果から，オンディスク

4M の値で一定であり，オンディスク KVS への分間書き込

KVS へ直接書き込む方式と比較して，提案手法はオンディ

み回数は最初の 15 分間では 0 のまま遷移し，それ以降は

スク KVS への書き込み回数を約 1/20 に削減していると言70k から 170k の間の値をとりつつ遷移している．4M といえる．また，実験に利用したベンチマーククライアントは，

う値は，ベンチマークプログラムにて指定した分間書き込

同じメトリック名かつ同じタイムスタンプをもつデータ点ⓒ 2018 Information Processing Society of Japan13

インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

を 1 回のみ送信するため，インメモリ KVS 上ではデータ

まれ，インメモリ KVS に対する書き込みクエリのサイズが追記されるのみとなり，メモリ使用量は時間経過に対しが実装上の上限を超えエラーを返し，Lambda 関数の実行て単調増加するはずである．4 章で示した結果から，インが再試行され続け，MetricWriter 全体の処理が遅延した．

メモリ KVS のメモリ使用量が時間経過に対して変化しな

MetricWriter にて，同一メトリック名かつ同一タイムスタ

いため，提案手法は，オンディスク KVS へデータを移動さンプをもつデータ点の重複を除去するようにプログラムをせることにより，インメモリ KVS のメモリ使用量を一定修正し，解決した．

に保つことがわかる．以上により，実験では，書き込み処

同期間に発生した故障として，インメモリ KVS のノー

理効率の高いインメモリ KVS にデータを書き込みつつも，

ド故障が 2 件ある．ただし，AWS の利用者からは本システ

容量単価の大きいメモリの使用量の増加を抑え，容量単価

ム構成の要素のうち EC2 インスタンス以外のコンポーネの小さいオンディスク KVS へデータを移動していること

ントの故障を確認できないため，故障記録の対象から除外を確認できたため，提案手法は書き込み処理効率とデータしている．1 件目では，クラスタを構成するノードのうち保存効率を両立できていると考える．

1 個の EC2 インスタンスが意図せず再起動したが，Redis

図 5(b) において，ベンチマーククライアントは一定のス

Cluster の故障検知機能により，クラスタから自動で除外さループットでデータ点を送信しているにも関わらず，時間れたため，サービス利用者に影響はなかった．EC2 インス

経過するとインメモリ KVS の CPU 利用率が増加していタンスの起動時に同一データの複製をもつ他のノードからる．MetricWriter のインメモリ KVS に対する処理が時間

データを取得するようにしているため，データの消失なく変化に対して増える要素は，インメモリ KVS 上に一定個自動で復旧した．2 件目では，クラスタ内のノードのうち数以上蓄積したメトリック系列をオンディスク KVS へ書

同時に 2 個の EC2 インスタンスが意図せず停止したが，1き込むときに，インメモリ KVS から系列を読み出し，削除

件目と同様にクラスタから自動で除外されたため，クラス

する処理以外に実装上存在しないため，これらのオーバー

タから除外されるまでエラーが短時間発生し，一部のメト

ヘッドにより，CPU 利用率が増加していたと推測できる．

リックの書き込みが遅延するのみの影響に留まった．以上

インメモリ KVS からオンディスク KVS へのデータ移動ににより，故障が発生したとしても，全体として処理を継続

ついて，実験にて採用したカウント手法ではなくタイマーできていたことから，可用性を確保できていると言える．

手法を採用することにより，インメモリ KVS から系列を読み出す処理が不要になるため，CPU 利用率の増加を抑えられると考える．

6. 実環境への適用

7. まとめと今後の展望
本研究では，モニタリングサービスの要件を踏まえ，デー
タ構造の拡張性を高めるために異種混合 DBMS 構成を前提とし，インメモリ KVS とオンディスク KVS を自動階層

株式会社はてなのモニタリングサービスである Mackerel

化する時系列データベースアーキテクチャの HeteroTSDBの実環境に HeteroTSDB アーキテクチャを適用した例を示を提案した．AWS のサーバレスプラットフォーム上で実す．具体的には，本手法を適用した 2017 年 8 月から 2018

装することにより，複数の DBMS の構築やスケールアウト

年 8 月までの 1 年間の時系列データベースに関する障害と作業の負担を低減できるため，異種混合 DBMS 構成をとり故障についての対応を記述する．実環境におけるシステム

やすくなり，HeteroTSDB アーキテクチャを実環境へ適用

構成は，図 4 と同等だが，開発当時に ElastiCache for Redis

しやすくしている．実験により，拡張性のために疎結合ながクラスタのサイズの拡張に対応しておらず，スケールア

アーキテクチャをとりつつも，実用に耐えられる程度の書

ウトが困難であったために，実環境では EC2 インスタン

き込み処理効率，データ保存効率，および書き込みスケール

ス上の Redis Cluster を採用している．

アウト性をもつことを確認した．また，HeteroTSDB アー

上記の期間に発生した障害は 2 件ある．1 件目では，イ

キテクチャを実環境へ適用した結果，故障時に全体の処理

ンメモリ KVS の特定のノードに書き込み負荷が集中し，を継続できなくなることがなく，可用性が問題になること

当該ノード内のメモリ消費が上限に達し，OS がプロセスがないことがわかった．

を強制停止した結果，複数の特定のメトリックのデータを

今後の展望としては，まず，他の時系列データベースと一時的に消失した．そこで，Kinesis Data Streams に残留の比較実験をした上で HeteroTSDB アーキテクチャが性しているデータに対して，消失した時刻よりも前の時刻か能面で実用的であることを示す必要がある．次に，データ

ら Lambda 関数により再処理させることにより，消失し構造の拡張の実装を進め，HeteroTSDB アーキテクチャのたデータを復旧した．インメモリ KVS の故障時のデータ拡張性を評価できるように研究を進めていく．モニタリン

永続性の課題をメッセージブローカーにより解決できたとグのために有用な機能を追加する予定であり，具体的には，

言える．2 件目では，同一メトリック名かつ同一タイムス

問い合わせ時に必要なデータが存在する KVS のみ参照すタンプをもつ想定以上の個数のデータ点が短時間で書き込るためのデータ構造を追加することにより，低速な KVSⓒ 2018 Information Processing Society of Japan14

インターネットと運用技術シンポジウム 2018
Internet and Operation Technology Symposium 2018

IOTS2018
2018/12/6

への参照を減らし，読み込み処理速度を高めていく．さらに，OpenTSDB や InfluxDB のようにメトリック系列に対して属性情報を付与することにより，豊富なデータ表現が可能となるように拡張していく．最後に，KVS 間のデー
タ移動のためのタイマー手法を汎用化し，処理とデータとタイマーを結びつけたデータパイプラインのための新たなアーキテクチャを考えていく予定がある．
参考文献
[1]

[2]

[3]
[4]
[5]

[6]

[7]

[8]

[9]
[10]

[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]

[20]

Meng S, Liu L: Enhanced Monitoring-as-a-Service for
Effective Cloud Management, IEEE Transactions on
Computers, Vol. 62, No. 9, pp. 1705–1720 2013.
Jensen S K, et al.: Time Series Management Systems:
A Survey, IEEE Transactions on Knowledge and Data
Engineering, Vol. 29, No. 11, pp. 2581–2600 2017.
OpenTSDB, http://opentsdb.net.
Cattell R: Scalable SQL and NoSQL Data Stores, ACM
SIGMOD Record, Vol. 39, No. 4, pp. 12–27 2011.
Zhang H, et al.: In-Memory Big Data Management andProcessing: A Survey, IEEE Transactions on Knowledge and Data Engineering, Vol. 27, No. 7, pp. 1920–
1948 2015.
O’Neil P, et al.: The Log-Structured Merge-Tree (LSMtree), Acta Informatica, Vol. 33, No. 4, pp. 351–385
1996.
Chang F, et al.: Bigtable: A Distributed Storage System
for Structured Data, ACM Transactions on Computer
Systems (TOCS), Vol. 26, No. 2, pp. 4:1–4:26 2008.
Pelkonen T, et al.: Gorilla: A Fast, Scalable, In-Memory
Time Series Database, 41st International Conference on
Very Large Data Bases (VLDB), Vol. 8, No. 12, pp.
1816–1827 2015.
InfluxData: InfluxDB, https://www.influxdata.com/timeseries-platform/influxdb/.
Mohan C, Levine F: ARIES/IM: An Efficient and High
Concurrency Index Management Method Using WriteAhead Logging, ACM International Conference on
Management of Data (SIGMOD), pp. 371–380 1992.
John V, Liu X: A Survey of Distributed Message Broker
Queues, arXiv preprint arXiv:1704.00411 2017.
Sanfilippo S, Noordhuis P: Redis, https://redis.io.
Amazon Web Services:
Amazon DynamoDB,
https://aws.amazon.com/dynamodb/.
Amazon Web Services: Serverless Computing and Applications, https://aws.amazon.com/jp/serverless/.
Amazon Web Services: Amazon Kinesis Data Streams,
https://aws.amazon.com/jp/kinesis/data-streams/.
Amazon Web Services: Amazon ElastiCache for Redis,
https://aws.amazon.com/elasticache/redis/.
AmazonWeb
Services:
AmazonS3,
https://aws.amazon.com/jp/s3/.
Amazon Web Services:
Amazon CloudWatch,https://aws.amazon.com/documentation/cloudwatch/.
Donovan A A, Kernighan B W: The Go Programming Language, Addison-Wesley Professional, 1st edition 2015.
AmazonWeb
Services:
AmazonEC2,
https://aws.amazon.com/jp/ec2/.

ⓒ 2018 Information Processing Society of Japan

15