Taste of Tech Topics

Taste of Tech Topics

Acroquest Technology株式会社のエンジニアが書く技術ブログ

ElasticsearchのShrink APIを検証した

こんにちは。
最近暖かくなってきて春を感じている新人エンジニアの片岡です。
elasticsearch運用時には、indexのライフサイクルマネジメントとして、
書き込みせずに参照だけになるindexに対してshard数の変更やforcemergerを実行してメンテナンスする必要ありますよね。
elasticsearchでは一般的な手順として次のような手順を実行します。

  1. shard数の削減
  2. 圧縮形式の変更
  3. merge処理を行いセグメントをまとめる

elasticsearchではデータを保持する際に裏で圧縮を行っています。
そこで、圧縮方法の違いやmerge処理によるサイズ変化への影響を検証してみました。

検証概要

次の検証を行いました。

1. 2.2GBのApacheログをelasticsearchに投入し、Primary Shardの数を5に設定した。
2. Shrink APIを使ってshard数を削減し、Primary Shard : 1にする。
 その際圧縮方法をLZ4→Best Compressionに変更する。
3. force mergeを実行する。

shard数を減らせるShrink APIを用いて、shard数を減らしたり、圧縮方法を変更したりしています。
データが圧縮されたかどうかはディスクサイズを確認して検証しました。

今回はelasticsearchを自分のPC一台で立ち上げています。
そのためReplicaは生成されないのでReplica数は0にして検証を行っています。

検証環境

OS X 10.1.3
elasticsearch 6.2.1

検証内容

初期状態

まずはデータを投入した段階のshardの状態をcat APIを使って見てみました。
元のデータサイズである2.2GBと比べると2倍以上の大きさになっていますが、
これはelasticsearchがデータを持つときのオーバーヘッドや、Logstashの加工による影響があるためです。

圧縮形式:LZ4

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb

Shrink API

初期状態からShrink APIをたたいてみました。

POST apache_log/_shrink/best_compression
{
    "settings": {
        "index.number_of_replicas": 0,
        "index.number_of_shards": 1, 
        "index.codec": "best_compression" 
    }
}

実行したときのレスポンス遅延はほとんどありませんでした。
shrinkのマニュアルにありますが、即応答を返して、非同期でshrink処理が実行されるからですね。

The above request returns immediately once the target index has been added to the cluster state — it doesn’t wait for the shrink operation to start.

www.elastic.co


結果は以下。
best compressionにしたらstore.sizeが大きくなってしまいました。
公式HPを見ると、

Best compression will only take affect when new writes are made to the index,
such as when force-merging the shard to a single segment.

とあります。圧縮方法の変更は新しく書き込まれたデータにしか適用されないなので
force merge等を利用する必要がありますね。

www.elastic.co

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb
green open best_compression UgRAepvGR1Or1Pl3MZLqOQ 1 0 10310474 0 6.8gb 6.8gb

Force merge

複数のセグメントを1つにまとめるmerge処理を強制的に行うAPIです。

POST best_compression/_forcemerge
{
    "max_num_segments":1
}

結果はこちら。

health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb
green open best_compression UgRAepvGR1Or1Pl3MZLqOQ 1 0 10310474 0 4.3gb 4.3gb

best compressionされました。
LZ4と比べて8%削減されましたね。

検証結果

以下のように検証を行いディスクサイズが変化しました。
f:id:acro-engineer:20180212171531p:plain

まとめ

ShrinkAPIを実行しただけでは圧縮が適用されないということ、
また、Shrink APIを実行すると、一度データサイズが大きくなることには注意が必要ですね。

Acroquest Technologyでは、キャリア採用を行っています。


  • ビッグデータHadoop/Spark、NoSQL)、データ分析(Elasticsearch、Python関連)、Web開発(SpringCloud/SpringBoot、AngularJS)といった最新のOSSを利用する開発プロジェクトに関わりたい。
  • マイクロサービスDevOpsなどの技術を使ったり、データ分析機械学習などのスキルを活かしたい。
  • 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
  • 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。

 
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。

データ分析基盤Elasticsearchを使い倒したいエンジニア募集! - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com