時系列を扱うDB「Amazon Timestream」と「Amazon DynamoDB」の違いとは？

2021.09.01

本記事のポイント

2020年10月に利用可能となった時系列データ専門のデータベース「Amazon Timestream」ですが、もうすぐでリリースから1年が経過します。それより以前は、IoTデータや監視ログデータなどの収集に「Amazon DynamoDB」を利用する方も多かったのではないでしょうか。

今回、今までDynamoDBで行えていた作業をわざわざ専門のTimestreamで行う必要があるのか、メリットを調査しました。

はじめに

「大量のデバイスから時系列のログデータを収集し、それらのデータを数分以内に集計して、結果を示すようなサービスを行いたい」

このようなユースケースでは、スケールアウトにより膨大なリクエストに対応でき、収集したデータをニアリアルタイムで反映できるAmazon DynamoDB（以下、DynamoDB）を用いてシステムを構築する方が多いのではないでしょうか。

しかし、時系列データを扱う場合、Amazon Timestream （以下、Timestream）という選択肢も存在することを忘れてはいけません。Timestreamとは、2020年10月に利用可能になった、時系列データを専門に扱うサーバーレスのデータベースです。まさに上記のような要求を満たすために誕生しました。

しかし、Timestreamを使ってみたという記事はまだあまり見かけず、「実際にDynamoDBに比べて性能やコストパフォーマンスはどうなの？」という疑問があったため、DynamoDBとTimestreamの比較検証を行いたいと思います。

> AWS利用料今なら8%OFF – 利用中の方も、アカウント移管だけで割引適用

> AWSの監視・障害対応・運用保守を一括代行！

DynamoDBとTimestream、比較検証の結果

今回、時系列データを扱ったシナリオを想定し、いくつかの比較を行いました。
まず、結論から記載します。

時系列のログデータなど、大量のデータを収集・保持し続け、さらにいつでも分析を必要とするような用途だと、DynamoDBよりもTimestreamの方が使いやすくコストパフォーマンスが高いことが分かりました。

今回の比較では、速度に関してはDynamoDBの方が若干速く、料金はTimestreamの方が安い、という結果が出ました。また、ベストプラクティスに沿って設計をした場合、Timestreamの方がシンプルに設計でき、DynamoDBでは少し複雑な設計を必要とし煩雑になる印象を受けました。
DynamoDBとTimestream、比較検証の結果

想定シナリオ

想定するシナリオは、以下の通りです。

200個のEC2インスタンス

各インスタンスから毎分1回のメトリクス書き込みが発生
（1回のメトリクス書き込みは2KB = 1つのメトリクス0.2KB × 10個）

毎時100回のアラートクエリの読み込みを実行
（1回のアラートクエリの読み込みは2MB= 2KB × 200個のインスタンス × 5分）

本シナリオは、AWSの公式サイトに記載の「Timestream料金の例」を参考にしています。

EC2インスタンスのメトリクス監視を想定します。200個のEC2インスタンスを実行し、各インスタンスから1分間隔で10 個のメトリクスを出力するアプリケーションがあるとします。データベース（ここではTimestreamまたはDynamoDB）を使用して、このデータを保存および分析し、アプリケーションのパフォーマンスと可用性を深く理解したいと考えています。

各メトリクスは約0.2KBで各インスタンスからは10個のメトリクスをまとめて送信されます。インスタンスの稼働状況を監視するために、1時間に100 件のクエリを実行して異常なアクティビティを特定してアラートを出力する予定です。アラートクエリでは過去5分間のデータを基に異常なアクティビティがないかどうかを確認します。

※ 参考）https://aws.amazon.com/jp/architecture/icons/

> AWS利用料今なら8%OFF – 利用中の方も、アカウント移管だけで割引適用

> AWSの監視・障害対応・運用保守を一括代行！

料金の比較

DynamoDBとTimestreamの料金比較ですが、結論、過去データの保持期間を長くすればするほど、Timestreamに軍配が上がります。

これは、DynamoDBはTimestreamと比べ、データの書き込み/読み込みの価格が安く、ストレージの価格が高くなっているためであると考えられます。

また、DynamoDBにはリザーブドキャパシティという選択肢もありますが、ストレージの割引は適用されません。そのため書き込み/読み込みがシナリオと同程度かそれほど膨大でなければ、DynamoDB単体では、ストレージの使用量が多くなった場合、長期戦になった場合Timestreamに価格勝負で勝つことができません。

今回のシナリオでは両者ともに書き込み/読み込みにかかるコストは一定なので、価格を決めるうえで重要になってくるのはストレージコストです。

したがって、短期間であればTimestreamのメモリストアが高価であるため損をしますが、長期間であればマグネティックストアの圧倒的な安さで、合計コストではDynamoDBに比べるとTimestreamの方が安くなります。

DynamoDBとTimestream、料金の比較方法

データベースでメトリクスを保持する期間をN年として比較

Timestreamでは、メモリストアに6時間、マグネティックストアを残りの時間に設定

DynamoDBでは、プロビジョンドキャパシティのデフォルト設定
（ターゲット使用率70%、キャパシティ5～40,000）

> AWS利用料今なら8%OFF – 利用中の方も、アカウント移管だけで割引適用

> AWSの監視・障害対応・運用保守を一括代行！

速度の比較

DynamoDBとTimestreamの速度比較ですが、今回の調査では、DynamoDBの方がTimestreamに比べて書き込み/読み込みスピードが速い、という結果になりました。

なお、Amazonの公式サイトによると、両者ともに1秒あたり数千の書き込み/読み込みリクエストを処理できる、とあります。（2021年8月30日時点）

DynamoDBではスケーリングにより毎秒数千万の書き込み/読み込みをサポートされ、 Timestreamではオートスケールにより毎日数兆のイベント（= 毎秒約数千イベント）をサポートされるようです。

DynamoDBとTimestream、速度の比較方法

同じリージョン内（バージニア: us-east-1）のAWS Lambda から、AWS SDKを使って書き込み/読み込みを行います

書き込みでは、1KBのデータを100回書き込む速度を計測します
（データサイズはAmazon Timestreamの料金を参考にしました）

読み込みでは、上で書き込んだ100レコードをすべて読み込みます
（データサイズはAmazon DynamoDBの料金を参考にしました）

結果は3回の測定の平均です

テスト結果

以下がテスト時の結果です。書き込み/読み込み共にDynamoDBの方がTimestreamに比べて早いことがわかります。特に、書き込み速度はDynamoDBの方が1.25倍速いです。

比較項目	DynamoDB	Timestream
書き込み速度（秒 / 100レコード）	3.69	4.64
読み込み速度（秒 / 100レコード）	0.20	0.22

> AWS利用料今なら8%OFF – 利用中の方も、アカウント移管だけで割引適用

> AWSの監視・障害対応・運用保守を一括代行！

ベストプラクティスの比較

時系列データを扱うときの、DynamoDBとTimestreamのベストプラクティスをまとめます。結論、Timestreamの方がフルマネージドされており制約は多いですが、管理がシンプルで楽だと思います。

DynamoDBでは柔軟性がありできることは多いですが、それを実現するためにはすべて自分で設定する必要があり、難易度が高いと言えます。多少の煩わしさがあるかもしれません。

例えば、テーブルとデータライフサイクルに関しては、Timestreamでは1つの事象で1つのテーブルを用意して、あらかじめライフサイクルを設定するとあとは自動で永続的に実行されます。しかし、DynamoDBでは一定期間ごとに書き込み/読み込みキャパシティを最適化する必要があり、別々のテーブルを用意して管理しなければなりません。

さらに、それぞれのテーブルに対してTTL（Time to Live）の設定をしてようやくライフサイクルの設定ができます。

ベストプラクティスな構成（DynamoDB）

DynamoDBの時系列データを扱う際のベストプラクティスな構成をご紹介します。一般的な設計原則では、使用するテーブルの数を最小限に抑えますが、時系列データでは一定期間ごとに個別のテーブルを作成すると最適に処理できます。

タイムスタンプをプライマリーキーとして設定します。
例えば、パーティションキーに日付（date: 2021-09-21）、ソートキーに時間（time: 21-19-56）のようにします。

一定期間ごとに別のテーブルを用意します。そうすることで、ホットパーティション（最新のレコード）とアクセス頻度の低いパーティション（古いレコード）でキャパシティの最適化が行えます

例えば、月次のテーブルを用意しその月を表すテーブル（table: 2021-09）を作成していきます。各期間が終了する前に、次の期間のテーブルを事前に作成しておき、現在のテーブルから次のテーブルへ書き込みが完全に移行するまで待機します

期間が変わったら、古いテーブルのキャパシティを低い値に設定します