時系列データベース - Amazon Timestream で IoT / メトリクスデータを効率管理する

時系列データの特性と専用データベースの必要性

時系列データは、タイムスタンプを持つデータポイントが時間順に連続的に生成されるデータです。IoT センサーの温度 / 湿度 / 振動データ、アプリケーションのメトリクス (CPU 使用率、レスポンスタイム、リクエスト数)、金融市場の価格データ、ログイベントなどが該当します。時系列データには固有の特性があります。書き込みが圧倒的に多く読み取りは集計クエリが中心であること、直近のデータほどアクセス頻度が高いこと、古いデータは自動的に削除または低コストストレージに移行したいこと、時間範囲での集計 / 補間 / 異常検知が必要なことです。RDS や DynamoDB でも時系列データを格納できますが、これらの特性に最適化されていないため、データ量の増加に伴いコストとクエリ性能が悪化します。Amazon Timestream は時系列データに特化したサーバーレスデータベースで、これらの課題を根本的に解決します。なお、本記事で扱う従来型の Timestream for LiveAnalytics は 2025 年 6 月 20 日に新規顧客向けの受付を終了しており、新規の時系列ワークロードには Timestream for InfluxDB が案内されています (2026 年 8 月時点)。

アーキテクチャと自動階層化ストレージ

Timestream は 2 層のストレージアーキテクチャを採用しています。メモリストアは直近のデータを保持する高速ストレージで、書き込みと直近データのクエリに最適化されています。保持期間は 1 時間〜 8,766 時間 (約 1 年) で設定します。マグネティックストアは過去のデータを保持する低コストストレージで、長期間のデータ分析に使用します。保持期間は 1 日〜 73,000 日 (約 200 年) で設定できます。データはメモリストアの保持期間を過ぎると自動的にマグネティックストアに移行し、マグネティックストアの保持期間を過ぎると自動的に削除されます。この自動階層化により、データのライフサイクル管理が不要になります。データは自動的に圧縮 / 暗号化され、ストレージコストを最小化します。Timestream はサーバーレスで、キャパシティプランニングやインスタンス管理が不要です。書き込みスループットとクエリ処理能力は自動的にスケーリングされます。

SQL クエリと時系列関数

Timestream は SQL 互換のクエリ言語を提供し、標準的な SQL に加えて時系列固有の関数をサポートします。補間関数はデータポイント間の欠損値を補完するもので、線形補間の interpolate_linear 、三次スプライン補間の interpolate_spline_cubic 、直前の観測値をそのまま引き継ぐ interpolate_locf 、指定した定数で埋める interpolate_fill の 4 種類が用意されています。センサー値のように連続的に変化する系列は線形か三次スプライン、開閉状態のように次の観測まで値が保たれる信号は interpolate_locf を選びます。あわせて平滑化関数で移動平均を計算し、近似関数でトレンドを抽出できます。

-- 直近 1 時間の 5 分間隔の平均温度
SELECT device_id,
       bin(time, 5m) AS interval,
       avg(measure_value::double) AS avg_temp
FROM iot_db.sensor_data
WHERE measure_name = 'temperature'
  AND time > ago(1h)
GROUP BY device_id, bin(time, 5m)
ORDER BY interval DESC

スケジュールクエリは、定期的にクエリを実行して結果をマグネティックストアに書き戻す機能です。たとえば 1 時間ごとの集計結果を事前計算しておくことで、ダッシュボードのクエリコストとレイテンシを大幅に削減できます。 Grafana との統合でリアルタイムダッシュボードを構築でき、 Timestream 用の Grafana プラグインが公式に提供されています。

データの取り込みとユースケース

Timestream へのデータ取り込みは AWS SDK (WriteRecords API) で行います。IoT Core のルールアクションで IoT デバイスからのデータを直接 Timestream に書き込むことも可能です。ストリーミングデータは Amazon Managed Service for Apache Flink 経由で取り込み、メトリクス収集エージェントの Telegraf からも書き込めます。Kinesis Data Streams のレコードは、Managed Service for Apache Flink 用のサンプルのコネクタか EventBridge Pipes を間に置いて取り込めます。過去データをまとめて投入する場合は、S3 上の CSV ファイルを読み込むバッチロードが使えます。主なユースケースは、IoT センサーデータの収集 / 分析 (工場の設備監視、スマートホーム、車両テレメトリ)、アプリケーションメトリクスの長期保存と分析 (CloudWatch の保持期間を超えるメトリクスの保存)、DevOps のインフラ監視 (サーバーメトリクス、コンテナメトリクスの集約)、ビジネスメトリクスの追跡 (売上推移、ユーザーアクティビティ) です。DynamoDB との使い分けとして、キーバリューアクセスパターン (特定デバイスの最新値の取得) が中心なら DynamoDB、時間範囲の集計 / 分析が中心なら Timestream が適しています。

Timestream の料金

Timestream の料金は書き込み (取り込み)、ストレージ、クエリの 3 つで構成されます。以下は 2026 年 8 月時点 / 東京リージョンの単価です。書き込みはレコード件数ではなく取り込んだデータ量で課金され、1 GB あたり 0.625 USD です。各レコードは 1 KiB 単位に切り上げて計上されるため、1 レコードが小さいほど 1 KiB あたりの実効単価は割高になります。ストレージは 2 層で課金単位そのものが違います。メモリストアは保持しているデータ量と保持時間の積で課金され、1 GB 時 あたり 0.045 USD です。1 GB を 1 ヶ月置き続けると 730 時間換算で約 32.9 USD になります。マグネティックストアは 1 GB 月 あたり 0.0375 USD で、同じ 1 ヶ月あたりに揃えると 3 桁の開きがあります。この差が自動階層化の価値であり、メモリストアの保持期間設計がコストを左右する理由です。クエリは Timestream compute units (TCU) の稼働時間で課金され、1 TCU 時 あたり 0.648 USD です。1 TCU は 4 vCPU と 16 GB メモリに相当し、クエリの実行時間に応じて秒単位で計上されます (1 回のクエリの最小計上は 30 秒)。クエリを実行していない間は TCU の課金は発生せず、リージョンによってはプロビジョンド TCU を選んで上限を固定することもできます。スキャンしたデータ量に対する課金 (東京では 1 GB あたり 0.0125 USD) は旧世代の課金方式で、現在の既定は TCU 課金です。コストを抑える要点は 3 つあります。第 1 に、メモリストアの保持期間を直近データのクエリに必要な範囲まで短くし (例: 1 時間)、古いデータをマグネティックストアへ自動移行させること。第 2 に、クエリの時間範囲と measure_name を必ず絞り、TCU の稼働時間そのものを短くすること。第 3 に、ダッシュボードのように同じ集計を繰り返す用途ではスケジュールクエリで事前集計し、都度のクエリを軽くすることです。InfluxDB のセルフホストと比較すると、サーバー管理やバージョンアップに伴う運用コストを削減できます。

まとめ - Timestream の活用指針

Amazon Timestream は、時系列データに特化したサーバーレスデータベースです。自動階層化ストレージによるコスト最適化、SQL 互換の時系列クエリ、スケジュールクエリによる事前集計、Grafana との統合が主な強みです。IoT データの収集 / 分析、アプリケーションメトリクスの長期保存、DevOps の監視基盤として効果を発揮します。時系列データを DynamoDB や RDS に格納してコストやクエリ性能の問題を抱えている場合、Timestream への移行を検討する価値があります。