トップ > Architecture > サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ

サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ

Architecture DataBase TSDB

この記事は、第2回ウェブシステムアーキテクチャ研究会の予稿です。

ウェブシステムをモニタリングするために、高可用性、高書き込みスケーラビリティ、メトリックの長期保存が可能な時系列データベースが求められている。 これらを実現するために、性能特性の異なる汎用Key-Value Store(以下KVS)を組み合わせ、透過的に問い合わせ可能な、ヘテロジニアス時系列データベースであるDiamondを開発した。 この記事では、Diamondを分散システムの観点で捉え、アーキテクチャ、データ構造、実装を紹介し、考察によりFuture Workを議論する。

1. はじめに

クラウドコンピューティング、コンテナ型仮想化、マイクロサービスなどの普及により、ウェブシステムの複雑度が向上した結果、人間が複雑な構造を観測するために、よりよいモニタリングが必要とされている1。 モニタリング技術のうち、時系列データモニタリングがあり、時系列データの可視化と時系列データによるアラーティングが一般的である。 時系列データモニタリングのために、多数のサーバから複数のメトリックを定期的に時系列データとして収集する必要があり、ストレージとして時系列データに特化した時系列データベースが利用される2。 時系列データベースには、様々な要求があるが、ここでは、メトリックの長期保持、高書き込みスケーラビリティ、高信頼性が要求されるユースケースに着目する。メトリックの長期保持については、異常検知でのユースケースなどがあり3、高書き込みスケーラビリティについては時系列データベース一般に求められ、高信頼性についてはService as a Service(SaaS)型のモニタリングサービスにおいて強く求められる。

時系列データベースには、大きく分類すると専用DBMS方式と汎用DBMS方式、RDBMS拡張の3種類がある4。RDBMS拡張については、ここでは汎用DBMS方式に含むこととする。 専用DBMS方式は、時系列データベースに最適化されたデータベースエンジンを実装しており、汎用DBMS方式は汎用DBMS上に時系列データベースとして動作させるためのアプリケーションを実装している。 専用DBMS方式は、性能とデータ保存効率がよいが、分散システムとしての信頼性の観点では、汎用DBMS方式と比較して、成熟度が劣る傾向にあると考える。 例えば、Graphite5、Gorilla6、BTrDB7などがある。 一方、汎用DBMS方式は、汎用であるがゆえに専用DBMS方式と比較して性能は劣りやすいが、分散システムとしての信頼性が高い。 例えば、OpenTSDB、KairosDBなどがある。

このように、長期保存、高書き込みスケーラビリティ、高信頼性を満たす時系列DBはある一方で、特殊なストレージエンジンのため運用コストが高い、または、長期保存かつ高書き込みスループットであってもリソース使用量が高いといういずれかの課題がある。 リソース使用量の高さは最終的に費用の高さに結びつく。

そこで、低運用コスト、低費用で、メトリックの長期保存、高書き込みスケーラビリティ、高信頼性を実現するために、複数の異なる汎用DBMSを組み合わせ、透過的な問い合わせが可能なヘテロジニアス型時系列データべースとしてDiamondを開発した8。 具体的には、インメモリ分散KVS、オンSSD分散KVS、オンHDD分散KVSを組み合わせ、書き込みスループットとストレージのGB単価を最適化し、クラッシュリカバリのためのWrite-Ahead Log(WAL)9として分散メッセージブローカーを利用した。 プロビジョニングと故障からの復旧の容易さを低減するために、マネージドサービスを用いたサーバレスアーキテクチャ10を採用した。

2. アーキテクチャ

アーキテクチャ概要

アーキテクチャとしての達成要件は以下の5つである。

  • (a) 書き込みI/Oが増加したときに各コンポーネントがスケールアウト可能
  • (b) 高可用性: 特定のノードが故障しても処理を継続可能
  • (c) 書き込みI/Oとデータ保持の観点で、コンピューティングリソース費用効率が高いこと
  • (d) リソースのプロビジョニングおよび故障時の復旧の容易さ
  • (e) 検証および開発の容易さ

(a), (b)については、汎用DBMS方式を選択し、Dynamo-styleと呼ばれるようないわゆる分散データベース[2]を利用することにより達成できる。 Dynamo-styleのデータベースは、CassandraやDynamoDBのようにKVSの形をとることが多いため、以下ではKVSの利用を前提とする。 (c)については、書き込みI/OだけみればインメモリKVSが有利だが、データ保持の観点でみるとHDDベースのKVSが有利である。 そこで、複数のKVSを組み合わせたヘテロジニアス構成により、インメモリKVS書き込みI/Oを受け付け、参照頻度の低い古いタイムスタンプをもつデータポイントを低速なディスクに配置する。 さらに、インメモリKVSの耐久性を補うため、Apache Kafkaのような分散メッセージブローカーをWALとして利用し、クラッシュリカバリできるようにする。 しかし、複数のOSSのDBMS実装を用いつつ、(d),(e)を達成することは、困難であると考え、そこで、クラウド事業者が提供するマネージドサービスを用いたサーバレスアーキテクチャを採用する。

一方で、専用DBMS方式を選ばない理由として、次のの2点がある。 (a),(b),(c)を満たす専用DBMS方式を新規開発することは難易度が高いことと、汎用DBMS方式のほうが分散システムとして成熟した実装である傾向があるためだ。

ヘテロジニアス環境においては、一時的な故障の発生により、各KVS間のデータ整合性と耐久性を失いやすくなる。 そこで、故障時にリトライ可能にするために、べき等性をもつデータ構造が重要となる。 さらに、複数の異なる特性をもつKVS実装を利用するため、特殊な機能に依存しないシンプルな機能要件のみで、データ構造を実装できることが重要だ。 一方、伝統的なデータベースが備えるACID特性を満たすことは、サーバモニタリング向け時系列データベースのコアな要求ではない。

以下では、アーキテクチャの動作フロー、データ構造およびKVSの機能要件を説明する。

動作フロー

Diamondアーキテクチャの動作フローを以下に示す。

     write path
         |
         v
+----------------------+
| 分散メッセージブローカー |
+----------------------+
         |
         v
+-----------------+
|  writer node    |
+-----------------+
         |
         v
+-----------------+
| インメモリ分散KVS | -------------\
+-----------------+               \
         |  flush                  \
         v                          v
+-----------------+              +-------------+
| オンSSD分散KVS  | -----------> | reader node | ---> read path
+-----------------+              +-------------+
         |  export                  ^
         v                         /
+-----------------+               /
| オンHDD分散KVS  | ------------/
+-----------------+

まず、書き込み経路を説明する。

  1. クライアントが分散メッセージブローカーに非同期書き込み
  2. 分散メッセージブローカーからのメッセージを購読しているwriter nodeがインメモリ分散KVSに書き込み
    1. において、メトリックごとのデータポイント数が所定の個数を超えていれば、SSDベース分散KVSに書き込み
  4. 書き込み経路とは異なるバックグラウンド処理により、一定期間より前のタイムスタンプをもつデータポイントをSSDベース分散KVSからHDDベース分散KVSへデータを移動させる

分散メッセージブローカーは、インメモリKVSのクラッシュリカバリのために利用する。 分散メッセージブローカーに残留するログを再適用することにより、インメモリKVS上のロストしたデータを復元できる。

次に、読み込み経路を説明する。

  1. クライアントがメトリック名とタイムスタンプのレンジをクエリとして、reader-nodeに問い合わせる
  2. reader nodeは、クエリに含まれるタイムスタンプのレンジに応じて、データが配置されているKVSコンポーネントからデータポイントを取得する
  3. reader nodeは、データポイントを取得したのちに、任意の集約操作を適用し、クライアントへデータポイント列を返却する

Diamondアーキテクチャでは、複数のKVS間のデータの整合性を保つために、各KVSへの書き込み処理がべき等であることが重要となる。 書き込み処理がべき等であれば、既に書き込んだデータを再度書き込んだとしても、データの一貫性が担保される。 したがって、クラッシュリカバリの発生またはいずれかのKVSの故障が発生したとしても、リトライによりデータの耐久性を確保できる。

書き込み処理をべき等にするためのデータ構造を以下に説明する。

データ構造

Diamondは、Graphiteプロジェクトの時系列データベースであるWhisper[^14]データ構造に近いモデルを採用している。 Diamondでは、Whisperデータ構造の特徴のうち、以下の2点に着目している。

  • 書き込み処理がべき等であること
  • クライアントの入力にかかわらずメトリック系列に含まれるデータポイント数の最大値を制御できること

まず、KVSに時系列データを格納するための最もシンプルなデータ構造を、以下の図に示す。

+------+        +-----------------------------------------+
| name |  --->  | {timestamp:value, timestamp:value, ...} |
+------+        +-----------------------------------------+

図中のnameはメトリック名を表す文字列、timestampはデータポイントのUNIX時間を表すint64型の数値、valueはデータポイントの値を表すfloat64型の数値である。 このデータ構造では、メトリック名(name)をキー、ハッシュマップをバリューとし、ハッシュマップのキーをタイムスタンプ(timestamp), ハッシュマップのバリューを値(value)とする。 グラフ表示などの読み込みワークロードを考慮すると、ある系列に含まれるデータポイント列をまとめて効率よく読み出す必要があるため、データポイント列を同じレコード内にまとめて格納する。 データポイント列を表すデータ構造が、リストではなくハッシュマップである理由は、同じタイムスタンプをもつデータポイントの上書きを許し、べき等性を確保するためだ。 タイムスタンプのレンジがクエリに含まれる場合は、バリューをすべて取得し、reader nodeがレンジ外のタイムスタンプをもつデータポイントを間引く必要がある。

このデータ構造は、データポイントが追記されるたびに、レコードサイズが増大していく。 KVSはレコードサイズに制限をもつことがあり、その場合制限を超えない程度のレコードサイズを維持しなければならない。 DynamoDB11は400KB、Cloud Bigtable12は256MBのハードリミットをそれぞれ持つ。 この問題を解決するために、メトリック系列を固定幅のタイムウィンドウに分割するデータ構造を以下の図に示す。

+------------------+        +-----------------------------------------+
| name, wtimestamp |  --->  | {timestamp:value, timestamp:value, ...} |
+------------------+        +-----------------------------------------+

wtimestampは、タイムウィンドウの開始時刻を表すUNIX時間であり、ウィンドウサイズは固定長とする。 例えば、ウィンドウサイズが3000秒とすると、wtimestampの値は1482700020, 1482703020, 1482706020...のように3000ずつ加算される。

しかし、ウィンドウ内のデータポイント数の最大値が不定であるため、レコードサイズのハードリミットを超える可能性がある。 時系列データベースとしてサポートするメトリックの解像度をステップと呼ぶことにすると、クライアントがステップより小さなインターバルでメトリックを書き込む場合、ウィンドウ内のデータポイント数は想定よりも大きな値となる。 そこで、データポイント数の最大値を固定するために、ステップの倍数にアラインメントする。 例えば、解像度を60秒とするならば、元のtimestampが1482700025であれば、60で割った剰余を差し引いた値である1482700020に変更したのちに、KVSに書き込む。 ステップよりも小さいインターバルで書き込まれると、アラインメントにより既に書き込まれたtimestampの領域を上書きすることになり、ウィンドウ内のデータポイント数は一定の個数以下となることが保証される。

以上により、Diamondデータ構造がべき等性をもちつつ、KVSの制限内で書き込み処理可能であることを示した。 次に、Diamondデータ構造を実現するためのKVSの機能要件を説明する。

KVSの機能要件

Whisperデータ構造をKVS上で実装するには、各KVSへ求める最低限の機能要件として以下を満たす必要がある。

  • キーを入力とし、キーに対応するバリューを出力できる
  • バリューのデータ型としてバイナリが実装されている

KVSとしてごく標準的な機能を満たせば実装可能であることが要点である。

ただし、書き込み処理効率の観点では、バリューのデータ構造としてハッシュマップが実装されていることが望ましい。 データポイントをレコードに追記する際に、レコード内に存在する既存のデータポイントをKVSの外へ読み出したのちに、新らたに書き込むデータポイントを結合し、レコードを更新する必要がある。 KVSがハッシュマップを実装していれば、KVS内で効率よくデータポイントを追記できる。

さらに、ACIDのうち隔離性の観点では、read-modify-write操作をatomicに実行できることが望ましい。 複数のクライアントが同じレコードを書き込もうとしたときに、クライアントAが既存のレコードを読み取ったあとに、クライアントBがレコードに書き込んだとき、クライアントBの書き込みが失われることがありえる。

3. 実装

実装概要

分散メッセージブローカーとしてAmazon Kinesis Streams13、インメモリ分散KVSとしてRedis14、SSDベース分散KVSとしてAmazon DynamoDB、HDDベース分散KVSとしてAmazon S315を採用した。 writer nodeとして、AWS Lambda16、DynamoDBからS3へのデータ移動についてはDynamoDB TTLとDynamoDB Triggerを利用し、TTLの期限切れイベントを契機にLambda functionを起動し、S3へ期限切れしたレコードを書き込む。

実装の構成図を以下に示す。

              +---------------------------------------------------------------+
              |                                                               |
write path -->|--> Kinesis Streams --> Lambda (writer) ------------------+    |
              |                                                          |    |
              |                                   |<- Redis Cluster <----+    |
read path  <--|<-- ALB <-- reader(golang) <-------|                      |    |
              |                                   |<- DynamoDB <---------+    |
              |                                   |      v                    |
              |                                   |   Lambda (exporter)       |
              |                                   |      v                    |
              |                                   +<---- S3                   |
              |                                                               |
              +---------------------------------------------------------------+

実装の詳細については、AWS Summit Tokyo 2017のプレゼンテーション17,18,19にて紹介している。

KVS間のデータ移動

まず、RedisからDynamoDBへの移動の実装を説明する。 バックグラウンドプロセスによるバッチ処理ではなく、writerがRedisへのデータポイント書き込み時に条件を満たした場合のみメトリック系列単位でDynamoDBに移動させる。 条件は、Redis上の該当メトリック系列に含まれるデータポイント数がN個以上である。 条件を満たすかをチェックしたのちに、Redisのレコードを読み出し、DynamoDBへ書き込み、最後にRedisの該当レコードを削除する。 データポイントが書き込まれなくなったメトリック系列は、DynamoDBに移動されず、Redis上にデータポイントが残り続けるため 定期的なバッチ処理により、DynamoDBに移動させる。 もし、一連の処理の流れの中で、一時的なエラーが発生した場合はLambda function実行のリトライにより、耐久性とRedisとDynamoDB間のデータ整合性が担保される。

次に、DynamoDBからS3への移動の実装を説明する。 TimeFuzeアーキテクチャ20により、TTLイベントを契機にDynamoDB Triggerを経由して、Lambda Functionを起動し、DynamoDBの期限切れレコードをS3に書き込む。 S3に書き込む際に、FacebookのGorillaにて実装されているdouble-delta-encodingとXOR encodingにより差分符号化した結果を書き込み、データポイントあたりのバイト数を削減している。 S3への書き込み時に一時的なエラーが発生しても、Lambda function実行のリトライにより、データの耐久性と整合性が保証される。

データ位置の解決

reader nodeは、受信したメトリック名とタイムスタンプレンジから、各KVSのうち必要なデータが存在するKVSからデータを取得する。 データが存在するKVSは、メトリックごとに記録せずに、静的に解決している。 タイムスタンプレンジの開始時刻をst、終端時刻をet、現在時刻をnow、Redisにデータが残留する最大経過秒数をn、DynamoDBにデータが残留する最大経過秒数をm、S3にデータが移動するまでの最短経過秒数をkとすると、Redisからのデータ取得条件は et > (now - n)、DynanoDBからのデータ取得条件は et > (now - m)、S3からのデータ取得条件は (now - k) > stとなる。 ただし、n < m とする。 n, m, kの値はヒューリスティックに決定される。

同じメトリック系列かつ同じタイムスタンプをもつデータポイントを異なるKVSからそれぞれ取得した場合、Redis、DynamoDB、S3の順に採用する。

費用特性

本実装において、書き込みスループットとデータ保持の観点で、3種類のKVSによる費用最適化が可能であることを確認する。

まず、サンプルとして、100,000データポイント/sの書き込みスループットにおける費用比較を以下の表に示す。 2018/05/05時点のap-northeast-1リージョンのオンデマンド費用を元にしている。

KVS I/O費用(USD/月)
Redis 1405.44
DynamoDB 54300.83
S3 1258848.00

RedisはEC2インスタンスのr4.large(0.176USD/時間)を使用し、各パーティションあたりのレプリカ数を2、つまり3ノード/パーティションとする。 1ノードあたりの書き込み上限を25,000reqs/secとする(要出典)。 したがって、r4.largeインスタンスが12台必要となる。 EC2インスタンス上のRedisは、書き込み元のwriterと異なるアベイラビリティゾーンに配置されている場合、別途GBあたりのゾーン間転送料金が発生する。 DynamoDBの料金構造21からアイテムサイズに比例してI/Oコストが大きくなる。今回は、最低単位の1KBで計算する。 S3は、標準ストレージを利用するもとすると、S3のPUT料金は1000リクエストあたり0.0047USDである。 S3はKVSではあるが、ファイルを格納するためのオブジェクトストレージであるため、高スループットかつ小さな書き込みには向いておらず、今回のワークロードでは上表のように高額な料金となる。

次に、データ保持費用における費用比較を以下の表に示す。

KVS データ保持費用(USD/GB/月)
Redis 21.96
DynamoDB 0.25
S3 0.025

r4.largeのRAMのサイズは16GBであり、GB単価は7.32USD/月、レプリカ数を2とすると上表の値となる。 S3は標準ストレージを利用するものとする。

以上より、I/O費用とデータ保持費用はトレードオフの関係にあり、高スループット書き込みをインメモリKVSで受け付け、蓄積したメトリックを低速なディスク指向KVSへ移動させる手法の有効性を確認できた。

4. 考察と今後の課題

Diamondの欠点

Diamondは、アーキテクチャレベルで以下の欠点をもつ。

  • (1) 最適化された専用DBMS方式と比べ、処理効率の観点で無駄が多い
  • (2) 各KVSにて実装されているデータ構造が異なるため、ある特定のKVSに実装されている特殊なデータ構造を使いづらい
  • (3) 構成が一見複雑にみえる

(1) については、アーキテクチャの章の概要で述べたように、他の要件の達成により欠点を補えると考えている。 (2) については、シンプルなKVSで表現できる時系列データ構造やインデックス構造の限界がどこにあるかを調査する必要がある。 (3) については、分散トレーシングなどの分散システムをモニタリングする技術の発達により、補えると考えている。

実装レベルでは、以下の欠点がある。

  • (1) S3に移動済みの古いタイムスタンプをもつデータポイントを書き込みしづらい
  • (2) データ位置の解決がヒューリスティックであり、データを正しいKVSから取得できることを完全には保証できない

(1)については、通常の書き込み経路とは異なる、過去の時系列データをまとめたファイルをバッチでアップロードする書き込み経路を実装することで解決できる。 (2)については、静的解決ではなくフォールバック方式またはインデックス方式による動的解決を考えている。

フォールバック方式とは、インメモリKVS、SSDベースKVS、HDDベースKVSの順にメトリック系列を参照することである。 タイムスタンプレンジの開始時刻のデータポイントが存在すれば、その時点でフォールバックを停止し、応答を返却する。 存在しなければ、引き続きフォールバックする。 欠点として、静的解決と比較して、低速なKVSに応答速度を律速されやすい可能性がある。

インデックス方式は、メトリック名とタイムスタンプレンジを入力として、該当するKVSを返却するインデックスにより動的解決することである。 インデックスはインメモリKVS上に保持しておき、データ移動が発生するたびに、インデックスを更新する。 欠点として、インデックス分のメモリ使用とI/Oが増加することがある。

将来機能

Diamondの時系列データモデルとして、現在のWhisperモデルに加えて、Prometheus22が提供するようなラベルによる多次元データモデルをサポートを考える。

前者の多次元データモデルの例を以下に示す。

requests_total{path="/status", method="GET", instance=”10.0.0.1:80”}
requests_total{path="/status", method="POST", instance=”10.0.0.3:80”}
requests_total{path="/", method="GET", instance=”10.0.0.2:80”}

メトリック名であるrequests_totalと、ラベルと呼ばれるキーバリューペアの組み合わせにより、メトリック系列を表現する。 Prometheusでは、V2ストレージではLevelDBによりラベルに対するインデックスを作成しており、V3ストレージでは転置インデックスに置き換えている23。 Prometheusのストレージはファイルシステム上に実装されている一方で、DiamondではKVS上に実装する必要がある。

そこで、V3ストレージエンジン同様に、次のように転置インデックスをKVS上に実装することを考えている。

  1. メトリック系列にユニークなIDを割り当て、データポイントを書き込む
  2. データポイントに紐づくラベルのキーペアをキー、ラベルに紐づくメトリックIDをバリューとして、別途用意したインデックス用KVSに書き込む。
  3. 参照時には、ラベルを入力として、メトリックIDを転置インデックスから取得し、メトリックIDをキーとして各KVSからデータポイント列を取得する。

5. まとめ

本稿では、時系列データに対する高い書き込みスケールアウト性、高可用性、費用効率、低い運用性、開発容易性を実現する時系列データベースアーキテクチャを提案し、実装を示した。 アーキテクチャの要点は、複数のKVSを組み合わせたヘテロジニアス構成、メッセージブローカーによるWALリプレイ、サーバレスアーキテクチャおよびべき等性とデータ幅を制御可能なデータ構造である。 考察では、アーキテクチャと実装のそれぞれの欠点と解決策、さらに多次元データ構造のサポートのアイデアを議論した。

今後の課題としては、以下の2点について、実験・調査したいと考えている。 まず、アーキテクチャ要件の(a)、(b)、(c)の有効性を示すために、先行実装であるGraphiteと比較実験する。 次に、アーキテクチャ要件の(d)、(e)の有効性を示すための文献を調査する。例えば、ソフトウェア開発論文のサーベイにより開発容易性やOSS実装の複雑性を示すヒントを発見する。

スライド

あとがき

@hirolovesbeerさんからの「ヘテロジニアス(heterogeneous)に込めた意味はなにか？」という質問に対してうまく答えられなかったが、この問いの答えがもともとあとがきで書こうと思っていたことだということに気づいたので、ここに記しておく。

ヘテロジニアスの対義語として、ホモジニアス(homogeneous)があり、ホモジニアスな時系列データベースとはここではDBMSの実装を一つだけ使ったものを指す。 それに対して、ここでのヘテロジニアスとは、異種混合データベースの上にデータベースエンジンを実装することを指しており、ヘテロジニアスであることがDiamondアーキテクチャのアイデアの要点となる。

Martin Kleppmann著、「Designing Data-Intensive Applications」24の12章 The Future Of Data Systemsにて、データシステムを構築する上で、すべての異なる状況に適した1つのソフトウェアは存在せず、異なるソフトウェアを組み合わせアプリケーションを開発していく必要があるという趣旨の意見が書かれている。 Diamondアーキテクチャは、この考え方の延長線上にあり、インデックス、WAL、メモリ上のデータ構造、ディスク上のデータ構造など、古典的なデータベースエンジンの構成要素を、ヘテロジニアス環境で再構築したものになる。 そして、サーバレスアーキテクチャにより、分散システム上での複数箇所にまたがるデータの更新、移動を、信頼性のあるビルディングブロックの上に構築しやすくなった。

実際に、ヘテロジニアスKVS環境でGraphiteを実装したもになるため、今度はヘテロジニアスKVS環境でPrometheusを実装することを考えるといろいろとアイデアがでてくる。

実はこれと似た話が身近にあり、例えば id:matsumoto_r さんの言葉を引用する。

今後はVMやコンテナの連携が今でいうOSとなる世界が来ると思っているので、古典的なOSの機能をいかにネットワークに通じたそれに置き換えていくかに挑戦 cgroupとLinux Capabilityの活用 - https://speakerdeck.com/matsumoto_r/rcon-and-capcon-internals-number-lxcjp

この言葉を、分散システム上でOSの構成要素を再構築していくということだと理解しており、これをデータベースに置き換えたような話をやろうとしている気がしてきている。

参考文献

  1. ウェブシステムの運用自律化に向けた構想 - 第3回ウェブサイエンス研究会 - ゆううきブログ↩

  2. B. Mitschang et al. “Survey and Comparison of Open Source Time Series Databases.”, In Proceedings of Database Systems for Business, Technology, and Web, 2017↩

  3. Florian Lautenschlager, et.al., “Chronix: Long Term Storage and Retrieval Technology for Anomaly Detection in Operational Data”, In Proceedings of 14th USENIX Conference on File and Storage Technologies (FAST), 2016.↩

  4. Jensen, Søren Kejser, et al. “Time Series Management Systems: A Survey.” IEEE Transactions on Knowledge and Data Engineering, vol.29, no.11, 2017, pp. 2581-2600.↩

  5. “Whisper”, https://github.com/graphite-project/whisper↩

  6. Pelkonen, Tuomas and Franklin, Scott and Teller, Justin and Cavallaro, Paul and Huang, Qi and Meza, Justin and Veeraraghavan, Kaushik, “Gorilla: a fast, scalable, in-memory time series database”, In Proceedings of the VLDB Endowment, 2015↩

  7. Michael P Andersen and David E. Culler, “BTrDB: Optimizing Storage System Design for Timeseries Processing”, In Proceedings of 14th USENIX Conference on File and Storage Technologies (FAST), 2016.↩

  8. Hatena Co., Ltd., “はてな、サーバー監視サービス「Mackerel」の時系列データベースを強化。1分間隔の時系列データ保持期間を460日に変更”, http://hatenacorp.jp/press/release/entry/2018/01/24/153000, 2018↩

  9. C. Mohan and Frank Levine, “ARIES/IM: An Efficient and High Concurrency Index Management Method Using Write-Ahead Logging”, at ACM International Conference on Management of Data (SIGMOD), June 1992.↩

  10. Sarah Allen, et al. “CNCF Serverless Whitepaper v1.0”, https://github.com/cncf/wg-serverless↩

  11. Amazon Web Services, Inc., “Amazon DynamoDB”, https://aws.amazon.com/dynamodb/, 2018↩

  12. Google, “CLOUD BIGTABLE - A high performance NoSQL database service for large analytical and operational workloads”, https://cloud.google.com/bigtable/, 2018↩

  13. Amazon Web Services, Inc., “Amazon Kinesis Data Streams”, https://aws.amazon.com/kinesis/data-streams/, 2018↩

  14. “Redis”, https://redis.io/↩

  15. Amazon Web Services, Inc., “Amazon S3”, https://aws.amazon.com/s3/, 2018↩

  16. Amazon Web Services, Inc., “AWS Lambda”, https://aws.amazon.com/lambda/, 2018↩

  17. 時系列データベースという概念をクラウドの技で再構築する - ゆううきブログ↩

  18. サーバレスアーキテクチャによる時系列データベースの構築と監視 / Serverlessconf Tokyo 2017 - Speaker Deck↩

  19. AWS で実現した Mackerel 時系列データ1分粒度長期保存の裏側 / Mackerel Meetup #11 Tokyo - Speaker Deck↩

  20. TimeFuzeアーキテクチャ構想 - 処理とデータとタイマーを一体化したデータパイプライン - ゆううきブログ↩

  21. DynamoDBのインフラコストの構造と削減策 - ゆううきブログ↩

  22. Prometheus Authors, “Prometheus”, https://prometheus.io/, 2018↩

  23. Fabian Reinartz, “Writing a Time Series Database from Scratch”, https://fabxc.org/, April 20 2017.↩

  24. Martin Kleppmann, “Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems”, O'Reilly Media, March 2017↩