Elasticsearch v8.17 GAの新機能LogsDBモードによるログ容量の削減度合いについて検証

# はじめに
v8.17でGAになったElasticsearchの[LogsDB](https://www.elastic.co/guide/en/elasticsearch/reference/current/logs-data-stream.html)モードについてのログ削減容量について検証してみました。

まず、LogsDBは以下のようなログ容量削減効果があるとされています。
* _logsdb index mode allows to reduce storage usage up to ~3 times compared to storing logs in Elasticsearch using the default index mode._ [引用元](https://www.elastic.co/guide/en/elasticsearch/reference/8.17/release-highlights.html)
* _In benchmarks, log data stored in a logs data stream used ~2.5 times less disk space than a regular data stream. The exact impact varies by data set._[引用元](https://www.elastic.co/guide/en/elasticsearch/reference/8.17/logs-data-stream.html)

~3倍（あるいは~2.5倍）のストレージ削減ということは、最も効果的なケースでログの容量が33.3%（あるいは40%)になるということだと思います。実際本当にこれくらい削減となるのかをrallyというElasticsearchの負荷テストツールを使って検証してみました。

その前にLogsDBの中身についてもう少し見ていきます。LogsDBは実は以下のような性能向上機能を有効化するモードとなっています。
* [Synthetic _source](https://www.elastic.co/guide/en/elasticsearch/reference/8.17/mapping-source-field.html#synthetic-source) <-- サブスクリプションがEnterpriseの場合のみ有効化される
* [Index sort](https://www.elastic.co/guide/en/elasticsearch/reference/current/logs-data-stream.html#logsdb-sort-settings)
* [ZSTD codec](https://www.elastic.co/guide/en/elasticsearch/reference/current/logs-data-stream.html#logsdb-specialized-codecs)

今回は記事の目的として実際のデータ削減量の確認に注力するため、これらの機能の解説やなぜログ容量削減になるのかという点についてはまた別の機会にしたいと思います。

# LogsDBの設定に関して

LogsDBモードはindex template上でのindex.mode設定（[doc](https://www.elastic.co/guide/en/elasticsearch/reference/8.17/index-modules.html)） を`logsdb`に設定することで利用可能です。これを設定すると上記で記した３つの機能がデフォルトで使われるようになるとされていますが、サブスクリプションがEnterpriseではない場合、Synthetic _sourceに関しては設定されません。これはIndexのsettingsを見て確認できます。

```: Enterpriseサブスクリプションがある場合
{
  "settings": {
    "index": {
      "mode": "logsdb",
      ...
      "mapping": {
        "source": {
          "mode": "SYNTHETIC"
        }
      }
      ...
```

```: Enterpriseサブスクリプションがない場合
{
  "settings": {
    "index": {
      "mode": "logsdb",
      ...
      "mapping": {
        "source": {
          "mode": "STORED"
        }
      }
      ...
```


Codecについては従来バージョンから存在する設定値`best_compression`で使われる方式がv8.15以前ではDEFLATEでしたが、v8.16以降はZSTDとなっていますので、これを知っていないと設定の見た目上では違いがわかりません。

https://www.elastic.co/guide/en/elasticsearch/reference/8.15/index-modules.html
_index.codec: The `default` value compresses stored data with LZ4 compression, but this can be set to `best_compression` which uses **DEFLATE** for a higher compression ratio, at the expense of slower stored fields performance. ...... Experiments with indexing log datasets have shown that best_compression gives up to **~18%** lower storage usage in the most ideal scenario compared to default while only minimally affecting indexing throughput (~2%)._

https://www.elastic.co/guide/en/elasticsearch/reference/8.16/index-modules.html
_index.codec: The `default` value compresses stored data with LZ4 compression, but this can be set to `best_compression` which uses **ZSTD** for a higher compression ratio, at the expense of slower stored fields read performance. ...... Experiments with indexing log datasets have shown that best_compression gives up to **~28%** lower storage usage and similar indexing throughput (sometimes a bit slower or faster depending on other used options) compared to default while affecting get by id latencies between ~10% and ~33%. The higher get by id latencies is not a concern for many use cases like logging or metrics, since these don’t really rely on get by id functionality (Get APIs or searching by _id).__

Index sortingに関しては、IndexのSettingsを確認すると以下のように表示され、一見index sortingが有効なのかわかりませんが、logsdbモードの場合は実質は[ここ](https://www.elastic.co/guide/en/elasticsearch/reference/current/logs-data-stream.html#logsdb-sort-settings)に書かれた通りの設定がデフォルトになり、index sortingが有効になっています。
```json:logsdbモード有効なときのIndex settingの表示（実際の有効値は表示されない）
    "index": {
      "sort": {
        "missing": [],
        "mode": [],
        "field": [],
        "order": []
      }, 
```

## 検証結果
3つのログタイプ(k8sアプリログ、システムログ、監査ログ）についての比較をまとめました。結果として、v8.17.2 LogsDBオン Enteprise Subscriptionは最も効果あるログタイプで従来のデータの32.7%のデータサイズになりました。減りが少ないケースで従来の56.0%のサイズになりました。Enteprise Subscriptionがない場合のLogsDBの場合は、最も効果ある場合で40.7%にまで減り、少ない場合は68.1%にまで減りました。
詳細データに興味ある場合は下の方に載せてあります。
（storage sizeはforce mergeでshardにつき1 segmentにした場合のサイズを使っています）

**k8sアプリケーションログの場合**
| テストNo. | 環境 | Index名 | docs count | storage size | storage size / docs count | 対8.15.5 データサイズ比 | 
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | 
|1| **v8.15.5**　(codec方式：DEFLATE) | .ds-logs-k8-application.log | 2,757,000 | 931.71 MB | 0.338 KB | 100% | 
|2| **v8.17.2 LogsDBオフ** (codec方式：ZSTD, Index sort無し, Synthetic _source無し） | .ds-logs-k8-application.log | 2,760,000 | 826.82 MB | 0.300 KB | 88.8 % | 
|3| **v8.17.2 LogsDBオン Enteprise Subscription以外の場合** (codec方式：ZSTD, Index sort有り, Synthetic _source無し） | .ds-logs-k8-application.log | 2,757,000 | 423.4 MB | 0.154 KB | 45.6% | 
|4| **v8.17.2 LogsDBオン Enteprise Subscriptionの場合** (codec方式：ZSTD, Index sort有り, Synthetic _source有り） | .ds-logs-k8-application.log | 2,760,000 | 366.95 MB | 0.132 KB | 39.1% |

**システムログの場合**
| テストNo. | 環境 | Index名 | docs count | storage size | storage size / docs count | 対8.15.5 データサイズ比 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|1| **v8.15.5**　(codec方式：DEFLATE) | .ds-logs-system.syslog | 420,000 | 97.52 MB | 0.232 KB | 100% |
|2| **v8.17.2 LogsDBオフ** (codec方式：ZSTD, Index sort無し, Synthetic _source無し） | .ds-logs-system.syslog | 420,000 | 89.08 MB | 0.212 KB | 91.4 % | 
|3| **v8.17.2 LogsDBオン Enteprise Subscription以外の場合** (codec方式：ZSTD, Index sort有り, Synthetic _source無し） | .ds-logs-system.syslog | 420,000 | 66.53 MB | 0.158 KB | 68.1% | 
|4| **v8.17.2 LogsDBオン Enteprise Subscriptionの場合** (codec方式：ZSTD, Index sort有り, Synthetic _source有り） | .ds-logs-system.syslog | 420,000 | 54.46 MB | 0.130 KB | 56.0% | 

**監査ログの場合**
| テストNo. | 環境 | Index名 | docs count | storage size | storage size / docs count | 対8.15.5 データサイズ比 |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- |
|1| **v8.15.5**　(codec方式：DEFLATE) | .ds-logs-system.auth | 60,000 | 23.85 MB | 0.398 KB | 100% |
|2| **v8.17.2 LogsDBオフ** (codec方式：ZSTD, Index sort無し, Synthetic _source無し） | .ds-logs-system.auth | 60,000 | 19.66 MB | 0.328 KB |  82.4% | 
|3| **v8.17.2 LogsDBオン Enteprise Subscription以外の場合** (codec方式：ZSTD, Index sort有り, Synthetic _source無し） | .ds-logs-system.auth | 60,000 | 9.72 MB | 0.162 KB | 40.7% | 
|4| **v8.17.2 LogsDBオン Enteprise Subscriptionの場合** (codec方式：ZSTD, Index sort有り, Synthetic _source有り） | .ds-logs-system.auth | 60,000 | 7.82 MB | 0.130 KB | 32.7% | 

**Ingest時のElasticsearchのCPU使用率の比較**
CPU使用率は特にSynthetic _sourceを使った場合に少し上がると思いましたが、結果としてはそんなに上がりませんでした。
| テストNo. | 環境 |Ingest時のCPU使用率 |
| ---- | ---- | ---- |
|1| **v8.15.5**　(codec方式：DEFLATE)  | 23~24%くらい |
|2| **v8.17.2 LogsDBオフ** (codec方式：ZSTD, Index sort無し, Synthetic _source無し） | 23~24%くらい |
|3| **v8.17.2 LogsDBオン Enteprise Subscription以外の場合** (codec方式：ZSTD, Index sort有り, Synthetic _source無し） | 24~25%くらい |
|4| **v8.17.2 LogsDBオン Enteprise Subscriptionの場合** (codec方式：ZSTD, Index sort有り, Synthetic _source有り）| 24~25%くらい |
* Ingest CPU使用率は2ノード中高い方のノード、チャートで見た値なのでおおよその値となります。

# まとめ
8.17.2のLogsDBモードは、無料のベーシックにおいても十分容量削減が可能で、さらにEnterpriseを使っていると最大限の削減効果を得られることが確認できました。このLogsDBを使うと従来比の半分のデータサイズ前後になることが確認できました。
これはとても大きな効果で、特にElasticのFrozen data tierを使うケースではデータが保存されるオブジェクトストレージ費用が半分くらいになることを意味し、会社全体のログを集中管理するようなケースだとTB~PB級の保管量になるため、コスト削減効果がひじょうn大きいです。

# Appendix: データの詳細　
## テスト1: v8.15.5 (codec方式：DEFLATE)

データ投入直後 (Force merge前)
![Pasted Graphic 86.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/86be60dd-b4ff-41ac-94f4-8c80f9098d63.png)

Force merge segment=1 実行後
![Pasted Graphic 87.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/f90d9851-8f04-43c6-9199-3392cd0e95f0.png)

Index時の性能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/8b353d99-8f01-477a-8ddf-91dc9c316f54.png)

ノード1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/a7220a27-2d94-4a5a-af25-61eec2935e98.png)

ノード2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/acfcb7ce-9d7a-4f69-9421-b65a479e3ec4.png)


## テスト2: v8.17.2 LogsDBオフ** (codec方式：ZSTD, Index sort無し, Synthetic _source無し）

データ投入直後 (Force merge前)
![Pasted Graphic 79.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/25ed8b78-7e88-4dba-8bba-c3f08780bc4f.png)

Force merge segment=1 実行後
![Pasted Graphic 80.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/9e34d4b8-de5b-43aa-8cb9-a90ca345bc3f.png)

Index時の性能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/03b36443-707a-427d-ba30-daf4b26f4a2e.png)

ノード1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/cf08c852-091d-45bc-ab56-cd68baa4b762.png)

ノード2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/3b35e2bd-9204-4c4a-beb5-d31c251ba00f.png)

## テスト3: v8.17.2 LogsDBオン Enteprise Subscription以外の場合** (codec方式：ZSTD, Index sort有り, Synthetic _source無し）

データ投入直後 (Force merge前)
![Pasted Graphic 88.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/1866082b-345d-45ca-b1e6-780474321f45.png)

Force merge segment=1 実行後
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/d545c806-4d0e-41f2-95dd-a3f04a604050.png)

Index時の性能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/3931e930-cc30-43cc-ab26-e992bfeed42d.png)

ノード1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/af70fd2e-5db9-4b92-a51e-cfa9dd452e3d.png)

ノード2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/9353f656-b5e3-4e6c-9464-8313f7615e74.png)

## テスト4: v8.17.2 LogsDBオン Enteprise Subscriptionの場合** (codec方式：ZSTD, Index sort有り, Synthetic _source有り）

データ投入直後 (Force merge前)
![Pasted Graphic 77.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/e72729aa-7bac-4e7e-bd82-204be338ae42.png)

Force merge segment=1 実行後
![Pasted Graphic 78.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/4d747268-67db-4153-87b1-c6d065504dd3.png)

Index時の性能
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/addbff04-0c09-41e2-9fbb-b7c53f98d70d.png)

ノード1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/cdbcfb6b-2445-49e9-8f32-99b1d0e52b42.png)

ノード2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/109197/617e9fcc-0bb1-477f-95a6-0389f8f22826.png)