「ElasticsearchのReindexをするために試行錯誤して分かったこと」 50回 Elasticsearch勉強会

ElasticsearchのReindexをするために
試行錯誤して分かったこと
[email protected]第50回Elasticsearch勉強会　#elasticsearchjp
NewsPicks Engineer / 崔井源

View Slide

00 自己紹介
©NewsPicks Inc. All Rights Reserved.  
崔井源（ちぇじょんうぉん）
NewsPicks エンジニア
Data/Algorithm Unit で主に検索周りを担当中
● 検索データの整形・管理
● 検索失敗をモニタリング
● 検索の精度改善
● インフラの開発・メンテ
@jonlpstudy

View Slide

1. やりたかったこと
2. Elasticsearchの構成
3. Reindexとは
4. Reindexの実験
5. 実験でわかったこと
目次
00

View Slide

やりたかったこと
● 精度改善がしたい
○ クエリを改善する策は全て打ったのでanalyzerを改善したい
○ 例１）インデックス時に登録した同義語を変えたい・消したい
○ 例２）analyzerの定義を変えたい
● マネージド化がしたい（Amazon OpenSearch Service）
○ 仕様の問題で今のテンプレートは使えない
○ 例１）ユーザ辞書のファイル名をパッケージIDに変更する必要がある
● Reindexによる副作用はないか確認したい
○ 負荷はどれくらい高まるのか
○ Reindexの完了までどれくらいかかるのか
○ 本番ではどんな手順で行えばいいか
01

View Slide

Elasticsearchの構成
02
● Node：Elasticsearchが動作する各サーバ
● Cluster：複数のノードの束
● Shard：Lucene Indexとしてディスクに保存
○ Lucene Segmentファイルを定期的にマー
ジすることで作成される
○ ↑のRefresh処理をすることで検索可能な
データになる
● Primary Shard：格納されたデータ
● Replica Shard：データのコピー

View Slide

Reindexとは
03
インデックス
ドキュメント
[
{
“token”: “環境”,
“partOfSpeech”: “名詞-一般”,
},
{
“token”: “に”,
“partOfSpeech”: “助詞-格助詞-一般”,
},
{
“token”: “優しい”,
“partOfSpeech”: “形容詞-自立”,
},
...
]
インデックスを作り直すこと！
● analyzerで形態素解析の方法などを定義
● 定義を変えるなどして再分析してもらうにはインデッ
クスを作り直す必要がある
{
“title”: “環境に優しいオレンジジュース”,
“summary”: “近年、オレンジジュース産業が...”,
...
}

View Slide

Reindexの実験
この実験のゴール
04
● Reindex実行中の負荷がどれくらい高まるかを調べ、ユーザが検索するのに支障がないか
確認する
● 各インデックスをReindexして終わるまでかかる時間を確認する
● 実際本番でどのような手順で作業すればいいかを知り、考慮漏れがないようにする

View Slide

本番環境の検索データのコピー
● Snapshot / Restore機能を利用
する
○ S3のパスが同じであれば別
のClusterからレポジトリー
を作ってRestoreできる
○ Restore時に
e”include_global_state”:
truee オプションを付けるこ
とでインデックスのCluster
設定もコピーできる 
本番で運用しているCluster
環境と近い環境を構築
● 本番のReplica Shard数に合わせて
Nodeを構成する
○ Replica Shardを持たないか、
本番より少ない場合
eno_valid_shard_copye などの
エラーによりNode Failureにな
る可能性がある
○ EC2でサーバを立てているの
で、EC2 Discovery Pluginで
「EC2インスタンス1台 =
Node1台」にする
● インデックスのPrimary Shard /
Replica Shardの設定は
e_settingse から確認できる 
実験設定
● 同時にReindexするインデッ
クス数：1
● インデックスが持つドキュ
メント数：約1,500万件
○ Node1台あたり15GBを
占める
● Cluster数：1
● Node数：3
○ 1台のディスク容量
：40GB
○ SSDのGP2を使用
04 Reindexの実験
実験環境づくり

View Slide

04 Reindexの実験
● Primary Shard数：5
● Replica Shard数：2
実験結果
● CPU使用率はReindex実行直後急激に上がり、その後は90%程
度を維持
● ↑の状態で検索APIを連続で実行してもレスポンスが帰ってくる
までの時間に影響なし（0.5秒以下）
● Node1台あたり15GBを占めるインデックスで8時間がかかった
実験1) Templateを変更せずインデックスをそのまま
Reindexする
2分で全NodeのCPU使用率が92%
ずっとその状態を維持

View Slide

● Node1台のPrimary Shard数が多くなるにつれ遅くなるので、実験1)よりPrimary Shard数を少なくした
○ Primary Shard数：1
○ Replica Shard数：0
○ e(replica shard 数 + 1) * primary shard 数 = (0 + 1) * 1 = 1e になり、Shardは1つのみ
実験結果
● 実験1)よりReindexにかかる時間が3倍短縮できた
● Replica Shard数が本番より少ない場合、Node Failureが起きる
○ 実験に使ったインデックスはNode1台当たり15GBだが、40GBのNode1台に収まらない
実験2) Templateを修正しReplica Shardは持たさずReindexする
04 Reindexの実験
[2022-03-31T03:52:53,741][WARN ][o.e.c.r.a.AllocationService] [ip-{node_ip_address}] failing shard [failed
shard, shard [some_index][0], node[{node_id}], relocating [{id}], [P], recovery_source[peer recovery],
s[INITIALIZING], a[id={id} rId={id}], expected_shard_size[18148402752], message [shard failure, reason
[index]], failure [IOException[No space left on device]], markAsStale [true]]java.io.IOException: No space
left on device

View Slide

● データを書き込む空間が足りないと、インデックスは読み込みのみが可能になる
○ 空間確保後も ecluster_block_exceptione エラーになったら ecluster.blocks.read_onlye をnullにする
● Reindex失敗後のディスク容量は74%しか占めていなかった
○ Lucene Segmentファイルの統合に瞬間的にディスク容量を多めに使ってしまうのが原因
実験2) Templateを修正しReplica Shardは持たさずReindexする
04 Reindexの実験
{
"error": {
"root_cause": [
{
"type": "cluster_block_exception",
"reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
}
],
"type": "cluster_block_exception",
"reason": "blocked by: [FORBIDDEN/12/index read-only / allow delete (api)];"
},
"status": 403
}

View Slide

● 実験1)より高速化するためShard数を減らし、正常終了するようReplica Shardを持たせた
○ Primary Shard数：2
○ Replica Shard数：2
○ e(replica shard 数 + 1) * primary shard 数 = (2 + 1) * 2 = 6e になり、Shardは6つ
■ Node1台が2つのShardを持つ
実験結果
● 90%進んだ時点で実験2)と同様のエラーで異常終了した
● 保存すべき品詞の種類の数を増やしたことで、実験1)で使用したTemplateよりディスクをより占めるよう
になったと推測される
● 実験1)と違い、CPU使用率は60%で維持
● 異常終了まで3時間かかった
● Node1台のディスク容量を40GB→60GBにしたら、3時間で正常終了した
実験3) Templateを修正しReplica Shardを持たせReindexする
04 Reindexの実験

View Slide

● Node1台のShard数が増えるとReindexの速度は低下する
● Reindexする際は最初 CPU 使用率がぐっと上がり、終わるまでその状態がつづく
○ Node1台あたりのShard数が多くない場合は、Reindex中の CPU 使用率が60％程度に留まる
● Reindex中に既存インデックスに対して検索を連続で行っても、レスポンスは問題なくスピーディー
に返し、負荷もかからない
● Templateを変更してのReindexは場合によっては、ディスクを多く占めるので、e既存 index サイズ
* 3e のディスク容量を用意するのが安全である
05 実験でわかったこと
3つの実験からの気づき

View Slide

● Reindex中に既存インデックスに追加・更新・削除されるドキュメントの追い更新処理の方法を考え
る必要がある
○ もしリアルタイムで追加・更新・削除している場合は、それをしばらく止めてReindex後にでき
るようにする
● 問題が生じ、巻き戻す場合を考える
○ インデックスの更新を止め、スナップショットをとっておく
● ディスク容量的に問題ないか確認し、問題がある場合は解決策を考える
● Template を変える場合の諸事項を考慮する
● 更に高速化できる方法がないか考える
○ Refreshの頻度を下げるなど
○ Shardの構成を再考する
05 実験でわかったこと
Reindex時に発生する付随作業・気をつけること

View Slide

ご視聴ありがとうございました！
ブログ記事：https://tech.uzabase.com/entry/2022/04/18/193513

View Slide

「ElasticsearchのReindexをするために試行錯誤して分かったこと」 50回 Elasticsearch勉強会

「ElasticsearchのReindexをするために試行錯誤して分かったこと」 50回 Elasticsearch勉強会

Jungwon Choi

Other Decks in Technology

Featured

Transcript