1. はじめに
Elastic Stackの比較的新しい機能として、TSDS (Time Series Data Stream) に対する Downsampling（ダウンサンプリング） がサポートされています。
これは、例えば「1秒ごとに収集された高頻度なメトリクス」を「1分ごと、あるいは1日ごとの統計値」へと自動的に集計・集約することで、データ量を劇的に削減し、長期保存データのクエリを高速化するための機能です。
今回は、この Downsampling 機能が実際にどのように動作し、どれほどの効果があるのかを検証してみました。
2. 検証環境
今回の検証は、以下の環境で行いました。
- Elastic Stack: v9.4.2 (Self-Managed, Trial License)
- 収集データ: Elastic を動作させている Windows ホストのパフォーマンスメトリクス（OpenTelemetry Collector経由）
3. Downsampling の設定方法
Downsampling の実行方法はいくつかありますが、今回は最も実用的な Index Lifecycle Management (ILM) のポリシー内に組み込む方法を採用しました。
- ILMポリシー名:
metric-otel-ilm-policy - フェーズ遷移:
- Hotフェーズ: データのインジェストと直近データの保持
- Coldフェーズ: 移行タイミングで Downsampling を実行
- Downsampling interval:
1 days（1日粒度に集約）
- Downsampling interval:
※参考画面
💡 ※注意: 今回の
1 daysという設定値は、検証結果（変化）をわかりやすく確認するための極端な設定です。本番環境での推奨値ではありません。
4. Downsampling の実行と容量削減効果
設定後、データがある程度蓄積され、インデックスが Rollover して Cold フェーズへ移行するのを待ちました。
Cold フェーズ移行前後のデータ量の変化は以下の通りです。
| ステータス | ドキュメント数 | インデックスサイズ |
|---|---|---|
| Rollover 直前 (Hotフェーズ) | 約 650,000 件 | 約 20 MB |
| Cold フェーズ移行後 (Downsampling 適用後) | 5,865 件 | 1.14 MB |
インデックスサイズが約20分の1、ドキュメント数にいたっては約110分の1にまで圧縮されており、期待通りの強力なデータ削減効果が確認できました。
（※注 メトリクスは24時間取得していたわけではありません。24時間取得し続けていたら、もっと大きな圧縮率になっていたと思われます。）
※Cold フェーズ移行後の参考画面
（※Rollover 直前のデータ量に関するスクリーンショットは取り損ねてしまいました。）
5. ES|QL（TSコマンド）によるデータ確認と注意点
Kibana の Discover から、ES|QL の TS コマンドを使用して、格納されたデータを集計してみます。
TS metrics-hostmetricsreceiver.otel-default*
| WHERE state == "free" or state == "used"
| STATS mem = AVG(metrics.system.memory.usage) BY TBUCKET(1h), state
| KEEP `TBUCKET(1h)`, mem, state
| SORT `TBUCKET(1h)` desc, state※参考画面
クエリ結果の考察
出力された結果（一部抜粋）を確認すると、Downsampling の仕様が顕著に現れた挙動を示していました。
| TBUCKET(1h) | mem | state | データの特徴 |
Jun 12, 2026 @ 11:00:00.000 | 11,889,684,480 | free | (*1) |
Jun 12, 2026 @ 11:00:00.000 | 21,892,382,720 | used | (*1) |
Jun 12, 2026 @ 10:00:00.000 | 11,387,027,456 | free | (*1) |
Jun 12, 2026 @ 10:00:00.000 | 22,395,039,744 | used | (*1) |
| … | … | … | … |
Jun 9, 2026 @ 09:00:00.000 | 12,531,630,920.205 | free | (*2) |
Jun 9, 2026 @ 09:00:00.000 | 21,250,436,279.795 | used | (*2) |
Jun 8, 2026 @ 09:00:00.000 | 14,159,069,970.101 | free | (*2) |
Jun 8, 2026 @ 09:00:00.000 | 19,622,997,229.899 | used | (*2) |
Jun 7, 2026 @ 09:00:00.000 | 7,128,812,202.667 | free | (*2) |
Jun 7, 2026 @ 09:00:00.000 | 26,653,254,997.333 | used | (*2) |
| … | … | … | … |
(*1) 直近データ（未圧縮）、1時間単位で取得可能
(*2) Downsampling 適用済み（1日1バケットのみ出力）
クエリでは TBUCKET(1h)（1時間ごと）の集計を要求しているにもかかわらず、Cold Tier に格納されている過去データ（Jun 9 以前）は「1日（24時間）に1データ」しか返ってきていません。
これは、Downsampling によってデータがすでに 1 days の粒度に丸められ、それより細かい時間軸のデータが消失しているためです（内部的に事前集計された代表値のみが残るため）。クエリ側でどれだけ細かいバケットを指定しても、保持されている最小粒度（今回は1日）でしか結果を得られないという特性がよくわかります。
検証用のデータのためクエリの速度向上までは測定できていませんが、集計対象のデータ量が劇的に少なくなっているため、理論上は従来よりも大幅な速度向上が見込めます。
6. まとめ
今回、Elastic TSDS の Downsampling 機能を検証し、以下のことが分かりました。
- 圧倒的なストレージ削減効果
- ドキュメント数やデータサイズを劇的に削減できるため、長期的なトレンド分析用のインデックスにおいて非常に有効です。
- データ粒度とのトレードオフ
- 今回の検証結果が示す通り、Downsampling を適用した期間のデータは、指定したインターバルより詳細な分析（例：瞬間的なスパイクの検知など）ができなくなります。
実運用においては、
- 直近のトラブルシューティング用に、Hot フェーズでは生データを数週間保持する。
- それ以降の長期的なキャパシティプランニング用に、Warm/Cold フェーズで1時間〜1日粒度へDownsampling する。
といった、要件に合わせたメリハリのあるILMポリシーの設計が重要になりそうです。
